PR #21093 opened by Jan Ekström (jeeb) URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21093 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21093.patch
After the full ffmpeg CLI multithreading changes went in, this test started depending on how far the input side read and decoded the input compared to how quickly the output encoded things, causing spurious failures on the CI. If the input gets further, subtitles' end points are more likely to be found out and thus their final form would be passed on to muxer as-is. On the other hand, if the input does not get that far, an intermediate split subtitle is output instead, with the duration ending at the point of a random access point packet that caused the state of the ongoing subtitle to be checked. To my knowledge all of the failures have so far been valid correct results, but unfortunately FATE's built in checks mostly consist of whether there is a difference against an exact result. In the case of this test, what would need to be checked is that the same subtitle is indeed shown from time A to time B, but it may be split into multiple parts (limited by size of GOPs output during the test, which is defined in it). Alternatively, this test could be fixed by making it possible to define how far the input is allowed to read and decode compared to the output. That is currently not something implemented in the project, either. All in all, I dislike lowering the test coverage of code, but this removal will at least make people less aggravated about a test spuriously failing. From eae5252368d3ce07a4fa54454b52ffcde6091beb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= <[email protected]> Date: Thu, 4 Dec 2025 01:37:08 +0200 Subject: [PATCH] fate/ffmpeg: remove test for fix_sub_duration_heartbeat After the full ffmpeg CLI multithreading changes went in, this test started depending on how far the input side read and decoded the input compared to how quickly the output encoded things, causing spurious failures on the CI. If the input gets further, subtitles' end points are more likely to be found out and thus their final form would be passed on to muxer as-is. On the other hand, if the input does not get that far, an intermediate split subtitle is output instead, with the duration ending at the point of a random access point packet that caused the state of the ongoing subtitle to be checked. To my knowledge all of the failures have so far been valid correct results, but unfortunately FATE's built in checks mostly consist of whether there is a difference against an exact result. In the case of this test, what would need to be checked is that the same subtitle is indeed shown from time A to time B, but it may be split into multiple parts (limited by size of GOPs output during the test, which is defined in it). Alternatively, this test could be fixed by making it possible to define how far the input is allowed to read and decode compared to the output. That is currently not something implemented in the project, either. All in all, I dislike lowering the test coverage of code, but this removal will at least make people less aggravated about a test spuriously failing. --- tests/fate/ffmpeg.mak | 15 -------- .../fate/ffmpeg-fix_sub_duration_heartbeat | 35 ------------------- 2 files changed, 50 deletions(-) delete mode 100644 tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index c0da2da7f8..7b96e662e6 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -119,21 +119,6 @@ fate-ffmpeg-fix_sub_duration: CMD = fmtstdout srt -fix_sub_duration \ -real_time 1 -f lavfi \ -i "movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]" -# Basic test for fix_sub_duration_heartbeat, which causes a buffered subtitle -# to be pushed out when a video keyframe is received from an encoder. -FATE_SAMPLES_FFMPEG-$(call FILTERDEMDECENCMUX, MOVIE, MPEGVIDEO, \ - MPEG2VIDEO, SUBRIP, SRT, LAVFI_INDEV \ - MPEGVIDEO_PARSER CCAPTION_DECODER \ - MPEG2VIDEO_ENCODER NULL_MUXER PIPE_PROTOCOL) \ - += fate-ffmpeg-fix_sub_duration_heartbeat -fate-ffmpeg-fix_sub_duration_heartbeat: CMD = fmtstdout srt -fix_sub_duration \ - -real_time 1 -f lavfi \ - -i "movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]" \ - -map 0:v -map 0:s -fix_sub_duration_heartbeat:v:0 \ - -c:v mpeg2video -b:v 2M -g 30 -sc_threshold 1000000000 \ - -c:s srt \ - -f null - - # FIXME: the integer AAC decoder does not produce the same output on all platforms # so until that is fixed we use the volume filter to silence the data FATE_SAMPLES_FFMPEG-$(call FRAMECRC, MATROSKA, H264 AAC_FIXED, PCM_S32LE_ENCODER VOLUME_FILTER ARESAMPLE_FILTER) += fate-ffmpeg-streamloop-transcode-av diff --git a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat b/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat deleted file mode 100644 index 1a946394e9..0000000000 --- a/tests/ref/fate/ffmpeg-fix_sub_duration_heartbeat +++ /dev/null @@ -1,35 +0,0 @@ -1 -00:00:00,968 --> 00:00:01,168 -<font face="Monospace">{\an7}(</font> - -2 -00:00:01,168 --> 00:00:01,368 -<font face="Monospace">{\an7}(<i> inaudibl</i></font> - -3 -00:00:01,368 --> 00:00:01,568 -<font face="Monospace">{\an7}(<i> inaudible radio chat</i></font> - -4 -00:00:01,568 --> 00:00:02,002 -<font face="Monospace">{\an7}(<i> inaudible radio chatter</i> )</font> - -5 -00:00:02,002 --> 00:00:03,103 -<font face="Monospace">{\an7}(<i> inaudible radio chatter</i> )</font> - -6 -00:00:03,103 --> 00:00:03,303 -<font face="Monospace">{\an7}(<i> inaudible radio chatter</i> ) ->></font> - -7 -00:00:03,303 --> 00:00:03,503 -<font face="Monospace">{\an7}(<i> inaudible radio chatter</i> ) ->> Safety rema</font> - -8 -00:00:03,504 --> 00:00:03,704 -<font face="Monospace">{\an7}(<i> inaudible radio chatter</i> ) ->> Safety remains our numb</font> - -- 2.49.1 _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
