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 ...
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.
Size: 1.93 MB
Language: en
Added: Oct 16, 2019
Slides: 48 pages
Slide Content
SFU's, Simulcast and SVC
What's new in WebRTC?
Lorenzo Miniero
@elminiero
IIT Real-Time Communication 2019 WebRTC Track
October 15
th
2019, Chicago, IL, USA
A few words about me
Lorenzo Miniero
Ph.D @ UniNA
Chairman @ Meetecho
Main author of Janus
®
Contacts and info [email protected]
https://twitter.com/elminiero
https://www.slideshare.net/LorenzoMiniero
Simulcast in a nutshell
https://webrtchacks.com/sfu-simulcast/
SVC as a different way to encode multiple tracks
https://webrtchacks.com/chrome-vp9-svc/
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 sacricing quality
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 sacricing quality
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 sacricing quality
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 SelectiveForwarding Unit!
Pretty much all SFU's support simulcast today
Janus (wink wink!
)
Jitsi
mediasoup
Medooze
...
Most support some avour of SVC as well (more on that later)
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 SelectiveForwarding Unit!
Pretty much all SFU's support simulcast today
Janus (wink wink!
)
Jitsi
mediasoup
Medooze
...
Most support some avour of SVC as well (more on that later)
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 SelectiveForwarding Unit!
Pretty much all SFU's support simulcast today
Janus (wink wink!
)
Jitsi
mediasoup
Medooze
...
Most support some avour of SVC as well (more on that later)
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 SelectiveForwarding Unit!
Pretty much all SFU's support simulcast today
Janus (wink wink!
)
Jitsi
mediasoup
Medooze
...
Most support some avour of SVC as well (more on that later)
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 SelectiveForwarding Unit!
Pretty much all SFU's support simulcast today
Janus (wink wink!
)
Jitsi
mediasoup
Medooze
...
Most support some avour of SVC as well (more on that later)
Tackling simulcast at the IETF 104 hackathon
https://trac.ietf.org/trac/ietf/meeting/wiki/104hackathon/webrtc
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 specied 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 specic rid$ssrc association
Once you know the SSRC, keep on multiplexing on that
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 specied 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 specic rid$ssrc association
Once you know the SSRC, keep on multiplexing on that
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 specied 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 specic rid$ssrc association
Once you know the SSRC, keep on multiplexing on that
Mapping rid values to SSRC
Mapping rid values to SSRC
Testing rid-based simulcasting via sendEncodings
https://www.meetecho.com/blog/simulcast-janus-ssrc/
What about SVC?
https://webrtchacks.com/chrome-vp9-svc/
Currently only available in Chrome, and behind a ag
/opt/google/chrome/google-chrome
--user-data-dir=/home/user/customprofile
--no-first-run
--force-fieldtrials=
WebRTC-SupportVP9SVC/EnabledByFlag_2SL3TL/
Testing VP9 SVC in Chrome
https://www.meetecho.com/blog/vp9-svc-in-janus-meetecho-cosmo/
AV1 is coming! (and SVC is mandated)
https://aomediacodec.github.io/av1-spec/