Hi, I've just pushed the code for Scalable Video Coding (SVC) to the branch "svc" of the github repository; be aware that I will be rebasing this branch. It's currently running on galene.org port 8444 (but not port 8443, which is running stable 0.3.5). SVC is a technique where a single video stream is "layered": frames are labelled with information about whether they can be dropped, and the server can reduce the bitrate sent to a client. The advantage of SVC over simulcast is that switching layers is a much more lightweight operation: switching simulcast streams requires a keyframe, while switching scalable layers can happen a few times per packet. SVC requires no support on the receiver side -- it's the sender who does the layering, the receiver receives a perfectly banal video stream. Sending a scalable stream is controlled by the simulcast switch, due to some limitations in both Chrome/Chromium and Firefox, so you cannot have SVC without simulcast. Which is a waste, but what can I do. You can test by enabling simulcast then testing the "stats.html" page; the layer chosen for each down track is indicated before the bitrate. Temporal scalability (reducing the framerate) is supported for both VP8 and VP9; unfortunately, I wasn't able to test the VP9 support, since my version of Chromium immediately crashes when you request a VP9 simulcast stream. Spacial scalability (reducing the resolution) should be doable for VP9, but the point is somewhat moot until Chromium fix their bug. -- Juliusz
On Wed, May 12, 2021 at 8:19 AM Juliusz Chroboczek <jch@irif.fr> wrote: > > Hi, > > I've just pushed the code for Scalable Video Coding (SVC) to the branch > "svc" of the github repository; be aware that I will be rebasing this > branch. It's currently running on galene.org port 8444 (but not port > 8443, which is running stable 0.3.5). > > SVC is a technique where a single video stream is "layered": frames are > labelled with information about whether they can be dropped, and the > server can reduce the bitrate sent to a client. The advantage of SVC over > simulcast is that switching layers is a much more lightweight operation: > switching simulcast streams requires a keyframe, while switching scalable > layers can happen a few times per packet. This is a really, really promising sounding technique! > SVC requires no support on the receiver side -- it's the sender who does > the layering, the receiver receives a perfectly banal video stream. > Sending a scalable stream is controlled by the simulcast switch, due to > some limitations in both Chrome/Chromium and Firefox, so you cannot have > SVC without simulcast. Which is a waste, but what can I do. Currently. As both these are open source they can certainly be improved. I haven't hacked on firefox in quite some time... I can reach out to some contacts in the mozilla organization and/or is there a good mailing list to join? > You can test by enabling simulcast then testing the "stats.html" page; the > layer chosen for each down track is indicated before the bitrate. > > Temporal scalability (reducing the framerate) is supported for both VP8 > and VP9; unfortunately, I wasn't able to test the VP9 support, since my > version of Chromium immediately crashes when you request a VP9 simulcast > stream. Spacial scalability (reducing the resolution) should be doable > for VP9, but the point is somewhat moot until Chromium fix their bug. Have you reported it? > > -- Juliusz > _______________________________________________ > Galene mailing list -- galene@lists.galene.org > To unsubscribe send an email to galene-leave@lists.galene.org -- Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave Täht CTO, TekLibre, LLC
>> SVC is a technique where a single video stream is "layered": frames are >> labelled with information about whether they can be dropped, and the >> server can reduce the bitrate sent to a client. The advantage of SVC over >> simulcast is that switching layers is a much more lightweight operation: >> switching simulcast streams requires a keyframe, while switching scalable >> layers can happen a few times per packet. > This is a really, really promising sounding technique! Yes, I find it exciting too. You can essentially switch layers every 100ms or so, with no disturbing artifacts, so you can react to fine-grained congestion control feedback. You'll be glad to know that SVC is tightly integrated in AV1. > Currently. As both these are open source they can certainly be > improved. I haven't hacked on firefox in quite some time... I can reach > out to some contacts in the mozilla organization and/or is there a good > mailing list to join? The current situation is a mess: - both Chromium and Firefox tie together simulcast and SVC for VP8; - Chromium does weird things when attempting simulcast VP9; - Debian's Chromium crashes when attempting simulcast VP9; - Firefox uses a non-standard protocol for simulcast. For now, I'm just disabling simulcast/SVC when the sender is Firefox. Jitsi appear to implement Firefox's protocol for simulcast, we should probably do the same in Pion. >> unfortunately, I wasn't able to test the VP9 support, since my version >> of Chromium immediately crashes when you request a VP9 simulcast >> stream. I've found a version of Brave that doesn't crash. However, it doesn't seem to actually send either simulcast or a scalable stream. So it's going to be VP8-only for now. >> Spacial scalability (reducing the resolution) should be doable for VP9, >> but the point is somewhat moot until Chromium fix their bug. > > Have you reported it? I've reported it with Debian, since Brave is based on the same version of Chromium and doesn't crash. I've talked to Lorenzo Miniero (the Janus guy), and he hasn't seen that bug. The crash is immediately reproducible here: https://janus-legacy.conf.meetecho.com/echotest.html?simulcast2=true&vcodec=vp9 With my version of Chromium, clicking "Start" leads to an immediate crash. -- Juliusz
> - both Chromium and Firefox tie together simulcast and SVC for VP8; Here's the Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=986069