[FFmpeg-devel] [RFC] rtpdec: Reordering RTP packets

[Martin Storsjö]

Hi,

When quoting and replying, make sure that the new text you write is on the 
correct quoting level. Part of your reply looks like it was written by me, 
making it much harder to read for other people observing the conversation.

On Mon, 24 May 2010, trueice wrote:

> On Sun, May 23, 2010 at 6:34 PM, Martin Storsj? <martin at martin.st> wrote:
> 
> > On Wed, 19 May 2010, trueice wrote:
> >
> > > We have also found that Adobe's Flash Media Server sends dis-ordered rtmp
> > > packets.
> > > It's quite necessary for lavf or ffmpeg/ffplay to support reordering of
> > > these kind of network packets.
> > > Some API like av_interleave_packets() should work for input formats.
> >
> > In which way are they disordered; are packets from different streams
> > received incorrectly interleaved, or are packets within one stream
> > received in non-monotonic order?
>
> The latter case, non-monotonic packets in both audio and video stream.
> This will happen when FMLE (3.0 version) has run for a long time.
> 
> We use libavformat/rtmpproto.c as the receiver, the captured timestamps
> are totally dis-ordered. However, Adobe Flash Player itself can play the
> rtmp
> stream quite well. As we know, flash player has an internal reordering
> buffer
> with 64 packets or so (that will cause 2-3 seconds brain-damaged delay).
> FMS seems not doing any reordering before packet transmission.
> 
> To reproduce the issue, you can try:
> $ ffmpeg -i rtmp://server/live/livestream -acodec copy -vcodec copy -y
> test.flv
> 
> If the stream is troublesome, the above command may fail with a "non
> monotone timestamps" error.

That is a separate issue from this RTP case.

Also, are the packets actually continuously out of order (e.g. receiving 
packets in order 2, 4, 6, 1, 3, 5, as in the RTP case we're addressing), 
or is there simply one single discontinuity (5, 6, 7, 8, 9, 10, 11, 12, 
13, 5, 6, 7, 8 ...)?

If you haven't debugged this, please do before you're suggesting any 
action. And then when you've got suggestions to do, do so in a separate 
thread.

For the latter case, which I suspect is the case (I've seen such with 
RTMP), no reordering as such would help you - but timestamp rewriting or 
something such could be necessary.

// Martin