[vlc-devel] Re: [Patch] RTP reordering - dropping of old/duplicate packets

Fri Sep 30 11:49:12 CEST 2005

Something that is configurable/optional is of course worth trying.  My
leeriness is because the lowest total delay I have seen with anything other
than RTP, using VLC, has been on the order of 750 ms.  This may be fine for
many applications, but doesn't work well for actual real-time work, manual
remote control of cameras.
I switch to RTP specifically for time critical use, where latency doesn't
cut it.  Unfortunately, even trying many optimizations, and explicitly
trying to force the caches towards 0, I still seem to be getting around 750
ms delay when I do other things, like UDP multicast, while with RTP, for
whatever reason, it is much lower.  For comparison, my older HW CODEC
implementation, a tweaked MJPEG, was 160 - 200 ms total delay, analog video
input to display, and one other niche VTC product, a proprietary CODEC
implementation video over IP, was on the order of 200 ms
To say that other stacks in VLC implement something, so RTP should, misses
the point. Turning the present approximately 200 ms RTP latency to 300 - 400
ms is not, my opinion only, good.  Based on my experience with other VLC
mechanisms, I also suspect that the residual code complexity might (only
might)  add a bit more inherent delay, something that you end up stuck with.
If it's what people want, no problem, I can always go and do my own custom
builds off of older editions of the code, just that I'd rather avoid it if
possible.  If it is implemented, I'd suggest real testing to ensure it can
be tuned so as to have the least possible impact.
(I test with timestamped video as my source, side-by-side monitors
displaying the source video and a VLC client.  The results I get from
capturing the delta-T in these tests seems to match tactical use, actually
controlling a camera rig from a client.  Pan/Tilt/Zoom/Focus overshoots can
be a bear.)

-----Original Message-----
From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org]
On Behalf Of Marian Durkovic
Sent: Friday, September 30, 2005 3:25 AM
To: vlc-devel at videolan.org
Subject: [vlc-devel] Re: [Patch] RTP reordering - dropping of old/duplicate
packets

On Thu, Sep 29, 2005 at 10:12:51PM -0400, braymond at echostorm.net wrote:
> I've worked in the VTC community for a long time and although long 
> delays are bad a small smount of buffering can smooth what would be an 
> unplayable stream into something usable by handling some jitter and 
> out of order packets. Like you say buffering can be bad, I can however 
> see a configurable static buffer being useful, or even optionally the 
> same kind of dynamic RTP buffer used in most H.323 stacks.
> 
> Generally a 100-200ms buffer is enough to smooth out minor 
> troublespots and most people won't even notice anything like that, but 
> it doesn't have to be used.

Just to add:  requirements for packet reordering are in most cases less
demanding than requirements to compensate network or OS jitter.

VLC by default implements a 300 msec buffer to compensate network jitter
(see udp-caching). This is much more than satisfactory for reordering
purposes - however it will probably require serious modifications to be able
to insert late packet somewhere into the middle of this buffer.

Thus I've prepared just a simple patch which improves the situation by
trashing duplicates and/or late packets and thus reducing the number of
discontinuities from 3 to only 1. Since it's very simple, I'd appeciate if
this patch could be included into 0.8.4-test2.

	Thanks & kind regards,

		M.  

> 
> - Brian
> 
> > Be careful about anything reordering RTP -- the whole idea is Real Time
--
> > adding buffers is bad juju for people who rely on it to be just that.
> >
> > -----Original Message-----
> > From: vlc-devel-bounce at videolan.org
[mailto:vlc-devel-bounce at videolan.org]
> > On Behalf Of Marian Durkovic
> > Sent: Thursday, September 29, 2005 10:10 AM
> > To: vlc-devel at videolan.org
> > Subject: [vlc-devel] [Patch] RTP reordering - dropping of old/duplicate
> > packets
> >
> > Hi all,
> >
> >   I've added a bit of code to the UDP/RTP input, which assures that old
or
> > duplicate RTP packets are trashed. When the network performs packet
> > reordering, only one discontinuity happens instead of 3 before - since
the
> > old packet is trashed. If multiple copies of the same packet are
received,
> > only one is used and all the others are trashed.
> >
> >   This is still not the full solution, since in case of packet
reordering
> > this code is not able to restore the correct order and still creates one
> > discontinuity. But to avoid this, some kind of buffer needs to be
> > implemented, which would be able to hold the early packets until the
> > correct
> > one arrives.
> >
> >   Please find the patch in the attachment.
> >
> >
> > 	With kind regards,
> >
> > 		M.
> >
> >
--------------------------------------------------------------------------
> > ----
----
> > ----   Marian Durkovic                       network  manager
----
> > ----
----
> > ----   Slovak Technical University           Tel: +421 2 524 51 301
----
> > ----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351
----
> > ----   812 43 Bratislava, Slovak Republic    E-mail/sip: md at bts.sk
----
> > ----
----
> >
--------------------------------------------------------------------------
> >
> > --
> > This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> > To unsubscribe, please read http://developers.videolan.org/lists.html

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html