[vlc-devel] Re: PTS is out of range (), dropping buffer, late picture skipped

[Bart Kerver]

Jean-Paul

> Look at your settings inside /proc/sys/net/core. My values are:
> 
> cat /proc/sys/net/core/rmem_max
> 65535
> cat /proc/sys/net/core/rmem_default
> 65535
> cat /proc/sys/net/core/optmem_max
> 1024
> cat /proc/sys/net/core/netdev_max_backlog
> 300

settings are alike, execpt
/proc/sys/net/core/optmem_max
10240


> So if I start calculating with my values, then with an mtu of 16384 I 
> can keep 3 packets inside my socket buffer. This is way to little to 
> survice some scheduling latency and will definitly result in corrupted 
> packets, because when more packets come in packets in the buffer are 
> dropped without notice (default behaviour of udp). I would try enlarging 
> these buffers to a value that can hold approximately 30 or 40 of those 
> big packets..
> 
> E.g:
> /sbin/sysctl -w net.core.rmem_max=655360
> /sbin/sysctl -w net.core.rmem_default=655360
> /sbin/sysctl -w net.core.netdev_max_backlog=3000
> 
> Maybe this will help to get a better reception of those packets.

I will try (tomorrow ;-) and send feedback. However it would be weird 
for end-users to fiddle around with the OS like this...

Very true, however - how comes the other players (Cisco IPTV eg) 
playback fine? I think that with this bandwidth buffers shouldn't be 
filledup that fast, it's just above 5 Mbit/s, VLC is not consuming too 
much procces-time, I think the NIC (or even the network!) will probably 
fragment these packets, since SURFnet will allow only jumboframes upto 
8192 bytes. The reordering might be the problem, however see reactie on 
latest mail from Gildas...

regards,
Bart

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>