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

[Andreas Rheinhardt <andreas.rheinhardt@outlook.com>]

Jan Ekström:
> On Sun, Aug 20, 2023 at 4:12 PM Michael Niedermayer
> <michael@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@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.
> 

Actually, x264 allows to select only eight or ten bit bitdepth (or both)
at configure-time. IIRC opening the encoder will fail if an eight-bit
only libx264 is used when one tries to use a 10bit pixel format.
(This is actually a regression since x264 version 153; with older
versions the codec's advertised pixel formats actually match the really
supported pixel formats.)

> 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?
> 

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".