[FFmpeg-devel] [PATCH 1/5] tests/fate-run: only support le format result on pixfmts

Michael Niedermayer michael at niedermayer.cc
Sun Jan 27 22:07:05 EET 2019


On Sun, Jan 27, 2019 at 11:24:46PM +0700, Muhammad Faiz wrote:
> On Sun, Jan 27, 2019 at 10:53 PM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> >
> > On Sun, Jan 27, 2019 at 04:36:15PM +0700, Muhammad Faiz wrote:
> > > regardless of the actual supported formats.
> > > This allows filters to support only native-endian formats,
> > > and also allows consistency checks between little-endian
> > > and big-endian implementation.
> > >
> > > This also reveals bugs on gbrap10, p010, p016 format, and
> > > super2xsai filter (mismatched checksums between little-endian
> > > and big-endian).
> > >
> > > Suggested-by: Hendrik Leppkes <h.leppkes at gmail.com>
> > > Signed-off-by: Muhammad Faiz <mfcc64 at gmail.com>
> > > ---
> > > Old thread is here: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195930.html
> > >
> > >  tests/fate-run.sh                        |   6 +-
> > >  tests/ref/fate/filter-pixfmts-copy       | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-crop       | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-field      | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-fieldorder |  88 +++++++++---------
> > >  tests/ref/fate/filter-pixfmts-hflip      | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-il         | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-null       | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-scale      | 112 +++++++++++------------
> > >  tests/ref/fate/filter-pixfmts-super2xsai |   8 +-
> > >  tests/ref/fate/filter-pixfmts-swapuv     |  56 ++++++------
> > >  tests/ref/fate/filter-pixfmts-transpose  |  90 +++++++++---------
> > >  tests/ref/fate/filter-pixfmts-vflip      | 112 +++++++++++------------
> > >  13 files changed, 573 insertions(+), 571 deletions(-)
> > >
> > > diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> > > index aece90a01d..faa4285e71 100755
> > > --- a/tests/fate-run.sh
> > > +++ b/tests/fate-run.sh
> > > @@ -297,8 +297,10 @@ pixfmts(){
> > >
> > >      outertest=$test
> > >      for pix_fmt in $pix_fmts; do
> > > -        test=$pix_fmt
> > > -        video_filter "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt -frames:v $nframes
> > > +        # force little endian format on result
> > > +        pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> > > +        test=$pix_fmt_le
> > > +        video_filter "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt_le -frames:v $nframes
> > >      done
> >
> > if the input to a filter is a big endian format and the output is little
> > endian. Then there really isnt a gurantee that the filter will work with
> > big endian data. The libavfilter core could convert before or after the filter
> > as it preferrs. At least thats how i remember it from the last time i looked
> > at the code.
> > This also makes sense, as there are very good reasons to convert before,
> > for example when doing so results in better quality or higher speed
> > or fewer converts overall in multi input or multi output filters...
> 
> Of course, this can be easily fixed by adding format=$pix_fmt after
> $filter=$filter_args.
> 

> >
> > So if the output is always forced to LE then this may unintentionally
> > remove testing a range of cases.
> > also this removes testing the codepath for big endian formats after the
> > convert. Or do we have remaining cases that test these ?
> 
> Do you suggest to duplicate test to output BE and LE simultaneously?

I dont really have a specific suggestion, just dont want to have some
codepathes be lost from testing
a solution that doesnt duplicate all the tests would be better i guess
as it would be quicker

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190127/4eca6249/attachment.sig>


More information about the ffmpeg-devel mailing list