[vlc-devel] receiving HVDTS MPEG2 strams: UDP makes artifacts, RTP is OK.

[Claudio Allocchio]

On Mon, 14 Dec 2009, Rémi Denis-Courmont wrote:

> Le lundi 14 décembre 2009 19:01:42 Claudio Allocchio, vous avez écrit :
>>>  this is most probably due to packet reordering happening somewhere on
>>> the path between the server and you. 10G interfaces on Juniper M160
>>> routers are famous for this.
>>
>> it is true that there are plenty of M160 and 10G interfaces between
>> Internet2 and GEANT and GARR... but we have the same result over a pure
>> LAN connection, too.
>>
>> It might be related to the amount of packets, of course, as 28Mbps can
>> cause packets reordering also in switches.
>>
>> However, when we use just DVTS to DVTS (DVTS also as receiver) we run UDP
>> at 30Mbps, and we never have a single video glitch for hours.
>
> There are a few potential differences though.
>
> First, VLC does _not_ attempt to correct packet ordering based on the
> continuity counter. Instead, it assumes a discontinuity means a packet loss,
> which in most cases: file storage, DVB reception, simple IP networks. I don't
> know how DVTS handles this.

it drops the packet, and counts it into the packet loss counter. Usually 
if the connection is OK, the packet loss counter stay 0. If there are 
losses along the network, artifacts and a metallic sound is immediately 
shown, too, also in DVTS.

>
> Second, VLC tries to set rather large socket receive buffers. However most
> operating systems will pad the limit to a much lower value for security
> reasons. Hence, at outragous rate, buffer overflow and then packet loss is
> likely to occur (Windows seems more prone to this than Linux, but this is
> entirely empirical).

This is more likely... at HD resolution with MPEG2 buffer overflows are 
possible if the buffer sizes do not match reasonably. The problems shows 
identical on MacOS and XP, too.

I might setup for a testbed streaming, but the receiver needs 28Mbps 
avaialbe (in multicast)... maye it is easier if we try to debug it 
locally...

back tomorow!

have a nice evening!

  >
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio at garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca