Chrome has had it enabled for years, we had disabled it originally due to crashes seen on Windows 7.
Differential Revision: https://phabricator.services.mozilla.com/D23656
--HG--
extra : moz-landing-system : lando
The rate changes after decoding the first sample to what was indicated in the container. The code to handle that case was incorrectly removed in bug 1530234
Differential Revision: https://phabricator.services.mozilla.com/D21618
--HG--
extra : moz-landing-system : lando
The WMF audio decoder recalculated the timestamp of each audio sample according to the number of frames decoded so far.
This is incompatible with the trimming mechanism that rely on the timestamps of the audio to be matching what is found in the container.
All the other audio decoders do it that way already.
Depends on D20969
Differential Revision: https://phabricator.services.mozilla.com/D21305
--HG--
extra : moz-landing-system : lando
We didn't set the duration on the created IMF sample before sending it to the decoder.
For audio this isn't a problem as the duration is calculated from the number of frames returned.
For video however, the duration appears to have been calculated by WMF as the delta of pts. However, for the last frame, the value returned was set to a value not matching our input.
So we set the duration on the IMFSample so it doesn't have to make it up.
Setting the duration on the IMFSample isn't sufficient with Windows 7, which still continues to calculate it based on previous samples durations.
So we store the last sample duration and set it when draining.
Differential Revision: https://phabricator.services.mozilla.com/D20653
--HG--
extra : moz-landing-system : lando
It can be determined from the size of the buffer and the number of audio frames. Additionally, it ensures that the duration of the frame is always exactly what the AudioData contains.
Differential Revision: https://phabricator.services.mozilla.com/D20170
--HG--
extra : moz-landing-system : lando
Usually the threshold is reset internally in MediaDataDecoder subclasses
that support the hint in their Flush() implementations so the value
will start fresh after seeking completed. But sometimes when there are
consecutive seek requests, MediaFormatReader::DecoderData::Flush() could
return early because DecoderData::mFlushed stays true when there is no
sample demuxed yet, and the threshold will not be cleared. Also, in
MediaFormatReader::SetVideoDecodeThreshold() we decide not to set the
hint when the seek target is close to EOS by checking the existence of
the next keyframe, and that could fail when there are gaps between MSE
buffered ranges. To make sure the hint is never out of date, we should
clear it rather than leaving it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D15227
--HG--
extra : moz-landing-system : lando
Usually the threshold is reset internally in MediaDataDecoder subclasses
that support the hint in their Flush() implementations so the value
will start fresh after seeking completed. But sometimes when there are
consecutive seek requests, MediaFormatReader::DecoderData::Flush() could
return early because DecoderData::mFlushed stays true when there is no
sample demuxed yet, and the threshold will not be cleared. Also, in
MediaFormatReader::SetVideoDecodeThreshold() we decide not to set the
hint when the seek target is close to EOS by checking the existence of
the next keyframe, and that could fail when there are gaps between MSE
buffered ranges. To make sure the hint is never out of date, we should
clear it rather than leaving it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D15227
--HG--
extra : moz-landing-system : lando
Why we would need this is unclear however. the destination texture should always be smaller than what comes out of the decoder.
Differential Revision: https://phabricator.services.mozilla.com/D8672
--HG--
extra : moz-landing-system : lando
The Windows' hardware decoder always return an image whose dimensions are multiple of 16 pixels. As such, the image coming out of the decoder is typically bigger than the wanted image.
The D3D11 documentation states that " If you try and copy outside the destination resource or specify a source box that is larger than the source resource, the behavior of CopySubresourceRegion is undefined."
We've always copied from a bigger texture into a smaller one without specifying clipping. It seems to have always worked but falls into the undefined behaviour category.
So to be extra safe, we clip the source so that it matches the dimension of the destination texture.
Depends on D8129
Differential Revision: https://phabricator.services.mozilla.com/D8203
--HG--
extra : moz-landing-system : lando
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
I find it easier to read than a function pointer making you search elsewhere to see what it's about
Depends on D7294
Differential Revision: https://phabricator.services.mozilla.com/D7295
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
I find it easier to read than a function pointer making you search elsewhere to see what it's about
Depends on D7294
Differential Revision: https://phabricator.services.mozilla.com/D7295
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
The Windows VP9 hardware decoder currently do not support anything else than profile 0 and 2 (YUV420) and return garbage when decoding.
We error on those streams allowing to fall back on the ffvp9 software decoder.
Depends on D7647
Differential Revision: https://phabricator.services.mozilla.com/D7648
--HG--
extra : moz-landing-system : lando
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.
Depends on D7316
Differential Revision: https://phabricator.services.mozilla.com/D7318
--HG--
extra : moz-landing-system : lando
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.
Depends on D7295
Differential Revision: https://phabricator.services.mozilla.com/D7296
--HG--
extra : moz-landing-system : lando
I find it easier to read than a function pointer making you search elsewhere to see what it's about
Depends on D7294
Differential Revision: https://phabricator.services.mozilla.com/D7295
--HG--
extra : moz-landing-system : lando
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.
When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
Differential Revision: https://phabricator.services.mozilla.com/D7294
--HG--
extra : moz-landing-system : lando
On some platforms where a hardware decoder is present, but non functioning, we would fail to initialize the video stride, leading to the frames being incorrectly displayed later.
Also delete the DXVA2 manager early under those circumstances
Differential Revision: https://phabricator.services.mozilla.com/D5402
--HG--
extra : moz-landing-system : lando
Summary:
We know those sampling rate aren't supported and cause initialization errors later.
Depends on D1624
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1625
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Under most cases, the frame decoded height is just the displayed height rounded to the next 16 row aligned value.
However, this doesn't appear to always be the case. So we query the WMF framework for the decoded frame size.
We continue to use the displayed sizes as found in the SPS to ensure proper display of non 1:1 aspect ratio.
Adding diagnostic assertion to find potential regressions, we will address those as they come.
MozReview-Commit-ID: L8VowEw6L9F
--HG--
extra : rebase_source : 49acd9fd36469ee0a4e1ed0fe5cd6f2211ba8117
TaskQueue::Dispatch returns a nsresult which must be checked.
MozReview-Commit-ID: 7Tl7O96rQNt
--HG--
extra : rebase_source : e898b776f765a5641a794a7242715728940075f6
