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

[Martin Storsjö]

Hi,

Now that the initial patch for a LATM demuxer is available, I tried 
implementing a MP4A-LATM RTP depacketizer, initially using a chained 
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? 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.

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?


What do you think is the best approach for doing this - a straightforward 
standalone depacketizer or adapting the generic demuxer to handle being 
used from the RTP depacketizer?

Regards,
// Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-an-MP4A-LATM-RTP-depacketizer.patch
Type: text/x-diff
Size: 8811 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/0c0b2aad/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-the-getbitcontext-before-and-the-pos-after-re.patch
Type: text/x-diff
Size: 1026 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/0c0b2aad/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Don-t-increment-cur_stream-after-each-packet.patch
Type: text/x-diff
Size: 993 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/0c0b2aad/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Refill-the-internal-latm-read-buffer-at-the-start-of.patch
Type: text/x-diff
Size: 1306 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/0c0b2aad/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Initial-MP4A-LATM-RTP-depacketizer-using-a-chained-L.patch
Type: text/x-diff
Size: 9599 bytes
Desc: 
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100804/0c0b2aad/attachment-0004.patch>