[X2go-dev] X2Go media player for redirected video [was Re: EyeOS]

Alexander Wuerstlein snalwuer at cip.informatik.uni-erlangen.de
Wed Feb 23 13:12:45 CET 2011


On 11-02-23 05:59, John A. Sullivan III <jsullivan at opensourcedevel.com> wrote:
> On Tue, 2011-02-22 at 23:23 -0500, Gerry Reno wrote:
> > On 02/22/2011 10:16 PM, John A. Sullivan III wrote:
> > > On Tue, 2011-02-22 at 21:09 -0500, Gerry Reno wrote:
> > >   
> > > <big snip>
> > >> And rather than trying to pass the actual content around it's just seems
> > >> easier to post the content on a webserver that the users can access from
> > >> their client machines.
> > >>     
> > > This is where I disagree.  When we have control of the content and
> > > environment that works.  But that's not our environment.  We want as
> > > seamless a user experience as possible whether they are browsing the
> > > Internet and hit a video, clicking on an email attachment that happens
> > > to be video, or viewing some kind of embedded video content.  We expect
> > > our clients to be able to work as closely as possible to their physical
> > > environment in their virtual environment.  The onus is on us to make
> > > that possible as transparently as possible without changing their
> > > procedures.  That may not be true of all deployments but it is true of
> > > ours - John
> > >   
> > 
> > Right now there is no simple way to do this with x2go or any of the
> > other remote access technologies.
> Actually, although I have not used it, I believe Citrix is doing
> something like this.  Whatever EyeOS is doing works very well.  HP is
> taking a different approach by adapting their transport to the nature of
> the video being transmitted.  If what I propose is feasible, we have a
> possible solution.

There are basically 2 solutions to this problem (actually 3):
- Adapt the software playing the media to stream the raw data over to
  the thin-client without reencoding and play that stream on the
  thin-client. Pros: same quality as local, Cons: possibly needs a lot
  of bandwith and processing power on the thin-client. Only works with
  adapted media-players.
- Adapt some video-API like XVideo to re-encode every video-stream its
  asked to play into some transfer format which is encodable in realtime
  and sufficiently small in bandwith usage. Pros: thin-clients may be
  smaller, works with every software that uses standard Video-APIs (so
  possibly not flash...), lower bandwith usage. Cons: Possibly wouldn't
  work with flash, needs a lot of processing power on the server,
  possibly too much for high quality or larger window sizes of the video
- Use some heuristics to recognize rapidly changing window contents
  (which probably is either video or a game). Encode that window content
  into a video stream. Pros: works with every software, including flash,
  games and other weird stuff (i guess there will be corner cases
  though). Cons: unbelievably ugly, lots of server load, possibly crappy
  quality.

> > For true transparency the media would have to be played on the remote
> > desktop media player but then the performance is bad.
> > 
> > To get satisfactory performance you have to use the media players on the
> > users machine but then you would not have seamless experience.
> It is not entirely seamless but, at least for our purposes, it is much
> better than saying, "save the video to disk, transfer the file to your
> local computer, now open it using your local media player." Let's do all
> of that automatically for them.  That may not work well for your
> environment but it would for ours.

The approaches described above practically preclude any scenario where
playing videos would be absolutely seamless. Practically all solutions
that do not take the third approach do only work with a few media
players (in practice: their "special" Windows Media Player and their
"special" Flash). I could be wrong and there are better solutions out
there, but everything I have seen so far suggests that there is no nice
and easy way...




Ciao,

Alexander Wuerstlein.



More information about the x2go-dev mailing list