[FFmpeg-devel] [PATCH] RTP depacketizer for AMR
Wed Jan 27 20:45:34 CET 2010
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
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.
More information about the ffmpeg-devel