| Message ID | tencent_A5D539A7033898162D4D0B20484DA2CF9A07@qq.com |
|---|---|
| State | Accepted |
| Commit | edb1f1bc09c7dd89d35da670d8b1f4366003df59 |
| Headers | show |
| Series | [FFmpeg-devel] tests: Remove fate-libx265-hdr10 | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
Quoting Zhao Zhili (2024-03-22 13:43:43) > From: Zhao Zhili <zhilizhao@tencent.com> > > The test depends on the compile option of x265. It failed when > HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled > because of memory issue inside of x265, which I don't think can > be fixed within FFmpeg. I suggested some time ago we should mark x265 as experimental. It didn't receive much enthusiasm, and some probably considered it a joke, but I was mostly serious. It has major memory safety issues that have been ignored for years.
On Fri, Mar 22, 2024 at 10:18 PM Anton Khirnov <anton@khirnov.net> wrote: > > Quoting Zhao Zhili (2024-03-22 13:43:43) > > From: Zhao Zhili <zhilizhao@tencent.com> > > > > The test depends on the compile option of x265. It failed when > > HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled > > because of memory issue inside of x265, which I don't think can > > be fixed within FFmpeg. > > I suggested some time ago we should mark x265 as experimental. It didn't > receive much enthusiasm, and some probably considered it a joke, but I > was mostly serious. It has major memory safety issues that have been > ignored for years. > Yea, I recall when I was testing my patch set with valgrind about half a year ago, some of the memory issues showed up there as well. The problem being that most users are happily oblivious to these issues as long as the piece of software "seems to work". Which is a line that x265 does cross. Thus at least on my side the reason for not much enthusiasm for marking it experimental at this point came from it being on the output side (and thus not handling random input/being a parser) as well as it most likely receiving much less understanding from users than just complaints about command lines which had worked for ages suddenly breaking. Jan
Ping. Is it OK to apply the patch as it is? > On Mar 23, 2024, at 06:36, Jan Ekström <jeebjp@gmail.com> wrote: > > On Fri, Mar 22, 2024 at 10:18 PM Anton Khirnov <anton@khirnov.net> wrote: >> >> Quoting Zhao Zhili (2024-03-22 13:43:43) >>> From: Zhao Zhili <zhilizhao@tencent.com> >>> >>> The test depends on the compile option of x265. It failed when >>> HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled >>> because of memory issue inside of x265, which I don't think can >>> be fixed within FFmpeg. >> >> I suggested some time ago we should mark x265 as experimental. It didn't >> receive much enthusiasm, and some probably considered it a joke, but I >> was mostly serious. It has major memory safety issues that have been >> ignored for years. >> > > Yea, I recall when I was testing my patch set with valgrind about half > a year ago, some of the memory issues showed up there as well. The > problem being that most users are happily oblivious to these issues as > long as the piece of software "seems to work". Which is a line that > x265 does cross. > > Thus at least on my side the reason for not much enthusiasm for > marking it experimental at this point came from it being on the output > side (and thus not handling random input/being a parser) as well as it > most likely receiving much less understanding from users than just > complaints about command lines which had worked for ages suddenly > breaking. > > 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-request@ffmpeg.org with subject "unsubscribe".
Quoting Zhao Zhili (2024-03-26 03:30:21)
> Ping. Is it OK to apply the patch as it is?
Fine with me.
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak index 30021efbcd..4095a4b51a 100644 --- a/tests/fate/enc_external.mak +++ b/tests/fate/enc_external.mak @@ -12,10 +12,5 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 HEVC, MOV, LIBX264_HDR10 HEVC_DEMUXER H fate-libx264-hdr10: CMD = enc_external $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \ mp4 "-c:v libx264" "-show_frames -show_entries frame=side_data_list -of flat" -# test for x265 MDCV and CLL passthrough during encoding -FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX265 HEVC, MOV, HEVC_DEMUXER) += fate-libx265-hdr10 -fate-libx265-hdr10: CMD = enc_external $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \ - mp4 "-c:v libx265" "-show_frames -show_entries frame=side_data_list -of flat" - FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_ENC_EXTERNAL-yes) fate-enc-external: $(FATE_ENC_EXTERNAL-yes) diff --git a/tests/ref/fate/libx265-hdr10 b/tests/ref/fate/libx265-hdr10 deleted file mode 100644 index 571c837cac..0000000000 --- a/tests/ref/fate/libx265-hdr10 +++ /dev/null @@ -1,16 +0,0 @@ -frames.frame.0.side_data_list.side_data.0.side_data_type="H.26[45] User Data Unregistered SEI message" -frames.frame.0.side_data_list.side_data.1.side_data_type="H.26[45] User Data Unregistered SEI message" -frames.frame.0.side_data_list.side_data.2.side_data_type="Mastering display metadata" -frames.frame.0.side_data_list.side_data.2.red_x="13250/50000" -frames.frame.0.side_data_list.side_data.2.red_y="34500/50000" -frames.frame.0.side_data_list.side_data.2.green_x="7500/50000" -frames.frame.0.side_data_list.side_data.2.green_y="3000/50000" -frames.frame.0.side_data_list.side_data.2.blue_x="34000/50000" -frames.frame.0.side_data_list.side_data.2.blue_y="16000/50000" -frames.frame.0.side_data_list.side_data.2.white_point_x="15635/50000" -frames.frame.0.side_data_list.side_data.2.white_point_y="16450/50000" -frames.frame.0.side_data_list.side_data.2.min_luminance="50/10000" -frames.frame.0.side_data_list.side_data.2.max_luminance="10000000/10000" -frames.frame.0.side_data_list.side_data.3.side_data_type="Content light level metadata" -frames.frame.0.side_data_list.side_data.3.max_content=1000 -frames.frame.0.side_data_list.side_data.3.max_average=200
From: Zhao Zhili <zhilizhao@tencent.com> The test depends on the compile option of x265. It failed when HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled because of memory issue inside of x265, which I don't think can be fixed within FFmpeg. --- tests/fate/enc_external.mak | 5 ----- tests/ref/fate/libx265-hdr10 | 16 ---------------- 2 files changed, 21 deletions(-) delete mode 100644 tests/ref/fate/libx265-hdr10