Closed Bug 1392961 Opened 4 years ago Closed 4 years ago

Make VP9 the default decoder/encoder by default


(Core :: WebRTC: Signaling, enhancement, P2)




Tracking Status
firefox57 --- wontfix
firefox58 --- fixed


(Reporter: jya, Assigned: jya)


(Depends on 1 open bug)



(1 file)

This will be a meta-bug to track the progress of switching to VP9 as default codec for both encoder and decoder.

This will allow to use HW acceleration on machines supporting it.
Depends on: 1392962
Rank: 15
Priority: -- → P1
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Has this been tested with major services 1:1 and in conference (both mesh, and SFU-based when it's in SFU mode), and also in these situations with interop/heterogeneous calls with Chrome (and perhaps Edge, though I don't think it does VP9 currently in webrtc) and Safari (which doesn't support VP9 or VP8 at all -- don't expect problems there).

What's the difference in CPU load in a 1:1 call (SW decode/encode) in a few services, and in a conference?  
What about when screen-sharing an HD screen?

This isn't to say I'm against this change... I think overall this would be good.   (There are optimizations one might do in heavy conferences or when CPU is limited but BW doesn't appear to be -- switch to VP8 to cut CPU cost -- but those are optional follow-ons)
Comment on attachment 8920131 [details]
Bug 1392961 - Add preference to make VP9 the preferred video codec.

r+ to the code; want to see the other questions answered before we land (or at least some data)
Attachment #8920131 - Flags: review?(rjesup) → review+
Comment on attachment 8920131 [details]
Bug 1392961 - Add preference to make VP9 the preferred video codec.

Without having run this patch I'm pretty sure it's only choosing VP9 out of the list of codecs. But you are not offering it in the SDP with a higher preference then VP8. To also offer VP9 with higher preference you will need to make changes here
Attachment #8920131 - Flags: review-
Component: WebRTC: Audio/Video → WebRTC: Signaling
the sdp list all codecs as before, but now vp9 is at the top of the list, (while vp8 used to be prior this change)

The change modifies how the sorting is done. The comparator used in the sort is where the change occurs.

The pref does the same thing (excep the you can set which codec)

And for the comparator:

A look into about:webrtc shows that vp9 is used between two Firefox clients by default.
If on one client, vp9 is removed from the sdp, it will negotiate vp8 as expected.

The order in which codec are pushed in JsepSessionImpl do not appear to matter, they will be sorted after.
Interesting that it even sorts the offer properly. But another problem remains: all gtests don't use (I think they can't) preferences. Therefore all of our gtests runs still with VP8 as the perferred codec. The only way to switch them is by changing the order of the codecs.

I think it's good to have/get a pref to be able to make VP9 the preferred codec. But since the patch as is enables it for everyone I'm strongly opposed to land it as is. If it lands with the default switched to off and it then gives us the ability to turn it on for a certain percentage for example through a shield study or a test-pilot thing.

I would prefer if we turn it on for a certain percentage of our users if we can also find a way to have our gtests run in that configuration. For example run them twice, once with VP8 as the most preferred and once with VP9 as most preferred.
Why would it matter that the gtest can't set preferences in this instance?
It would be using the default. There are no preferences to set.

I was only pointing at the preference as this was until this proposed change, the way to change which codec would be made the preferred one; to highlight the fact that to make a codec preferred there was only one spot to change.
Sorting is done there:

It is unfortunate that we have discussed at length on why we wanted to make this change, the steps taken to ensure it would be acceptable with known downsides ( adjusts the resolution, the bitrate and so forth if the decoder/encoders are too slow), and how it would allow to better identify borderline (and invalid) behaviours,

Could also limit to nightly only for now.
this still needs answers to the questions in comment 3.  I'll add we should also make sure we can track what happens due to this landing in Telemetry - we have no telemetry currently based on codec, and some of the existing telemetry should be split up by codec used probably (just as frame rate or resolution), or telemetry on those (by codec) added.
Pushed by
Add preference to make VP9 the preferred video codec. r=jesup
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.