screen capture streaming

[mkempf]

I would like to stream (multicast) a computer screen (desktop). The only software I have found, capable of doing it, is MS WMencoder and Media Server. There are tons of software who will capture the screen and make a file and also others like Netmeeting or vnc to share a desktop with specific other computers. But none of these simply grabs the framebuffer, encodes and transmits it. I can think of two possible solutions. A hardcoded screen capture capability in VLC or a directshow screen capture filter (WDM Streaming capture device). The perfect solution would be the DS filter, but unfortunately I wasn't able to find one.

Markus

[Sigmund]

I think I've heard stories of such filters around these forums.

[Guest]

I'm looking for the same thing. No luck so far, despite several searches.

[killswtch]

The closest i've found is the LEAD Screen Capture Filter .. but its not free, and I cant find a demo of it.

http://www.pds-site.com/LEAD/SDK/Multim ... ilters.htm

Sigmund: any chance you could help narrow the search? I've done several searches on the forums with no luck so far.

[Gibalou]

Support for this is implemented in the development version (although there currently is a problem with colours inversion).

See http://www.videolan.org/~videolan for the nightly builds.
Run "vlc screen:" to capture your screen.

[killswtch]

Thanks

[somoose]

I have the same need as mkempf. This has drawn me to VLC.

I have downloaded the nightly build (vlc-win32-last.zip) and here are my results. Please let me know what, if anything, I am doing wrong.

If I enter

Code: Select all

vlc test.mpg :sout=#duplicate{dst=std{access=http,mux=mpeg1,url=:1234}}

from the command line, then I am able to see the stream by entering the IP address in a client on another PC (VLC on a Windows PC or Totem on Linux work great, WMP waits until the stream is completed from the server before it starts displaying the stream on the client).

However, if I enter

Code: Select all

vlc screen:sout=#duplicate{dst=std{access=http,mux=mpeg1,url=:1234}}

then the server's CPU utilization shoots to 100% (as I would expect), but I cannot watch the stream from another PC.

I have also tried

Code: Select all

vlc screen :sout=#duplicate{dst=std{access=http,mux=mpeg1,url=:1234}}

but nothing appears to happen other than the VLC client opening.

Thank you for any help. I would be glad to contribute by testing and possibly writing a little bit of documentation on this feature in return for any aid.

[markfm]

Try this on the Server side.
OPen Settings -- Preferences.
Check Advanced Options
Go down to Modules -- Access_Demux -- Screen.
Crank your cache up (say, 6000 ms), and your frame rate down (say, 0.25 -- 1 frame per four seconds)

(You can also set the above by hand editing vlcrc)

Do a stream, with transcoding. A command line of the form:
vlc screen:
:sout=#transcode{vcodec=mp4v,vb=2048,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=239.20.30.40:1234}}

This is VERY CPU intensive on the Server side, right now, in Windows at least.

One other thing, if you roll your own build, is look in win32.c of the screen code. I changed the BitBlt function call, changed the parameter SRCCOPY to read 0x40000000 | SRCCOPY . This is something that only works with the WinNT/Win2K/WinXP family I believe, not Win98, but may have sped things up a bit.

(I'm running a VLC Server session multicasting to a client on my WinXP PC right now. It clearly needs work, but is also clearly working. There's a killer memory leak floating around, which is why it's imperative to get your processing load down -- I'm running about 55% right now.)

[somoose]

I made the config changes as recommended, and the CPU utilization went down tremendously.

However, I have tried the command as recommended:

Code: Select all

vlc screen: :sout=#transcode{vcodec=mp4v,vb=2048,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=239.20.30.40:1234}}

to no avail. The client cannot connect to the server. I have tried changing url=:1234 and url=<myip>:1234, but the client cannot connect. I have tried the same url changes when changing the access= to http, but the client still cannot connect. I have the debug output from the client if that would be helpful.

Thank you

[markfm]

Debug messages would be handy, for both Server (if it is complaining) and Client. The client end will take some time to make the connection, given the low rate of updates.

[somoose]

I have no messages on the server side. Here are the client side messages. This was for an attempt using http:

Code: Select all

main debug: adding playlist item `http://90.33.216.67:1234' ( http://90.33.216.67:1234 ) main debug: creating new input thread main: playlist item `http://90.33.216.67:1234' main debug: waiting for thread completion main debug: access `http', demux `', name `90.33.216.67:1234' main debug: looking for access module main debug: probing 1 candidate main debug: thread 2904 (input) created at priority 1 (src/input/input.c:326) access_http debug: http: server='90.33.216.67' port=1234 file='(null) main debug: net: connecting to '90.33.216.67:1234' main debug: looking for network module main debug: probing 2 candidates ipv4 debug: connection in progress ipv4 debug: connection aborted ipv6 warning: cannot create socket (No error) main debug: net: connection to '90.33.216.67:1234' failed access_http error: cannot connect to 90.33.216.67:1234 main debug: net: connecting to '90.33.216.67:1234' main debug: looking for network module main debug: probing 2 candidates ipv4 debug: connection in progress

Please let me know what else would be useful.

[somoose]

After reading this excellent thread, I decided to attempt this command:

Code: Select all

vlc test1.mpg :sout=#transcode{vcodec=mp4v,vb=2048,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=<my_friend's_ip>:1234}}

My friend was able to see the test1.mpg video. I then tried this command:

Code: Select all

vlc screen::sout=#transcode{vcodec=mp4v,vb=2048,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=<my_friend's_ip>:1234}}

and he could not see anything from my server.

Here is the debug info from his client (production version 0.7.2; I'm still using the 0.7.3-svn nightly build):

Code: Select all

main debug: adding playlist item `udp://' ( udp:// ) access_udp: closing UDP target `udp://' main debug: unlocking module "access_udp" main debug: pes: 0 packets main debug: data: 0 packets main debug: buffers: 1 packets main debug: thread 2904 joined (src/input/input.c:373) main debug: creating new input thread main: playlist item `udp://' main debug: waiting for thread completion main debug: access `udp', demux `', name `' main debug: looking for access module main debug: probing 1 candidate main debug: thread 2916 (input) created at priority 1 (src/input/input.c:326) access_udp debug: opening server=:0 local=:1234 main debug: net: connecting to ':0@:1234' main debug: looking for network module main debug: probing 2 candidates main debug: using network module "ipv4" main debug: unlocking module "ipv4" main debug: using access module "access_udp"

[The DJ]

i'd put a space between ::

[somoose]

Thanks. I tried that. Specifically:

Code: Select all

vlc screen: :sout=#transcode{vcodec=mp4v,vb=256,scale=1}:duplicate{dst=std{access=udp,mux=ts,url=<my friends_ip>:1234}}

and his client gave this message:

Code: Select all

main debug: adding playlist item `udp://' ( udp:// ) main debug: prebuffering done 0 bytes in 10s - 0 kbytes/s main error: cannot pre fill buffer main warning: cannot create a stream_t from access main debug: unlocking module "access_udp" main debug: thread 2792 joined (src/input/input.c:286) main debug: creating new input thread main debug: waiting for thread completion main debug: `udp://' gives access `udp' demux `' path `' main debug: demux2_New: access='udp' demux='' path='' main debug: looking for access_demux module main debug: probing 0 candidates main debug: thread 2792 (input) created at priority 1 (src/input/input.c:224) main error: no access_demux module matched "udp" main debug: access2_New: access='udp' path='' main debug: looking for access2 module main debug: probing 5 candidates access_udp debug: opening server=:0 local=:1234 main debug: net: connecting to ':0@:1234' main debug: looking for network module main debug: probing 2 candidates main debug: using network module "ipv4" main debug: unlocking module "ipv4" main debug: using access2 module "access_udp" main debug: pre buffering

When I execute the command without the space I see my desktop in the VLC session on my PC. When I execute the command with the space my memory usage shoots to 40M for vlc and I do not see my own desktop within VLC. This leads me to believe that I'm closer, but it still does not work.

I'm in a corporate environment, is there a chance that something in our network is preventing this from working? My ip looks something like 90.33.x.y and his looks like 90.136.m.n. I have not played with the TTL settings much, nor am I sure exactly where in the command line they should go.

Again, I appreciate your help.

[markfm]

Given your friend could see you push the test video, you have a valid network path -- the company isn't blocking the streaming method you are using.

The "pre buffering" sounds like you might have a connection. On my PC, the Server, I went into Settings -- Preferences, changed Modules -- encoder -- ffmpeg, set "Ratio of key frames" to 1. I absolutely do not know for sure, but ffmpeg may have defaults set that try to push a bunch of delta frames between key frames, which is fine for standard multiple-frame-per-seond video, but not good for multiple-second-per-frame screen streaming.

[somoose]

I still can't get screen: to work. Unfortunately I'm not a programmer, so I can't roll my own, which puts me at a bit of a disadvantage.

I double checked my settings, and I have made all of the setting changes which markfm recommended. I've tried streaming using http and udp. As before, the client does not see the udp stream at all. The VLC Client finally received some sort of stream, but it did not show it. He opened the client and did a file/open network stream. He then selected HTTP/FTP/MMS with a url of <my_ip>:1234. His client then showed a progress bar (which was new) but nothing else appeared on the screen. We left the server and client up while we went to lunch. When we came back my server no longer showed screen: in the lower right hand corner, but his PC was nearly frozen. We suspect either the previously mentioned memory leak or it's possible that the entire stream was being loaded into memory. We were unable to get any debug messages out of the client before we shut it down.

Thank you again for your help. I hope that I have not hijacked this thread; if it belongs in the streaming forum, please let me know.

[markfm]

I think I've got the server-side memory leak captured, and sent an e-mail with recommended code change to the vlc-devel mailing list (I'm not a software person, need someone else to verify and submit it). That won't fix CPU utilization on the Server, it just prevents VLC from eating up all of the Server's memory.

Does your satellite pipe have enough bandwidth to support what you selected for Transcoding? VLC has definite "jitter", variability, plus there's packet overhead. For example, if you have a 756 kbps connection, I might try video at 256 kbps, audio at 64 kbps, just to start.

You're definitely getting closer.

[somoose]

I haven't run into the server-side problem yet. That's probably because I haven't streamed anything for a long period of time.

I'm not sure what the pipe between my PC and the client PC is, but we're on a corporate LAN, and the PC's are right next to each other. The commands which I have executed have been variations of:

Code: Select all

vlc screen: :sout=#transcode{vcodec=mp4v,vb=256,scale=1}:duplicate{dst=std{access=http,mux=ts,url=:1234}}

As best as I can tell, the vb=256 should do what you're recommending. I don't think I'm even attempting to stream audio, but I'm not 100% positive. Does screen: attempt to stream any audio?

Any other recommendations? I'd really love to make this work.