Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Achieve higher efficiency and quality in low-bandwidth and high-latency environments #152

Open
ehfd opened this issue May 9, 2024 · 0 comments
Labels
encoding Audio or video encoders but not the OS interfaces enhancement New feature or request help wanted External contribution is required interface OS input, display, or audio interfaces performance Performance or latency issues, not critical but impacts usage transport Underlying media or data transport protocols web Web components including gst-web

Comments

@ehfd
Copy link
Member

ehfd commented May 9, 2024

In low-bandwidth environments (under 2 mbps), while still acceptable, there is a cross in terms of performance and quality (starting from 1920x1080 FHD) compared to VNC.

This is because:

  1. We do not use XDamage with ximagesrc, which can differentiate between updated parts of the screen and those that are not updated (but leads to issues in higher bandwidth videos and thus disabled by default).
  2. We do not adapt encoder settings in low bandwidth environments to prefer not blurring while sacrificing performance with fullscreen refreshes (which leads back to number one).
  3. MJPEG, which is suited for partial screen refresh and is the core codec for various VNC implementations, is not applicable with WebRTC MediaStream (but may be applicable with WebRTC DataChannels, WebTransport or WebSocket, combined with nvjpegenc and vajpegenc hardware encoders).
  4. Most importantly, keyframes (also called IDR frames in H.264 and H.265), which are required to reestablish the video when the stream is down, lead to congestion because of their notably large size (often multitudes) compared to normal P-frames. No longer default.

(WebP is essentially VP8 and VP9, so it technically is already incorporated, but not optimized enough for the above scenarios.)

This should technically be possible within GStreamer, provided that various parameters are explored.

@ehfd ehfd added enhancement New feature or request help wanted External contribution is required encoding Audio or video encoders but not the OS interfaces transport Underlying media or data transport protocols performance Performance or latency issues, not critical but impacts usage web Web components including gst-web interface OS input, display, or audio interfaces labels May 9, 2024
@ehfd ehfd changed the title Achieve higher efficiency and quality in low-bandwidth environments Achieve higher efficiency and quality in low-bandwidth and high-latency environments May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
encoding Audio or video encoders but not the OS interfaces enhancement New feature or request help wanted External contribution is required interface OS input, display, or audio interfaces performance Performance or latency issues, not critical but impacts usage transport Underlying media or data transport protocols web Web components including gst-web
Projects
None yet
Development

No branches or pull requests

1 participant