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

[Anssi Hannula]

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:
>> 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
>> 2. Output second packet no DTS:
>> => now the AVPackets jump back to DTS = X, X+1, X+2
>> 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

You'll also see the previously mentioned drift and jumps due to rounding
error accumulation with the above. E.g. before dts=1794302 there is a
gap of 2431 while packets have a duration of 2089.
(with MAX_RAW_PACKET_SIZE 1024*1024 which doesn't have the other issue).

-- 
Anssi Hannula