4

I'm setting up a media server for my movies. The server is networked and so are a couple laptops/desktops. The server is running the latest Ubuntu (desktop edition, not server).

This is the scenario I'm trying to achieve:

  • Server is turned on and is connected to the network
  • Client (my laptop) opens a web interface to the server (or just sends it a command via ssh). I select the movie I want via the web interface, and my interface executes a command.
  • The command spawns an instance of VLC with the specified movie playing and forwards the window (just the window) to the computer which requested it.
  • End result: I have a VLC window on my laptop which plays the movie for me. I can close it when I'm done.

Is it at all possible to forward just a window to a client on the network like that?

n0pe
  • 9,411
  • 13
  • 60
  • 108
  • 1
    Look into [streaming](http://www.ehow.com/how_5143120_stream-vlc.html), it'll probably work better. – Kevin Jun 03 '12 at 17:38

1 Answers1

5

It's possible, but probably not desirable. The VLC client (window) will be shown on whatever display you want, but it will be playing uncompressed video, which will have to be sent as networked X requests. Even without any overheads, sending 720×540 at 24 bpp and 30 fps will need around 279 Mbps (720px × 540px × 3 bytes/pixel × 30 fps × 8 bits per byte).

Ethernet frames, TCP/IP packets and the X protocol itself will bloat this even more.

What's even more counter-intuitive is that, since you're displaying post-processed RGB data, the bigger the window, the more bandwidth you'll need. (take this with a pinch of salt, the actual scaling may happen display-side — in which case, reducing the window size won't have any effect on performance)

When VLC (or any other X client) is displaying on a display on localhost, a whole family of huge optimisations kick in that give you the responsiveness you expect.

You can try this yourself if you want (it's pretty interesting to see it in action):

ssh -Yf user@hostname vlc some-file.avi

VLC starts, BUT: audio plays on the X client's host (hostname above), not the X server's host, and video is updated at a fraction of the expected fps. A few seconds into the stream, and the video and audio are hopelessly desynchronised. Most standard streams are unwatchable. Don't even think about HD A/V streams.

The standard media server set up delivers the compressed stream from the server to the client using some form of network file access protocol (e.g. NFS, CIFS), and lets the video client do the decompression and playback.

Alexios
  • 18,757
  • 3
  • 57
  • 74
  • I didn't even think of the amount of bandwidth it would be using. My old setup had me using `sshfs` to mount the remote raid and play the files that way. What would you suggest I do if I want to go the compressed route? Is there software that I can call from my web interface to send me the compressed video data? – n0pe Jun 03 '12 at 16:11
  • 1
    Is the web interface a must? If so, YouTube uses HTTP to send content and does it pretty well considering the scale of things: you don't need an out-of-band protocol for video. If the web interface isn't crucial, and the point is just to have access to media, I'd export the relevant volumes over NFS (or SMB/CIFS if you run a non-homogeneous network) and just use the client's local browsing tools to get to the media (file managers, web browsers, whatever you have). – Alexios Jun 03 '12 at 16:18
  • The web interface is just to make searching and browsing easier and more user friendly. I'll probably use NFS to get the volumes mounted on the clients and use the web interface to open the local copy somehow. Thanks for your insight. – n0pe Jun 03 '12 at 16:32
  • If you use NFS, you still have good searching and browsing features. Depending on what desktop environment you use, you can just search for media files from your desktop, and most modern file managers produce very nice looking previews of video files. – Alexios Jun 03 '12 at 22:11