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

[Martin Storsjö]

On Wed, 27 Jan 2010, Michael Niedermayer wrote:

> On Wed, Jan 27, 2010 at 05:15:50PM +0200, Martin Storsj? wrote:
> > Hi,
> > 
> > On Wed, 27 Jan 2010, Michael Niedermayer wrote:
> > 
> > > > I also tried returning all frames at once, but ffmpeg.c gives the 
> > > > "Multiple frames in a packet from stream" error message (but works fine 
> > > > except for that).
> > > 
> > > is there a meassureable difference in speed between returning all and
> > > spliting? Spliting is preferred but if there are speed advantages then
> > > we might think about detecting the cases where spliting is unneeded and
> > > avoid it. (its unneeded when decoding, needed when doing stream copy)
> > 
> > Splitting it within the RTP depacketizer needs one extra memcpy compared 
> > to returning all data at once, but I guess the same copy would have to be 
> > done in a parser instead (for the stream copy case) if we don't split them 
> > here.
> 
> so why does it need a copy?

If returning all at once, we copy data from the source RTP packet straight 
into the output AVPacket. If returning one frame at a time, the dynamic 
handler is called with the whole input RTP packet the first time, which 
the dynamic handler is supposed to store internally so that it can return 
the later frames when called with a NULL buffer for the later calls. So in 
that case, we copy from the source RTP packet, to the dynamic handler's 
internal buffer, into each output AVPacket.

If using a parser, we would copy all the AMR data from the RTP packet into 
one output AVPacket, which the parser then reads and copies pieces of it 
into each output AVPacket for each frame, when things are split. So in 
this case, the amount of copying is exactly the same as when splitting 
inside the RTP depacketizer, only that the work is split between the 
depacketizer and the parser. The internal extra buffer in the RTP 
depacketizer is replaced by the AVPacket passed from the RTP demuxer to 
the parser.

If the parser is able to output the split out AVPackets for each split 
frame without copying them out from the original AVPacket containing many 
frames, though, then it would be an improvement compared to splitting 
within the RTP depacketizer.

> > As for the speed difference, I don't really think it's measurable. The 
> > data amount for AMR is very low anyway (around 1,6 KB/s), so one extra 
> > memcpy of that amount isn't bad. And splitting may have to be done at some 
> > point anyway.
> 
> have you considered a little battery powered cpu in something like a phone?

I occasionally do, yes. Point noted.

// Martin