Xpra: Ticket #510: video stream pass-through
Similar to #509 and related to #410: we could register a dummy libva video decoder and most video players/browsers would talk to it instead of the X11 server, we can then grab the raw
vp8 stream from it, saving us the cost of decoding it on the server then re-encoding it ourselves!
- handling clients (re-)connecting after the stream has started playing: we cannot force key frames to appear when we need them... so we have to wait for the stream to produce one, until then the client won't be able to decode anything.. we can replace it with a static image telling the user to pause/restart the stream
- sound: each stream has its own sound (usually), so this makes our sound forwarding a little redundant for this use case - this is not a real problem, in fact this makes audio-video synchronization a trivial issue
- security: this pass-through exposes clients to remote input..
- bandwidth: we cannot control the video bandwidth used, and if the server has more bandwidth connecting to the Internet server sending the video than it has to the client consuming it... we will have problems. This one is hard to solve.
Mon, 13 Jul 2015 05:26:23 GMT - rektide: cc set
Mon, 23 Jan 2017 07:44:57 GMT - Antoine Martin: milestone changed
changed from 1.0 to 3.0
#56 will have to come first.
Tue, 19 Sep 2017 08:20:42 GMT - Antoine Martin: milestone changed
changed from 3.0 to 2.3
No progress on #56, re-scheduling.
Wed, 28 Mar 2018 05:10:05 GMT - Antoine Martin: milestone changed
changed from 2.3 to future
Probably easier to just implement a wayland backend (#387) which will give us a surface for video.
Sat, 23 Jan 2021 04:57:50 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/510