[FFmpeg-devel] [PATCH v2] tests/fate/vcodec: Limit mem alignment for vsynth..mpeg2-422 tests

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, May 30, 2022 12:24 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] tests/fate/vcodec: Limit mem
> alignment for vsynth..mpeg2-422 tests
> 
> Quoting Soft Works (2022-05-30 10:08:11)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, May 30, 2022 9:35 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v2] tests/fate/vcodec: Limit
> mem
> > > alignment for vsynth..mpeg2-422 tests
> > >
> > > Quoting Soft Works (2022-05-28 15:17:54)
> > > > Do you have a better idea?
> > > >
> > > > The one advantage of this method is that you don’t need to
> change
> > > compilation parameters
> > > > nor  any source code. It’s only a runtime flag being set only
> for
> > > this specific family of tests.
> > >
> > > At the very least, I would expect the commit message to explain
> what
> > > exactly the problem is, and why is it fixed in this seemingly ad-
> hoc
> > > manner.
> > >
> > > "limit mem alignment to fix failing tests" explains nothing.
> >
> >
> > There was a longer conversation ("FATE Errors") with a number of
> > people, I'm not sure whether you followed.
> 
> I saw the thread, I did not read it in enough detail to understand
> the
> cause of the errors.
> 
> > I submitted this as a possible way to work around the issue. If you
> > find that patch acceptable, then I'll gladly adjust the commit
> message
> > with a detailed explanation.
> > It's just that I learned that it's not very effective to spend a
> lot
> > of time on things that are likely to get rejected or ignored.


> > Well, the test .mak files are full of hacks then, with the many
> super-
> > special flags in place that do not reflect any real world use at
> all.
> 
> There are AFAIK zero tests that override cpuflags.
I meant other flags, but well, that's not getting us anywhere..


> From a first glance, this looks very ad-hoc (i.e. a hack). But ugly
> hacks may sometimes be temporarily acceptable if a proper solution
> requires too much work and the problem needs to be fixed ASAP.

Yes, that's how I see the situation.


> So whether the patch is acceptable or not really depends on what the
> problem is and why are you fixing it in this specific way.


From what I gathered from James' and Paul's responses, there is no
easy fix for this.

Personally, I am not familiar with the code nor do I have the capacity
to resolve the issue at its core.

> Most of the code is supposed to be arch-independent. A test producing
> different results on different architectures should be considered a
> bug.

Yes, I fully agree to that. But those FATE tests have already fulfilled
their duty: 

	the problem is now a known problem

It can be put on a list, a trac entry can be made and somebody can 
work on a fix for it at some time.

It just doesn't make sense to keep those tests failing up until that
point in time. Being unable to get clean FATE runs locally is 
affecting productivity.

When you or one of the others in this conversation would be affected,
I wonder whether such discussion about a trivial issue would have
been necessary.

(trivial: the tests should not fail; probably non-trivial: the 
actual fix)

Thanks,
softworkz