Seems like 2.1 will be the "multimedia release".
One idea is to add support for some video format such as MPEG. The server could "transcode" the video stream to MPEG and transfer it over VNC or a separate SSH tunnel. One advantage with this solution is that we don't need hundreds of codecs on the client. One disadvantage is that in worst case, the server will need to re-code every frame. According to Ossman, the X11 extension XV might be useful. Christian Nygaard mentions the VideoLan and Avidemux project.
By accident, I discovered that Xv actually works across the network. The performance was so good that it wasn't possible to tell that it wasn't a local application. This demonstrates that it is possible to network abstract video playback, although a LAN probably is required when running without compression.
Implementing this requires several steps. The time estimations are very rough guesses as I have no experience in Xv or the transformations necessary: * Implement Xv in the Xvnc server. (24h) * Implement a server side renderer for old clients. (16h) * Implement a protocol for transferring the images. (16h) * Include renderer in the clients. (16h) On top of this, a number of optimisations can be done: * Resize support on server to reduce needed bandwidth. * Compression support. * Xv support on client. * General optimisations of routines, possibly using assembly libs.
The technical group in TUG wants this.
Ossman, Calmblad and I discussed this today. Multimedia and streaming video is currently very hot. Hot enough to be discussed for 1.6. Ossman presented the Xv solution and it does indeed looks interesting. The main drawback is that it's "Linux-only": It does not enhance video playback from a WTS. Doing that is a separate (very large) task.
Created attachment 232 [details] Mail about the new ZYWRLE encoding Thie new ZYWRLE encoding from Hitachi Systems & Services, Ltd. looks very interesting.
Time est. according to work in comment #4.
Const has added support for hardware accelerated JPEG video compression in TightVNC. Log message for rev 2358: Added support for new UseHardwareJPEG parameter ("Use hardware-accelerated JPEG compressor for video if available") which is 'true' by default. Also, in IRIX, if IrixDMJpegCompressor fails to initialize, we use StandardJpegCompressor instead. This way, video will be transmitted even if we could not open hardware JPEG compressor.
Unfortunately, "video" here seems to mean "region with video like data". So what has been implemented is a generic JPEG accelerator, not video support. (Actually the JPEG accelerator was already there, the new commit just added a config option and a proper fallback.)
I wonder how relevant this is these days. I'm don't know how much still uses Xv. And we have our accelerated JPEG that handles the general case.
Not interesting as described. There are many more cases where we need fast graphics besides video so we need something generic. Closing in favour of general performance improvements via bug 5106.
