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.