[FFmpeg-devel] [PATCH 07/19] avformat/hls_id3_audio: add HLS ID3 timestamped audio demuxer

[Michael Niedermayer]

On Wed, Jan 08, 2014 at 02:23:27PM +0200, Anssi Hannula wrote:
> 03.01.2014 16:21, Anssi Hannula kirjoitti:
> > This is to be mainly used via the hls demuxer.
> > 
> > Signed-off-by: Anssi Hannula <anssi.hannula at iki.fi>
> > ---
> > 
> > I've included an alternative read_probe() function which assumes an
> > uncompressed ID3 tag and just uses string search. WDYT, is full id3
> > tag parsing ok in probe() or should the assumption be made?
> > I'll drop one of the alternatives before commit.
> > 
> > Also, not sure about AV_OPT_FLAG_DECODING_PARAM, since this isn't
> > really so "generic" parameter since it should be updated during
> > playback (playback works without it, but timestamps may drift).
> > 
> > Also, I've set a MAX_RAW_PACKET_SIZE of 1MB since doing otherwise
> > (i.e. 1024) causes some timestamp weirdness as previously described:
> 
> This seems to be caused by the way the hls demuxer and the hls_id3_audio
> subdemuxer interact.
> 

> >> When I have:
> >> - one stream, with AVSTREAM_PARSE_FULL, and
> >> - avformat_find_stream_info() done (by HLS demuxer),
> >> and then do:
> >> 1. Output first packet with DTS=X, containing multiple actual frames
> >> => the AVPackets output from lavf get proper DTS = X, X+1, X+2
> 
> At the subdemuxer level these packets actually do not contain any
> timestamps (packet duration is not known yet).
> 
> The X+1, X+2 timestamps are filled in by the main hls demuxer generic
> timestamp generation code (the packet duration is known here, as
> avformat_find_stream_info() for the subdemuxer is finished when
> read_packet() is called for the main demuxer).
> 
> >> 2. Output second packet no DTS:
> >> => now the AVPackets jump back to DTS = X, X+1, X+2
> 
> At this point the subdemuxer now knows the packet duration, so it starts
> assigning generated timestamps, starting from the last known DTS
> timestamp (X). Main demuxer passes these timestamps as-is, causing the
> jump backwards.

maybe its unrelated but make sure you have
5047849584f278d62b2e18281e89da13dddcbf87
it might affect the first few timestamps


> 
> 
> Not immediately sure what should be done, whether some small workaround
> or rethinking how the ID3 audio is handled as a whole. Will think about
> it, but suggestions welcome.

i cant really suggest much, the whole idea of id3 being used to
store timestamps is ugly

but with the demuxer, i would suggest to avoid request_probe = 1
it inevitably will delay everything and could be related to the
timestamp issues you see as the codec must be probed before frame
durations and parsing of frames can happen.



> 
> 
> >> 3. Output third packet, no DTS:
> >> => DTS continues correctly, X+3, X+4, X+5
> >>
> >> And this jumping back only happens exactly once in the beginning of the
> >> stream, everything is fine the next time a timestamped packet is output.
> >>
> >> Anyway, I'll just workaround it for now by avoiding the DTS-less demuxer
> >> packets by putting the whole segment (10sec) in the same AVPacket for
> >> lavf to split.
> > 
> > To reproduce, download these:
> > http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_16x9/alternate_audio_aac_sinewave/prog_index.m3u8
> > http://devimages.apple.com.edgekey.net/streaming/examples/bipbop_16x9/alternate_audio_aac_sinewave/main.aac
> > 
> > and then run this with both MAX_RAW_PACKET_SIZE options to see a
> > difference in output:
> > ffprobe -show_packets prog_index.m3u8 | grep ^dts= > DTSout
> > 
> > 
> [...]
> 
> -- 
> Anssi Hannula
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20140108/6b5e7314/attachment.asc>