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
This updates the repeat init data detection code in TrackBuffersManager to also
detect repeat video init data. This will also detect cases where the init
segment contains repeat video and audio init data if both the audio and video
are the same as the previous init data.
Differential Revision: https://phabricator.services.mozilla.com/D103174
This should be a strict refactor (no functional changes), but makes the
boundaries of the code doing the repeat check more clear. This code will be
updated in a following patch.
Differential Revision: https://phabricator.services.mozilla.com/D103173
`HasAudio` is capable of racing between `TrackBuffersManager::OnDemuxerInitDone` and `TrackBuffersManager::Buffer`. One option was to protect all of these calls by the mutex, or we could simply make `TrackData::mNumTracks` atomic. The latter seems like a reasonable solution given it looks like it’s only got one notable race between its accesses.
Differential Revision: https://phabricator.services.mozilla.com/D102484
When we shutdown `MediaSourceDecoder`, it would trigger a shutdown for `MDSM` and a detaching for media source.
In the previous one, that would eventually shutdown `MediaFormatReader` via tasks going through different threads (main->MDSM->MFR's supervisor).
In the latter one, it would eventually detach the `TrackBufferManager` from the `MediaSourceTrackDemuxer`. (main->Demuxer's supervisor)
As these two tasks running in different threads, and the latter usually get finished before the former one, which would result in `MediaSourceTrackDemuxer` no longer being able to get a sample.
When that happens, the reader hasn't been shutdown yet, so it's still holding track demuxers and keeps requesting data from them. Then demuxers would return error because their corresponding track managers have been detached.
The reader would report the demuxing error to the console, but that's acutally not a fatal error, because in this situation the reader is going to be shutdown soon. Therefore, return `NS_ERROR_DOM_MEDIA_CANCELED` to allow MFR to treat this error differently.
Differential Revision: https://phabricator.services.mozilla.com/D100153
different init segment may yield the same AudioInfo object; so we can't rely on the AudioInfo value to determine if we should use the new init segment or not.
Depends on D98874
Differential Revision: https://phabricator.services.mozilla.com/D98875
different init segment may yield the same AudioInfo object; so we can't rely on the AudioInfo value to determine if we should use the new init segment or not.
Depends on D98874
Differential Revision: https://phabricator.services.mozilla.com/D98875
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This renames the thread and identifiers derived from the thread's name. This is
to avoid ambiguity over if the thread relates to the MediaController class,
which it does not.
Differential Revision: https://phabricator.services.mozilla.com/D93806
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
Historically, the MediaThreadType::PLAYBACK was used just for that; the MediaDecoderReader and exclusively for playback content.
This is no longer the case ; it's used in multiple places, and not just with playback: webrtc, webaudio, benchmark etc.
The primary use of the "PLAYBACK" thread was to distinguish from the "PLATFORM_DECODER" one as they dispatch synchronous tasks from one to the other, and we must ensure they don't share the same threadpool.
CONTROLLER is more fitting here, as this is how it's typically used: a controller thread manage the decoder threads.
Additionally, we remove the MTG_CONTROL one as it's not used.
Differential Revision: https://phabricator.services.mozilla.com/D85543
AutoEnter was an attempt around a race between AbstractThread and MessageLoopAbstractThreadWrap that would cause AbstractThread::GetCurrent() to return an incorrect value. MessageLoopAbstractThreadWrapper is no more and as such AutoEnter is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D71279