[FFmpeg-devel] [PATCH 12/18] avformat/hls: parse ID3 timestamps for elementary audio streams

[Anssi Hannula]

31.12.2013 09:15, Michael Niedermayer kirjoitti:
> On Tue, Dec 31, 2013 at 08:20:19AM +0200, Anssi Hannula wrote:
>> I seem to now be hitting "first_dts 895690 not matching first dts 920758
>> (pts 920758, duration 2089) in the queue" for every packet after the
>> first one (only the first one has actual dts), though...
>>
>> I have to quit debugging now for a while, but if you know off-hand what
>> I'm doing wrong (if anything - just noticed it is only AV_LOG_DEBUG) it
>> would save me some time :)
> 
> if the timestamps you get are correct then you can probably ignore it
> this message can get printed when nothing is really wrong ...
> 
>>
>> I have AVSTREAM_PARSE_FULL and I set pkt->dts for first pkt, and later
>> ones have AV_NOPTS_VALUE (the interspersed timestamps aren't yet handled).


Since there are several hundred non-timestamped packets between the
timestamped packets, the fact that compute_pkt_fields() rounds the
computed frame duration down (utils.c line ~1096) will cause the packet
timestamps to fall behind of the actual time (approx. ~5ms for 48kHz @
1024 samples/pkt with 10sec segments, since the pkt duration can't be
expressed exactly in MPEG timebase), so there will be a corresponding
jump in timestamps the next time a timestamped packet is output.

(this didn't happen with my original patch since I kept the offset
between last timestamp and current packet around in the audio timebase,
not MPEG timebase, converting the full offset each time so that rounding
error did not accumulate)

What should we do? Probably these are the reasonable options, unless you
think of something else:
a) Not care.
b) Add some artificial left-shift to all the timestamps in
   hls_id3_audio demuxer so that the rounding error will be negligible.
c) Make compute_pkt_fields() keep track of the rounding error and
   correct pkt duration and/or dts accordingly.
d) Go back to intercepting the ID3 timestamps in the HLS demuxer
   instead of a separate subdemuxer, i.e. like my original PATCH 12 did
   (just fixing the issue it had). Then the subdemuxer is just raw
   demuxer and we can correct timestamps in hls demuxer like the patch
   did.

I think I'd like (c) most, but I don't really want to delve into the
lavf timestamping code right now myself...
Then maybe (b) or (d), not sure.

-- 
Anssi Hannula