[FFmpeg-devel] [PATCH 27/31] fate/matroska: Add test for avoiding negative timestamps

[Andreas Rheinhardt]

Andreas Rheinhardt:
> This tests the issue from tickets #4536, #5784;
> the output of this test is currently broken.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> ---
>  tests/fate/matroska.mak                   | 15 +++++++
>  tests/ref/fate/matroska-avoid-negative-ts | 55 +++++++++++++++++++++++
>  2 files changed, 70 insertions(+)
>  create mode 100644 tests/ref/fate/matroska-avoid-negative-ts
> 
> diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak
> index 2fcac34d62..3bc35d0f4c 100644
> --- a/tests/fate/matroska.mak
> +++ b/tests/fate/matroska.mak
> @@ -90,6 +90,21 @@ FATE_MATROSKA_FFMPEG_FFPROBE-$(call ALLYES, FILE_PROTOCOL MOV_DEMUXER       \
>                                 += fate-matroska-dovi-write-config7
>  fate-matroska-dovi-write-config7: CMD = transcode mov $(TARGET_SAMPLES)/mov/dovi-p7.mp4 matroska "-map 0 -c copy -cues_to_front yes -reserve_index_space 40  -metadata_header_padding 64339" "-map 0 -c copy" "" "-show_entries stream_side_data_list"
>  
> +# This tests the scenario like tickets #4536, #5784 where
> +# the first packet (with the overall lowest dts) is a video packet,
> +# whereas an audio packet to be muxed later has the overall lowest pts
> +# which happens to be negative and therefore needs to be shifted.
> +# This is currently buggy (the timestamps of the video frames muxed
> +# before the first audio frame are not shifted).
> +# Also tests muxing DOVI.
> +FATE_MATROSKA_FFMPEG_FFPROBE-$(call ALLYES, FILE_PROTOCOL MOV_DEMUXER        \
> +                                            AAC_FIXED_DECODER HEVC_DECODER   \
> +                                            AC3_FIXED_ENCODER MATROSKA_MUXER \
> +                                            MATROSKA_DEMUXER FRAMECRC_MUXER  \
> +                                            PIPE_PROTOCOL) \
> +                               += fate-matroska-avoid-negative-ts
> +fate-matroska-avoid-negative-ts: CMD = transcode "mov -c:a aac_fixed" $(TARGET_SAMPLES)/hevc/dv84.mov matroska "-map 0:v -map 0:a -c:v copy -c:a ac3_fixed" "-c copy -t 0.4" "" "-show_entries stream_side_data_list"
> +
>  # This tests writing the MS-compatibility modes V_MS/VFW/FOURCC and A_MS/ACM.
>  # It furthermore tests writing the Cues at the front if the cues_to_front
>  # option is set and more than enough space has been reserved in advance.
> diff --git a/tests/ref/fate/matroska-avoid-negative-ts b/tests/ref/fate/matroska-avoid-negative-ts
> new file mode 100644
> index 0000000000..9c23f4721c
> --- /dev/null
> +++ b/tests/ref/fate/matroska-avoid-negative-ts
> @@ -0,0 +1,55 @@
> +6048ff1b45660eb544c1f0db450afff5 *tests/data/fate/matroska-avoid-negative-ts.matroska
> +3618353 tests/data/fate/matroska-avoid-negative-ts.matroska
> +#extradata 0:      551, 0xa18acf66
> +#tb 0: 1/1000
> +#media_type 0: video
> +#codec_id 0: hevc
> +#dimensions 0: 1920x1080
> +#sar 0: 0/1
> +#tb 1: 1/1000
> +#media_type 1: audio
> +#codec_id 1: ac3
> +#sample_rate 1: 44100
> +#channel_layout 1: 3
> +#channel_layout_name 1: stereo
> +0,        -67,          0,       33,    63375, 0xc76606ab, S=1,        8
> +0,        -34,        133,       33,    46706, 0x0e08a7e5, F=0x0
> +0,          0,         73,       33,    29766, 0x753c031a, F=0x0
> +1,          0,          0,       34,      834, 0x7e7776bd
> +1,         35,         35,       34,      836, 0x14a3a0ff
> +0,         39,         39,       33,    19409, 0x4b948b6c, F=0x0
> +1,         70,         70,       34,      836, 0xf55e9a61
> +0,         73,        106,       33,    21086, 0x1b9412ce, F=0x0
> +1,        105,        105,       34,      836, 0x415591f1
> +0,        106,        273,       33,    62043, 0xc2356b56, F=0x0
> +0,        133,        206,       33,    36175, 0x0a7df38c, F=0x0
> +1,        140,        140,       34,      836, 0xe26c9bad
> +0,        173,        173,       33,    16028, 0xa57fcbe9, F=0x0
> +1,        174,        174,       34,      836, 0xbc8c9b66
> +0,        206,        239,       33,    15428, 0x9a91f357, F=0x0
> +1,        209,        209,       34,      836, 0xddeb9643
> +0,        239,        406,       33,    66072, 0xa542b6d7, F=0x0
> +1,        244,        244,       34,      836, 0x08a494eb
> +0,        273,        339,       33,    34985, 0xbfd8ff45, F=0x0
> +1,        279,        279,       34,      836, 0x94f09bb4
> +0,        306,        306,       33,    16036, 0xfc39c6ea, F=0x0
> +1,        314,        314,       34,      836, 0xd6358a3a
> +0,        339,        373,       33,    19893, 0x7e746f4e, F=0x0
> +1,        348,        348,       34,      836, 0x76ac91f1
> +0,        373,        539,       33,    77576, 0xeba2e5c8, F=0x0
> +1,        383,        383,       34,      836, 0xb32a86ac
> +[STREAM]
> +[SIDE_DATA]
> +side_data_type=DOVI configuration record
> +dv_version_major=1
> +dv_version_minor=0
> +dv_profile=8
> +dv_level=4
> +rpu_present_flag=1
> +el_present_flag=0
> +bl_present_flag=1
> +dv_bl_signal_compatibility_id=4
> +[/SIDE_DATA]
> +[/STREAM]
> +[STREAM]
> +[/STREAM]
> 

Seems like this test fails on PPC64 despite only using the fixed-point
version of the AAC decoder and the AC-3 encoder (with no format
conversion in-between); given that these codecs are used in other tests
using hash I entertained the hope that it would be otherwise. Will
reconsider.

- Andreas