avcodec: truehd parser drops data but does not adjust initial timestamps

[jeeb]

Summary of the bug:

1. The TrueHD parser does drop data received until sync with first random access point packet is received.
2. The parser framework seems to be oblivious to this, and sticks the first received buffer's dts/pts on the received data.

How to reproduce:

The bug is easily reproducible with a Matroska sample that starts with non-random access point TrueHD packets, as the demuxer itself requests parsing for TrueHD and MLP. This can be reproduced by just utilizing the parsing API by itself as well with av_parser_parse2, as this is how I noticed the issue originally.

% ffprobe -of json -show_packets -show_frames -i http://www.cccp-project.net/beta/test_files/mzero_truehd_sample.mkv

{
    "packets_and_frames": [
        {
            "type": "packet",
            "codec_type": "audio",
            "stream_index": 1,
            "pts": 0,
            "pts_time": "0.000000",
            "dts": 0,
            "dts_time": "0.000000",
            "size": "324",
            "pos": "501277",
            "flags": "K_"
        },
        {
            "type": "frame",
            "media_type": "audio",
            "stream_index": 1,
            "key_frame": 1,
            "pts": 0,
            "pts_time": "0.000000",
            "pkt_dts": 0,
            "pkt_dts_time": "0.000000",
            "best_effort_timestamp": 0,
            "best_effort_timestamp_time": "0.000000",
            "pkt_pos": "501277",
            "pkt_size": "324",
            "sample_fmt": "s32",
            "nb_samples": 40,
            "channels": 6,
            "channel_layout": "5.1(side)",
            "side_data_list": [
                {
                    "side_data_type": "AVMatrixEncoding"
                }
            ]
        },
        {
            "type": "packet",
            "codec_type": "audio",
            "stream_index": 1,
            "pts": 93,
            "pts_time": "0.093000",
            "dts": 93,
            "dts_time": "0.093000",
            "size": "132",
            "pos": "559062",
            "flags": "__"
        },
        {
            "type": "frame",
            "media_type": "audio",
            "stream_index": 1,
            "key_frame": 1,
            "pts": 93,
            "pts_time": "0.093000",
            "pkt_dts": 93,
            "pkt_dts_time": "0.093000",
            "best_effort_timestamp": 93,
            "best_effort_timestamp_time": "0.093000",
            "pkt_pos": "559062",
            "pkt_size": "132",
            "sample_fmt": "s32",
            "nb_samples": 40,
            "channels": 6,
            "channel_layout": "5.1(side)",
            "side_data_list": [
                {
                    "side_data_type": "AVMatrixEncoding"
                }
            ]
        }
    ]
}

The first received packet (324 bytes, random access point) came from a Matroska SimpleBlock with the pts=0.092. Yet since most likely the parser framework didn't get notified that the input got dropped until then, you will get the timestamps of when the feeding started.

The following buffers will get the right timestamps, as seen by the pts=0.093.

I did start looking into this, but unfortunately was not able to focus on it, and decided to file this issue so that it is known by others than just me.

[Balling]

Should not TrueHD always start with 2 major syncs? Why there is some garbage behind the sync? This is supposed to be lossless, LOL.

Also, are we going to discuss start/end priming of EAC3 here? We can.

BTW, this was discovered here. ​https://github.com/mpv-player/mpv/pull/8967

[Elon Musk]

It is not parser job to readjust timestamps in any way.

[Balling]

I would say such a file is invalid, since TrueHD has keyframes, but it rather recently added the ability to see it has key frames (and not tag all of them as non-key frames), not to mention that only recently ffmpeg started writing key frames in mp4 for truehd encoder. See: 8ddbc26dedcf83962dd3aed90a6bb0a95847d386

File is here now: ​https://web.archive.org/web/20240000000000*/www.cccp-project.net/beta/test_files/mzero_truehd_sample.mkv

[Balling]

pos 501277 is not the keyframe for this track of TrueHD, so this is just a bug, I imagine.

For those that do not get it, this timestamp should be 0.092, not 0, coming from that adler-32 block with checksum 0xf3858bc9 and timestamp 0.092, not to mention that position in file is not 501277, but 558728, it is literally first key frame mkv and tagged as such.

        {
            "type": "packet",
            "codec_type": "audio",
            "stream_index": 1,
            "pts": 0,
            "pts_time": "0.000000",
            "dts": 0,
            "dts_time": "0.000000",
            "size": "324",
            "pos": "501277",
            "flags": "K__"
        },
        {
            "type": "frame",
            "media_type": "audio",
            "stream_index": 1,
            "key_frame": 1,
            "pts": 0,
            "pts_time": "0.000000",
            "pkt_dts": 0,
            "pkt_dts_time": "0.000000",
            "best_effort_timestamp": 0,
            "best_effort_timestamp_time": "0.000000",
            "pkt_pos": "501277",
            "pkt_size": "324",
            "sample_fmt": "s32",
            "nb_samples": 40,
            "channels": 6,
            "channel_layout": "5.1(side)"
        },