If an mp4 uses the AVC3 sample format then extra data will be stored in sample
data rather than in metadata. In encrypted streams the metadata is unencrypted
but samples are typically encrypted. If all samples are encrypted and the only
SPS data is in samples then the MediaChangeMonitor will never observe any SPS
data.
This updates the MediaChangeMonitor so that it will not try and inspect h264
content once encryption is detected and relies on the CDM to handle such
content.
Differential Revision: https://phabricator.services.mozilla.com/D37485
--HG--
extra : moz-landing-system : lando
Adds a lock in MediaCacheStream::SizeOfExcludingThis to prevent a race
condition with MediaCache::NoteSeek
Differential Revision: https://phabricator.services.mozilla.com/D36880
--HG--
extra : moz-landing-system : lando
In bug 1552607/D36382, RemoteDataDecoder always increases session ID but
CodecProxy only performs flush IPC when neccessary. This will cause the
ID numbers out of sync and prevent remote decoder from receiving any
more input. By reading the session ID in dequeued input samples, the
numbers can always be in sync.
Differential Revision: https://phabricator.services.mozilla.com/D37123
--HG--
extra : moz-landing-system : lando
This is a refactor of the encryption scheme detection used in Index.cpp aside
from one additional check: the new function verifies that if sample group
information is present that it is consistent with other encryption information.
Introduce a new function that contains all the logic to detect the encryption
scheme used for the current sample. This helps separate the logic of scheme
detection from setting scheme specific data on the current sample. This makes
the steps easier to understand and change in isolation.
This function returns a result, with failure cases containing a string
explaining the error. This is motivated by being able to log or surface the
error for failure cases. Logging is not yet implemented, but will be in
bug 1547328.
Driveby add comment documenting GetSampleEncryptionEntry.
Driveby adjust include order to match Mozilla/Google style.
Differential Revision: https://phabricator.services.mozilla.com/D30111
--HG--
extra : moz-landing-system : lando
According to the spec [1], the background box should be `display:inline`.
Therefore, we should create a `<span>`, which already is an inline element, for the background box, not a `<div>`, which is a block element.
In addition, when the pseudo element is enabled, even though the element is currently a `div`, it doesn't match the div `{ display: block; }` rule from the UA style sheet because the pseudo element only matches `::cue` rules. It also has the initial value of display which is `inline`.
[1] https://www.w3.org/TR/webvtt1/#webvtt-cue-background-box
Differential Revision: https://phabricator.services.mozilla.com/D36849
--HG--
extra : moz-landing-system : lando
If the background node is not a pseudo element, these properties would actually be inherited, so we have no need to set them again.
Differential Revision: https://phabricator.services.mozilla.com/D36848
--HG--
extra : moz-landing-system : lando
In order to clearly see what properties are applied on the root node, create a function to list all of them together.
Differential Revision: https://phabricator.services.mozilla.com/D36847
--HG--
extra : moz-landing-system : lando
Setting cue's position would also affect cue box's size which would be determined by cue's position alignment as well. If the cue box's width or height is zero, it means that this box should not be display on the screen and we should clear cue's display state as well.
Differential Revision: https://phabricator.services.mozilla.com/D35693
--HG--
extra : moz-landing-system : lando
This implements the machinery for the splitting of static prefs headers, and
uses it for a single header. #includes are used in such a way that the amount
of boilerplate for each static prefs header file is minimal.
Future patches will split the remaining prefs into more header files.
Differential Revision: https://phabricator.services.mozilla.com/D36154
--HG--
rename : modules/libpref/StaticPrefs.h => modules/libpref/StaticPrefsBase.h
rename : modules/libpref/StaticPrefs.h => modules/libpref/init/StaticPrefListBegin.h
extra : moz-landing-system : lando
In the spec [1], it only considers text's alignment when computing the `position`. However, the text alignment `start` and `end` can make the same result of what `left` and `right` make, depending on what direction the text uses.
For example, setting text alignment `left` is equal to `start` for the LTR text. Therefore, we could check the result of `ComputedPositionAlign`, which would return correctly direction automatically accoding to the text's base direction.
[1] https://www.w3.org/TR/webvtt1/#cue-computed-position
Differential Revision: https://phabricator.services.mozilla.com/D35272
--HG--
extra : moz-landing-system : lando
Add new test cases for alignment `start` and `end` for both LTR and RTL text.
Differential Revision: https://phabricator.services.mozilla.com/D35271
--HG--
extra : moz-landing-system : lando
This does two things:
It makes MediaEngineDefaultVideo::GetBestFitnessDistance include a facingMode
check.
It also makes FitnessDistance() for StringRanges take a Maybe<nsString>, since
the device might not have a value for all StringRange constraints, as is the
case for facingMode. This fixes this issue for a MediaEngineRemoteVideoSource
with no facingMode, since such a device would match a facingMode of the empty
string prior to this patch.
To be fully spec compliant, the Maybe should be a set instead, since a device
may support multiple values for the facingMode capability. We don't support
more than one value however, so this change can be made later as needed.
Differential Revision: https://phabricator.services.mozilla.com/D35841
--HG--
extra : moz-landing-system : lando
In order to simulate the specific running order, we have to add a test event 'mozStartedLoadingTextTrack', which would be controlled under a pref.
This test is used to ensure that we won't get `error` event when we change track's mode during loading.
Differential Revision: https://phabricator.services.mozilla.com/D36410
--HG--
extra : moz-landing-system : lando
There are several places doing channel or listenr clean up, all these places should do channel and listener clean-up together because they are being used as a pair.
Differential Revision: https://phabricator.services.mozilla.com/D36409
--HG--
extra : moz-landing-system : lando
When we start a new load, all previous data fetching from the previous listener and all state changing applied to track element should be ignored.
Therefore, we add a new method `Cancel()` which owner of the listener should call when we would like to discard current listener.
Differential Revision: https://phabricator.services.mozilla.com/D36407
--HG--
extra : moz-landing-system : lando
Refactor these log by using the `WebVTT` log module and adding address info in the log.
Differential Revision: https://phabricator.services.mozilla.com/D36405
--HG--
extra : moz-landing-system : lando
MediaInputPort::Destroy must always be called, or it will not remove its strong
ref to the MediaStreamGraph. The guard is not even needed, since
MediaInputPort::Disconnect is idempotent.
Differential Revision: https://phabricator.services.mozilla.com/D36571
--HG--
extra : moz-landing-system : lando