+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
For lower resolution videos, we should be able to decode them well without storing too many video frames. So let's keep this mechanism for 4k+ video only.
Differential Revision: https://phabricator.services.mozilla.com/D118402
Improve the readability of the check and remove the next key frame check for the internal seek target because it's not related.
Differential Revision: https://phabricator.services.mozilla.com/D118401
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
[1]: https://searchfox.org/mozilla-central/rev/f351e19360729b351bfc7c1386d6e4ca4ea676e2/tools/clang-tidy/config.yaml#70
Differential Revision: https://phabricator.services.mozilla.com/D117714
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
It's better to change the input parameter's type of
`AppendAndConsumeChunk` from `AudioChunk*` to `AudioChunk&&` since the
`AudioChunk` will be consumed once it's fed to this function.
One benefit for doing so is to prevent the consumed `AudioChunk` from
being used again after it's moved/consumed. Gecko has a clang-tidy
check, bugprone-use-after-move [1], to avoid this kind of error. We
should utilize this check instead of catching used-after-move error by
human eyes.
Differential Revision: https://phabricator.services.mozilla.com/D117714
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
- Replace DMABufSurfaceWrapper array by FFmpegVideoFramePool and create it only when DMABuf/VA-API is used.
- Use FFmpegVideoFramePool to allocate/recycle video frames backed by DMABuf surfaces.
- Enable SW decoding to DMABuf surfaces only when VA-API is enabled to avoid potential breakage (keep recent state).
- Disable VA-API / DMABuf decoding when WebRender is not used.
- Remove DMABufSurfaceWrapper class.
Depends on D117222
Differential Revision: https://phabricator.services.mozilla.com/D117223
- Implement abstract class for video frames named VideoFrameSurface
- Implement VideoFrameSurfaceDMABuf class for video frames uploaded to DMABuf memory from SW decoding.
- Implement VideoFrameSurfaceVAAPI class for video frames decoded by VA-API.
- Implement VideoFramePool to create and recycle video frames.
Depends on D117221
Differential Revision: https://phabricator.services.mozilla.com/D117222
- Split VA-API / DMABuf video images decoding to CreateImageDMABuf() and CreateImageVAAPI(). CreateImageVAAPI() is used for VA-API only and CreateImageDMABuf() for images decoded by SW and uploaded to DMABuf.
- Implement FFmpegVideoDecoder::InitHWDecodingPrefs() where VA-API related prefereces are processed.
- Change mDisableHardwareDecoding to mEnableHardwareDecoding for better readability.
- Implement nsDMABufDevice::IsDMABufVideoEnabled() to explicitly configure dmabuf texture setup.
- Remove unused AllocateYUV420PVideoBuffer() prototype.
Differential Revision: https://phabricator.services.mozilla.com/D117220
As it's done on windows, preload libmozavcodec.so and libmozavutil.so
before sandboxing, this way this allows for a tighter sandboxing
(no filesystem access but /tmp for shm files, no prot_exec pledge..)
Depends on D116634
Differential Revision: https://phabricator.services.mozilla.com/D116635
- Replace DMABufSurfaceWrapper array by FFmpegVideoFramePool and create it only when DMABuf/VA-API is used.
- Use FFmpegVideoFramePool to allocate/recycle video frames backed by DMABuf surfaces.
- Enable SW decoding to DMABuf surfaces only when VA-API is enabled to avoid potential breakage (keep recent state).
- Disable VA-API / DMABuf decoding when WebRender is not used.
- Remove DMABufSurfaceWrapper class.
Differential Revision: https://phabricator.services.mozilla.com/D117223
- Implement abstract class for video frames named VideoFrameSurface
- Implement VideoFrameSurfaceDMABuf class for video frames uploaded to DMABuf memory from SW decoding.
- Implement VideoFrameSurfaceVAAPI class for video frames decoded by VA-API.
- Implement VideoFramePool to create and recycle video frames.
Depends on D117221
Differential Revision: https://phabricator.services.mozilla.com/D117222
- Split VA-API / DMABuf video images decoding to CreateImageDMABuf() and CreateImageVAAPI(). CreateImageVAAPI() is used for VA-API only and CreateImageDMABuf() for images decoded by SW and uploaded to DMABuf.
- Implement FFmpegVideoDecoder::InitHWDecodingPrefs() where VA-API related prefereces are processed.
- Change mDisableHardwareDecoding to mEnableHardwareDecoding for better readability.
- Implement nsDMABufDevice::IsDMABufVideoEnabled() to explicitly configure dmabuf texture setup.
- Remove unused AllocateYUV420PVideoBuffer() prototype.
Differential Revision: https://phabricator.services.mozilla.com/D117220
MDSM will stop decoding video when it reaches the certain amount of frames, but that will not work well if the video decoding is way too slow than the audio decoding.
In that situation, video should keep decoding as much as possible, in order to catch up with the audio decoding.
But we also don't need to decode video without any constraint, set the duration of decoded video to at least as the same as the decoded audio seems fair and enough.
Differential Revision: https://phabricator.services.mozilla.com/D117243
If the decoded video MDSM received is already late, then it indicates that video decoding is too slow.
If we keep decoding but in the same speed, it's very likely all following decoded videos would still be behind the clock and need to be discarded.
The reader has its own mechanism to seek to the next keyframe, but that will only happen when the time of next keyframe is behind the given time threshold, which is the current time.
When the video has pretty long keyframe interval (eg. 5s), then that mechanism won't be triggered because the even if the decoded video frames are late, the next keyframe still far exceeds the current time, so the reader doesn't think it's necessary to skip.
Therefore, MDSM should force the reader to seek to the next keyframe directly, because it know both the decoded time of video frames and the current playback time.
Differential Revision: https://phabricator.services.mozilla.com/D117242
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
As far a I can tell, mValidMoof does the same job as mHeader and has a clearer
name. Let's just remove mHeader and make the tests a little simpler. Longer
discussion below about why we may want to separate the flags, but I'm fairly
confident that it does not apply to our current tests.
Hypothetically it may make sense to separate these flags. mValidMoof is checked
against RebuildFragmentedIndex, while mHeader is checking if the moof parser has
at least one moof. If we RebuildFragmentedIndex once and it returns true, that
implies we have a least one moof. That is the state of all our current tests
IIUC. So there is no need to have separate flags. However, if we call
RebuildFragmentedIndex multiple times, and it succeeds, then fails, and we don't
evict moofs, then we could have times where the parser still has moofs stored
internally, even if we have a failed Rebuild. But we're not doing that as far as
I can tell in these tests.
Differential Revision: https://phabricator.services.mozilla.com/D117351
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
Now that we always have an MTA active, we don't need to explicitly try to
start it anymore. These locations in our source were doing so, which is now
not only redundant, but fails (since `EnsureMTA`'s default constructor is now
`private`).
We also fix a spot in `JumpListBuilder` where we need a lambda to capture by
reference to fix a static analysis issue.
Differential Revision: https://phabricator.services.mozilla.com/D113563
We don't need to explicitly reject such files, we can try to play them, and
provided the sample description entires specify the same crypto data, we should
be fine. However, if different entries use different crypto, we will likely run
into problems.
This patch fixes the blanket rejecting and lets us handle cases where the crypto
in each entry matches. Bug 1714626 tracks handling different crypto data. FWIW I
have never seen different crypto per sample description entry, and handling that
is a much bigger task, so this patch doesn't seek to do so.
Differential Revision: https://phabricator.services.mozilla.com/D116873
Add an init segment with 2 sample description entries, each with crypto data, to
the mp4 parser gtests.
3 test cases are updated:
- We ensure the init data parses with expected results as part of our general
'does this header parse, and with what result' style test.
- We ensure expected telemetry data is gather as part of our specialized
telemetry tests. Specifically, this adds coverage to the previously uncovered
multiple sample description entries with crypto case.
- We relax the expectation that encrypted files we parse with the MoofParser
will only have one encrypted sample description entry. We now expect these
files to have at least one encrypted entry.
Note the test case has the same crypto info in both entires, so these tests do
not cover the case where we need to handle different crypto info per sample
description.
Differential Revision: https://phabricator.services.mozilla.com/D117052
We don't need to explicitly reject such files, we can try to play them, and
provided the sample description entires specify the same crypto data, we should
be fine. However, if different entries use different crypto, we will likely run
into problems.
This patch fixes the blanket rejecting and lets us handle cases where the crypto
in each entry matches. Bug 1714626 tracks handling different crypto data. FWIW I
have never seen different crypto per sample description entry, and handling that
is a much bigger task, so this patch doesn't seek to do so.
Differential Revision: https://phabricator.services.mozilla.com/D116873
Add an init segment with 2 sample description entries, each with crypto data, to
the mp4 parser gtests.
2 test cases are updated:
- We ensure the init data parses with expected results as part of our general
'does this header parse, and with what result' style test.
- We ensure expected telemetry data is gather as part of our specialized
telemetry tests. Specifically, this adds coverage to the previously uncovered
multiple sample description entries with crypto case.
Note the test case has the same crypto info in both entires, so these tests do
not cover the case where we need to handle different crypto info per sample
description.
Differential Revision: https://phabricator.services.mozilla.com/D117052
Add an utility function named AppendFromInterleavedBuffer in
AudioSegment to append data from the given interleaved buffer. This
function does the same job as what AudioInputProcessing::InsertInGraph
and NativeInputTrack::ProcessInput were used to do. As a result, these
two functions can be eliminated or simplified.
Depends on D116673
Differential Revision: https://phabricator.services.mozilla.com/D116674
The AudioInputProcessing now needs to call ProcessInput to process the
given input data instead of processing them in NotifyInputData
Differential Revision: https://phabricator.services.mozilla.com/D116673
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
Instead of receiving and processing audio input data in
AudioInputProcessing::NotifyInputData, we can get the audio input data
from the connected source via the MediaInputPort and process it in
AudioInputTrack::ProcessInput
Differential Revision: https://phabricator.services.mozilla.com/D114807
- Create a NativeInputTrack that is managed by main-thread in MTG
- Replace mInputDeviceUsers by a <device-id, NativeInputTrack> map
Differential Revision: https://phabricator.services.mozilla.com/D113680
When we adjust the playback rate on the audio track, the audio clock time would be no longer align with the graph time.
Eg. playback rate=2, when the graph time passes 10s, the audio clock time actually already goes forward 20s.
After audio track ended, the video track would start to drive the clock time but the video clock time is align with the graph time, which means it would be smaller than the audio clock in that situation.
Therefore, we have to ignore the video clock time in that case. In addition, this patch also address the duration change on video frames based on the playback rate.
Differential Revision: https://phabricator.services.mozilla.com/D115035
By using the soundtouch library, this patch implements the time stretching on the samples in AudioDecoderInputTrack when its playback rate is not 1.0f, in order to support changing playback rate on the captured media stream.
As the time stretcher has to be initialized by a fixed channel count, we would perform a realtime up-mix/down-mix for those audio chunks which have different channel count thant AudioDecoderInputTrack's initial channel count.
Differential Revision: https://phabricator.services.mozilla.com/D114560
This tests two things: whether `mozCaptureStreamUntilEnded` is handled correctly
when the media element source is a `MediaSource`, and whether all objects have
references to each other as to not garbage collect any part of the system.
Differential Revision: https://phabricator.services.mozilla.com/D116397
Each AudioInputTrack has its own AudioSegments storing the input audio
data. When the AudioInputTrack is in pass-through mode, the AudioSegment
is just the data de-interleaved from its raw data, without any audio
processing magic applied on it. If there are multiple AudioInputTracks
in pass-through mode exist in the same graph, then all of their
AudioSegments are same.
Before this patch, each of these AudioInputTracks allocates its own
space to store its own AudioSegments even those data are same. This
patch makes it possible for these AudioInputTracks to share the same
AudioSegment data they need. By creating the AudioSegment in the
NativeInputTrack, which is mapped to one specific device and is
connected to the AudioInputTrack, the AudioInputTrack can fetch the
AudioSegment data when they need and then append shared-references of
the AudioChunk, inside the fetched AudioSegment, into their own
AudioSegment. Therefore, we can have some AudioChunks created by the
NativeInputTrack and shared among the AudioInputTracks in pass-through
mode.
Differential Revision: https://phabricator.services.mozilla.com/D114801
Instead of receiving and processing audio input data in
AudioInputProcessing::NotifyInputData, we can get the audio input data
from the connected source via the MediaInputPort and process it in
AudioInputTrack::ProcessInput
Differential Revision: https://phabricator.services.mozilla.com/D114807
- Create a NativeInputTrack that is managed by main-thread in MTG
- Replace mInputDeviceUsers by a <device-id, NativeInputTrack> map
Differential Revision: https://phabricator.services.mozilla.com/D113680
When we switch to the DecodedStream from AudioSink. AudioSink would store some frames in its own media queue before those audio frames get played. After AudioSink got shutdown, it doesn't push those frames back to the original audio queue.
Therefore, when DecodedStream starts, it try to retrieve audio data from the audio queue, but it doesn't know that there is already a gap between "the audio DecodedStream is going to play" and "the audio that AudioSink had played".
Differential Revision: https://phabricator.services.mozilla.com/D115749
Nothing used this function before this bug, so this field has never been used
anyway. We handle challenge loops with nr_turn_stun_ctx.retry_ct.
Differential Revision: https://phabricator.services.mozilla.com/D115293
STUN/300 is only meaningful for specific STUN method types, and the handling
depends on the spec that those methods are defined in. Doing any handling in
the base stun client code is not appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D115285
We need this because the test TURN server does not support stun redirects where
the address changes. Even if we were to add this support to the test STUN
server, it would not be helpful in CI since it would require having additional
IP addresses, which we cannot count on since we do not control the network
configuration of those machines.
Also, the fact that the code in this patch does not support MESSAGE-INTEGRITY
allows us to test the case where it is not present in a STUN redirect. Some
deployments rely on this.
Lastly, this code supports adding multiple (or 0) ALTERNATE-SERVER fields,
which is something that the test TURN server does not support.
Differential Revision: https://phabricator.services.mozilla.com/D115277
There's a pattern of clearing JS things when calling mozilla::DropJSObjects,
but mozilla::DropJSObjects already clears the JS things itself by calling
CycleCollectedJSRuntime::RemoveJSHolder.
Differential Revision: https://phabricator.services.mozilla.com/D115885
Various code was passing 'this' to mozilla::DropJSObjects in unlink, but that's
the CC participant. The right object to pass is 'tmp'. I also added static
asserts in mozilla::Hold/DropJSObjects to block this in the future.
Differential Revision: https://phabricator.services.mozilla.com/D115884
This changes the MediaKeys to actually service output protection status queries
by sending those queries to the EncryptedMediaChild actor and handling responses
from the actor. These interactions are done via the observer service.
Differential Revision: https://phabricator.services.mozilla.com/D115418
This patch plumbs the QueryOutputProtectionStatus call from the CDM up to the
MediaKeys. This is plumbing is done to get the request to an endpoint of Gecko
C++ code, and future patches will do further plumbing in order to complete the
query.
After the first query is complete, we cache the result in a CDM's
ChromiumCDMParent and update the value only when notified of changes from the
MediaKeys. This has the benefit of that checks after the first don't need to
touch the main thread. This avoids adding more main thread work, and means we
can still complete checks in a timely fashion even if the main thread is running
hot.
We cache in the parent rather than the child so that the parent can make
decisions on how to handle requests even if the CDM machinery is not yet fully
initialized. In future it may make sense to move the caching to the child, but
I'd prefer to do this only after other refactoring of the machinery which I
consider out of scope for this bug.
Future patches will ensure listeners are in place such that the cached data is
updated when updates are received further up the stack.
Differential Revision: https://phabricator.services.mozilla.com/D115415
This changes the MediaKeys to actually service output protection status queries
by sending those queries to the EncryptedMediaChild actor and handling responses
from the actor. These interactions are done via the observer service.
Differential Revision: https://phabricator.services.mozilla.com/D115418
This patch plumbs the QueryOutputProtectionStatus call from the CDM up to the
MediaKeys. This is plumbing is done to get the request to an endpoint of Gecko
C++ code, and future patches will do further plumbing in order to complete the
query.
After the first query is complete, we cache the result in a CDM's
ChromiumCDMParent and update the value only when notified of changes from the
MediaKeys. This has the benefit of that checks after the first don't need to
touch the main thread. This avoids adding more main thread work, and means we
can still complete checks in a timely fashion even if the main thread is running
hot.
We cache in the parent rather than the child so that the parent can make
decisions on how to handle requests even if the CDM machinery is not yet fully
initialized. In future it may make sense to move the caching to the child, but
I'd prefer to do this only after other refactoring of the machinery which I
consider out of scope for this bug.
Future patches will ensure listeners are in place such that the cached data is
updated when updates are received further up the stack.
Differential Revision: https://phabricator.services.mozilla.com/D115415
The assertion check likely doesn't have a performance impact, and allows
compilers to know the dereference that follows is not going to apply to
a NULL pointer.
Differential Revision: https://phabricator.services.mozilla.com/D115447
This adds a test case that ensures we get expected durations out of the Windows
h264 decoder. Bug 1576990 changed how we handle durations to avoid the decoder
incorrectly estimating durations. In some cases this could result in frames
appearing stuck. This reftest covers that.
Differential Revision: https://phabricator.services.mozilla.com/D114510
An enumerateDevices() call before a navigation possibly should sometimes
resolve its promise even after the navigation, but that shouldn't depend on
whether another enumerateDevices() call is made with the same Window after the
navigation but before the first would resolve.
The current behavior is that listeners are removed on Document navigation, but
listeners can be added after navigation. Testing the window listener is
checking for any listener but testing the placeholderListener checks the
listener associated with this particular operation.
Differential Revision: https://phabricator.services.mozilla.com/D114317
I acutally discovered that during testing the bug1709130, but I forgot to update that in D114150.
We would get an decoding error during testing, which is a different issue from what bug1709130 encountered.
That error only happens on testing, directly playing that video on Firefox works. So disabling the test on OSX for now, we can dig into that later if that really causes a problem.
Differential Revision: https://phabricator.services.mozilla.com/D114400
When the audio sink shutdown, we should also reset the audible state for the listeners. Otherwise, MediaDecoderStateMachine would possibly rely on the incorrect audible state that is produced by previous sink, which would cause showing the sound indicator even if no sound is being playing.
Eg.
Considering following case without the reset of the audible state
1. Sink A is audible -> MDSM set `mIsAudioDataAudible=true`
2. Stop sink
3. Recreate sink B and it's playing silence -> MDSM's `mIsAudioDataAudible=true` is still true, this is wrong!
Differential Revision: https://phabricator.services.mozilla.com/D113550
The purpose of this patch is to create a consistent clock timeline among different media sinks.
Having a consistent clock timeline can help the newly created media sink to understand audio data's "adjusted" time, which can prevent the sink from inserting silence if the sink incorrectly think there is a gap between data and sink start time.
However, once seeking completed, we should use the media time that indicates to the new position, instead of using the previous clock time.
Eg.
Audio duration = 10, and has seamlessly looped 5 times. Then the start time of the sample in 2s in the 6th looping would be 2 + 5*10 = 52.
If we switch to the new sink, and use media time (which is 2s) as a start time to start a new sink, then the new sink would think there is a gap between 2s and 52s and push a lot of silence into the data. [1]
[1] https://searchfox.org/mozilla-central/rev/9b430bb1a11d7152cab2af4574f451ffb906b052/dom/media/mediasink/AudioSink.cpp#390-426
Differential Revision: https://phabricator.services.mozilla.com/D113548
For normal seeking operation, we would stop the sink first and restart sink if needed when MDSM enters `DecodingState` later.
We should also do that for seek-to-next-frame. After seeking completes, MDSM would reset the media time by the video keyframe's time, but the audio clock time might still behind because it doesn't skip to next keyframe (audio also doesn't have that concept).
We hit this issue in the `1709130.html` in the previous patch. After seeking completed, the media time (video next keyframe time) is updated but the audio clock time is still behind, so we hit the assertion in the `GetClock()` [1]
[1] https://searchfox.org/mozilla-central/rev/54097530955a98c768f2aaf56925578ec886ec77/dom/media/MediaDecoderStateMachine.cpp#3585
Depends on D114150
Differential Revision: https://phabricator.services.mozilla.com/D114151
In the initial implementation, we only used 20 capacity for SPSC queue and added some mechanisms (batched data to save the free space of SPSC queue/clean SPSC queue in each graph iteration) to prevent it from being full.
But that seems not working in some extreme cases where decoding is too fast and the graph thread can't catch up the speef of processing the input. So extend the queue size to 40 that should allow SPSC to work without being full again.
Differential Revision: https://phabricator.services.mozilla.com/D114150
My last patch used the incorrect format specifier (%d) when logging the seconds
for a negative timestamp. This should be a %f as the value is a double.
Differential Revision: https://phabricator.services.mozilla.com/D114299
This patch changes our handling of durations in the WMF video MFT manager.
Prior to this patch we had some handling for if VP9 samples were returned with
zero duration. However, this patch extends this to the general case so that we
will try and estimate the duration using Gecko data in the following cases
- If Windows returns an error code when getting the duration. This can be
because the duration is unknown, but the API also specifies it can fail due to
other, unstated reasons (we handle these too).
- If Windows returns a 0 duration. This is also used to indicate an unknown
duration. We now handle this for arbitrary codecs, not just VP9.
- If Windows returns a negative duration. It's unclear if Windows will do this,
and if it does, under what cases. However, since the API returns the duration
as an signed int it's possible, so we cover this too.
In all cases above, we will use the duration we record from our last input
sample as the output sample duration.
Differential Revision: https://phabricator.services.mozilla.com/D114247
when the setter should not throw because there are no events in the timeline
and the time is known valid.
This will allow us to make SetValue() throw when it conflicts with a
setValueCurveAtTime() curve.
Depends on D113937
Differential Revision: https://phabricator.services.mozilla.com/D113938
Change the audio track from `SourceMediaTrack` to `AudioDecoderInputTrack`, which allows us to use a pull-based stream track in DecodedStream.
Also a pre-requirement before we start implementing supporting playback rate change on a track captured from the media element.
Differential Revision: https://phabricator.services.mozilla.com/D106042
This patch implements a new track `AudioDecoderInputTrack` which inherits from `ProcessedMediaTrack` and is a pull-based media stream track.
This track would be used for receiving audio decoded data and will support changing playback rate in the future (not yet, will be done in Bug 1517199).
Differential Revision: https://phabricator.services.mozilla.com/D106040
This patch adds an `AudioDeviceID` member in `AudioInputTrack`. This
aims to simplify `AudioInputTrack::CloseAudioInput`.
Before this patch, the `AudioDeviceID` is tracked by
`MediaEngineWebRTCMicrophoneSource` only instead so `AudioInputTrack`
has no idea of what device it pairs with. One main drawback is that
`MediaTrackGraphImpl` needs to search all the `AudioDataListener`
inside it to infer what device is closed when
`AudioInputTrack::Destroy()` is called, since `AudioInputTrack`
doesn't know what is its paired device, which gives an O(N) time
complexity, where N is the number of `AudioDataListener` in
`MediaTrackGraphImpl`
A simple way to reduce the time complexity from O(N) to O(1) is to track
the paired device when `AudioInputTrack::OpenAudioInput` is called. This
also enables the possibility to remove `mInputDeviceUsers` in Bug
1702646.
Differential Revision: https://phabricator.services.mozilla.com/D113040
Change the audio track from `SourceMediaTrack` to `AudioDecoderInputTrack`, which allows us to use a pull-based stream track in DecodedStream.
Also a pre-requirement before we start implementing supporting playback rate change on a track captured from the media element.
Differential Revision: https://phabricator.services.mozilla.com/D106042
This patch implements a new track `AudioDecoderInputTrack` which inherits from `ProcessedMediaTrack` and is a pull-based media stream track.
This track would be used for receiving audio decoded data and will support changing playback rate in the future (not yet, will be done in Bug 1517199).
Differential Revision: https://phabricator.services.mozilla.com/D106040
In addition, the comment seems out-of-date, which was added for running the runnable on the main thread and our code is totally different from that time. So we can remove that as well.
Differential Revision: https://phabricator.services.mozilla.com/D112139
This expands on existing checks when getting a webms buffered intervals. The
additional check ensures we don't end up with end < start due to our code that
clamps end at duration.
This patch moves those checks into their own helper function so as to reduce
clutter in GetBuffered.
Differential Revision: https://phabricator.services.mozilla.com/D111152
It is already set by VideoCore to a profile with 1.9 gamma. This causes
hw decoded video to have a different color profile than software decoded
video which isn't ideal but matches what happens in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D111218
At the time I worked on this state, it was only used for audio. There were some problems blocking the implementation for video, but the comment wasn't updated.
So we should correct the comment to make it reflect the real situation.
Differential Revision: https://phabricator.services.mozilla.com/D110881
This patch makes MediaManager notify of recording-device-events as soon as any
gUM-track has ended, as opposed to when all tracks in a gUM-request have ended.
This effectively makes temporary permissions per-track rather than per-request.
Differential Revision: https://phabricator.services.mozilla.com/D109943
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
CLOSED TREE
Backed out changeset 813c7ce3607b (bug 1395819)
Backed out changeset 46083fddeb0d (bug 1395819)
Backed out changeset 990441f04a86 (bug 1395819)
This patch makes MediaManager notify of recording-device-events as soon as any
gUM-track has ended, as opposed to when all tracks in a gUM-request have ended.
This effectively makes temporary permissions per-track rather than per-request.
Differential Revision: https://phabricator.services.mozilla.com/D109943
Jeff Gilbert
Alexandre Lissy
alwu
Chun-Min Chang
Nika Layzell
Mike Hommey
Butkovits Atila
Paul Adenot
Alexandru Michis
Byron Campen [:bwc]
R. Martinho Fernandes
stransky
Landry Breuil
Sebastian Hengst
Aaron Klotz
Bryce Seager van Dyk
Marian-Vasile Laza
Noemi Erli
Dorel Luca
Karl Tomlinson
Andreea Pavel
Joel Maher
Peter Van der Beken
Emilio Cobos Álvarez
Kris Wright
Olli Pettay
Michelle Goossens
Sandor Molnar
Csoregi Natalia
John Lin
Iulian Moraru
Andi-Bogdan Postelnicu
Matt Woodrow
Paul Bone
Cosmin Sabou
Brindusan Cristian
Agi Sferro
Jan-Ivar Bruaroey
Florian Quèze
Brendan Early
owlishDeveloper
Kris Maglione
Mark Striemer
Jeff Muizelaar
Robert Bryer
Andreas Pehrson
David Parks