This removes all references to application capture except from MediaSourceEnum.
That was left in place so as to not change the enumerated values used
for WEBRTC_GET_USER_MEDIA_TYPE telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D28089
--HG--
extra : moz-landing-system : lando
These are added in start, and we get into unexpected state if they notify us
after Stop() (when MediaEncoder shuts down and internally removes the tracks
it is encoding) but before Shutdown() when we remove the listeners. This is not
symmetrical. The proper thing to do is to remove these listeners in Stop() as
well.
Depends on D29080
Differential Revision: https://phabricator.services.mozilla.com/D29081
--HG--
extra : moz-landing-system : lando
The mp4 demuxer already does this, so have the WebM case follow suit. This
avoids asserts with creating 0 size shmems in the case where the demuxer is
being used with the remote data decoder.
Differential Revision: https://phabricator.services.mozilla.com/D25846
--HG--
extra : moz-landing-system : lando
As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.
However, we can't always ensure the demuxed start time is correct, the decoded first frame sample time might be different with the time demuxer provides.
Even if we try to update the start time when we get the first decoded sample, there is still a problem because a decoder might return samples with different order, which means the first frame the decoder returns is probably not a real first frame.
Therefore, using warning to help us knows how many this situaion would be.
Differential Revision: https://phabricator.services.mozilla.com/D28432
--HG--
extra : moz-landing-system : lando
Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time.
When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should throw an error for that.
Differential Revision: https://phabricator.services.mozilla.com/D28167
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
We're rarely getting nullptrs out of MediaQueues. It's not clear where these are
coming from, as we have many guards against them. Upgrade this assert to a
diagnostic to help us track the source and determine if the value is null before
entering the queue.
Differential Revision: https://phabricator.services.mozilla.com/D28866
--HG--
extra : moz-landing-system : lando
We don't currently know any ways in which external code can make the
suspendCount negative, but this will keep us safe should a future bug enable it.
Depends on D28805
Differential Revision: https://phabricator.services.mozilla.com/D28806
--HG--
extra : moz-landing-system : lando
This patch moves remaining public `enum` of `nsIPresShell` to `mozilla`
namespace in `mozilla/PresShellForwards.h` and make them `enum class`es.
Additionally, some methods which use the moving `enum`s from `nsIPresShell`
to `PresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D28607
--HG--
extra : moz-landing-system : lando
The value of `mAudioDecodedDuration` can be larger than `int32`, so we should use the modular function which accepts `TimeUnit`as a input.
Differential Revision: https://phabricator.services.mozilla.com/D28536
--HG--
extra : moz-landing-system : lando
We should only use valid time to construct a `SeekTarget`, because we can't get the value from the invalid time.
This can help us to prevent having a crash when request data value from an invalid time.
Differential Revision: https://phabricator.services.mozilla.com/D28564
--HG--
extra : moz-landing-system : lando
As the purpose of adjusting time is to make the start of the playback to align to zero, so the result should not be negative.
Differential Revision: https://phabricator.services.mozilla.com/D28432
--HG--
extra : moz-landing-system : lando
Considering that the audio sample's time is always increased, the decoded sample's time decoder returns should always be equal or larger than its demuxed time.
When the decoded sample's time is smaller than the time of first demuxed sample, that time would probably cause a problem so we should throw an error for that.
Differential Revision: https://phabricator.services.mozilla.com/D28167
--HG--
extra : moz-landing-system : lando
This moves the responsibility for creating MediaStreamTracks from
DecodedStream::Start to MediaDecoder. This let's MediaDecoder create them as
soon as metadata is known. This gives the application guarantees on when tracks
can be expected to exist, and aligns with the spec that says they should be
created when metadata is known.
Differential Revision: https://phabricator.services.mozilla.com/D28473
--HG--
extra : moz-landing-system : lando
This gives us a guarantee that the first frame of a media file can be rendered
with a second media element and mozCaptureStream(), even if the file is very
very short.
With longer video-only files there were also cases where nothing ended up being
rendered. Probably because the MediaStreamGraph ended up switching from an
AudioCallbackDriver to a SystemClockDriver and this took enough time to put the
SourceMediaStream::EndTrack and the SourceMediaStream::AddTrackListener calls
for this video track to be processed in the same iteration. The listener would
then always lose to the ending track and update main thread state too late,
leading to its media element not rendering any frames and nasty intermittent
failures.
Differential Revision: https://phabricator.services.mozilla.com/D27270
--HG--
extra : moz-landing-system : lando
`streamCurrentTime` is relative to the start of the stream, as is the track's
segment. We need to account for the track's start time in the stream when
notifying of output.
Differential Revision: https://phabricator.services.mozilla.com/D27268
--HG--
extra : moz-landing-system : lando
A case where this wasn't working was bipbop-lateaudio.mp4, where the last frame
has duration 0 and starts and ends before the previous frame has ended. The
VideoSink still renders this frame at the end of playback, so this patch
brings DecodedStream closer to that behavior by rendering all frames with a
start time after the previous frame's start time. The track's duration is still
based on absolute times so things don't blow up.
Differential Revision: https://phabricator.services.mozilla.com/D27267
--HG--
extra : moz-landing-system : lando
This is necessary to get an accurate total track duration in case DecodedStream
does a lot of seeking and pausing.
This also removes previous code for avoiding blocking a video track, as this new
code handles that case too.
Differential Revision: https://phabricator.services.mozilla.com/D27264
--HG--
extra : moz-landing-system : lando
Null frames could still be valid. It's how DecodedStream signals a pause. They
could also be valid and have an intrinsic size and the force-black flag set.
Differential Revision: https://phabricator.services.mozilla.com/D27263
--HG--
extra : moz-landing-system : lando
This is similar to what VideoSink does, and is required for us to end playback
on HAVE_CURRENT_DATA (a frame for currentTime must be available).
Differential Revision: https://phabricator.services.mozilla.com/D27261
--HG--
extra : moz-landing-system : lando
This tests HTMLMediaElement::MozCaptureStream on all of our play-tests, rather
than just a single test, in order to test more corner cases in the capture code.
Because this test checks that the media element that's playing the
mozCaptureStream()-stream ends after at least the duration of the original media
file, and because media elements playing a MediaStream have a `currentTime`
based on the MediaStreamGraph's monotonically increasing clock, we need to have
accurate metadata for how long the duration of the content of the original media
file is. There are several cases among the play-tests where the duration
metadata doesn't match what the decoder gives us -- the reason is often preroll
or corrupt containers. This patch updates manifest.js with `contentDuration` for
the tests among `gPlayTests` where try detected mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D27257
--HG--
extra : moz-landing-system : lando
Dan Minor
Sylvestre Ledru
Andreas Pehrson
Jan-Ivar Bruaroey
Bryce Van Dyk
Byron Campen [:bwc]
Cosmin Sabou
Alastor Wu
Dorel Luca
Emilio Cobos Álvarez
Masayuki Nakano
shindli
Michael Froman
Razvan Maries