The slides for a talk I presented at the WebRTC track of IIT-RTC in Chicago, titled "SFU's, Simulcast and SVC: what's new in WebRTC?". Mostly a high-level introduction to how simulcast and SVC work (or not) today in browsers, how they came to be and where they might be headed from a standards perspective.
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Simulcast/SVC @ IIT-RTC 2019
1. SFU’s, Simulcast and SVC
What’s new in WebRTC?
Lorenzo Miniero
@elminiero
IIT Real-Time Communication 2019 – WebRTC Track
October 15th 2019, Chicago, IL, USA
2. A few words about me
Lorenzo Miniero
• Ph.D @ UniNA
• Chairman @ Meetecho
• Main author of Janus®
Contacts and info
• lorenzo@meetecho.com
• https://twitter.com/elminiero
• https://www.slideshare.net/LorenzoMiniero
6. Simulcast in a nutshell
https://webrtchacks.com/sfu-simulcast/
7. SVC as a different way to encode multiple tracks
https://webrtchacks.com/chrome-vp9-svc/
8. Simulcast vs. SVC
• Simulcast
• Same source, same m-line
• Streams of different “quality” are separate tracks
• Each track is a different SSRC
• Each track can be decoded indepedently from others
• SVC
• Same source, same m-line
• Streams of different “quality” are layers of the same “thing”
• All tracks share the same SSRC (since they’re layers)
• Each track depends on the previous to be decoded
• Less bandwidth, but more CPU intensive
Fun fact – Simulcast in browsers also enables temporal scalability
Allows to drop to lower framerate without sacrificing quality
9. Simulcast vs. SVC
• Simulcast
• Same source, same m-line
• Streams of different “quality” are separate tracks
• Each track is a different SSRC
• Each track can be decoded indepedently from others
• SVC
• Same source, same m-line
• Streams of different “quality” are layers of the same “thing”
• All tracks share the same SSRC (since they’re layers)
• Each track depends on the previous to be decoded
• Less bandwidth, but more CPU intensive
Fun fact – Simulcast in browsers also enables temporal scalability
Allows to drop to lower framerate without sacrificing quality
10. Simulcast vs. SVC
• Simulcast
• Same source, same m-line
• Streams of different “quality” are separate tracks
• Each track is a different SSRC
• Each track can be decoded indepedently from others
• SVC
• Same source, same m-line
• Streams of different “quality” are layers of the same “thing”
• All tracks share the same SSRC (since they’re layers)
• Each track depends on the previous to be decoded
• Less bandwidth, but more CPU intensive
Fun fact – Simulcast in browsers also enables temporal scalability
Allows to drop to lower framerate without sacrificing quality
11. Both only make sense with an SFU on the path
• Browsers can’t negotiate receiving part of simulcast
• ... unless you’re Philipp Hancke’s browser!
• https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
• It wouldn’t make much sense anyway!
• Why receive all “versions” when you only need one?
• Job for a Selective Forwarding Unit!
• Pretty much all SFU’s support simulcast today
• Janus (wink wink! )
• Jitsi
• mediasoup
• Medooze
• ...
• Most support some flavour of SVC as well (more on that later)
12. Both only make sense with an SFU on the path
• Browsers can’t negotiate receiving part of simulcast
• ... unless you’re Philipp Hancke’s browser!
• https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
• It wouldn’t make much sense anyway!
• Why receive all “versions” when you only need one?
• Job for a Selective Forwarding Unit!
• Pretty much all SFU’s support simulcast today
• Janus (wink wink! )
• Jitsi
• mediasoup
• Medooze
• ...
• Most support some flavour of SVC as well (more on that later)
13. Both only make sense with an SFU on the path
• Browsers can’t negotiate receiving part of simulcast
• ... unless you’re Philipp Hancke’s browser!
• https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
• It wouldn’t make much sense anyway!
• Why receive all “versions” when you only need one?
• Job for a Selective Forwarding Unit!
• Pretty much all SFU’s support simulcast today
• Janus (wink wink! )
• Jitsi
• mediasoup
• Medooze
• ...
• Most support some flavour of SVC as well (more on that later)
14. Both only make sense with an SFU on the path
• Browsers can’t negotiate receiving part of simulcast
• ... unless you’re Philipp Hancke’s browser!
• https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
• It wouldn’t make much sense anyway!
• Why receive all “versions” when you only need one?
• Job for a Selective Forwarding Unit!
• Pretty much all SFU’s support simulcast today
• Janus (wink wink! )
• Jitsi
• mediasoup
• Medooze
• ...
• Most support some flavour of SVC as well (more on that later)
15. Both only make sense with an SFU on the path
• Browsers can’t negotiate receiving part of simulcast
• ... unless you’re Philipp Hancke’s browser!
• https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/
• It wouldn’t make much sense anyway!
• Why receive all “versions” when you only need one?
• Job for a Selective Forwarding Unit!
• Pretty much all SFU’s support simulcast today
• Janus (wink wink! )
• Jitsi
• mediasoup
• Medooze
• ...
• Most support some flavour of SVC as well (more on that later)
16. Tackling simulcast at the IETF 104 hackathon
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon/webrtc
32. Why remove the SSRC from the SDP?
• Many implementations rely on the SSRC for demultiplexing
• RTP/RTCP from multiple streams all muxed together
• SSRC used to recognize one stream from another
• Missing SSRCs break most of those applications
• Chrome’s perspective: the problem of mapping “rid” to “ssrc”
• Both are in the SDP, but how are they mapped?
• Order-based just a convention, and at the time not specified anywhere
• https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00
Solution: parse rid RTP extension on the recipient side
• SSRC in related packet allows for specific rid↔ssrc association
• Once you know the SSRC, keep on multiplexing on that
33. Why remove the SSRC from the SDP?
• Many implementations rely on the SSRC for demultiplexing
• RTP/RTCP from multiple streams all muxed together
• SSRC used to recognize one stream from another
• Missing SSRCs break most of those applications
• Chrome’s perspective: the problem of mapping “rid” to “ssrc”
• Both are in the SDP, but how are they mapped?
• Order-based just a convention, and at the time not specified anywhere
• https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00
Solution: parse rid RTP extension on the recipient side
• SSRC in related packet allows for specific rid↔ssrc association
• Once you know the SSRC, keep on multiplexing on that
34. Why remove the SSRC from the SDP?
• Many implementations rely on the SSRC for demultiplexing
• RTP/RTCP from multiple streams all muxed together
• SSRC used to recognize one stream from another
• Missing SSRCs break most of those applications
• Chrome’s perspective: the problem of mapping “rid” to “ssrc”
• Both are in the SDP, but how are they mapped?
• Order-based just a convention, and at the time not specified anywhere
• https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-00
Solution: parse rid RTP extension on the recipient side
• SSRC in related packet allows for specific rid↔ssrc association
• Once you know the SSRC, keep on multiplexing on that
39. Currently only available in Chrome, and behind a flag
/opt/google/chrome/google-chrome
--user-data-dir=/home/user/customprofile
--no-first-run
--force-fieldtrials=
WebRTC-SupportVP9SVC/EnabledByFlag_2SL3TL/
40. Testing VP9 SVC in Chrome
https://www.meetecho.com/blog/vp9-svc-in-janus-meetecho-cosmo/
41. AV1 is coming! (and SVC is mandated)
https://aomediacodec.github.io/av1-spec/
