New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 726009 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Task



Sign in to add a comment

Add WPTests for vp09 string in MSE isTypeSupported

Project Member Reported by chcunningham@chromium.org, May 24 2017

Issue description

New vp09 codec string is implemented behind a flag.
https://www.webmproject.org/vp9/mp4/

Its currently tested via browsertests. Plan is to update the existing mediasource-is-type-supported.html to test the new string. 

We should also update the MSE WebM byte stream registry to document support for vp09.

https://github.com/w3c/media-source/issues/180
 
Hello. I'm on latest (60.0.3112.78) Chromium, Linux, and all of the following return false:

MediaSource.isTypeSupported('video/webm; codecs="vp9"')
MediaSource.isTypeSupported('video/webm; codecs="vp9,opus"')
MediaSource.isTypeSupported('video/webm; codecs="opus,vp9"')
MediaSource.isTypeSupported('video/webm; codecs="vp09"')
MediaSource.isTypeSupported('video/webm; codecs="vp09.00.10.08"')
MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01,opus"')

At least the first three _used to_ work quite recently. Is this a new thing for Linux Chromium, or is my box uniquely messed up? I have MediaSource stuff in production, and I don't want to downgrade to vp8 -- we need to keep bandwidth down to support as many users as possible.

Thoughts? Thanks :)
Incidentally, I haven't seen any MediaSource/vp9 examples floating around. Nevertheless, this excellent demo:

https://storage.googleapis.com/chcunningham-chrome-shared/mr_to_mse.html

that you (chcunningham@chromium.org) posted here:

https://bugs.chromium.org/p/chromium/issues/detail?id=606000#c85

can illustrate what I'm talking about. It works fine with vp8, but if you change "vp8" to "vp9" on line 39, you get an error avalanche on Chromium, at least on my Linux box. Has there been a mixup at headquarters, or is my system uniquely broken?
Just tested the strings from your comment. The only ones that return false for me are:

1. MediaSource.isTypeSupported('video/webm; codecs="vp09"')
2. MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01,opus"')

#1 is invalid (missing some mandatory fields. #2 specifies a hdr color space (bt2020) and transfer function (SMPTEST2084). Chrome's support for HDR is still experimental and disabled by default. 

But all other fields return true for me on linux. My version is slightly ahead of yours, (60.0.3112.90), but I doubt that's the issue. Do you have any plugins installed that manipulate answers to isTypeSupported (e.g. "h264ify")? 
I don't see any reference to plugins in my Chromium settings. I have 4 extensions installed, all of which were already there by default:

Bookmark Manager
Chromium PDF Viewer
CryptoTokenExtension
GNOME Shell integration

I'm running Debian 9.1 by the way. Anyway, I didn't change anything, and the MediaSource played fine with vp9 until very recently.

The only suspicious setting I found was that hardware acceleration was disabled. However, enabling it and restarting Chromium didn't change the output of:

MediaSource.isTypeSupported('video/webm; codecs="vp9"')

I'm wondering whether these codecs aren't enabled by default on Chromium, or whether there's some extra dependency there that is handled in some other way in Chrome? Because, as mentioned in other ticket, Chrome works fine. But I like Chromium!

Thanks for helping :)
Are you compiling chromium from sources? Any changes to code / compile time flags?

Some codecs do require special flags, but to my knowledge Vp9 is always included. 

What happens if you run:
 document.createElement('video').canPlayType('video/webm; codecs="vp9"')
I'm not compiling Chromium. I'm just using the regular version in the repositories.

Interestingly, when I run that, I get an empty string. Probably not what you'd expect, right?
And I should note that vp9 seems available other than for the MediaSource. For instance:

MediaRecorder.isTypeSupported('video/webm; codecs="vp9"')

returns true. Only the MediaSource has this issue as far as I can tell.
Definitely not what I expect. Did you install from google's site, or from some linux distro's repository (if so, which one)? 
I got it from the Debian repos. Here's the deets:

marbar@marbox:~$ apt-cache policy chromium
chromium:
  Installed: 60.0.3112.78-1~deb9u1
  Candidate: 60.0.3112.78-1~deb9u1
  Version table:
 *** 60.0.3112.78-1~deb9u1 500
        500 http://security.debian.org stretch/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     59.0.3071.86-1 500
        500 http://ftp.us.debian.org/debian stretch/main amd64 Packages

Thanks for helping dude, you're my hero :)
I know Debian makes some tweaks to chromium. I don't know the details, but just grepping around in their packaging repo I see these mentions of vp9:

$ git grep vp9
debian/changelog:  * Simplify approach for disabling vp9.
debian/changelog:  * Use embedded libvpx for vp9 support, which chromium now requires.
debian/rules:         rtc_libvpx_build_vp9=false \

I'd first check to see if you have libvpx installed. This usually ships with Chromium but linux distros don't like having two coppies of a library so they may strip it out. Beyond that, I'd try posting to some Debian boards (let me know what you find out). 
Looks like it's installed:

marbar@marbox:~$ apt-cache search libvpx
libvpx-dev - VP8 and VP9 video codec (development files)
libvpx-doc - VP8 and VP9 video codec (API documentation)
libvpx4 - VP8 and VP9 video codec (shared library)
marbar@marbox:~$ apt-cache policy libvpx4
libvpx4:
  Installed: 1.6.1-3
  Candidate: 1.6.1-3
  Version table:
 *** 1.6.1-3 500
        500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

Good idea about the Debian boards. I'll give it a try and let you know what I find out. Thanks again!
Labels: -Pri-1 M-66 Pri-2
Status update: Waiting on approval to include the new string in the bytestream registry.

https://github.com/w3c/media-source/pull/182

Downgrading priority since this isn't urgently needed in the current milestone. Hopefully the approvalcomes by M66.

Sign in to add a comment