[FFmpeg-devel] [PATCH/RFC] MP4A-LATM RTP depacketizer

[Janne Grunau]

On Wed, Aug 04, 2010 at 06:13:00PM +0300, Martin Storsj? wrote:
> 
> Now that the initial patch for a LATM demuxer is available, I tried 
> implementing a MP4A-LATM RTP depacketizer, initially using a chained 
> demuxer.

You should have said more explicitly that you're working on it. I would
have made my local changes available earlier. Here is a git tree with my
local changes after from the review.

http://git.jannau.net/git/FFmpeg/log/?h=loas_demuxer

> Attached is two different ways of implementing it - the first one is a 
> simple and straightforward way without using a chained demuxer. There's 
> really not much code duplication - a 6 line loop for reading the packet 
> lengths, plus a few get_bit calls for extracting the extradata from the 
> config data block. This is more or less quite equivalent to the way 
> gstreamer's MP4A-LATM demuxer works.
> 
> 
> The approach using a chained demuxer is a bit more complicated. I have to 
> add some extra sync headers to the config data for the demuxer to 
> recognize it, and I had to make a few other changes to the demuxer, too - 
> see the other attached patch series, 1-4. This is based on top of the 
> patch that Janne sent a few days ago.
> 
> (Both implementations also require the hex_to_data patch I sent earlier 
> today.)
> 
> The part requiring most discussion is patch #2, where I've commented out 
> the incrementing of cur_stream in the LATM demuxer. Janne - how are things 
> laid out in the streams this normally handles? One config packet, followed 
> by one data packet for each stream, and then a sync marker and another 
> config packet?

config (if present) and payload for all streams are part of a single
AudioMuxElement. I've only seen LOAS streams (11 bit syncword and 13 bit
frame length) wrapping around AudioMuxElement. LOAS has always in band
config. The config is not in every frame but only in some. All other
have useSameStreamMux set.

> When receiving packets over RTP, there are (normally) no 
> config packets inbetween, so incrementing cur_stream this way makes it 
> start looking for another sync and config packet again.

See above. I have only samples with in-band config. And the reason the
patch didn't include a real LATM demuxer is that even LATM needs out of
band signalling whether the config is signalled in or out of band.

I'll look at your patches tomorrow evening.

> Also, Janne, I'd appreciate if you could try reading section 4.1 in 
> http://www.rfc-editor.org/rfc/rfc3016.txt - what would the payload look 
> like if muxConfigPresent is set to 1, compared to if it is 0 (which is the 
> one I've got samples for)? If there are in-band config packets, what would 
> they look like?

read_stream_mux_config() does the parsing of the config section of the
frame.

Janne