Gate One Will Support X11: Fast Enough To Run VLC In Your Browser 164
Riskable writes "Ever seen a remote desktop tool that's fast/efficient enough to play back video? Gate One will soon have that capability via the forthcoming X11 support (as demonstrated in the video). I am posting this to Slashdot looking for suggestions and feedback as to how I should move forward with it before I solidify the architecture, API, and even the business end of it (making money). I'll be watching the thread and replying to comments (as I have time). Also, if you're interested you can sign up to be notified when it's available."
We've posted a few stories about Gate One previously.
Ever seen...? (Score:5, Informative)
Re:The network says no (Score:5, Informative)
I think the minor detail that was lost in the slashvertisement was that gate one eliminated the need for remote desktop software by being browser based and its performance is at least comparable to other remote desktop software.
In addition, the author is offering to add X terminal emulation as a feature.
I don't think he meant to pass it off as the fastest possible protocol out there.
what is Gate One? (Score:5, Informative)
Gate One is an HTML5 web-based terminal emulator and SSH client.
Re:The network says no (Score:5, Informative)
If you have an otherwise decent connection you should be able to play 1080p just fine. If you can't, your ISP is probably sending the traffic to one of the massively overloaded mirrors they run. You can block them easily by following the directions here [mitchribar.com] for Linix or here [mitchribar.com] for Windows. Or you can apply the same rules at your router to take care of the issue for your whole network.
Re:The network says no (Score:4, Informative)
I hear what you're saying and I agree that network latency is one of the biggest problems. Having said that, I have performed testing with my home Comcast Internet connection with Gate One running on a Rackspace cloud instance (512MB). The latency is negligible. My ping time to that server was a pretty steady ~50ms and apps like Chrome (yes, Chrome inside Chrome), LibreOffice (Calc/Writer), Sublime Text 2, kate, etc worked very well.
Re:what is Gate One? (Score:5, Informative)
That's what it is right now. Soon it will be so much more.
X11 is just the start. I also have File Transfer and other apps in the works. The File Transfer app will be interesting... It will be more than just an, "SFTP client." It will allow you to fetch a file from just about any URL (back-end is already written and supports ftp:// [ftp] sftp://, ftps://, magnet://, and even dns://, dict:// and other obscure things which I think makes it all that more interesting/useful) and deliver it to any number of destinations you like. Even if the destination uses a different protocol.
So for example, if you wanted to download a magnet/bittorrent URL and have it automatically delivered to your home theater PC, your phone, and your brother's computer when complete you could do that.
Re:RDP - Win8 client to a Win2012 backend - very f (Score:5, Informative)
What is the CPU load while watching a video over RDP? I'm genuinely curious.
For reference, the gateone.py process(es) hover around 5% utilization when playing back a video @30fps (~720p resolution). Here's what it's doing while a video is playing back:
1) Capture the screenshot of the changed region on the X11 display. It can do this every 33ms (a capped equivalent to 30fps). It only needs to take screenshots when there's a change but in the case of a video it happens very fast, hence the 33ms cap.
2) Convert the raw captured image to selected format (JPEG for this example). It also makes a hash of the image that's used by both the server and client JS for caching purposes.
3) Transmit the image to the browser. If the image has recently been sent to the client it will be aware of this and will only send the hash. This transmission occurs in binary mode over the WebSocket (it's complicated).
From that point it's up to the client-side JavaScript to handle displaying the raw JPEG data. It is quite CPU-intensive if your hardware doesn't accelerate 2d canvas elements but not too bad (Chrome will hog around 50-80% of a single core while the video plays). Everything will remain responsive regardless.
For reference, I've done extensive benchmarking of the browser-side CPU utilization and Chrome's developer tools will report 81% idle even when the actual CPU consumption of the process is nearing 80%. That means that all the overhead is inside the code that renders canvas elements; which is good because it means my JavaScript is not a bottleneck.
Re:The network says no (Score:5, Informative)
Then, I'm afraid you might not have enough practical experience on the topic.
I've encountered performance issues across an organization, and definitely been able to identify it as network latency.
And when we spoke with the network architects, they essentially told us it could be made no faster because of the distances involved. I'm not talking trans-continental/trans-oceanic links, I'm talking two data centers separated by only about a thousand miles.
And, with the latency issues, we can't make some things responsive enough to interactive users to not be exceedingly painful. A 60-100ms latency is enough to have users screaming at you as everything they do has a long delay in it -- for interactive applications, that's very noticeable.
You don't need to have data centers on Mars to be able to experience latency which is exceedingly painful. Within the last few months I've personally ran up against it in an organization which has offices through North America.
If you're just mirroring data, sure. But running an interactive application over a long-distance link for which latency becomes a factor -- that can be very painful. And even within North America, you can easily get to the point where the latency can't be fixed because the signal can still only travel so fast.
It really doesn't take all that much distance before it becomes observable. And angry/frustrated users don't want to be told about the laws of physics. They want to be able to click a button and not wait several seconds.
Re:The network says no (Score:5, Informative)
Reading your comment makes me think you'll love Gate One's ability to resume your session--even after restarting the process. I'll give you a hypothetical example:
1) I connect to https://gateone.mycompany.com/ [mycompany.com] and open up LibreOffice Calc.
2) I connect to the server running Gate One via SSH and run "/etc/init.d/gateone stop"
3) The web page reports it has been disconnected but it will retry connecting every five seconds.
4) I run "/etc/init.d/gateone start"
5) The web page reconnects to the Gate One server and my spreadsheet is back in front of me--right where i left it.
That works with terminals too if you install the dtach command. Everything will resume right where you left off even after killing and restarting the gateone.py process. This makes upgrading Gate One about as easy as can be; users will experience ~5 seconds of down time while the upgrade takes place and the process is restarted.
Re:The network says no (Score:4, Informative)
I'm going to do everything in my power to make sure your use case works because I want to be able to do that too! I also want to be able to pick up where I left off if I have to work on something while I'm out & about. Just whip out my Chromebook and I'm coding using the desktop (or just the app) I left behind.
So yeah, I just gave away an interesting feature: If you're using a Linux desktop (like I do) and you fire up Gate One it can connect to the existing X11 display and forward just the app you want it to. It doesn't have to be the entire desktop.
Re:The network says no (Score:5, Informative)
Three reasons this isn't all that "insightful" (sorry):
1) two hours to encode a two hour movie is real time.
2) 1080p h.264 video encoders are available in $10 chips. Or if you don't want dedicated hardware for it, it can also be done on a PC at good quality using a half-decent GPU.
3) there are already decent examples of this being done in the real world - OnLive, GaiKai, etc. So it's clearly not only plausible, but working.
Re:The network says no (Score:4, Informative)
Well, it probably does real time encodes of 24 FPS content, but perhaps would struggle a bit more with 60 FPS+ Desktop content. Likewise, if the content is photographic, the compression artifacts tend to be less noticeable. Have some simple shapes and bright colors with crisp edges like a GUI in the mix, and you tend to need much higher quality than with photographic content. Even doing the encode in real time at adequate quality, you are probably encoding to a long GOP codec which has quite a lot of inherent latency. If the GOP size adds 1 second of latency, it doesn't matter how much CPU and bandwidth you throw at the problem, it would still be very bad for real time interactive uses.
* (Used to be an Engineer responsible for dealing with remote sites and technology for real time remote color grading sessions transmitted over the internet and over private WAN links using H.264 and JP2K based codecs mostly for TV commercials.)