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

[Martin Storsjö]

On Thu, 5 Aug 2010, Janne Grunau wrote:

> 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

Thanks!

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

Ah - for the RTP case, this is signalled in the SDP. If this would use 
in-band config, would the length indication be prepended by a single bit 
for useSameStreamMux then (making the length indication not byte aligned), 
or would there be a whole byte allocated for that, before the packet 
length indication? The RTP spec says that it is byte aligned, but it 
doesn't really tell me which individual parts are byte aligned.

I guess it's quite hard to speculate on this until we've actually got a 
sample stream that uses in-band config.

Btw, do you have a copy of ISO/IEC 14496:3?

> I'll look at your patches tomorrow evening.

Thanks! I'll probably resend new versions of them then, based on your 
latest branch.

// Martin