Closed
Bug 1198715
Opened 9 years ago
Closed 8 years ago
Enable MSE WebM/VP9 on all platforms (media.mediasource.webm.enabled pref)
Categories
(Core :: Audio/Video: Playback, defect, P1)
Core
Audio/Video: Playback
Tracking
()
RESOLVED
WONTFIX
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.
Updated•9 years ago
|
Priority: -- → P2
Updated•9 years ago
|
Updated•9 years ago
|
Comment 2•9 years ago
|
||
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.
Comment 3•9 years ago
|
||
(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.
Comment 4•9 years ago
|
||
(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: 8 years ago
Resolution: --- → WONTFIX
Comment 8•8 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.
Comment 9•8 years ago
|
||
This is about MSE. What do you mean with MediaRecord being useless if one format isn't enabled with MSE?
Comment 10•8 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.
Comment 11•8 years ago
|
||
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•8 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•8 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•8 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.
Comment 15•8 years ago
|
||
I guess we could always enable webm container if the vp8 codec is specified.
Comment 16•8 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•8 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.
Comment 18•8 years ago
|
||
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•8 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.
Comment 20•8 years ago
|
||
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•8 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.
Comment 22•8 years ago
|
||
(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...
You need to log in
before you can comment on or make changes to this bug.
Description
•