[vlc-devel] receiving HVDTS MPEG2 strams: UDP makes artifacts, RTP is OK.
Claudio.Allocchio at garr.it
Mon Dec 14 19:22:31 CET 2009
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
have a nice evening!
> Rémi Denis-Courmont
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
More information about the vlc-devel