You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
orvp8
stream from it, saving us the cost of decoding it on the server then re-encoding it ourselves!Potential problems:
The text was updated successfully, but these errors were encountered: