Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast. It was entirely acceptable to watch streaming video in its web browser. It also seemed to do local redirection for video- although, as I said, viewing video within the desktop had both excellent video and sound.
I wonder what they use for a transport mechanism in version 1. It might be something we could investigate as an alternative to NX. It was truly impressive. I'd imagine we could also learn how they do the redirect detection. X2Go is still the product for us as we need the flexibility of running any application, not just those written to run on EyeOS but we might be able to learn quite a bit from their work - John
On 02/22/2011 04:42 PM, John A. Sullivan III wrote:
Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast.
<snip>
I don't remember if it was eyeos, but we looked at some of these "web desktop integration" solutions a while back.
It's not the same experience as having a "real" desktop.
Yes, they've managed to write some office-style apps and email clients and other things.
But that does not truly duplicate a bona-fide native desktop.
Many of the clients we pursue have very industry-specific software they need to run. It needs to run the same whether we put it on their machines or ours in the cloud.
With good remote access there's no retraining of users because they are using the same software they've been using for years. Just accessing it remotely.
In the end, we opted to not go the WDI approach and instead looked for good remote access technologies such as x2go that gives us the flexibility to offer nearly any type of local/remote/cloud solution for the client.
Regards, Gerry
On Tue, 2011-02-22 at 17:11 -0500, Gerry Reno wrote:
On 02/22/2011 04:42 PM, John A. Sullivan III wrote:
Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast.
<snip>
I don't remember if it was eyeos, but we looked at some of these "web desktop integration" solutions a while back.
It's not the same experience as having a "real" desktop.
Yes, they've managed to write some office-style apps and email clients and other things.
But that does not truly duplicate a bona-fide native desktop.
Many of the clients we pursue have very industry-specific software they need to run. It needs to run the same whether we put it on their machines or ours in the cloud.
With good remote access there's no retraining of users because they are using the same software they've been using for years. Just accessing it remotely.
In the end, we opted to not go the WDI approach and instead looked for good remote access technologies such as x2go that gives us the flexibility to offer nearly any type of local/remote/cloud solution for the client. <snip> That is exactly why we chose X2Go instead. However, what caught my eye (no pun intended) was how responsive the video and sound were - significantly better than what we are doing in X2Go. So, in the openness of open source, I wonder what we can learn from what they have done to improve X2Go - John
On 02/22/2011 05:59 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 17:11 -0500, Gerry Reno wrote:
On 02/22/2011 04:42 PM, John A. Sullivan III wrote:
Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast.
<snip>
I don't remember if it was eyeos, but we looked at some of these "web desktop integration" solutions a while back.
It's not the same experience as having a "real" desktop.
Yes, they've managed to write some office-style apps and email clients and other things.
But that does not truly duplicate a bona-fide native desktop.
Many of the clients we pursue have very industry-specific software they need to run. It needs to run the same whether we put it on their machines or ours in the cloud.
With good remote access there's no retraining of users because they are using the same software they've been using for years. Just accessing it remotely.
In the end, we opted to not go the WDI approach and instead looked for good remote access technologies such as x2go that gives us the flexibility to offer nearly any type of local/remote/cloud solution for the client.
<snip> That is exactly why we chose X2Go instead. However, what caught my eye (no pun intended) was how responsive the video and sound were - significantly better than what we are doing in X2Go. So, in the openness of open source, I wonder what we can learn from what they have done to improve X2Go - John
Since most of these WDI offerings are browser-based my guess is that they are passing a link down to the browser and accessing the video and sound through an embedded media player directly rather than playing the media on the server and then passing the output through to the client.
Just a guess.
Regards, Gerry
On 02/22/2011 05:59 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 17:11 -0500, Gerry Reno wrote:
On 02/22/2011 04:42 PM, John A. Sullivan III wrote:
Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast.
<snip>
I don't remember if it was eyeos, but we looked at some of these "web desktop integration" solutions a while back.
It's not the same experience as having a "real" desktop.
Yes, they've managed to write some office-style apps and email clients and other things.
But that does not truly duplicate a bona-fide native desktop.
Many of the clients we pursue have very industry-specific software they need to run. It needs to run the same whether we put it on their machines or ours in the cloud.
With good remote access there's no retraining of users because they are using the same software they've been using for years. Just accessing it remotely.
In the end, we opted to not go the WDI approach and instead looked for good remote access technologies such as x2go that gives us the flexibility to offer nearly any type of local/remote/cloud solution for the client.
<snip> That is exactly why we chose X2Go instead. However, what caught my eye (no pun intended) was how responsive the video and sound were - significantly better than what we are doing in X2Go. So, in the openness of open source, I wonder what we can learn from what they have done to improve X2Go - John
Since most of these WDI offerings are browser-based my guess is that they are passing a link down to the browser and accessing the video and sound through an embedded media player directly rather than playing the media on the server and then passing the output through to the client.
Just a guess. <snip> That is definitely the case in one scenario. When starting a YouTube video, I was asked it I wanted to allow a redirect and, sure enough, it opened up as a local browsing session on my physical computer. However, if I did not allow redirection (answered no), the video opened in the EyeOS browser and played remarkably well. I'm assuming (ignorantly)
On Tue, 2011-02-22 at 18:21 -0500, Gerry Reno wrote: that that was not using a local media player - John
On 02/22/2011 06:36 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 18:21 -0500, Gerry Reno wrote:
On 02/22/2011 05:59 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 17:11 -0500, Gerry Reno wrote:
On 02/22/2011 04:42 PM, John A. Sullivan III wrote:
Hello, all. I'd imagine none of us have the time to investigate this but I just took a quick look at EyeOS (http://www.eyeos.org). It is an open source cloud desktop solution. Version 2 was very slow and buggy but version 1 was amazingly fast.
<snip>
I don't remember if it was eyeos, but we looked at some of these "web desktop integration" solutions a while back.
It's not the same experience as having a "real" desktop.
Yes, they've managed to write some office-style apps and email clients and other things.
But that does not truly duplicate a bona-fide native desktop.
Many of the clients we pursue have very industry-specific software they need to run. It needs to run the same whether we put it on their machines or ours in the cloud.
With good remote access there's no retraining of users because they are using the same software they've been using for years. Just accessing it remotely.
In the end, we opted to not go the WDI approach and instead looked for good remote access technologies such as x2go that gives us the flexibility to offer nearly any type of local/remote/cloud solution for the client.
<snip> That is exactly why we chose X2Go instead. However, what caught my eye (no pun intended) was how responsive the video and sound were - significantly better than what we are doing in X2Go. So, in the openness of open source, I wonder what we can learn from what they have done to improve X2Go - John
Since most of these WDI offerings are browser-based my guess is that they are passing a link down to the browser and accessing the video and sound through an embedded media player directly rather than playing the media on the server and then passing the output through to the client.
Just a guess.
<snip> That is definitely the case in one scenario. When starting a YouTube video, I was asked it I wanted to allow a redirect and, sure enough, it opened up as a local browsing session on my physical computer. However, if I did not allow redirection (answered no), the video opened in the EyeOS browser and played remarkably well. I'm assuming (ignorantly) that that was not using a local media player - John
I think they are just giving you a choice of viewing the video as embedded or non-embedded.
Either way it's still playing locally.
Regards, Gerry
I think they are just giving you a choice of viewing the video as embedded or non-embedded.
Either way it's still playing locally. <snip> That really got me to thinking this evening as video is still a big
On Tue, 2011-02-22 at 18:42 -0500, Gerry Reno wrote: <snip> problem for us. Every time we present to a school, we hear how important it is to play videos. We are potentially looking at a large PR firm but they are big multimedia users. So, I got to thinking . . .
Could we take a page from the X2Go client printing to do something similar for video? The X2Go printer takes the pdf file and sends it via sshfs to the local system which then can use the associated PDF reader to open it. What if X2GoServer installed a "media player" which did nothing more than take the video stream and send it to the physical computer to be played with whatever player the local system has configured? Doing that with a regular file should be trivial. I'm not sure how one does that with a streaming video but I suppose it would be similar to spooling a print job to a file. We could popup a dialog box (perhaps with a progress indicator) saying we are redirecting the video to the local computer.
The X2Go Client would need another checkbox to activate redirection of video to local computer. If checked, the client would activate a script on the X2Go server via ssh which would backup the existing mime-type associations and edit the association files to make the X2Go media player (spooler might be a better term) the default player for the appropriate mime-types for the specific user. When a session is suspended or terminated, the original mime-types associations are restored.
Browsers might be a bit of a challenge if they are not using default applications for video but we could always edit the rdf files for Firefox (not sure what Chrome uses).
I have a pretty good handle on how mime-type associations are set for KDE, Gnome, and Trinity as well as Firefox and would be willing to determine what those edits need to be if someone else could do the X2Go Client code changes, the X2Go Server script to implement the edits, and the X2Go media spooler itself. Does this sound possible? Thanks - John
On 02/22/2011 08:55 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 18:42 -0500, Gerry Reno wrote: <snip>
I think they are just giving you a choice of viewing the video as embedded or non-embedded.
Either way it's still playing locally.
<snip> That really got me to thinking this evening as video is still a big problem for us. Every time we present to a school, we hear how important it is to play videos. We are potentially looking at a large PR firm but they are big multimedia users. So, I got to thinking . . .
Could we take a page from the X2Go client printing to do something similar for video? The X2Go printer takes the pdf file and sends it via sshfs to the local system which then can use the associated PDF reader to open it. What if X2GoServer installed a "media player" which did nothing more than take the video stream and send it to the physical computer to be played with whatever player the local system has configured? Doing that with a regular file should be trivial. I'm not sure how one does that with a streaming video but I suppose it would be similar to spooling a print job to a file. We could popup a dialog box (perhaps with a progress indicator) saying we are redirecting the video to the local computer.
The X2Go Client would need another checkbox to activate redirection of video to local computer. If checked, the client would activate a script on the X2Go server via ssh which would backup the existing mime-type associations and edit the association files to make the X2Go media player (spooler might be a better term) the default player for the appropriate mime-types for the specific user. When a session is suspended or terminated, the original mime-types associations are restored.
Browsers might be a bit of a challenge if they are not using default applications for video but we could always edit the rdf files for Firefox (not sure what Chrome uses).
I have a pretty good handle on how mime-type associations are set for KDE, Gnome, and Trinity as well as Firefox and would be willing to determine what those edits need to be if someone else could do the X2Go Client code changes, the X2Go Server script to implement the edits, and the X2Go media spooler itself. Does this sound possible? Thanks - John
We just tell clients that if they want really good video performance then their users will need to use a local media player on their client machine to play video.
There's really no good solution to be able to do this from a media player on the remote desktop that delivers any type of acceptable performance.
Maybe when the entire world has 1Gbps internet but otherwise just configure things for a local media player.
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.
Regards, Gerry
On Tue, 2011-02-22 at 21:09 -0500, Gerry Reno wrote:
On 02/22/2011 08:55 PM, John A. Sullivan III wrote:
On Tue, 2011-02-22 at 18:42 -0500, Gerry Reno wrote: <snip>
I think they are just giving you a choice of viewing the video as embedded or non-embedded.
Either way it's still playing locally.
<snip> That really got me to thinking this evening as video is still a big problem for us. Every time we present to a school, we hear how important it is to play videos. We are potentially looking at a large PR firm but they are big multimedia users. So, I got to thinking . . .
Could we take a page from the X2Go client printing to do something similar for video? The X2Go printer takes the pdf file and sends it via sshfs to the local system which then can use the associated PDF reader to open it. What if X2GoServer installed a "media player" which did nothing more than take the video stream and send it to the physical computer to be played with whatever player the local system has configured? Doing that with a regular file should be trivial. I'm not sure how one does that with a streaming video but I suppose it would be similar to spooling a print job to a file. We could popup a dialog box (perhaps with a progress indicator) saying we are redirecting the video to the local computer.
The X2Go Client would need another checkbox to activate redirection of video to local computer. If checked, the client would activate a script on the X2Go server via ssh which would backup the existing mime-type associations and edit the association files to make the X2Go media player (spooler might be a better term) the default player for the appropriate mime-types for the specific user. When a session is suspended or terminated, the original mime-types associations are restored.
Browsers might be a bit of a challenge if they are not using default applications for video but we could always edit the rdf files for Firefox (not sure what Chrome uses).
I have a pretty good handle on how mime-type associations are set for KDE, Gnome, and Trinity as well as Firefox and would be willing to determine what those edits need to be if someone else could do the X2Go Client code changes, the X2Go Server script to implement the edits, and the X2Go media spooler itself. Does this sound possible? Thanks - John
Yes and no. I'll respond below.
We just tell clients that if they want really good video performance then their users will need to use a local media player on their client machine to play video.
There's really no good solution to be able to do this from a media player on the remote desktop that delivers any type of acceptable performance. I agree with this as long as we are using NX.
Maybe when the entire world has 1Gbps internet but otherwise just configure things for a local media player. I agree with this, too. That's the idea of my post.
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 <snip>
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.
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.
A 'Catch-22' scenario that will probably only be solved with future network bandwidth increase.
Regards, Gerry
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.
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.
A 'Catch-22' scenario that will probably only be solved with future network bandwidth increase.
Not if what I propose if feasible or if we find a more video friendly transport. <snip>
On 02/22/2011 11:59 PM, John A. Sullivan III 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.
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.
A 'Catch-22' scenario that will probably only be solved with future network bandwidth increase.
Not if what I propose if feasible or if we find a more video friendly transport.
The only thing you can do is mock up some experiment and see if it works.
I'd be the first to shout 'hooray' if there's something better than the 2 alternatives we face now.
Regards, Gerry
Am 23.02.2011 06:28, schrieb Gerry Reno:
On 02/22/2011 11:59 PM, John A. Sullivan III 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.
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.
A 'Catch-22' scenario that will probably only be solved with future network bandwidth increase.
Not if what I propose if feasible or if we find a more video friendly transport.
The only thing you can do is mock up some experiment and see if it works.
I'd be the first to shout 'hooray' if there's something better than the 2 alternatives we face now.
Regards, Gerry
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Hello,
We have some ideas about redirecting videos to client pc, but currently we have not enough resources to work in this direction.
Regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
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.
Hello, I'm would like to suggest something to complete the third solution. Why don't we offer to the user the possibility to encode with a video stream a particular window. The server don't have to decide to encode or not. You decide to encode only when it' absolutly necessary by a right click on the window and finaly a choice in a menu.
regards,
cédric cavret
ps : sorry for my poor english. I just discovered x2go a couple of months ago and i'm very insterested in it's developpement. Thanks to the developpers for the great job.
Le mercredi 23 février 2011 à 13:12 +0100, Alexander Wuerstlein a écrit :
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.
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
-
Alexander Wuerstlein -
cedric cavret -
Gerry Reno -
John A. Sullivan III -
Oleksandr Shneyder