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.
Client losing end of multicast video
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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.
sout access access_output_udp
access (access2 in 0.
access_UDPaccess (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.
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.
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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
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
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
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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.
You don't know these guys....
Dave
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.
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.
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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).
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).
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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)
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)
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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.You should be down to 200 ms
Nah, they're being provided by a production company.if you have access to the source files
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.
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.
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
-
SoftwareDave
- Blank Cone
- Posts: 30
- Joined: 25 Jun 2004 21:37
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
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
multicast packets size
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.
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.
Return to “VLC stream-output (sout)”
Who is online
Users browsing this forum: No registered users and 7 guests