Opened 17 months ago

Last modified 12 months ago

#9428 new defect

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

Reported by: jeeb Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Change History (2)

comment:1 by Balling, 17 months ago

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

Last edited 17 months ago by Balling (previous) (diff)

comment:2 by Elon Musk, 12 months ago

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

Note: See TracTickets for help on using tickets.