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

[Michael Niedermayer]

On Tue, Dec 31, 2013 at 08:15:14AM +0100, Michael Niedermayer wrote:
> On Tue, Dec 31, 2013 at 08:20:19AM +0200, Anssi Hannula wrote:
> > 31.12.2013 06:58, Michael Niedermayer kirjoitti:
> > > On Tue, Dec 31, 2013 at 04:46:37AM +0200, Anssi Hannula wrote:
> > >> I need communication in the "opposite" direction than AVPackets go, so
> > >> they are not a good option AFAICS. AVOptions might do it, though, I
> > >> think I was under the impression they are not changeable after-the-fact
> > >> so I didn't consider it before...
> > >>
> > >> Basically the custom AVIOContext (which has access to AVFormatContext in
> > >> this case) has to inform the demuxer of either position of ID3 data, or
> > >> the timestamp recovered from the ID3 data.
> > >>
> > >> Since both subdemuxer .read_packet() (which needs the pos) and
> > >> AVIOContext .read_packet() (which knows the pos) have access to
> > >> AVIOContext buffer position, I guess the ID3 data buffer position could
> > >> be transmitted via AVOptions to the subdemuxer (the ID3 tags appear
> > >> usually every 10 seconds or so, so multiple ID3 tags getting buffered in
> > >> aviobuf.c should not be an issue).
> > >>
> > >> Now the only issue is how to select the hls-id3-audio subdemuxer...
> > >> (a) Have a regular probe() that detects the timestamp in the ID3 tag
> > >>     in the beginning of the stream (ID3 tag needs to be made available
> > >>     in AVProbeData for that, though, presently it is just stripped).
> > >>     Without AVOption assistance the demuxer can only detect the first
> > >>     ID3 tag, but it would still work quite ok (the rest of the packets
> > >>     just get generated timestamps).
> > >>     Then we also either have to
> > >>     (I)   Try to parse every ID3 tag in the probe() to look for the
> > >>           timestamp, or
> > >>     (II)  Assume ID3 tag is uncompressed and just look for
> > >>           "com.apple.streaming.transportStreamTimestamp" in it.
> > >>     (III) Add some lighter-weight option to our ID3 parser to just check
> > >>           if there is a PRIV tag (and maybe the PRIV tag owner string),
> > >>           or
> > >>     (IV)  Have av_probe_input_format3() do ID3 parsing and make the
> > >>           results available in AVProbeData.
> > >>
> > >> (b) Have it without probe() and have HLS demuxer detect the ID3 tag
> > >>     and select the demuxer manually.
> > >>
> > >>
> > >> Sounds to me like (a)(IV) might be the winner here, or WDYT?
> > > 
> > > iam happy with anything that works and is reasonable simple & clean
> > > i dont think i have a deep enough understanding of id3 tags in hls
> > > to really say which is the best solution
> > 
> > Well, I just realized one issue with (a)(IV), we can't really add fields
> > to AVProbeData due to ABI. Maybe without probe() is the way to go then,
> > I'll have to think about it...
> 
> 
> > 
> > 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 ...

"first_dts X not matching first dts..." debug spam should be fixed

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20131231/7a6adc4a/attachment.asc>