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

[trueice]

Hi, Martin,

The disordering of RTMP is caused by rtmpproto.c's bug, I've posted the
patch to the mail list.
It seems there is no need for RTMP reordering now.

On Mon, May 24, 2010 at 3:08 PM, Martin Storsj? <martin at martin.st> wrote:

> 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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
Yours trueice