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
P2 changed the way the H264Converter would be calling the decoder. The assumption in the EMEDecryptor was pretty incorrect to start with.
Depends on D7865
Differential Revision: https://phabricator.services.mozilla.com/D7882
--HG--
extra : moz-landing-system : lando
When used with the LowLatency option, we guarantee that the stream will contain no B-frame, as such we can reduce the re-ordering queue to zero. The apple VT decoder already returns frames in decode order making this change trivial.
Depends on D7861
Differential Revision: https://phabricator.services.mozilla.com/D7862
--HG--
extra : moz-landing-system : lando
The H264Converter can be used on a thread that isn't a nsThread or a TaskQueue, so having the H264Converter dispatching tasks isn't going to work
So instead we run all the code on the decoder's taskqueue using promise chaining.
All internal methods are made to assert that they are running on the task queue accordingly
Depends on D7860
Differential Revision: https://phabricator.services.mozilla.com/D7861
--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
Both D3D11 compositor and WebRender now supports 10/12 bits images.
Depends on D6688
Differential Revision: https://phabricator.services.mozilla.com/D6695
--HG--
extra : moz-landing-system : lando
Update content_decryption_module.h and other Widevine headers. This removes the
CDM8 interface and adds in the CDM10 and CDM11 interfaces. As such this patch
removes references to CDM8 from the code and adds some of the foundations for
supporting CDM10. Most of the CDM10 code will be implemented in another bug, but
there are a number of cases where it was straight forward to shuffle CDM8+9 code
-> CDM9+10, rather than deleting it and replacing it later.
Differential Revision: https://phabricator.services.mozilla.com/D5628
--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
In FFmpeg 4.0 and later, draining the parser will cause later decoding error as the decoder expects to only be fed a null packet.
It was also unnecessary for earlier version of FFmpeg
Differential Revision: https://phabricator.services.mozilla.com/D5056
--HG--
extra : moz-landing-system : lando
Despite wording of the documentation to the contrary, we can't provide a static pointer to an immutable object.
Apparently, it's always been that way.
Differential Revision: https://phabricator.services.mozilla.com/D4323
--HG--
extra : moz-landing-system : lando
This method will allocate a decoder according to the GlobalAllocPolicy. On Android API 18 and lower, there can only be a single decoder created at a time. The promise returned by CreateDecoder will only be resolved once the allocation policy permits a new decoder to be created.
Differential Revision: https://phabricator.services.mozilla.com/D3678
We extract the GlobalAllocationPolicy and the MediaDataDecoder wrapper from MediaFormatReader.
They will be used to create a new wrapping class that will serialize allocation and initalization of decoders if the platform requires it.
Differential Revision: https://phabricator.services.mozilla.com/D3676
A mDisplay vs mImage mixup. We also set both values in CreateTrackInfoWithMIMETypeAndContainerTypeExtraParameters to prevent similar issues in the future.
Differential Revision: https://phabricator.services.mozilla.com/D3788
--HG--
extra : moz-landing-system : lando
MediaCodec products out of order buffers for some Twitch (60fps)
streams. Detecting and discarding these frames asap to make the
buffers available to codec sooner, reducing the chances of
starvation.
Differential Revision: https://phabricator.services.mozilla.com/D2977
--HG--
extra : moz-landing-system : lando
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
--HG--
extra : rebase_source : 72ebe662f76fb6c9d8be1f753890601aac440061
Jean-Yves Avenard
Sylvestre Ledru
Narcis Beleuzu
Brindusan Cristian
Bryce Van Dyk
Coroiu Cristina
John Lin
Karl Tomlinson
Noemi Erli