Closed Bug 1198715 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: Audio/Video: Playback, defect, P1)

Product:
Core
Component:
Audio/Video: Playback
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox43 --- affected

People

(Reporter: j, Unassigned)

References

Details

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
No longer blocks: 1184774
Depends on: 1184774
No longer depends on: 1184774
Depends on: 1202580
Depends on: 1205911
Depends on: 1193614
Depends on: 657791
Depends on: 1202098
Depends on: 1216018
Depends on: ffvp9, 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
Closed: 9 years ago
Resolution: --- → WONTFIX
Is there a bug to track the standardization/implementation of that API?
Yes, Bug MSE
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?
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.
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/
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.
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.
>I guess we could always enable webm container if the vp8 codec is specified. Yes, that would solve this particular issue.
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
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
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.