The VideoLAN Forums

VLC 0.7.2, Windows 2k
I'm successfully multicasting, but have found that the clients are losing the final second or so of a multicast video.
I'm guessing that this is something to do with caching or latency. I note that when the server end starts up (I'm using VLC at the server, not VLS), it takes about a second or so before the client starts playing, and then the client appears to stop playing a second or so before the actual end of the video. They stop playing immediately that VLC at the server stops playing, i.e. it's as if the server is not flushing a cache or something.
I've played with the sout access UDP stream output caching value, and the access_udp caching value, to no avail.
I note this posting: viewtopic.php?t=1504&highlight=interesting%20things
but it looks like the link that it refers to is down.
The actual latency doesn't worry me, the problem is the missing video. I don't care if it's a second late, but I need to see all of it.
Any suggestions appreciated.

Dave -- I believe there are actually 3 cache values.

sout access access_output_udp

access (access2 in 0. access_UDP

access (access2...) the input cache for whatever you are streaming

Your server is opening something -- file, dshow, whatever -- you need to set this original source-of-video cache to a small value, too.

Personally, I set them all to 30 ms -- my norm is streaming dshow input, over a controlled LAN segment. Doesn't mean the values are good, they're just what I've been using.

Indeed, VLC does tend not to flush its pipelines when it stops (reaching the end of the file).

Some work would be needed to ensure all the data is flushed but that hasn't happened until now mainly because it isn't considered a high priority (it would be nice though).

However the development version of VLC has had some improvements in this regard so you definitely should give it a try (nightly builds available at http://www.videolan.org/~videolan/).
You should also give a try to the --minimize-threads option in this development version (preferences, misc options). It may improve the amount of data lost on stop.

Aaaahhh, suddenly I'm inundated !
Thanks guys...

Yeah, it would seem to be unimportant (hell, what's a second between friends??) but unfortunately they have put a fade-out at the end of the their videos, and they're not seeing it fade. Hence they are unhappy.

I'll try your various suggestions.

Again, your help is much appreciated

Dave

With a current vlc build, file cache 300 ms, output udp cache 30 ms, input udp cache 30 ms:

Test video with superimposed timestamp, 1:39.76 duration.

Multicast stream of the video, to a VLC client.

1:39.23 is the last frame, so 0.5 seconds "stuck" somewhere.

Try again, 30 ms file cache, knock the output UDP to 0:
1:39.53 last frame -- down to about 0.2 seconds missing.

Gibalout -- definitely sounds like there's a 4th cache somewhere, any idea what?

Dave -- if they can't deal with 0.2 seconds, that really is getting picky

Ok, tried the following on both the server and client ends:

General settings/Miscellaneous/Minimize number of threads checked
Modules/access/access_udp Cacheing 300->0
Modules/access/access_tcp Cacheing 300->0
Modules/access/access_file Cacheing 300->0
Modules/sout access/access_output_udp Caching 300->0
Modules/sout stream/stream_out_display Delay 300->0
Modules/demux/dshow/ Cacheing 200->0

It's difficult to see if it made a difference, because there's no timestamp on the video. However, if it did, it isn't noticeable.

I did find that if I set Modules/sout access/access_output_udp Caching
to 5000, then sure enough there's about a 6 second delay before the client starts playing.
However, reducing all those above to 0 still shows the problem.

markfm - I'm opening from a local file, I assume that Modules/access/access_file is the value you referred to when you said source-of-video cache.

The only thing I haven't tried yet is to try the latest build. Currently getting it, I'll try in the morning as it's late and I want some beer.

Dave -- if they can't deal with 0.2 seconds, that really is getting picky

You don't know these guys....

Dave

I seemed to do best with the access_file at 30 ms -- when I dropped it to zero I actually got slightly worse performance. (Last frame was .4x, vs .5x -- 300 ms "stuck" instead of 200 ms).

My results are with the latest 0.8 vlc (actually, a newer test build)

One biggie, ,knocking the file cache down -- you really want to make sure you have a decent disk on the server, defragment the files.

The results I report here are also on my kind of light work machine -- 800 MHz laptop. I'll see what my home PC does, see if that lets me knock down the file cache parameter with a faster disk subsystem.

btw. i'd love to see some photos of VLC in actioin on a high profile site

Partial success!

I ran the latest build (on the server), and to be honest it seemed worse than the version I was running before (0.7.2).

Went through the preferences again, and in General Settings/Stream output, there's the option to "Keep stream output open". When I mouse over, it says it keeps the stream open for multiple playlist items.

Ah-ha, so that implies that it doesn't shut the stream when an item has finished. Cool. So I checked it, and sure enough the client now sees the fade-out!

However, , here's the bummer. My software invokes VLC to stream the video. My software is a general purpose networked multimedia control system, that issues commands to clients (play this picture and this sound, or start up VLC locally to receive a stream, that kind of thing). It calls VLC at the server with a command line containing the name of the file to stream out, the UDP address etc, and finally a vlc:quit, so that VLC terminates.
My server software watches the application for terminating before it goes onto the next thing to do (maybe another stream, maybe something else).
Of course, using vlc:quit means that VLC at the server quits when it reaches the end of the input, and before the buffer is flushed.
What I need is a "vlc:wait 1 darn second before you quit" command line option. Any ideas?

Actually, while previewing this, I had this idea of having a 1 second blank video clip, that I could just assign to the end of each playlist. However, I'm open to any suggestions.

markfm - I'm trying this out here in the UK on my development system, I've got an Athlon 2600 (1.9GHz) streaming to a Pentium 4 1.(1.4GHz). Standard desktop models, so the disks are nothing special. However, out in Las Vegas, the server is something you'd use to power NASA, not entirely sure of the specs, but it's totally dedicated to this system. Clustered, and with a gigaterasomething of RAID disk space. It's meaty.

The DJ - Well, I'll be honest, I hated Las Vegas, and never want to go there again! The project is basically to display security information videos to the public as they approach the security gates. This project has been in two parts: First part, I wrote all the software, went out there to install, do training etc. Then found that despite the fact that they hadn't mentioned it in the spec, they required multicasting. And they wanted it now. Came back, looked at coding multicasting, got scared. Found VLC. Got happy. Installed it all remotely using VNC over VPN, yes I can control Las Vegas airport security video system from a cottage in the South Downs...
So in a nutshell, if you want pictures, you'll have to go there yourself and take them! I can get you screenshots if you want, but it's nothing spectacular (fullscreen video at the client, vlc in the taskbar at the server).

markfm, The DJ, Gibalou - I've got a few gmail invites if any of you need one.

You should be down to 200 ms, since I'm hitting that with my 800 MHz laptop.

My base reference is video edited with VirtualDub. The clip I'm using now has a last frame stamped at .83 seconds. (the stamp is changing properly, frame-by-frame, visible with VirtualDub)

I'm consistently getting replays of 0.63 - 0.66 seconds, which means 5 - 6 frames total stuck, total across all buffers.

I do agree, however, that pushing a stub blank is not the worst thing in the world. Equally, if you have access to the source files, insert the blank directly into them with VirtualDub.

(there's a virtualdub filter for time code insertion, very handy if you need to do tests, really want to know absolute performance in this area)

You should be down to 200 ms

No, I'm not getting anywhere near that, it looks more like about 800 ms. I haven't had chance to try it out on-site yet, but here I'm running a 100Mb network through a single hub - whether that has anything to do with it.

if you have access to the source files

Nah, they're being provided by a production company.

Sounds like there's something odd with your setup, to be 800 ms stuck in the buffer, after optimization.

Here are my vlcrc settings, the ones giving me the consisten 170 - 200 ms results:
[access_file] # Standard filesystem file input

# Caching value in ms (integer)
file-caching=10
# Concatenate with additional files (string)
#file-cat=

[access_output_udp] # UDP stream output

# Caching value (ms) (integer)
sout-udp-caching=0
# Time To Live (integer)
#sout-udp-ttl=0
# Group packets (integer)
#sout-udp-group=1
# Late delay (ms) (integer)
#sout-udp-late=0
# Raw write (boolean)
#sout-udp-raw=0

[access_udp] # UDP/RTP input

# Caching value in ms (integer)
udp-caching=0
# Autodetection of MTU (boolean)
#udp-auto-mtu=1

[stream_out_display] # Display stream output

# Enable audio (boolean)
#sout-display-audio=1
# Enable video (boolean)
#sout-display-video=1
# Delay (integer)
sout-display-delay=50

[mux_ts] # TS muxer (libdvbpsi)

# Video PID (integer)
#sout-ts-pid-video=0
# Audio PID (integer)
#sout-ts-pid-audio=0
# Shaping delay (ms) (integer)
sout-ts-shaping=80
# Use keyframes (boolean)
#sout-ts-use-key-frames=0
# PCR delay (ms) (integer)
sout-ts-pcr=10
# DTS delay (ms) (integer)
sout-ts-dts-delay=80
# Crypt audio (boolean)
#sout-ts-crypt-audio=1
# CSA Key (string)
#sout-ts-csa-ck=


By the way, there's a new time display plugin, in the developer version, lets you superimpose date/time plus an arbitrary text string, controllable via the command line you use to launch vlc.

Thanks, I missed some - the [mux_ts] section of your vlcrc file contains settings lower than mine. I'll try those and let you know. Tomorrow. Just got back from the pub...

Dave

For the pause command, use "vlc:pause:1 vlc:quit"

markfm - loaded the clip from your ftp site, ran it using my settings, and it finished at 1.38.99. ran it using your settings, and it finished at 1.39.66, exactly the same as your result.

However ran it using my clip and the picture stutters, and the sound is garbled. Returned to my settings and it's ok again. My clips are MPEG-2 BTW. (Don't ask me anything more, I know nothing about video encoding, I just write software...).

Gibalou - I probably should have RTFM for pause, unfortunately the idea of a delay struck me while I was writing the message about my findings, and so I just tossed it in.

Well, it looks like that does the job. I keep the stream open (--sout-keep 1) and add in a 2 second delay (vlc:pause:2) before the vlc:quit, and it looks good. I prefer this option to adding in the blank stub, because all it needs is someone with half a brain deleting the file called "blankvideo.mpeg" because they don't think they use it, and the system would fall apart.

Thanks again guys,

Dave

Hi all,

I have a multicast video streamer application (from a file) that sends 32Kbytes packets and VLC can show the streamed video.

Now i would like to know what is the size of the multicast packets when VLC sends the packets because i have a recorder application that waits 32Kb multicast packets. I have tried with several configurations but i don´t receive anything.

Any suggestion?

Regards.

Normal MTU is 1500 bytes, I believe.

Check your settings, there are a couple of MTU options.
# MTU of the network interface (integer)
#mtu=1500
and
# MTU for out mode (integer)
#ts-out-mtu=1500

Like always ... thank you for your answer

Go to options -> preferences

Go to Input and the set MTU to 32768 = 32Kb

The packets then go away with 32Kb size

VLC is wonderfull