Universal Media Server | Forum

Is it possible to stream from a TV Capture Card? I know mencoder has some capture tv options.

Try http://umediaserver.net/ for live capture and stream serving. I don't know if that stream can be plugged later into UMS for DLNA serving but worth digging into it.

Revisiting this topic I found a good article on how to tweak the DLNA server to pass the parameters a DLNA client will accept for a live stream (in this case being the desktop) as if it were a complete file: http://realmike.org/blog/2011/02/09/liv ... -gnulinux/

Does anyone know if it can be added to UMS or via a plugin?
Thx, Wolf

Wolfgan wrote:Does anyone know if it can be added to UMS or via a plugin?

• Screencasting
  • For linux pmsencoder already has x11grab.groovy which streams ffmpeg's x11grab device output (it's pretty slow, though).
  • According to the ffmpeg wiki the same thing is possible for Windows via the dshow device (haven't tried it).
  Camera/TV capture
  • Apparently also possible using either dshow or vfwcap devices in Windows and video4linux2 in linux.

I don't know how smoothly things would run in real time, but if you come up with an ffmpeg/ffplay command that works it's possible to wrap it in a jumpy python script (or pmsencoder groovy script) and use it in UMS, I'll be glad to help with the jumpy side of things.

Jumpy screencast example for Windows/Linux:

• Install jumpy.
• Put screencast.py in plugins/jumpy/:

  screencast.zip

  (710 Bytes) Downloaded 872 times

• Windows only: install the x86 edition of the UScreenCapture DirectShow filter from Unreal Media.
• Restart and look for the 'Screencast' video item in the xmb root folder.

I've tried the above instructions and for the most part they work great. A bit tricky to set up but once you get it working, the video quality is excellent and there's little delay. I even got it to work by forwarding the audio through the Stereo Mix device by editing the screencast plugin with:
However, while audio does get sent I've noticed it is de-synchronized from the video. I've experimented with the ffmpeg command line but couldn't get it to sync at all. Maybe someone with more experience with ffmpeg may have an idea (no luck with -async 1 or manually adjusting -itsoffset).

In addition, after streaming the screen for a while the UMS console gives me the following:
Is there anything I can do about this? Perhaps increase buffer size in UMS or change the ffmpeg command line to specify different parameters that would allow for the audio and video to remain synced?

Anyway, for a proof of concept this works incredibly well, so props to the developer who came up with this!

LnS wrote:However, while audio does get sent I've noticed it is de-synchronized from the video.

I actually took the script a bit further but never released it due to the overlong transcoding lag and choppy audio. The version below will let you experiment with more directshow capture filters and maybe find a better combination. As to buffering, sorry but no particularly useful advice comes to mind .

Update: jumpy capture script for Windows/Linux (with auto-discovery of devices and a/v combinations):

• Install jumpy.
• Put capture.py in plugins/jumpy/:

  capture-1.1.zip

  unzip to plugins/jumpy

  (1.85 KiB) Downloaded 1120 times

• Windows only: install any/all of these directshow filters:
  • x86 edition of the UScreenCapture DirectShow filter from Unreal Media.
  • screen-capture-recorder.
  • virtual-audio-capture-grabber.
• Restart and look for the 'Devices' folder in the xmb root folder.

Awesome! Thank you for the prompt response and updated plugins, I'm happy to report I did manage to get perfectly synchronized audio and video thanks to your efforts!

So here are my findings so far (on Windows 7 x64):

1. Disable Aero

Seriously, the encoding is that much more efficient and the fps remains constant between frames, whereas with Aero enabled it tends to get worse progressively.

2. MPEG2 works very well

Here are the two presets I've found work best:
30fps almost constantly, however audio starts do desynchronize a bit and after a few minutes of streaming a video the audio can be several seconds off. UScreenCapture works just fine if you don't need audio though.
Best by far. Perfect 30fps and audio remains in sync the whole time. Plus has the added benefit of not requiring your sound card to expose a Stereo Mix device.

By the way I found including "-rtbufsize 1500M" gets rid of all the buffer exceeded messages in both ffmpeg and the UMS console while preventing FPS fluctuations so if you have enough free RAM, definitely use it.

3. H.264 is hit and miss
Generates a very small, decent quality file with default ffmpeg x264 settings and audio is in sync however the framerate is very low, about 8-10fps max despite ffmpeg reporting recording at 30fps.
Adding the "-r 30" parameter before "-i video" fixes the framerate which is indeed at 30fps now, however the audio is no longer synced and starts a few seconds after the video and starts to get progressively delayed.
and Very large output files and audio still desynced, though by no more than a second now.

These seem to imply my CPU can't quite handle encoding 1080p/30fps in realtime with x264 (Phenom II x6 1090t @ Stock 3.2 GHz)
As I have a GTX570 I tried to find a hardware accelerated encoder utilizing OpenCL or CUDA (NVCUVENC stands out) or some means of utilizing the built in H264 encoder in the new NVIDIA cards, therefore bypassing the CPU bottleneck, but couldn't find anything that would work with ffmpeg.

4. Your mileage may vary

The stream worked perfectly in my Samsung TV with AllShare with the second MPEG2 preset above, but would only play for a few seconds and afterwards stutter considerably or outright refuse to play with my WD TV Live, with UMS reporting:
5. Latency is still fairly high

I found the stream to be around 2 to 3 seconds off in the TV (though this seems to vary). That's not an issue for streaming video or the normal contents of the desktop, but does pose an issue with games.

One of my original hopes was to be able to stream the desktop (second floor bedroom) to the TV (first floor living room) with as low latency as possible, and having something capture wireless gamepad input on the TV and forward it back to the desktop for processing. This would essentially allow you to play games without having to move over the desktop and physically plug it on the computer.

Regardless, I'm very glad to have managed to get video working fine with synchronized audio through DLNA and this is already outstanding, so major thanks to Infidel for making this possible. Also his latest Capture plugin just gave me an easy way for streaming my webcam through DLNA as well! =D

Wow, talk about thorough! Great post, and a very useful primer .

LnS wrote:I found including "-rtbufsize 1500M" gets rid of all the buffer exceeded messages in both ffmpeg and the UMS console while preventing FPS fluctuations

And ergo solves the audio choppiness I experienced before. Just for the record, anyone can customize the script's ffmpeg command by editing capture.py line 22:

return 'ffmpeg -y -rtbufsize 1500M -f {dev} -r {fps} -s {size} -i {input} -c:v mpeg2video -f mpegts -q:v 3 -threads 0 {OUTFILE}' \