[FFmpeg-devel] [PATCH] RTP reordering, again
Mon Sep 27 00:06:48 CEST 2010
On Sun, 26 Sep 2010, Luca Barbato wrote:
> On 09/26/2010 10:42 PM, Martin Storsj? wrote:
> > On Fri, 24 Sep 2010, Martin Storsj? wrote:
> >> On Fri, 3 Sep 2010, Martin Storsj? wrote:
> >>> This is a respin of the RTP reordering patches from May. Ronald was quite
> >>> ok with the actual reordering logic (as far as I remember), but Michael
> >>> wanted to make sure we could set a maximum delay for the reordering. Back
> >>> then, I made one attempt at this, but I've rethought the max delay logic
> >>> now, and I'd say this new attempt is both better and much more straight
> >>> forward than the previous one.
> >>> In order to set max_delay for demuxers, I add an AVOption for that field.
> >>> Without setting it (when max_delay is 0), no packet reordering will be
> >>> done, packets are passed straight through.
> >>> Attached is also a patch (not for review) for making rtpenc send packets
> >>> in non-linear order, just for testing this. I'm happy to say that our code
> >>> manages to decode the packets sent in non-linear order just fine with this
> >>> reordering code, as does QuickTime. VLC, with their current RTSP lib,
> >>> didn't work perfectly, though.
> >> Ping, Ronald and Luca B, do you think this looks sane? In particular, the
> >> code for enforcing a maximum reordering delay, is that ok?
> > Rebased onto the latest version.
> > // Martin
> 0001 -> Looks ok
> 0002 -> the memmove and memcpy might be avoided
Memmove (of a quite small amount of data) can be avoided by changing the
data structure to a linked list, yes.
Avoiding the memcpy of the payload data is harder - that requires
modifying the rtsp layer to dynamically allocate the buffer that the
received package is stored in so that it can be handed off to rtpdec.
This requires rtp_parse_packet to be able to return another status code,
whether ownership of the current buffer was taken or not. If
rtp_parse_packet took the previous buffer, we need to allocate a new
buffer for receiving packets, otherwise we can reuse the previous one.
I guess this could be valuable for other reasons, too, so I'll try to
> 0003 -> Looks ok
More information about the ffmpeg-devel