[FFmpeg-devel] [PATCH] RTP depacketizer for AMR

[Martin Storsjö]

On Wed, 27 Jan 2010, Ronald S. Bultje wrote:

> I think the best thing here is to return whole packets since the
> decoder handles that anyway. If needed, we'll write a AMR parser. And
> RTP depacketizers should not mess with timestamps, it's the wrong
> place.

Well, the current dynamic handler design suggests to me that they're 
inteded to be able to return parts of an RTP packet, one frame at a time, 
right - that's what returning 0/1 signals (0 - last packet from this data, 
1 - we've got more to return, so call again with NULL buf pointer). In 
more complicated scenarios, I do see the case where the depacketizer may 
need to hint about the timestamp of each returned packet, if they're 
nontrivial.

Also, another point that came to my mind regarding splitting in the 
depacketizer vs in a parser: AMR/RTP does allow interleaving (which I 
don't support yet, haven't run across any samples with that). In this 
case, the first RTP packet may contain audio frames 1, 4, 7, the second 
packet contains frames 2, 5, 8, etc.

In this case, I don't see any other option than buffering this within the 
depacketizer and then returning the individual frames in the correct 
order. Or is there another solution to that case? Also, if we notice that 
the packet containing frames 2, 5, 8 was dropped in transmission, we may 
need to return frames 1, 3, 4, 6, 7, 9, and thus may need to set the 
individual timestamp for each returned packet, since setting them 
sequentially doesn't yield the correct end result.

// Martin