[FFmpeg-trac] #9428(avcodec:new): avcodec: truehd parser drops data but does not adjust initial timestamps

[FFmpeg]

#9428: avcodec: truehd parser drops data but does not adjust initial timestamps
---------------------------------+--------------------------------------
             Reporter:  jeeb     |                     Type:  defect
               Status:  new      |                 Priority:  normal
            Component:  avcodec  |                  Version:  git-master
             Keywords:           |               Blocked By:
             Blocking:           |  Reproduced by developer:  0
Analyzed by developer:  0        |
---------------------------------+--------------------------------------
 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.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9428>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker