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

[Michael Niedermayer]

On Sun, May 23, 2010 at 10:13:53PM +0200, Luca Barbato wrote:
> On 05/23/2010 05:39 PM, Michael Niedermayer wrote:
> >> So given this, I still think the reordering should be done at the rtpdec 
> >> layer.
> > 
> > thats what i suggested
> > what is unclear to me is how you intend to decide what and when to return
> > things from the queue.  I suggested that the user application decide. how do
> > you want to handle this, an application might need audio a bit before video
> 
> > And how do you intent to keep the clocks synchronized? currently an application
> > could decode too fast and then get stuck when its out of data and all buffers
> > are empty
> 
> I think the idea is to keep filling the queue without returning till:
> 
> - you have the packet in-order
> - the queue hits its size limit.

this might work with playing a video but for lowdelay communication this
design fails

low delay implicates that video must be displayed in time and thus
rtpdec must return a packet if it has one
i have the feeling you 2 dont understand what i suggest.
the buffers in my suggestion are in rtpdec and the application calls
av_read_frame() when it needs a frame
if you are concerened that the time between calls could be too large
and kernel ques could overflow, the bad news are that currently there
alraedy can be arbitrary timespans betweem av_read_frame() calls.
Currently av_read_frame() is only called when the player needs a frame,
that is if it has a spot free in its buffers.
thats exactly what would be in case of my suggestion,just with smaller
buffers in the application.


There normally is some buffer, to compensate variable network delay
and there is one (possible the same) buffer to compensate bitrate
variation between frames (and all video since mpeg1 has variable sized
frames, keyframes are much larger) thats the vbv buffer, its mandatory.
currently these buffers are in the application and thus cannot be used
by rtpdec.
if rtpdec would return a packet if it has one when the application
requests one then these buffers could be inside rtpdec and rtpdec
could use them for free for reordering packets until the packets are
needed by the application.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100524/e481a361/attachment.pgp>