Seungmin Kim

@ndufresne, maintainer of the v4l2 plugin of GStreamer Good Plugins: ``` yeah, so I'd say, stick with VP8/H264 (and HEVC perhaps) I've seen some activity (of VP9 encoders) on Exynos...

From https://github.com/selkies-project/docker-nvidia-egl-desktop/issues/23: @brianlmerritt NVIDIA Jetson: 1. Compiling GStreamer for AARCH64 (addons/gstreamer) 2. Add nvv4l2h264enc/nvv4l2vp9enc and test 3. Verify all the pipeline works Would be trivial for newbies. https://docs.nvidia.com/jetson/archives/r35.2.1/DeveloperGuide/text/SD/Multimedia/AcceleratedGstreamer.html Nicholas Dufresne...

GST-OMX is deprecated. Stick with v4l2.

xpra-html5, a similar project with a different direction, seems to want to decode audio in a [worker](https://github.com/Xpra-org/xpra-html5/issues/89) or use [Web Audio API](https://github.com/Xpra-org/xpra-html5/issues/64). > Meh. Probably best to use Web Audio...

> The latency problems are almost always client side. I very much doubt that using pipewire server-side will help with anything. This is consistent with our observations so far. @totaam...

Is it possible to take advantage of NACKs and restransmissions without including features that officially requires datacenter GPUs? Looks marvelous nonetheless!

Relevant code: https://github.com/selkies-project/selkies-gstreamer/blob/master/src/selkies_gstreamer/gstwebrtc_app.py

https://chromestatus.com/feature/5177263249162240

Using `webrtcsink` instead of `webrtcbin` may substantially improve or fix this issue. https://github.com/centricular/webrtcsink

https://github.com/centricular/gstwebrtc-demos/issues/102 Interestingly, this issue highlights the same problems as us, and this might be the solution. Why not just turn off the audio syncing? @danisla @xhejtman