[FFmpeg-devel] [PATCH v2 3/3] avformat/mxfdec: Read Apple private Content Light Level from MXF

[Tomas Härdin]

tor 2020-10-01 klockan 22:13 +0200 skrev Michael Niedermayer:
> On Thu, Oct 01, 2020 at 03:29:19PM +0100, Harry Mallon wrote:
> > > On 30 Sep 2020, at 08:32, Michael Niedermayer <michael at niedermayer.cc> wrote:
> > > 
> > > fails on big endian
> > > 
> > > --- src/tests/ref/fate/mxf-probe-applehdr10	2020-09-28 23:21:12.291897976 +0200
> > > +++ tests/data/fate/mxf-probe-applehdr10	2020-09-30 09:31:38.614653806 +0200
> > > @@ -14,7 +14,7 @@
> > > has_b_frames=0
> > > sample_aspect_ratio=1:1
> > > display_aspect_ratio=16:9
> > > -pix_fmt=yuv422p10le
> > > +pix_fmt=yuv422p10be
> > > level=-99
> > > color_range=tv
> > > color_space=bt2020nc
> > > Test mxf-probe-applehdr10 failed. Look at tests/data/fate/mxf-probe-applehdr10.err for details.
> > > src/tests/Makefile:255: recipe for target 'fate-mxf-probe-applehdr10' failed
> > > make: *** [fate-mxf-probe-applehdr10] Error 1
> > 
> > It seems fair that the pixel type is in native endian.
> 
> maybe but the endianness of the decoder output doesnt belong in the
> comparission
> 
> 
> > I'm not really familiar enough with FATE to provide a patch to fix this though. Do any other FATE tests have wildcards or two versions for big and little endian?
> 
> i dont see another probe reference file that contains a le/be format
> 
> we had le/be issues in other places though where they where fixed by forcing
> a format with specific endianness in the test IIRC

How about something like this?

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fate-mxf-probe-applehdr10-Ignore-endianness.patch
Type: text/x-patch
Size: 1536 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20201005/8994dc17/attachment.bin>