[vlc-devel] Re: PTS is out of range (), dropping buffer, late picture skipped
bart.kerver at surfnet.nl
Thu Jul 24 13:21:06 CEST 2003
> Look at your settings inside /proc/sys/net/core. My values are:
> cat /proc/sys/net/core/rmem_max
> cat /proc/sys/net/core/rmem_default
> cat /proc/sys/net/core/optmem_max
> cat /proc/sys/net/core/netdev_max_backlog
settings are alike, execpt
> 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..
> /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...
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>
More information about the vlc-devel