For some platforms, when some HW codec is not available, we need to fallback to SW codec. Currently there is no such fallback mechanism in the Gecko. We need to have one to choose a better codec. Take webm for example (bug 986381), current FFOS only use internal SW decoder. But some platforms support VP8 HW decoder, we need to use it for smoother playback. However, we need to a fallback mechanism for those platforms that don't have a HW decoder.
I think in the WebM case we should instead have an abstraction layer in WebMReader where we can choose which decoder to use. This would end up being similar to the PlatformDecoderModule that we're using in MP4Reader. That way we can use our own WebM demuxer, and then choose to either use OMX's HW decoder, or libvpx software decoder. We already have Intel working on integrating a VP8 HW decoder for next generation ATOM chipsets on Windows 8.1 in bug 922314. They need something like this for bug 922314, so we make the decoders pluggable here, we could use that on desktop with Intel's HW decoder too.
Cool. This is a good idea. Once I finish PlatformDecoderModule on B2G, I can leverage it for B2G webm decoder!
Besides webm, since we are going to have open h.264 supported on firefox, on B2G it is required to be flexible to use either open h.264 decoder or omx decoder. For Android's h.264 SW decoder, it only supports baseline profile. http://developer.android.com/guide/appendix/media-formats.html#core
Assignee: nobody → bwu
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Jean-Yves - this is related to what we were discussing today.
Oh, I just created bug 1206977 for that :)
Component: Audio/Video: MSG/cubeb/GMP → Audio/Video: Playback
4 years ago
Depends on: 1206977
It is now up to GonkDecoderModule::SupportsMimeType to do the right thing and tell if it supports VP8/VP9
You need to log in before you can comment on or make changes to this bug.