Jan Ekström: > On Sun, Aug 20, 2023 at 4:12 PM Michael Niedermayer > <mich...@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 >>> <mich...@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-requ...@ffmpeg.org with subject "unsubscribe".
