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:
To properly determine if a decoder is hardware accelerated, we must pass information about the compositor to the decoder.
Depends on D1631
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1632
Summary:
For flac, mp3 and adts, if a codec was provided but wasn't supported in the container, it would have reported Maybe instead of No
Depends on D1628
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1629
Summary:
We now provides more detailed information for audio (check sampling rate and channels if provided).
And check for the power efficient attribute. We directly correlate this information with the decoder being hardware accelerated or not. All audio codecs are deemed to be power efficient.
Depends on D1626
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1627
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
Summary:
Allows to build an array ot TrackInfo built from the mimetype provided. This will allow to create dummy decoder to check that if they are supported and how well the decoder will perform.
Depends on D1623
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1624
Summary:
Addtionally, change the framerate to be of type double and allow to create a MediaExtendedMIMEType based on the new dom VideoConfiguration and AudioConfiguration object.
Depends on D1622
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1623
Summary:
TaskQueue no longer requires an explicit call to BeginShutdown() as such we no longer have a need for AutoTaskQueue.
Depends on D1621
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1622
Summary:
The information returned is identical to
1- canPlayType() for file
2- MediaSource.isTypeSupported for media-source
3- MediaRecorder.isTypeRecorder() for recordings.
Depends on D1616
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1617
Prior to the changes in this bug, a document would request autoplay permission
for its own origin, and not use the top level document's origin for the
permission check. Since now we use the top level document's origin for
requesting autoplay permission, some mochitests need to change, namely:
* test_autoplay_policy_permission.html can use
file_autoplay_policy_activation_frame.html directly.
The test was failing because its helper page was loaded same origin and the
helper page was testing if cross origin iframes could play; since we use the
top level document's permission request, this no longer effectively tests
whether the cross origin child can autoplay, as the cross origin child just
uses the top level window's origin for requests.
So we can instead load the helper window cross orgin instead, and remove one
helper layer.
Also an issue here is the way I was waiting for a new window to load was racy,
so now we wait for loading windows to send us a "ready" message.
* test_autoplay_policy_activation.html; this test's helper needs to wait for
loading windows to send it a "ready" message, as its helper is shared with the
above test.
MozReview-Commit-ID: LvRa4G7tqFw
--HG--
extra : rebase_source : 8ecd0e58200d79f0065a6d7b146d1d110d35953d
Add an implementation of nsIContentPermissionRequest to encapsulate requesting
permission from the user to autoplay audible media.
All documents in the tab request permission using the top level document's
origin, so the AutoplayRequest instance for a tab is stored on the top level
content window of the tab.
AutoplayRequest ensures that there's only a single prompt shown at once.
MozReview-Commit-ID: 2u3aLnEa21z
--HG--
extra : rebase_source : a3db3a1ef87a09442b47ae1b1034b4a0143289fb
extra : source : ae572bf618155a92b136fc5f12c1f8c9ab31f89c
Some MSE streams will resend the same init segment. In these cases we can treat
the following data as belonging to the already existing stream. We do this by
reusing the same stream id. This stops us tearing down and restarting decoders
in these cases. This has the benefit of stopping us introducing gaps to audio
and/or video.
Differential Revision: https://phabricator.services.mozilla.com/D1837
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Sometimes when video is playing, a preroll ad plays, and that may be in a cross
origin iframe. If autoplay media is disabled, we require a user gesture in a
document before playback in that document is permitted, and we require each
origin to be gesture activated separately. So in the cross origin preroll video
add case, then the user will have to click once to unblock playback for the
cross origin ad, and then once the preroll ad finishes, the user will have to
click again to activate playback of the same origin content video.
This is a bad user experience.
So we should instead make gesture activation propagate up the doc tree
irrespective of crossing origins. This way, when the user clicks to activate,
all documents in that tab are also also effectively gesture activated, and so
can autoplay.
MozReview-Commit-ID: 1HZQ5zkubR
--HG--
extra : rebase_source : d6b75732548cb1d73b9f82dce60a5e6e97d1da14
Re-creating a new demuxer is fine, provided that the SourceBufferResource exists. However, a resource is only created upon receiving an init segment.
The segment following a call to changeType() must be an init segment, will let the demuxer creation occurs there.
Differential Revision: https://phabricator.services.mozilla.com/D1812
SeekToNextFrame is handled differently than other seeks by the
MediaDecoderStateMachine, and should not take place while other seeks already
are. Bug 1410225 implemented some changes in HTMLMediaElement to prevent this,
but it's still possible to move to a seeking state in the MDSM and accept
SeekToNextFrame (as in this bug).
This changeset changes the MDSM to reject SeekToNextFrame if a seek is already
happening. Since the MDSM now does this the changes from bug 1410225 can be
removed.
This has the functional change of the promise from SeekToNextFrame being
rejected if the seek in not performed due to another seek. Previously the
promise would succeed when the other seek completed. This seems sensible as the
next frame seek does not actually take place.
MozReview-Commit-ID: HD9WRFq3LZV
--HG--
extra : rebase_source : fb276010119038db4319b3b81bcbf51ef2cab1d9
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
