[1.x] VP9 SVC room not working.

[faihan6]

What version of Janus is this happening on?
1.1.3

Have you tested a more recent version of Janus too?
No.

Was this working before?
I am not sure.

Is there a gdb or libasan trace of the issue?
No.

Additional context
We have a demo VP9 SVC room to test chrome's Spatial SVC capabilities. Chrome has now made it possible that we can enable Spatial Scaling using the 'scalabilityMode' property via addTransceiver. The respective Chrome beta version is 111.0.5563.19.

I tried accessing the VP9 SVC demo room with two participants from the above mentioned browser and SVC was not working. The SVC selection controls above the feeds were not present.

I tried the same with Stable Chrome using the flag --force-fieldtrials=WebRTC-SupportVP9SVC/EnabledByFlag_2SL3TL/ and I got same results.

Upon checking the webrtc-intenals, I could see that the scalabilityMode parameter was not present in the outbound-rtp stat. I checked the JS code and looks like we are missing to add the SVC parameter in the track object.

Commit 961b576 - File vp9svctest.js, Line 437
tracks.push({ type: 'video', capture: true, recv: false, simulcast: false, svc: 'S3T3'});

Making this change enabled VP9 SVC from the browser. I could see the scalabilityMode parameter now and the framesSent/s parameter has also doubled indicating that SVC is indeed working on the browser's end. However, the SVC controls on the video feeds were not present yet.

I checked the Source code of Janus Server and looks like the janus_videoroom_publisher_stream object of the appropriate mid will have a svc property and it has to be set to 1 for SVC to work. Unfortunately it has not been set.

I manually set the value to 1 by adding if(!ps->svc) ps->svc = 1; (inserted at line 8462. Filename: janus_videoroom.c. Same commit as mentioned above) and added logs to the janus_vp9_parse_svc function. It worked like a charm! I could see Two (not three unfortunately) spatial layers and Three temporal layers in the logs and SVC controls had now appeared in the browser. Clicking on those controls also changed the incoming resolution and framerate as expected.

I hope that's enough information to debug this issue. Thank you.

[lminiero]

I checked the Source code of Janus Server and looks like the janus_videoroom_publisher_stream object of the appropriate mid will have a svc property and it has to be set to 1 for SVC to work. Unfortunately it has not been set.

Yeah, apparently it's something we didn't fully port when working on the multistream branch. In 0.x, participants don't have an SVC property at all: only the room does, and in an SVC room all video packets are assumed to be SVC. In 1.x, SVC is a property of individual publisher streams, but we never set it since there is no way to figure out a video stream uses SVC from the SDP.

The easiest fix in the short term may be to do the same in 1.x, and so set ps->svc to whatever room->do_svc is. That said, in the future I think I'll just get rid of the SVC property in rooms, and the SVC demo too, and will instead change the default VideoRoom to allow you to publish using SVC (which it partly does already with AV1), since there's no reason why regular/simulcast/SVC streams can't coexist as long as the proper codecs are used.

[lminiero]

I made the simple change I anticipated in the plugin code itself, meaning that if the room is SVC, then the publisher stream will be marked as SVC as well. As discussed, later on I'll streamline that part so that SVC is advertised in other ways.

As a side note, I also modified the demo description so that it removes any reference to those old flags, and mentions scalabilityMode instead. As a result, I configured the demo code to indeed pass svc: "S3T3" as a scalability mode. Notice that I changed the default bitrate for the VP9-SVC demo room from 512000 to 0, which means "no limit": in fact, you wrote

I could see Two (not three unfortunately) spatial layers and Three temporal layers

but I actually got all three spatial layers to work when I tweaked the participant's bandwidth to "no limit". Since it was ~512kbps before, that meant the browser only sent layers 0 and 1, but not 2 (the highest) since it thought it had no bandwidth for that too.