Bug 45 - Investigate support for video for Linux applications
Summary: Investigate support for video for Linux applications
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client platforms (show other bugs)
Target Milestone: 4.10.0
Assignee: Pierre Ossman
Depends on:
Blocks: performance
  Show dependency treegraph
Reported: 2002-06-12 19:01 CEST by Anders Subotic
Modified: 2018-09-26 16:09 CEST (History)
0 users

See Also:
Acceptance Criteria:

Mail about the new ZYWRLE encoding (3.71 KB, text/plain)
2007-02-01 09:17 CET, Peter Åstrand

Comment 1 Peter Åstrand cendio 2003-08-21 11:39:29 CEST
Seems like 2.1 will be the "multimedia release". 
Comment 2 Peter Åstrand cendio 2005-10-04 14:37:16 CEST
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. 
Comment 3 Pierre Ossman cendio 2006-05-04 13:41:04 CEST
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.
Comment 4 Pierre Ossman cendio 2006-08-28 10:30:16 CEST
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.
Comment 5 Erik Forsberg cendio 2006-09-19 14:01:07 CEST
The technical group in TUG wants this. 
Comment 6 Peter Åstrand cendio 2006-12-08 10:29:04 CET
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. 
Comment 7 Peter Åstrand cendio 2007-02-01 09:17:07 CET
Created attachment 232 [details]
Mail about the new ZYWRLE encoding

Thie new ZYWRLE encoding from Hitachi Systems & Services, Ltd. looks very
Comment 9 Pierre Ossman cendio 2007-03-19 14:52:35 CET
Time est. according to work in comment #4.
Comment 10 Peter Åstrand cendio 2007-10-10 08:05:18 CEST
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
Comment 11 Pierre Ossman cendio 2007-10-10 12:59:19 CEST
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.)
Comment 12 Pierre Ossman cendio 2013-08-22 11:06:46 CEST
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.
Comment 13 Pierre Ossman cendio 2018-09-26 16:08:50 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.