[FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV

[Jan Ekström]

On Sun, Aug 20, 2023 at 4:12 PM Michael Niedermayer
<michael at niedermayer.cc> wrote:
>
> On Sun, Aug 20, 2023 at 01:25:27AM +0300, Jan Ekström wrote:
> > On Sat, Aug 19, 2023 at 7:53 PM Michael Niedermayer
> > <michael at niedermayer.cc> wrote:
> > >
> > > On Fri, Aug 18, 2023 at 12:48:49AM +0300, Jan Ekström wrote:
> > > > Both of these two structures were first available with X264_BUILD
> > > > 163, so make relevant functionality conditional on the version
> > > > being at least such.
> > > >
> > > > Keep handle_side_data available in all cases as this way X264_init
> > > > does not require additional version based conditions within it.
> > > >
> > > > Finally, add a FATE test which verifies that pass-through of the
> > > > MDCV/CLL side data is working during encoding.
> > > > ---
> > > >  libavcodec/libx264.c         | 79 ++++++++++++++++++++++++++++++++++++
> > > >  tests/fate/enc_external.mak  |  5 +++
> > > >  tests/ref/fate/libx264-hdr10 | 15 +++++++
> > > >  3 files changed, 99 insertions(+)
> > > >  create mode 100644 tests/ref/fate/libx264-hdr10
> > >
> > > fate fails with X264_BUILD 152
> > >
> > > The filters 'Parsed_null_0' and 'format' do not have a common format and automatic conversion is disabled.
> > > [vf#0:0 @ 0x55eddf8d4780] Error reinitializing filters!
> > > Failed to inject frame into filter network: Invalid argument
> > > Error while filtering: Invalid argument
> > > [out#0/mp4 @ 0x55eddf87b980] Nothing was written into output file, because at least one of its streams received no packets.
> > > frame=    0 fps=0.0 q=0.0 Lsize=       0kB time=N/A bitrate=N/A speed=N/A
> > > Conversion failed!
> > > threads=1
> > > tests/Makefile:307: recipe for target 'fate-libx264-hdr10' failed
> > > make: *** [fate-libx264-hdr10] Error 234
> > >
> >
> > Without having more information, that sounds more like a 8bit only
> > build rather than an X264_BUILD related issue, as the error seems to
> > come from a conversion from the input 10bit content to whatever not
> > being available.
> >
> > Can you check if that is the case?
>
> x264 152 was either 8bit or 10bit but not both. That box on which this
> fails has x264 builds for both for 8bit and 10bit.
> ffmpeg can at runtime be linked with either
> for example
> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/x264-10bit/libx264.so.152 ./ffmpeg -i ~/videos/mm-short.mpg  test.mkv
> produces a 10bit output
>
> maybe you should just disable this test for 152 and prior to avoid this complexity
>
> thx

Yup, before Vittorio allowed for both bit depths to be included that
indeed was the case, just didn't recall it was at X264_BUILD >= 153
where the work was done.

As for skipping, I was seemingly tired and focused more on the exact
error than the overall case. Indeed, >= 163 is required for the test
to pass, so some sort of disablement for older versions is required.

Is the simplest way to add a configure check for this, or can the
define be utilized in some manner from the test's Makefile?

Jan