Because we sync video frames to audio time before encoding, we suspend and
resume on the audio thread because that's the only place we have acccess to
both clocks at the same time;
- A dispatch to the audio encoder puts the event in the right place in the
audio encoder buffer.
- TimeStamp::Now() is the current video time, and since we capture it on the
audio thread these are in sync. This timestamp needs drift compensation too -
this happens in a later patch on this bug.
Differential Revision: https://phabricator.services.mozilla.com/D22907
--HG--
extra : moz-landing-system : lando
During review of bug 1458538, :bz noted that our event dispatching code could be
simplified by using DOMEventTargetHelper::DispatchTrustedEvent. As this was not
done during that bug, driveby fix here while we're making other changes.
Differential Revision: https://phabricator.services.mozilla.com/D14571
--HG--
extra : moz-landing-system : lando
Driveby change to bring our logging here in line with out other logging.
Depends on D14488
Differential Revision: https://phabricator.services.mozilla.com/D14489
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
This resolves the two problems of MediaRecorder:
1. MediaRecorder does not fire pause/resume events when the corresponding methods are called, as mentioned in D7910.
2. The WebIDL for MediaRecorder does not specify onpause/onresume event handler attributes neither.
DispatchSimpleEvent() is used because there are no event attributes needed.
Differential Revision: https://phabricator.services.mozilla.com/D7971
--HG--
extra : moz-landing-system : lando
Fix a bug that the current MediaRecorder's state error cases does not match the W3C spec.
pause() and resume() should throw an INVAILD_STATE_ERR only when it is inactive state, making them
independant.
Simply changing if statements is enough because the underlying encoder object (TrackEncoder) will
ignore Suspend/Resume calls when it is already suspended/recording so there won't be side-effects by
multiple pause()/resume() calls.
Differential Revision: https://phabricator.services.mozilla.com/D7910
--HG--
extra : moz-landing-system : lando
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
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
This allows MediaRecorder to pass non-empty blobs to content since our
blob gathering code waits for a new keyframe before writing to the blob.
--HG--
extra : rebase_source : be52d34df5c6b4d40d4b445c6d3ae0036e1c6904
extra : histedit_source : 43b2cf01b335a37f04032545fc9965bf574657ee
This is required now that the reporter is async.
MozReview-Commit-ID: djvw9v7kuj
--HG--
extra : rebase_source : d105f972eda0d59212b8094150762e44aa8c582d
This is primarily to improve code readability of the reporter's lifetime.
Creation of the singleton was hidden away in GetRecorders().
Both creation and destruction is now more explicit in {Add|Remove}MediaRecorder.
MozReview-Commit-ID: CqxgPQ1JptK
--HG--
extra : rebase_source : 5af3052911cd346c7d1221baf653f0b046304ed0
Add telemetry to collect the following:
- Number of times a MediaRecorder is started during a session
- Duration of media recordings
- How often we're timing out init of audio and video track encoders
MozReview-Commit-ID: 9Pc2oKNCH1M
--HG--
extra : rebase_source : 16414a5ffa95413458d36295e5508df4c16e6fa9
The main purpose of this patch is to make the TrackEncoders run in a TaskQueue
to avoid multi-threaded access to members, and to change to track listeners to
allow for recording all kinds of tracks (the description of bug 1296531).
MozReview-Commit-ID: EtLXaDDBPdy
--HG--
extra : rebase_source : 5761bb2c7d5832f69cc80129e5160f173e8168c7
extra : source : 24b2a67ddf5a621a5cf58af5b9e363dac3071775
The MediaRecorder should transition to a 'inactive' state immediately upon
error. This changeset updates the recorder to do so. Previously the recorder
would fire an error event before transitioning, resuling in the state still
being 'recording' for handling of the the thrown error.
MozReview-Commit-ID: KMkaPOnEBYx
--HG--
extra : rebase_source : 4d05d46de775029d307ac2460700ce28c4e8321a
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
In order to expose the JS stack on aync exceptions from the MediaRecorder,
these exceptions must be created at the time of the operation which led to the
exception. E.g. during the start() operation. This changeset creates the
exceptions ahead of time in order to expose the JS stack traces.
MozReview-Commit-ID: HgDJrpjgidD
--HG--
extra : rebase_source : 1d208a848308c819a209f4b5c33e3563e83b9518
The MediaRecorder is current not behaving as per the spec in regards to async
errors. The spec states that in such a scenario a MediaRecorderErrorEvent which
wraps a DOMException should be fired. This changeset updates the recorder to do
so.
MozReview-Commit-ID: xt4ipCmbiu
--HG--
extra : rebase_source : 50124e6c878438a84c8a440bf79e50b3b7da3998