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
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)
This reflects the API changes to the aom_codec_decode function and the removal
of I440. It also sets allow_lowbitdepth to give proper support for 8 bit video,
and removes the git version from the mime type.
MozReview-Commit-ID: GuTvnPkR1Er
--HG--
extra : rebase_source : 4540f74df335d59714a61d5f7e2ad7a54f8fa00d
Summary:
The Apple VT decoder requires SPS+PPS at construction time. If not provided, in earlier macOS it used to give an error. In the current 10.13 it appears to work, however the decoder always report to be software only.
To properly determine the decoder capabilities, we construct a SPS NAL from the codec mimetype provided.
Details on the structure of the mimetype can be found in https://tools.ietf.org/html/rfc6381#section-3.3 and is a 1:1 match with the data found in the SPS.
Depends on D1718
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1719
Summary:
By default, when creating a H264 decoder it is wrapped into a H264Converter which will only create the actual decoder once a valid SPS/PPS has been seen.
As creating valid SPS/PPS NALs isn't trivial, when all we care about are capabilities of such decoder, we do not wrap the decoder so that it will be immediately created.
We can then test its capabilities.
We only enable this on windows, as on mac we need to generate a SPS/PPS, otherwise the mac decoder always report that HW decoding is not enabled.
Depends on D1632
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1633
Summary:
We can't create a H264 VT decoder until we have all SPS/PPS NALs, which makes it tricky to generate when we only want to check if H264 is supported.
On mac, we can reasonable assume that hardware acceleration is always supported (though on a mac pro 2013 that isn't the case or hackintosh with nvidia cards).
Depends on D1625
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1626
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
Some invalid streams contain SPS changes and those appear to only occur on non-keyframe, this cause all frames to be dropped until the next keyframe is found. This result in apparent freezes.
While it is theoretically possible to have SPS changes inband on non-keyframe those should be very rare (I've never seen one). The content would have been invalid anyway in an non-fragmented mp4.
So we now only check for a SPS change on keyframe. This would cause no affect on either windows, android or ffmpeg as those decoders handle format change fine. The mac decoder could however show garbled frames temporarily.
Differential Revision: https://phabricator.services.mozilla.com/D1733
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
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
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : 17ef7f95f7205307980dd0924821b005ada06c56
extra : source : eb0a2bb44f95f195343fed284efcdd524a7bb868
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : ee6acf7d046e8ce6e18a53988a4ea308b8d4d44f
This patch converts all the prefs in MediaPrefs to the new StaticPrefs system.
Note that the "media.wmf.skip-blacklist" pref was present in both MediaPrefs
and gfxPrefs. The copy in MediaPrefs was never used; this explains why this
patch does not add an entry for it to StaticPrefList.h.
Note also that the patch removes themedia.rust.mp4parser pref, because it's
unused.
MozReview-Commit-ID: IfHP37NbIjY
--HG--
extra : rebase_source : df84ea813b7c366d7be663c696891325610149c8
Returning UniquePtr is nicer than returning raw pointers, and has the
nice side effect of forcing us to clean up the uses of nsAutoPtr that
were hanging about.
Also ensure that the MP4 demuxer can't create such sample.
MozReview-Commit-ID: JANgHNiiz2H
--HG--
extra : rebase_source : d6a68579e76f1eda651e38bec5a9ed17c9de3fa4
Because the shutdown closure awaits finishing itself by
TaskQueue::AwaitShutdownAndIdle(), the function blocks infinitely.
The code is wrongly introduced at the following commit:
* https://bugzilla.mozilla.org/show_bug.cgi?id=1319987
* https://hg.mozilla.org/mozilla-central/rev/b2171e3e8b69
This patch calls it on mTaskQueue intead of mOmxTaskQueue to
avoid the issue.
MozReview-Commit-ID: 4qmX2QlniEG
--HG--
extra : rebase_source : f0784c0c5b2e39d2078a5aff72be03b52e413139
extra : intermediate-source : 635153e1dcdc442f8d72727b6fe504842b4ffa31
extra : source : bf011140459cc227c9435e3960770bafb3cecb8e
It's a concrete class of OmxPlatformLayer for accessing OpenMAX IL
libraries directly. It will be usable on various embedded linux systems.
Note that it's not enabled by default yet. Add the following config to
your mozconfig.
ac_add_options --enable-openmax
TODO: Implement zero-copy mode
MozReview-Commit-ID: EMEXAKzzR64
--HG--
extra : rebase_source : d7c5b9baf66d87db38723b278c57fd581a3cbf98
extra : intermediate-source : b8c671a02a4fce085433b16db998c9b04ace87db
extra : source : 131b65580e3dd5c9dcb0ba6a05c16ab90c2dcc68
