Enable MSE WebM/VP9 on all platforms (media.mediasource.webm.enabled pref)

RESOLVED WONTFIX

Status

()

P1
normal
RESOLVED WONTFIX
3 years ago
a year ago

People

(Reporter: j, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox43 affected)

Details

(Reporter)

Description

3 years ago
Websites should be able to decide if they want to use MSE with WebM.
Right now WebM is only available on platforms without H.264 support.
Priority: -- → P2
Blocks: 1184774
No longer blocks: 1184774
Depends on: 1184774
No longer depends on: 1184774
Depends on: 1202580
Depends on: 1205911
Blocks: 1213177
Depends on: 1193614
Depends on: 657791
Depends on: 1202098
Depends on: 1216018
Duplicate of this bug: 1216298
Depends on: 1210219, 1230265
Priority: P2 → P1
Summary: Enable MSE WebM on all platforms (mediasource.webm.enabled) → Enable MSE WebM/VP9 on all platforms (media.mediasource.webm.enabled pref)
No longer depends on: 657791
Either Google is bypassing the VP9 MSE toggle, or detection is broken. In today's nightly YouTube will serve VP9 MSE when available despite the WebM MSE pref set as false. If the VP9 codec is disabled, it falls back to h.264.
(In reply to Leman Bennett [Omega] from comment #2)
> Either Google is bypassing the VP9 MSE toggle, or detection is broken. In
> today's nightly YouTube will serve VP9 MSE when available despite the WebM
> MSE pref set as false. If the VP9 codec is disabled, it falls back to h.264.

This was a change in Firefox: bug 1260305.
(In reply to Chris Peterson [:cpeterson] from comment #3)
> (In reply to Leman Bennett [Omega] from comment #2)
> > Either Google is bypassing the VP9 MSE toggle, or detection is broken. In
> > today's nightly YouTube will serve VP9 MSE when available despite the WebM
> > MSE pref set as false. If the VP9 codec is disabled, it falls back to h.264.
> 
> This was a change in Firefox: bug 1260305.

An estimiSer from bug 1230265, Thanks for the info!
We won't expose VP9 in MSE on all platforms until we can standardise a way to advertise preferred codecs. VP9/MSE support is hidden on slower machines where H.264 hardware decoding is available.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Is there a bug to track the standardization/implementation of that API?
Yes, Bug MSE

Comment 8

2 years ago
The problem with not enabling this option is that MediaRecorder is essentially useless, as it doesn't appear to be possible to record in any format other than webm using MediaRecorder in Firefox, unless I'm mistaken.
This is about MSE. What do you mean with MediaRecord being useless if one format isn't enabled with MSE?

Comment 10

2 years ago
MediaRecord only supports webm/vp8 recording as far as I can tell (it isn't documented, but that seems to be the case as far as I can tell). So, the user has to set media.mediasource.webm.enabled in order to play back any video recorded with MediaRecorder.
MediaRecorder saves as a plain webm. You do not need MSE to play back those webm recordings. That preference has no impact on webm playback.

Comment 12

2 years ago
It impacts if you are playing back via MediaSource, which you have to do if you want to play the video back in the browser in real-time (vs just saving it to a webm file). To see what I mean, try:

https://www.groupboard.com/gum_record/

Comment 13

2 years ago
Strangely it seems to be working today without requiring media.mediasource.webm.enabled to be set to true, but it was giving an error yesterday.

Comment 14

2 years ago
Ok, I see the problem. It fails on older machines if media.mediasource.webm.enabled is not set, but works on a machine with hardware vp8 encoding/decoding even if you don't enable that option. So it is still an issue. Worse, it works or fails depending on the user's hardware.
I guess we could always enable webm container if the vp8 codec is specified.

Comment 16

2 years ago
>I guess we could always enable webm container if the vp8 codec is specified.

Yes, that would solve this particular issue.

Comment 17

2 years ago
Another issue I've discovered is that MediaSource webm/vp8 is randomly enabled or disabled on the same machine. Sometimes it works and sometimes it gives "operation not supported". So it looks like the "VP9 Estimizer" (actually vp8/vp9) logic is somewhat unpredictable.

I'm using a late 2016 13in macbook pro 2.0Ghz, which I believe has hardware decoding and encoding for vp8 and vp9.
The VP9Estimizer is only ever called once. It then sets a pref which won't ever change until we bump the version number. 
So it can't give you varying results between playback runs

Comment 19

2 years ago
It works one day, then not the next day, then works the day after. I presume it's calling the estimizer function each time Nightly updates. Still, it probably shouldn't be giving different results on a machine that has hardware playback.
but does it have VP9 hardware playback though ? this is only happening with kabylake intel and nvidia Pascal (10xx) and some 9xx at this stage.

VP8 hardware on earlier intel was disabled as it was too slow.

You can also always set dom.mediasource.webm.enabled to true for now, and no longer have to worry about it.

I will open a new bug to support mse/vp8 all the time

Comment 21

2 years ago
It has skylake, which wikipedia says has vp9 hardware encoding/decoding. 

I would also expect it to have hardware decoding/encoding, as it's a brand new macbook pro. I would be extremely surprised if it was using the cpu every time I watch youtube or start a hangout.
(In reply to David Jameson from comment #21)
> It has skylake, which wikipedia says has vp9 hardware encoding/decoding. 

It doesn't.

Skylake only has VP8, and for VP9 it's only partially accelerated. On Windows, performance was poor and crashing often, we had to disable it.
On Mac, it's not available at all, the OS doesn't support it.

> I would be extremely surprised if it was using the cpu every time I watch youtube or start a hangout.
On mac, you can be certain that it does...
Depends on: 1341342
You need to log in before you can comment on or make changes to this bug.