| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
supportsHardwareH264Decoding() uses a promise if MP4 Hardware Acceleration to about:support
This concern was largely Mac-specific but I did leave Part 1 intact because the Mozilla Bug makes a good point that some systems may always software render a 64x64 video (specifically apple but other implementations could adopt this nonsense as well). Personally I want accelerated video.. damn it!
The real question is.. Why was the promise never resolving in the first place? Is it fall out from killing DOM Promise? It used jsval but who the hell knows or even cares.. It works and can once again be queried without jumping through god damned hoops.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Add an extraction function to parse the RFC-6381 VP9 codec string.
* Add VP9-in-MP4 support to the decoder
* Use Codec detail extractor helper to tell if it's a new style VP8/VP9 codec string.
* Add a gtest for testing the extraction function.
* Add mBitDepth field to VideoInfo.
* Extract bit depth information from codec parameter string into VideoInfo::mBitDepth.
* Check bit depth in WebMDecoder to determine if we support HDR.
* Add an extraction function to parse the RFC-6381 VP9 codec string.
Based on Bug 1407919
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
For some reason these changes never got merged back to master
after reverting to work on a branch...
|
| |
|
|
| |
This reverts commit b5b62d841c733dcb62112f3158f1488e670671d6.
|
| |
|
|
|
|
| |
This de-unifies up to and including dom/media/platforms with the exception of
dom/media/platforms/wmf, because that one throws weird errors in the Win
SDK which don't have a clear cause (yet)
|
| |
|
|
|
|
| |
- Exclude missed MediaKey functions and CDMProxy code.
- Exclude EME APIs frm being built (webidl change)
- Fix tests in --disable-eme state
|
| |
|
|
| |
Allow avc (h.264) content in matroska/webm containers
|
| | |
|
| |
|
|
| |
The MP4Reader no longer exists in the tree.
|
| | |
|
| | |
|
| |
|
|
|
| |
This creates a number of stubs and leaves some surrounding code that may be irrelevant (eg. recorded time stamps, status variables).
Stub resolution/removal should be a follow-up to this.
|
| | |
|
| | |
|
| | |
|
| |
|
