On 11-02-23 05:59, John A. Sullivan III <jsullivan@opensourcedevel.com> 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
On Tue, 2011-02-22 at 23:23 -0500, Gerry Reno wrote: 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.