Summary:
Additionally, consider all videos <= 480p to be smooth and power efficient as:
1- Hardware decoding it typically not used for those
2- We can't do any better
3- Any machines should be able to do 480p
Depends on D1794
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1796
Summary:
MediaCapabilities provide a finer detail on VP9 being supported or not. YouTube will use that information to determine which resolutions to support when using VP9
Depends on D1772
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1794
Summary:
If the benchmark task hasn't run yet, we will assume smoothness for now.
Depends on D1771
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1772
Summary:
This will allow to be called from the MediaCapabilities taskqueue if we find that a decoder won't be hardware accelerated.
It is still assumed that Benchmark::Init() was called at least once on the main thread.
Depends on D1628
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D1767
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:
We'll need it to properly build a SPS/PPS extradata later. Also, change the types used. The original data is stored on two bytes ASCII, it will always fit in a uint8_t. Additionally, this is how those values are stored in a SPS.
Depends on D1678
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1718
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
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
Since we switched to the mp4 rust demuxer, VP9 in mp4 is always supported.
Differential Revision: https://phabricator.services.mozilla.com/D2261
--HG--
extra : moz-landing-system : lando
This allows move semantics when resolving Promises
MozReview-Commit-ID: EYFd3Abr7Ec
--HG--
extra : rebase_source : e4553f3a5a9298d98ca454d98ca4158097b46efd
Previous commit added SetNextGetSampleIndexIfNeeded, let's re-use it for GetSample.
We continue to have an exception code as it caters for the most common code path, which is we retrieve one sample after the other.
MozReview-Commit-ID: HOQ53qwZj7w
--HG--
extra : rebase_source : cc9bc0b41a7085d28554f7ed764a18decfea327d
The assumption that when calling GetNextRandomAccessPoint the next GetSample index would always be known was incorrect. It assumed that the call to GetNextRandomAccessPoint would always be preceded by a call to GetSample.
This is not always how the MediaSourceDemuxer called it.
MozReview-Commit-ID: H1MyPpDEytk
--HG--
extra : rebase_source : 07f70ee87ae5084016a094c564382090a3045e94
I don't think we should allow media without audio tracks to autoplay because:
* It means play() before loaded metadata behaves differently than play()
called after loaded metadata.
* With the current impl we dispatch the "play" event and then the "pause"
event when we decide we should block, which may confuse some sites' controls.
* Delaying running the play() algorithm until we've loaded metadata would add
significant complexity, and may break sites.
* Chrome doesn't have this provision, meaning the complexity required to
support it will not result in much benefit to us.
MozReview-Commit-ID: FSVlDJAOisw
--HG--
extra : rebase_source : 93b1bcf8d8edbd6ca10ad918b40a87cd3cfbbf0b
We only should do the camera/mic permission or active capture test in
the case where document gesture activation is enabled.
MozReview-Commit-ID: 9xSe8FDn5tu
--HG--
extra : rebase_source : fb19fdcc7003d7ba04f5f1ab3a7d51ce63abc3db
extra : intermediate-source : 7de5bdbef79bacbee3284d49b77de36aceb0270e
extra : source : e72b9f4dcf418d4fcd2a0698f601d42eb9b0ecc0
Temporary diagnostic code to help determine what the problem might be.
MozReview-Commit-ID: D5Dm32aZ1Ia
--HG--
extra : rebase_source : ba0955c2b880823986277919f05a32e9095b14fa
This test became permafail after the patch for bug 1270217 landed to update
the default value for MACOS_DEPLOYMENT_TARGET from 10.7 to 10.9. We need to
update that value since otherwise local builds are broken on Mac, halting all
Mac development. As the lesser of two evils I'm disabling this test for now.
This patch splits FontTableURI and BlobURL in 2 classes:
FontTableURIProtocolHandler and BlobURLProtocolHandler
both under mozilla::dom.
It also removes a memory reporter because that report is already covered by the
BlobURL one.
--HG--
rename : dom/file/nsHostObjectProtocolHandler.cpp => dom/file/BlobURLProtocolHandler.cpp
rename : dom/file/nsHostObjectProtocolHandler.h => dom/file/BlobURLProtocolHandler.h
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
Change rules so we enforce ["foo", "bar"] rather than [ "foo", "bar" ].
MozReview-Commit-ID: KX6wJd8jmeJ
--HG--
extra : rebase_source : 6800cf4e701a33f246418e0deb35a206af8104f4
We initialize the channelCountMode and channelInterpretation (that cannot be
changed) appropriately in the C++ ctor, and the channelCount manually as well.
Then we check manually that the options for the channelCountMode, the
channelCount and channelInterpretation have not been passed, or are not
incorrect.
MozReview-Commit-ID: 4YdYfaGqKqn
--HG--
extra : rebase_source : 54000c4f79361945142bb413b7eeebb2967d4fbb
extra : intermediate-source : 9a085b0513f78344b07724c049860b089c313894
extra : source : 852233de6408712da07a2f09721c7e35d67d608f
Focusing a source during a test run can cause Firefox to lose focus and
subsequent tests to timeout. This adds a preference which defaults to true
that allows the source to be focused. It is then set to false for tests that
involve screen sharing.
MozReview-Commit-ID: CNq2c87y8Ho
--HG--
extra : rebase_source : 805e2cbf9c09af419419a64d074e020784185b1d
This adds a FocusOnSelectedSource method to PCameras and uses it to focus the
selected window while window sharing. We can't just focus the window as soon as
it is shared because we have a live preview in the getUserMedia permissions
prompt which would cause the prompt to lose focus. Instead, this only focuses the
window when the sharing is not done from a chrome context.
MozReview-Commit-ID: 5jre75E3JLi
--HG--
extra : rebase_source : 5f5154fc9fc7590cc02eb25146e5bc20b2243fa3
A call to NotifyDataEnded is required even if the size was known when the resource was created. This ensures that the readyState is properly updated and that playback can immediately as no more data can be added once first loaded.
MozReview-Commit-ID: FaJMBxJ9NkM
--HG--
extra : rebase_source : 448087a22635dac2aa31611c2b58a8e9c77121ec
If the particular track isn't encrypted, there's no need to wait for a CDMProxy.
MozReview-Commit-ID: DPbvbwsO58N
--HG--
extra : rebase_source : 0e7fea134404c861268dc8759cd7c0ebdf83dca4
The code couldn't have worked and didn't do what the comment stated. When the CDMProxy changes, the current PDMFactory for encrypted content can no longer be used.
MozReview-Commit-ID: 7LpcQkK5gLL
--HG--
extra : rebase_source : e3926034069285be1559d0a1ea20d5f3c1561eb7
If the content being played was first non-encrypted, the PDMFactory would have been set without a CDMProxy. As such, it is necessary to use a new PDMFactory when the encryption type changes (from clear to encrypted).
Rather than attempting to detect if the encryption status has changed, simply use two PDMFactory, one with CDMProxy set and one without (for clear content)
Also, never attempt to recycle a decoder if the encryption type changed (used only on Android)
The TrackBuffersManager would have already handle the dispatching of the encrypted event when parsing the new init segment. As such, nothing more is necessary.
MozReview-Commit-ID: Jn14P2F6N5V
--HG--
extra : rebase_source : afe254fa8c4b835b15d9d48bb52d832f28196b7e
Adding some documentation to clarify on the difference between mInfo and mOriginalInfo
MozReview-Commit-ID: DWBsoi16QKf
--HG--
extra : rebase_source : 719c17b9ce61efdb633db108230f1bf78773ee51
Bug 1415090 attempted to remove the need to access from the MediaResource members of MediaCacheStream from the main thread.
However, by doing so the logic flow for resuming the channel changed from a synchronous access to an asynchronous one.
This changed some assumptions and allowed the ChannelMediaResource to be used before the Seek call completed.
For now, re-add a cross thread access to the MediaCacheStream. A more elegant fix will be worked on in bug 1464045
MozReview-Commit-ID: 2xBTjDEqrkI
--HG--
extra : rebase_source : 0aa3cfcb8371d5147cbed746d9200dd22df4821b
When using a media element with a Media Source, the resource fetching algorithm is to be called in "local" mode:
https://www.w3.org/TR/media-source/#mediasource-attach
"Continue the resource fetch algorithm by running the remaining "Otherwise (mode is local)" steps, with these clarifications"
https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource
Under the local mode, the steps that would cause the element to fire suspend, stalled or progress can never occur.
We only prevent the stalled event to be fired, many websites rely on the progress event to be fired (such as when the init segment has been parsed). The HTML5 media spec will be amended to clearly indicate that progress is to be fired even with mediasource
MozReview-Commit-ID: DkoQzoV0JzO
--HG--
extra : rebase_source : 1e916eee50c9935f168797bb5a92052191cda59d
This will force the benchmark to be re-run, following de-activation of the AMD VP9 decoder.
MozReview-Commit-ID: KwwoQNfSJ4t
--HG--
extra : rebase_source : 4edc750d448d6f023a645457edcbd138974c7d9a
We currently set the Android JavaVM pointer in MediaEngineWebRTC.
However, because of that, we end up setting the pointer in the child
process, even though we really want to set the pointer in the parent
process because that's where the camera will be accessed.
This patch makes us set JavaVM inside VideoEngine itself, where we
actually access the camera in the parent process.
MozReview-Commit-ID: 3TeLiiK2vyh
Doesn't look like it's strictly necessary, but suppresses the warning.
MozReview-Commit-ID: EQBar71yNVg
--HG--
extra : rebase_source : 063639000fd47b32343d47a8ca428c134fdce43b
Add .eslintrc.js to configure globals from mediasource.js and to add extra
rules to encourage use of let and const over var.
Linting changes:
- Prefer const and let to var. This provides tighter scoping and avoids
reassignment.
- Mozilla rules do not allow for shadowing of variables, so several tests have
had promise lists renamed to avoid this.
- Numerous minor fixes to formatting including using double quotes, spacing,
missing semicolons.
- Remove some unused variables.
- Arrays have spaces after opening braces and before closing braces, e.g.
[ "foo" ], this is to be consistent with our clang-format rules.
- Fix naming of resourcePathSeen in test_MediaSource_memory_reporting.html.
MozReview-Commit-ID: 5q6oS7EWLTk
--HG--
extra : rebase_source : 9b67b294f338ca9205b52fded3af63e6c3ac9a5a
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
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: K93xiTod6tw
--HG--
extra : rebase_source : 788122a69b6cab96bab9c2ae6e8cdf7c61d4ed07
The aim of those changes is to be incubated in the WICG.
MozReview-Commit-ID: 5wEUnWz8i7kBug 1280613
--HG--
extra : rebase_source : 4360d2c34025bf3c87fff49f0e2aa01975fff15b
Audio context would be allowed to start if
(1) its document has been activated by user gesture
(2) it's a offline audio context, because it won't directly output sound to audio
devices
In addition, all resume promises would be pending until audio context has been
allowed and user calls resume() again.
MozReview-Commit-ID: G6RV8dDM6vQ
--HG--
extra : rebase_source : bc1d2ad0594ad1f54c05ade06495918aaee14911
extra : source : 5031770d70fd643230cb4caf6a5106616adaf0fd
With the updated OnThread method SetInputListener method cannot continue asserting for being in audio callback. This check is not realistic since it is used on a newly created driver before being started.
MozReview-Commit-ID: 5gntuHm3fnr
--HG--
extra : rebase_source : e3bc17e9d8c83c4d61686889af41edfb3ef3902f
These two methods assert for OnGraphThreadOrNotRunning when their callers assert for OnGraphThread. Since the second assert is more limited we do not have to assert for a wider eventuality.
MozReview-Commit-ID: 2cgzO160l6F
--HG--
extra : rebase_source : 922a3d9775bb25022e456c19495b5e1666e7f8b7
The class has been enhanced to store the thread id at the beginning of the callback and use it in order to compare with the current thread id when OnThread method is called. The old mechanism which includes the mInCallback flag has been removed.
MozReview-Commit-ID: DWSbFQfvKzX
--HG--
extra : rebase_source : e6c011da563b8f1d562ca7a394433e1e53fcffa4
That method is used on update of channelCount constraint. By raising a ControlMessage to MediaStreamGraph we avoid the lock the mutex on a non priority thread. Unfortunately we have to send the message in main thread first, thankfully this will change soon.
MozReview-Commit-ID: 8JRSmKGGVAN
--HG--
extra : rebase_source : 3d3a3f03ec601e5fbe0e8fda01608ee8cadf8d78
Restructuring of the existing code no functional change.
MozReview-Commit-ID: JWaa8LgG4MR
--HG--
extra : rebase_source : 97190b870172549a0cd2453078c0511887059b73
Restructuring of the existing code no functional change.
MozReview-Commit-ID: FARNItrajfD
--HG--
extra : rebase_source : 0887c6546bb43538e32b99950e2febca77a32bfb
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4a974aba0533bfbd5e9bb4c4c11d77d17a81db6d
If listeners are still registered to a MediaStream on MediaStream::Destroy
(triggered by MediaStream::UnregisterUser below), they will catch and act
on further events from the MediaStream (such as a track ending).
This may dispatch runnables that are unnecessary since we know we are
shutting down.
If we first remove the listeners from the MediaStream we will never see
said events.
MozReview-Commit-ID: IZ1kENqL2C8
--HG--
extra : rebase_source : 6f9201827a30f119b4c116d0cb798858408aed20
MediaStream::Destroy() is part of a controlled shutdown sequence.
If there are still tracks with content beyond Destroy() they will
only get caught by the dtor, which may be on CC shutdown and too late.
MozReview-Commit-ID: GV6XRiTCIRk
--HG--
extra : rebase_source : 88b5730c3566f8405c8f6da5e93e7cc446b9dd75
DecoderDoctorLifeLogger now passes a NonDereferenceable pointer to
LogConstruction/LogDestruction, to avoid UBSan errors. It is possible because
DDLogger only keeps pointer values for logging (the pointer type is converted
to a string), these pointers are never actually dereferenced.
Note that the uintptr_t value() is converted to `const void*` because that's
what DDLogger uses everywhere; an upcoming bug will make DDLogger use
NonDereferenceable everywhere instead.
MozReview-Commit-ID: K5wJrGVCub0
--HG--
extra : rebase_source : cc802706d1c2c5a60ac692d132038c8418f8dedd
Sites which are whitelisted should be allowed to autoplay audible media.
So check whether a HTMLMediaElement's owner doc's principal has an exact
"autoplay-media" permission. This ensures whitelisted origins can autoplay,
but sub-origins of whitelisted origins need their own permission.
MozReview-Commit-ID: 2IO5KIyplEa
--HG--
extra : rebase_source : 4d9afdec0caa4a82b53bedfd645f259a5c760e4d
Currently, the new init segment provided following a call to changeType() must contain the same number of audio and video tracks as previously.
The Chrome team has indicated concerns in regards to this restriction. TBD.
MozReview-Commit-ID: 3S6YVtQILF9
--HG--
extra : rebase_source : 59574301d8d4b6f04fc40a97a0917222f1d42fe4
Non functional code.
SourceBuffer.changeType allows to reconfigure a sourceBuffer so that a new codec type or new container format can be fed later.
The new code is placed behind the media.mediasource.experimental.enabled pref.
MozReview-Commit-ID: 5wj6J4uzLbA
--HG--
extra : rebase_source : b6f57246e0a4c856f6365bb0c8ec8d759a770105
Additionally, show the number of channels and the sampling rate.
MozReview-Commit-ID: L067Hbv0bXz
--HG--
extra : rebase_source : 193482c7e96b0094ec4d717a9cc30e371067aa1d
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
We made NotifyPull parallel to try to lower the load, and we initially measured
an improvement. However, we did the measurements with a profiler that did an
aggregation of the results. Our results had an high variance, so the mean load
was in fact not meaningful.
More careful measurement performed without doing any aggregation show that,
under load, relying on the fact that the scheduler schedules the tasks on time
is too risky, and that the code is fast enough to not have to parallelize.
MozReview-Commit-ID: CMhSn8Sc0OO
--HG--
extra : rebase_source : cfb41f861089bce9e10446bee81c13f8565ba90e
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
Bug 1435133 introduced a new path where we block autoplay and reject the play()
promise, but we didn't fire a "pause" event. This confuses YouTube's controls.
Additionally, even if we're not in a user generated event handler, we
unilaterally consider the media element blessed if execution reaches here:
https://searchfox.org/mozilla-central/rev/11a2ae294f50049e12515b5821f5a396d951aacb/dom/html/HTMLMediaElement.cpp#4110
We previously rejected before reaching here when not in a user generated event
handler, but now if play() is called before we've reached loadedmetadata, we
reject the promise if we're not in a non-event handler and bail out early, and
so we'll bless even if not in a user generated event handler. Meaning when we
do reach loadedmetadata, we think we were in a user generated event handler
when play() was originally called, and so we won't reject the play promise.
So this patch ensures we dispatch a "pause" event when we reject the play()
promise here. The WHATWG spec says we should do this when pausing anyway.
Note: calling our interal Pause() function when rejecting the play() promise
here breaks YouTube, as if we do that we fire a "timeupdate" event. So I opted
to manually code to fire the event here instead of just calling Pause()
everywhere we want to ensure we're paused.
MozReview-Commit-ID: 1snkiTnPGih
--HG--
extra : rebase_source : 2c5ca6c0ed7c2dff2fb971cd159cfdc12a8a227f
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : 03cefb8edf12b077607ae71aeb999fd0ac966674
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
This outputs to MOZ_LOG and using an MPSC lock-free queue so we can log to a
particular module from any thread.
MozReview-Commit-ID: INtlki4PEJs
--HG--
extra : rebase_source : c1d488fdd65bfa7ede12c12004921415aaaa1d55
extra : source : f9482471bbd83882f8da3f0ce929f72858abfa04
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
Use it like this:
MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_LOG=MSGTracing:5,sync,raw MOZ_LOG_FILE=trace.log ./mach run
Now open `chrome://tracing` and load the file.
Lanes are threads, thread 0 is the audio callback thread, the other thread have
normal numbers.
Thread 1 shows the theoretical budget we have for a particular audio callback.
MozReview-Commit-ID: 87woGiFT4ID
--HG--
extra : rebase_source : b4310af51efa83c6670ba4e37433f7a23a575bba
extra : source : 14929579ba3f71f14c9d81b6ed88563d35da11e0
This outputs to MOZ_LOG and using an MPSC lock-free queue so we can log to a
particular module from any thread.
MozReview-Commit-ID: INtlki4PEJs
--HG--
extra : rebase_source : c1d488fdd65bfa7ede12c12004921415aaaa1d55
extra : source : f9482471bbd83882f8da3f0ce929f72858abfa04
shindli
Aaron Klotz
Jean-Yves Avenard
Chris Pearce
Alex Chronopoulos
Arnaud Bienner
Bryce Van Dyk
Margareta Eliza Balazs
sotaro
Jeff Gilbert
Emilio Cobos Álvarez
Chris Peterson
Nico Grunbaum
Joel Maher
Dan Minor
Paul Adenot
Andreea Pavel
maxLanglade
Nathan Froyd
Andi-Bogdan Postelnicu
Valentin Gosu
arthur.iakab
Dorel Luca
Andreas Pehrson
Ciure Andrei
Jan de Mooij
Byron Campen [:bwc]
Jan-Ivar Bruaroey
Miko Mynttinen
Felix Weinrank
Jonathan Watt
Andrea Marchesini
Csoregi Natalia
Matthew Gregan
Kris Maglione
Jim Chen
Kartikaya Gupta
Adrian Wielgosik
Alastor Wu
Narcis Beleuzu
Gerald Squelart
Cosmin Sabou
Tiberius Oros
Mark Banner
Karl Tomlinson
Jean-Luc Bonnafoux
cubouyaka
David Major
Brindusan Cristian
Tom Ritter
Boris Zbarsky
Nico Grunbaum
Coroiu Cristina
Takuro Ashie
Nicholas Nethercote