Windows AAC decoder decode a mono AAC stream into a stereo PCM. Bug 1347101 set the output to be mono, which caused a failure to find the appropriate IMFMediaType.
This partially revert bug 1347101 audio changes.
MozReview-Commit-ID: 2M4X4rKKvXl
--HG--
extra : rebase_source : 6b7330a7edfc2c0504171828526221dcccb6f8c5
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
Under some circumstances, and seen on Windows 8, a decoded sample can be returned without the MFT returning MF_E_TRANSFORM_STREAM_CHANGE.
For historical reasons, we required that message to be returned at least once to set the output image size. This was required as the decoder used to be recycled with different video streams.
This is no longer the case, we can rely on the video info instead. It also greatly simplifies the code
MozReview-Commit-ID: H14KBiNWrjQ
--HG--
extra : rebase_source : d098f884127bc95e3ca4363bf3d0cdda6d3bd771
VideoData doesn't care what's in aInfo but display size and aPicture are unused.
MozReview-Commit-ID: IBqq8Rm8dM4
--HG--
extra : rebase_source : 10e2390f87925ef9179d28d86240f68a35c6c6d4
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
This will allow to minimize the memory usage when draining the decoder.
MozReview-Commit-ID: eKlHaji0Ei
--HG--
extra : rebase_source : 702ebdef78d27a8d6eefd6a2502762a5229621fe
The WMF audio decoder outputs a single audio frame after each drain, regardless of having been provided a frame to decode.
So we must ensure we only ever drain it, if inputs were provided.
MozReview-Commit-ID: 6owe49NjbBv
--HG--
extra : rebase_source : 61fefecf2e350f471ee0c00fce211c858b259508
As of bug 1325299, WINVER is always >= 0x0601 (Windows 7).
MozReview-Commit-ID: BJYg9d3zuYx
--HG--
extra : source : 4eff752dd001a722fe1d8e60e56ccb5f70c8d872
This is a big change, and unfortunately impossible to break down with independently functional commits.
There are four main changes being applied here:
* Code cleanup, including making all MediaDataDecoder related code mozilla coding style compliant
* Make MediaDataDecoder use MozPromise
* Making Flush and Shutdown processes fully asynchronous
* Fixing few data races encountered across the code, in particular in the Android PDM
MozReview-Commit-ID: DpiZucGofJT
--HG--
extra : rebase_source : 80bd6c6f9726d536b6f306c40d9af6df27333be9
Previously the combined tests meant that if a track was H264, and we supported
H264, BUT media.wmf.allow-unsupported-resolutions==true, we would just skip the
whole block, meaning we would return 'false' (unsupported) in the end.
Instead, if a track is H264, and we support H264, we should return 'true'
(supported), unless media.wmf.allow-unsupported-resolutions==false and the
resolution is too high.
MozReview-Commit-ID: 5YUhlxmfPIO
--HG--
extra : rebase_source : 48fdcdc0ec83368fe1e97f30d87fb9384129700f
When MFT returns MF_E_NOTACCEPTING means the input buffer is full and it can't
accept input data anymore, so we need to output the data first and then resummit
the input data.
MozReview-Commit-ID: DfSTASsEX7r
--HG--
extra : rebase_source : fd3cff6284345872dd580fbd0568d99129af936c
When we want to decode with DXVA2 aPI directly instead of using it by MFT, we need to take responsibility for
creating a decoder and handle the related decoding operations by ourself. So implement a method to create and
hold a ref to DXVA2 decoder for DXVA2Manager.
MozReview-Commit-ID: 4EyrsjzEyYK
--HG--
extra : rebase_source : 6719bfe15243395711984d66919baca2bb74699e
