This only enables mDNS on OS X for now. Some versions of Windows lack mDNS
support, there are some oddities with resolving IPv6 addresses on Linux, and
Android has not yet been tested. All of these will be addressed in follow on
bugs.
Differential Revision: https://phabricator.services.mozilla.com/D38496
--HG--
extra : moz-landing-system : lando
Before this patch, it was unclear who was responsible for checking deviceId and
groupId constraints for devices. MediaManager was doing it through one path for
getUserMedia, with the help of the devices, as part of selecting the
best-fitting device. However, Reconfigure() took another path where the regular
backends for camera and microphone were implemented correctly, but fake devices
were left out so automated tests for applyConstraints were failing.
This patch lifts the responsibility for checking deviceId and groupId
constraints out of the MediaEngineSources into MediaDevice, which already is the
owner of the anonymized ids that MediaEngineSources are unaware of.
This makes constraints checking a two-staged approached where deviceId and
groupid goes first. If they satisfy the constraints, the underlying device is
queried for whether the constraints fit.
As a bonus, this unclutters a lot of the MediaEngineSource interface.
Differential Revision: https://phabricator.services.mozilla.com/D40834
--HG--
extra : moz-landing-system : lando
As we will allow user inputs on editable content to activate document, we should remove them from black list test.
Differential Revision: https://phabricator.services.mozilla.com/D43533
--HG--
extra : moz-landing-system : lando
It would be easier to reuse the utterance if it's stateless. The state
could still be tracked by moving from SpeechSynthesisUtterance to
nsSpeechTask, which is the place to change the state in original
implementation. By removing state in utterance, we don't need to check
the state of utterance when it's pushed into the speech queue.
Differential Revision: https://phabricator.services.mozilla.com/D35464
--HG--
extra : moz-landing-system : lando
All the LOG are placed in Dispatch*Impl except DispatchErrorImpl. Move
the LOG from DispatchError to DispatchErrorImpl to align the LOG policy
in the nsSpeechTask.
Differential Revision: https://phabricator.services.mozilla.com/D35461
--HG--
extra : moz-landing-system : lando
The nsAString overload of GetCallingLocation directly converts the
original source file name string into an nsAString. A number of
callers that want the source file name in an nsAString are calling the
nsACString overload of GetCallingLocation, then calling
NS_ConvertUTF8toUTF16. This results in an extra intermediate copy of
the original string data.
Differential Revision: https://phabricator.services.mozilla.com/D42727
--HG--
extra : moz-landing-system : lando
This adds a field to about:webrtc which indicates whether an associated
candidate is behind a proxy or not.
Differential Revision: https://phabricator.services.mozilla.com/D39974
--HG--
extra : moz-landing-system : lando
We have already had a exactly same function, so can remove a redundant one.
Differential Revision: https://phabricator.services.mozilla.com/D41132
--HG--
extra : moz-landing-system : lando
When adjusting cues with `snapToLines=false`, first we would generate an array with all different axises which we would use to move cue on the specific direction.
However, for the different writing directions, we should have different priority for the moving directions.
For example, if the wriring direction is `horizontal`, which means cues will grow from the top to the bottom, then moving cues along the `y` axis should be more important than moving cues along the `x` axis, and vice versa for those cues growing from the left to right, or from the right to the left.
After decided the moving direction, then we have to decide the moving offset. Now we use line box's Bsize as a basic moving unit.
Moving cues, however, by such as large distance as a time would cause too many redudant space between cue boxes, which doesn't provide a good enough visual arrangement result. Therefore, we divide the Bsize by a factor, which can control the granularity of the moving unit and can still preverse a reasonable space between boxes. That can provide way better visual result than the one we had used before, and still has certain good performance comparing with moving 1px at a time.
Differential Revision: https://phabricator.services.mozilla.com/D41131
--HG--
extra : moz-landing-system : lando
When adjusting the position of the cue box, if we can't find a proper place to display the cue within the video rendering area, we should return `null` and not to show it on the screen.
Differential Revision: https://phabricator.services.mozilla.com/D40901
--HG--
extra : moz-landing-system : lando
When calculating position percentage, `top` should divide the height of the video rendering area, and `left` should divide the width of the video rendering area.
Differential Revision: https://phabricator.services.mozilla.com/D40900
--HG--
extra : moz-landing-system : lando
In order to encode video frame, we have to convert `webrtc::VideoFrame` to gecko's video data, and then send this YUV-based video data to the encoder.
The encoder won't return an encoded frame everytime when we call its `encode()`, so we have to wait until there are valid samples added to `mEncodedFrames`.
Then, convert the `MediaRawData` to `webrtc::EncodedImage` and provide an NAL entries list to indicate where the NALs are in the encoded bytes stream and how large they are. We would send those data back
to the consumer of the encoder via calling a callback function `OnEncodedImage()`.
Differential Revision: https://phabricator.services.mozilla.com/D40532
--HG--
extra : moz-landing-system : lando
Implement a basic interface for `WebrtcMediaDataEncoder`, which will only be used on OSX for encoding h264 only.
Differential Revision: https://phabricator.services.mozilla.com/D40529
--HG--
extra : moz-landing-system : lando
Bug 1522547 overlooked the need for specifying map entries for both nsISupports
and nsIDocumentActivity and only had the latter. This changeset adds the missing
nsISupports case.
Differential Revision: https://phabricator.services.mozilla.com/D42563
--HG--
extra : moz-landing-system : lando
__PRETTY_FUNCTION__ and __FUNCTION__ are not guaranteed to be a string
literal, and only string literals should be used as format strings. GCC
9 complains about this with -Werror=format-security.
Differential Revision: https://phabricator.services.mozilla.com/D42459
--HG--
extra : moz-landing-system : lando
If Status is defined (X11 headers define it as int), it ends up busting the
Status enum used in the Widevine headers. Avoid this by undeffing it before
including headers.
Differential Revision: https://phabricator.services.mozilla.com/D42335
--HG--
extra : moz-landing-system : lando
GetStatusPolicy should not treat unrecognized values as if they were no hdcp
policy. A trivial example is that if we do not recognize a newer hdcp string,
say "2.3", then we should not query if the CDM supports this policy as if it
were no hdcp.
This patch means that we surface and error to JS if we do no recognize an hdcp
string.
Differential Revision: https://phabricator.services.mozilla.com/D42061
--HG--
extra : moz-landing-system : lando
This removes the call to SetThreeDPointParameter which is no longer necessary
now that we're using AudioParams for position and orientation. Doing the
conversion can cause an assertion failure when the AudioParams have a scheduled
future value.
Differential Revision: https://phabricator.services.mozilla.com/D42023
--HG--
extra : moz-landing-system : lando
The return value for PChromiumCDM::Init was unused when the IPDL change was
first made. However, that quickly changed, but I failed to update the IPDL to
reflect that the value is now used to propagate the value that CDM interface 10
Widevine modules give us via the OnInitialized callback.
This patch fixes the IPDL to reflect that. The changes in C++ code have already
been made, so no change needed there.
Differential Revision: https://phabricator.services.mozilla.com/D41995
--HG--
extra : moz-landing-system : lando
These functions were made public in 10.6. The oldest version we support is 10.9.
Differential Revision: https://phabricator.services.mozilla.com/D41813
--HG--
extra : moz-landing-system : lando
Bug 1540748/D28167 checks the output sample timestamp against the
time parsed by demuxer to determine the validness. However, unlike
Android builtin MP3 decoder which sets EOS flag in the final valid
output, the Samsung MP3 decoder always emit additional EOS sample
with invalid timestamp. To address this, the timestamp check should
be ignore for EOS samples.
Differential Revision: https://phabricator.services.mozilla.com/D41872
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
If for some reason mDecoder didn't exist, we would get an assertion inside FinalizeShutdown().
Differential Revision: https://phabricator.services.mozilla.com/D41359
--HG--
extra : moz-landing-system : lando
Introduce a static method to call the CheckVersion method of the IPDL protocol from the content process. Every time a video decoder is initialized, the method is called to verify the version of the stored benchmark entries.
Differential Revision: https://phabricator.services.mozilla.com/D41003
--HG--
extra : moz-landing-system : lando
The new protocol method transfers the database name and the version number from the content to the parent process. Then the parent process retrieves the stored version number from the database and compares it to the provided version number. If they are the same it stops there, otherwise it erases all the entries from the database and stores the new version number.
Differential Revision: https://phabricator.services.mozilla.com/D41002
--HG--
extra : moz-landing-system : lando
Add a new method in the key-value wrapper (KeyValueStorage) to clear all the entries of a database.
Differential Revision: https://phabricator.services.mozilla.com/D41001
--HG--
extra : moz-landing-system : lando
This does the following things:
- Renames mClusters to mCurrentCluster and updates the comment to be accurate.
- Removes the need for mClusterHeaderIndex since it was always 0.
- Removes the need for mWritingCluster since it was redundant with
mCurrentCluster containing something.
- Renames mClusterLengthLoc to mCurrentClusterLengthLoc to better pair with
mCurrentCluster.
- Renames mClusterTimecode to mCurrentClusterTimecode to better pair with
mCurrentCluster.
- Reorders member declarations to better reflect which members group together.
- Fixes static-analysis warnings by removing uint32_t from loop variables.
Differential Revision: https://phabricator.services.mozilla.com/D40835
--HG--
extra : moz-landing-system : lando
This changes from trying to encode at the memory-blob-limit to requesting small
blobs for ensuring a memory blob and increasingly large blobs for ensuring a
file blob.
A theory why this would end up failing on Android hw is because fake video on
Android is 320x240 as opposed to 640x480 on other platforms. Add timing changes
from bug 1014393 and the permafail on Android doesn't seem surprising.
Differential Revision: https://phabricator.services.mozilla.com/D40656
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
This changes the way crash reports for child processes happening too early
during the child process' startup. Before bug 1547698 we wrote a partial
.extra file with those crashes that lacked the process type. The user would
not be notified of those crashes until she restarted Firefox and even when
submitted those crashes would be erroneously labeled as browser crashes.
After bug 1547698 we stopped writing .extra files entirely for those crashes
which left orphaned .dmp files among the pending crash reports.
This patch does three things to improve the situation:
* It writes a partial .extra file so that the crashes are detected at the next
startup. So the user is still not notified directly of these crashes but she
can report them later.
* It adds the process type to the .extra file so that the crash reporters are
labelled correctly.
* It fixes a leak in the `pidToMinidump` hash-map. Since the crashes were
not finalized the `ChildProcessData` strucutre associated with them would
never be fred.
Differential Revision: https://phabricator.services.mozilla.com/D40810
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We don't want to enable audio competing by default, so hide this feature behind a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D38143
--HG--
extra : moz-landing-system : lando
In order to support audio competing among different tabs, we implement a new class AudioFocusManager.
AudioFocusManager is used to assign the audio focus to different requester and decide which requester can own audio focus when audio competing happens.
When the audio competing happens, the last request would be a winner who can still own the audio focus, and all the other requesters would lose the audio focus.
Now MediaController is the onlt requester, it would request the audio focus when it becomes audible and revoke the audio focus when the controller is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D38142
--HG--
extra : moz-landing-system : lando
In order to have a centralized audio control in the parent process, we create two new classes here.
* MediaController
MediaController is a class used to control certain amount of media in the content process. Every controller corresponds to a browsing context.
For example, TabMediaController would correspond to the top level browsing context, which mean it can control all media in the specific tab.
* MediaControlService
As there might be multiple tabs playing audio, so there would be multiple controllers. MediaControlService is a place to manage all of them, you can access specific controller through MediaControlService by providing controller ID.
Everytime a controller becomes active, which means there is a media starts in corresponding browsing context, then controller would be added into the list of the MediaControlService. And it would be removed from the list when the media in corresponding browsering context stopped.
Differential Revision: https://phabricator.services.mozilla.com/D38141
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We don't want to enable audio competing by default, so hide this feature behind a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D38143
--HG--
extra : moz-landing-system : lando
In order to support audio competing among different tabs, we implement a new class AudioFocusManager.
AudioFocusManager is used to assign the audio focus to different requester and decide which requester can own audio focus when audio competing happens.
When the audio competing happens, the last request would be a winner who can still own the audio focus, and all the other requesters would lose the audio focus.
Now MediaController is the onlt requester, it would request the audio focus when it becomes audible and revoke the audio focus when the controller is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D38142
--HG--
extra : moz-landing-system : lando
In order to have a centralized audio control in the parent process, we create two new classes here.
* MediaController
MediaController is a class used to control certain amount of media in the content process. Every controller corresponds to a browsing context.
For example, TabMediaController would correspond to the top level browsing context, which mean it can control all media in the specific tab.
* MediaControlService
As there might be multiple tabs playing audio, so there would be multiple controllers. MediaControlService is a place to manage all of them, you can access specific controller through MediaControlService by providing controller ID.
Everytime a controller becomes active, which means there is a media starts in corresponding browsing context, then controller would be added into the list of the MediaControlService. And it would be removed from the list when the media in corresponding browsering context stopped.
Differential Revision: https://phabricator.services.mozilla.com/D38141
--HG--
extra : moz-landing-system : lando
It would cause an assertion failure when OutputStreamManager was released on
main thread. It could be wrapped in an nsMainThreadPtrHandle instead, but that's
exactly what mPrincipalHandle is, so we can use that for both needs.
Differential Revision: https://phabricator.services.mozilla.com/D40789
--HG--
extra : moz-landing-system : lando
1. ShmemPool.cpp is now built for --disable-webrtc builds.
2. ShmemPool no longer uses the gCamerasParentLog logger, it
uses its own logger.
3. ShmemPool log macros were updated with a SHMEMPOOL_ prefix
to avoid undef-ing other log macros.
Differential Revision: https://phabricator.services.mozilla.com/D40722
--HG--
extra : moz-landing-system : lando
Create an event in MediaFormatReader the will signal to the HTMLMediaElement to initiate a new storing according to the latest VideoInfo. Also when the application is shutting down, trigger a new storing early enough, before all the events are disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D38316
--HG--
extra : moz-landing-system : lando
Make use of the new DecoderBenchmark class in MediaCapabilities instead of the old Benchmark mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D38315
--HG--
extra : moz-landing-system : lando
Create a class that gets the video properties and the frame statistics, calculates the score in percentage for that video playback, creates a key string according to video properties and trigger the storage of the score.
The video properties used are the resolution, the frame rate and the bitdepth.
For the key, a range of levels has been created for each property and the video is categorised on the closest levels. The key consists of the various levels like: "ResolutionLevel5-FrameRateLevel1-8bit".
Finaly, it uses the IPDL protocol to store the pair of the score and the key.
Differential Revision: https://phabricator.services.mozilla.com/D38314
--HG--
extra : moz-landing-system : lando
The database is accessible from the parent process due to to the sandbox thus it is required an IPDL protocol that will transfer the queries and the results
Differential Revision: https://phabricator.services.mozilla.com/D38313
--HG--
extra : moz-landing-system : lando
This patch implements how to use MediaController to control corresponding media in content processes.
Differential Revision: https://phabricator.services.mozilla.com/D38145
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We don't want to enable audio competing by default, so hide this feature behind a static pref.
Differential Revision: https://phabricator.services.mozilla.com/D38143
--HG--
extra : moz-landing-system : lando
In order to support audio competing among different tabs, we implement a new class AudioFocusManager.
AudioFocusManager is used to assign the audio focus to different requester and decide which requester can own audio focus when audio competing happens.
When the audio competing happens, the last request would be a winner who can still own the audio focus, and all the other requesters would lose the audio focus.
Now MediaController is the onlt requester, it would request the audio focus when it becomes audible and revoke the audio focus when the controller is no longer active.
Differential Revision: https://phabricator.services.mozilla.com/D38142
--HG--
extra : moz-landing-system : lando
In order to have a centralized audio control in the parent process, we create two new classes here.
* MediaController
MediaController is a class used to control certain amount of media in the content process. Every controller corresponds to a browsing context.
For example, TabMediaController would correspond to the top level browsing context, which mean it can control all media in the specific tab.
* MediaControlService
As there might be multiple tabs playing audio, so there would be multiple controllers. MediaControlService is a place to manage all of them, you can access specific controller through MediaControlService by providing controller ID.
Everytime a controller becomes active, which means there is a media starts in corresponding browsing context, then controller would be added into the list of the MediaControlService. And it would be removed from the list when the media in corresponding browsering context stopped.
Differential Revision: https://phabricator.services.mozilla.com/D38141
--HG--
extra : moz-landing-system : lando
If webm is disabled or not compiled in, the video assert would fail if trying
to record a video track -- we'd only have an ogg/opus encoder.
Differential Revision: https://phabricator.services.mozilla.com/D40648
--HG--
extra : moz-landing-system : lando
This hasn't been needed since the last larger refactor of DecodedStream
(bug 1423241), but got incorporated wrongly with bug 1493613.
When DecodedStream is Stop()ed and then Start()ed, a track is added to the graph
with a playout position starting at 0, and mStartTime is set to the starting
position, i.e., the seeked position in case of a seek or 0 if decoding from the
start of a file.
Hence, the reported position by DecodedStream should be mStartTime plus the last
reported output time of the tracks.
mStreamTimeOffset was offseting the tracks' reported output time further, so
DecodedStream was reporting a too large number.
Differential Revision: https://phabricator.services.mozilla.com/D40626
--HG--
extra : moz-landing-system : lando
If the encoded frame is a keyframe, we should also mark the MediaRawData which would contain the data from this encoded frame as a keyframe.
Differential Revision: https://phabricator.services.mozilla.com/D40465
--HG--
extra : moz-landing-system : lando
As we are not going to modify the CodecSpecific, it should keep const when we forward it.
Differential Revision: https://phabricator.services.mozilla.com/D40464
--HG--
extra : moz-landing-system : lando
We don't have a contraint for using PlatformEncoderModule in the specific thread only, so we should use thread-safe refcounting for it, like PlatformDecoderModule.
Differential Revision: https://phabricator.services.mozilla.com/D40463
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This removes all telemetry which expired in Firefox 69 or earlier, with the
exceptions of the following, which we plan to renew:
* AUDIO_TRACK_SILENCE_PROPORTION
* MEDIA_AUTOPLAY_WOULD_BE_ALLOWED_COUNT
* MEDIA_AUTOPLAY_WOULD_NOT_BE_ALLOWED_COUNT
* MEDIACACHESTREAM_LENGTH_KB
* MEDIA_MKV_CANPLAY_REQUESTED
* MEDIA_PAGE_COUNT
* MEDIA_PAGE_HAD_MEDIA_COUNT
* VIDEO_DROPPED_FRAMES_PROPORTION
* VIDEO_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME
* VIDEO_HIDDEN_PLAY_TIME_PERCENTAGE
* VIDEO_INFERRED_DECODE_SUSPEND_PERCENTAGE
* VIDEO_INTER_KEYFRAME_AVERAGE_MS
* VIDEO_INTER_KEYFRAME_MAX_MS
* VIDEO_SUSPEND_RECOVERY_TIME_MS
* VIDEO_VP9_BENCHMARK_FPS
* WEB_AUDIO_BECOMES_AUDIBLE_TIME
* WEBVTT_TRACK_KINDS
Differential Revision: https://phabricator.services.mozilla.com/D37313
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
This first of all does some refactoring of how metadata is encoded in
MediaEncoder. This is now guided by the new Muxer class. If we're ready to pass
data to the muxer and it does not have metadata yet, we provide metadata before
giving it any media data. This metadata is passed to the muxer in a single call.
The metadata provided in this call must stay valid for the entire recording.
This removes MediaEncoder::GetEncodedMetadata().
This also removes the ctor argument from the WebMWriter since it can now rely on
the single SetMetadata() instead.
To comply with the ContainerWriter::SetMetadata() docs,
WebMWriter::SetMetadata() will now also sanity check metadata.
ContainerWriter instances are updated somewhat, to accommodate these changes.
Lastly, and most important, the new Muxer class manages muxing of the (up to)
two tracks into a single container, ensuring that timestamps increase
monotonically throughout a recording.
Differential Revision: https://phabricator.services.mozilla.com/D35306
--HG--
extra : moz-landing-system : lando
Update MediaEncoder to pass frames to the muxer in order of their time stamps.
This should prevent the currently possible scenario where audio and video
frames are written with non-monotonically increasing timestamps (in violation
of the webm spec).
Differential Revision: https://phabricator.services.mozilla.com/D35388
--HG--
extra : moz-landing-system : lando
MediaQueue provides a better interface for interleaving frames when writing to
the muxer (this change will follow in another changeset). The queue interface
provides a nicer abstraction than manually managing a nsTArray.
Differential Revision: https://phabricator.services.mozilla.com/D35387
--HG--
extra : moz-landing-system : lando
This changes EncodedFrame to behave more like MediaData, so that EncodedFrame
can be used with the MediaQueue data structure. It also provides a somewhat
more consistent interface across media data types.
Differential Revision: https://phabricator.services.mozilla.com/D35386
--HG--
extra : moz-landing-system : lando
Move the responsibility of adjusting opus frame timestamps to the MediaEncoder.
This was previously done by the EbmlComposer, but doing so in the MediaEncoder
means we can have greater control over handling of time codes and interleaving
of frames.
Differential Revision: https://phabricator.services.mozilla.com/D35385
--HG--
extra : moz-landing-system : lando
Remove EncodedFrameContainer and clean up areas where it was used.
EncodedFrameContainer provided a wrapper around an
nsTArray<RefPtr<EncodedFrame>>, but it simplifies the code to simply expose
this array. Also clean up unused enums in EncodedFrame, and clean up some of
the outdated comments for our encoded frame handling.
Differential Revision: https://phabricator.services.mozilla.com/D35384
--HG--
rename : dom/media/encoder/EncodedFrameContainer.h => dom/media/encoder/EncodedFrame.h
extra : moz-landing-system : lando
Separating the encode and mux steps allows for better control over interleaving
audio and video data. If encode and mux are done in a single step it's possible
to mux large amounts of audio or video data which should have been interleaved
with the other data type to give correctly ordered time stamps in the target
container.
Differential Revision: https://phabricator.services.mozilla.com/D35383
--HG--
extra : moz-landing-system : lando
This moves the impl of PushBlobRunnable from a runnable to MozPromise, which
let's us more easily modularize it's parts (gather the blob, fire dataavailable)
to make individual code paths more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D17813
--HG--
extra : moz-landing-system : lando
