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. 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 _______________________________________________ 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".
