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

Michael Niedermayer michaelni at gmx.at
Fri Jan 3 05:33:37 CET 2014

On Fri, Jan 03, 2014 at 04:21:03AM +0200, Anssi Hannula wrote:
> 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,

this sounds a bit odd, mpeg has strict rules on how often timestamps
must be stored
without checking the spec i think the max duration between timestamps
was below 1 sec
so several hundread packets of 1024 samples sound like too much

> 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.

thats a possible temporary solution

> 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.

i probably could look into this tomorrow if the timestamps are really
that rare

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140103/556c7d85/attachment.asc>

More information about the ffmpeg-devel mailing list