Opened 7 years ago
Last modified 5 months ago
#510 new enhancement
video stream pass-through
| Reported by: | Antoine Martin | Owned by: | Antoine Martin |
|---|---|---|---|
| Priority: | major | Milestone: | future |
| Component: | core | Version: | |
| Keywords: | Cc: | rektide@… |
Description
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 h264 or vp8 stream from it, saving us the cost of decoding it on the server then re-encoding it ourselves!
Potential problems:
- 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.
Change History (5)
comment:2 Changed 6 years ago by
| Cc: | rektide@… added |
|---|
comment:5 Changed 4 years ago by
| Milestone: | 1.0 → 3.0 |
|---|
comment:8 Changed 3 years ago by
| Milestone: | 2.3 → future |
|---|
Probably easier to just implement a wayland backend (#387) which will give us a surface for video.
comment:9 Changed 5 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/510
Note: See
TracTickets for help on using
tickets.
copyleft 2010 - 2021
#56 will have to come first.