[FFmpeg-devel] [PATCH 07/19] avformat/hls_id3_audio: add HLS ID3 timestamped audio demuxer
anssi.hannula at iki.fi
Wed Jan 8 13:23:27 CET 2014
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
>> 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
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:
> 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
More information about the ffmpeg-devel