[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:

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.


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.


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