[FFmpeg-devel] [PATCH] RTP reordering, again

[Martin Storsjö]

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 
implement this.

> 0003 -> Looks ok

Good. :-)

// Martin