3 ms·
That's a cool problem! I could see how WebRTC out of the box would perform poorly. It wants to NACK + delay to give a good 'conferencing experience'. I bet wi
by Sean-Der 3y ago
That's a cool problem!
I could see how WebRTC out of the box would perform poorly. It wants to NACK + delay to give a good 'conferencing experience'.
I bet with FlexFEC [0] and playout-delay [1] you would get the behavior you were looking for. The sender would have to be custom, but the receivers (browsers) should just work! If you are interested in giving it a shot again would love to help :)
[0] https://datatracker.ietf.org/doc/html/rfc8627 https://datatracker.ietf.org/doc/html/rfc8627
[1] https://webrtc.googlesource.com/src/+/main/docs/native-code/rtp-hdrext/playout-delay/README.md https://webrtc.googlesource.com/src/+/main/docs/native-code/...
- tamimio 3y agoIt was an interesting problem indeed! I had some write up about it (and the whole project) in a link I have in the comment above, might gives more context. > I bet with FlexFEC [0] The previous draft (1) of this was my basis when I did the FEC sender. I didn’t manage to have it streamed 4K into the browser though, my client was OBS with gstreamer as it was far more performant than a browser in my tests, have you/any demo you did that I can try to stream it into the browser? That would be really major improvement! And appreciate the help, O would definitely give it another shot! (1) https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-20 https://datatracker.ietf.org/doc/html/draft-ietf-payload-fle...