[MPlayer-users] OT Re: Using mplayer with NX

[John A. Sullivan III]

On Tue, 2008-06-03 at 08:36 -0400, Paul wrote:
> >> John said: 
> >> 
> >>             user                                   mplayer
> >>               |                                        |
> >> CAM______physical desktop-----------------------virtual desktop
> >>              |                                          |
> >>              |                                          |
> >>           NXClient----------SMB share----------------NXServer
> >> 
> >> The webcam needs to be activated and de-activated by the application
> (e.g.,
> >> mplayer) on the virtual desktop
> >> ...
> >> 
> >> Why use mplayer for this? Use skype if you want to see a camera from
> remote.
> >> Then log into the client and startup a video session. 
> >> 
> >> mplayer can send streams but (and someone correct me if I am wrong),
> mplayer
> >> is not designed to be a remote media controller. Mplayer is a media
> receiver
> >> and encoder. 
> >> 
> >> mplayer can receive many streams which are being streamed. It can be
> turned
> >> on an off but the remote client control thing is beyond mplayer's core
> >> functionality as I know it. 
> >><snip>
> >Alas, mplayer is one of only several applications which will need this
> >functionality.  For example, they might use Skype but we have the same
> >problem.  Skype will be running on the virtual desktop but the web cam
> >and user are on the physical desktop.  Just like mplayer, Skype would
> >need to control and receive input from the remote device.  I'm not usre
> >that's possible but it would be a major coup if we could find some way
> >to do it.  Thanks - John
> <snip> 
> 
> 
> You show a connection between client and server using smb. Does the physical
> desktop have a command line or gui interface? Can it run mplayer? If so,
> virtualize access to physical desktop camera using ssh, VNC or the like,
> turn it on, control it, start the camera stream. Send the stream as rtp,
> smb, ip etc.  
> 
> Then, once the stream is streaming as rtp, smb, ip etc., access the camera
> image stream on the virtual desktop using the select protocol, in another
> instance of mplayer.  
> 
> It's sort of like running a live Webcast. 
> 
> Paul Yurt www.mastermoz.com 
> Make the Internet Work for You! MasterMOZ
<snip>

Thanks very much; I greatly appreciate the help.  Perhaps this will do
what we want but I have significant reservations which extend beyond
mplayer which is why I've now labeled this thread as off-topic.

We have some capabilities and some constraints I've not mentioned yet.
The physical desktop has both CLI and GUI but the user should not be
interacting with either.  We do have the ability to script as part of
the NX connection process so we could set up a separate data stream via
ssh, netcat or even using something like mplayer or vlc to create a
media stream.  That's the good news.

We have some additional constraints.  The solution must require no to
minimal interaction on the part of end users.  We are anticipating
hundreds to thousands of users so this is not a solution for the
tech-savvy - closer to a consumer solution.  Scripting can take care of
most of that.

Our bigger problem is control and traffic flow.  The real goal is
video-conferencing.  We've just been using mplayer for testing.  The
idea is to move the distributed office into the cloud.  Thus, I may have
users in New York, London, Hong Kong, Paris, Santiago, Tokyo (these are
where the physical desktops, web cams and users are) but they all have
their virtual desktops in the data center somewhere safe and sound.  In
other words, my WAN environment has become a LAN environment.  As much
as possible, I want to keep the data stream local and use NX's great
bandwidth and latency reduction capabilities to make it all appear local
to the user.

How would the virtual desktop application control the video stream?
Let's say we are using Ekiga as a video-conferencing tool.  How would it
find the video stream? How would it turn it on or off? What if it is a
proprietary video-conferencing product with limited configurability?
That's why we were trying to export /dev/videox directly.

Truth be told, the current potential client wants to use this with
Microsoft's OCS.  This is going to be a huge headache but also a
tremendous feather in the OSS cap if we can do it.  As far as I know,
neither Windows alone nor Windows plus Citrix can handle OCS right now.
The only way I can think of doing it is to run Linux underneath with a
successful remote video-access and then pass it up to something like
VirtualBox to run Windows with a virtualized video driver.

Back to our basic set up - the video output will always be on the
virtual desktop.  I suppose it is conceivable, we could actually set up
symmetric servers, i.e., I could publish the video application running
on the physical desktop (where the web cam resides) as an NX application
on the virtual desktop, i.e., the physical desktop now becomes an NX
server as well as an NX client.

This has several drawbacks - it requires more horsepower on the physical
desktop - we would like these to be thin clients or even old, junky
computers for the cash strapped - one of the selling points is a ten
year life-cycle on desktops rather than a three to five year life-cycle.
This setup would imply all the video applications actually run from the
physical desktops which would complicate maintenance and support.  For
something ugly like OCS in a virtual machine, that means two virtual
machines and two instances (and licenses) of the windows OS.

I realize this is now way off-topic and a long, complicated thread.
However, I would love to have an OSS solution to the OCS problem and,
even more, I would love to see open source video and OS at the forefront
of cloud computing with a solution to one of its most difficult issues -
video.  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society