As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
When mState is SEEKING, DispatchDecodeTasksIfNeeded() is a no-op.
MozReview-Commit-ID: 3sV6RdUwFBV
--HG--
extra : rebase_source : 12f01ab491b5f4326b08b44dd0789139db174d99
extra : source : 89cccddea7603912e264405040071ba0a98bf8de
1. |mState != DECODER_STATE_SEEKING| is true in DecodingState.
2. mSentFirstFrameLoadedEvent is true in DecodingState.
3. mMinimizePreroll is false because pop events fire only after MDSM starts playing.
MozReview-Commit-ID: FTkXmtEnzY5
--HG--
extra : rebase_source : 30392be881ebdb96469189a584a57b89d60cc2b4
Some code (mostly logging) needs to know the original full MIME string, which
we would normally not need to keep in MediaExtendedMIMEType.
MozReview-Commit-ID: Jcd290ScHAb
--HG--
extra : rebase_source : 1165bc3425ed34a93564335a10ea3c6257da6f19
When replacing strings with MediaContentType objects, some classes will want to
know about their size.
MozReview-Commit-ID: LNdaaUdJac3
--HG--
extra : rebase_source : 70bfbfa55bc6f2c7a8aa026797103cd77615df08
Now that we have move all data-handling functions to MediaMIMEType and friends,
we can remove direct accesses to data from MediaContentType, to better separate
the context that MediaContentType represents, from the data it includes.
Dependent code needs to be mechanically updated to now use the proper APIs.
Note that in most places, we just extract MIME strings. Further work will take
place in later bugs, to completely replace these strings with MediaContentType
or more appropriate types...
MozReview-Commit-ID: LoX8dhX7OlB
--HG--
extra : rebase_source : cf221ac3c104f99b36cfa055afcf67d3bca26d0e
MediaCodecs factors out the codecs string from MediaExtendedMIMEType.
It also provides utility methods to go through a list of codecs, and test the
presence of specific codecs.
Note that there is no real way (yet?) to validate the given codecs strings, we
just assume that it's a comma-separated list of codecs. Further work can be
done later on if useful.
MozReview-Commit-ID: 5n2nWmaNT2O
--HG--
extra : rebase_source : 44ca49aa3d2a795171ebff75c91bb228196bc429
A lot of code wants to check if the type starts with 'audio/' or 'video/',
MediaMIMEType::IsAudio() and IsVideo() will help with that -- and could later
be optimized if needed.
Note that types starting with 'application/' will still need manual testing,
but they are rare anyway.
MozReview-Commit-ID: UBcxS69Hcb
--HG--
extra : rebase_source : 24bd67f6ec18a2a6c7d33b065ac1036aa51de2ae
`==` and `!=` against other MediaMIMEType objects, and against MEDIAMIMETYPE
checked literals.
This will allow simple (and compile-time-checked!) tests like:
if (contentType.Type() == MEDIAMIMETYPE("audio/mp4")) { ...
MozReview-Commit-ID: 5yMua5krOKD
--HG--
extra : rebase_source : 778adc5fd45624d60529c259aeb1c41d4f66eb2f
MediaMIMEType object can now be constructed from string literals by using e.g.:
MEDIAMIMETYPE("audio/mp4") -- Note that it's an all-caps macro.
The string will be checked for validity at compile time.
To help with this, a new class DependentMediaMIMEType can point inside another
string (usually a string literal), but can only be constructed for valid
strings -- It will fail to compile when using MEDIAMIMETYPE, or it would
assert at runtime if directly built.
MozReview-Commit-ID: 5T3AKfpGbO4
--HG--
extra : rebase_source : 4bf9da294406c9dd6bfd69d560bae4bea44cadf3
Use IsMediaMIMEType to refuse MIME types that cannot possibly be media-related.
MozReview-Commit-ID: JXhf1biL4L0
--HG--
extra : rebase_source : a33e7be7bcc16685205f767d671a7812ee843364
Inside dom/media, we really only deal with audio and video MIME types.
IsMediaMIMEType will help check for that.
Note that 'application' is an acceptable MIME major type, as some A/V contents
do use it! E.g.: "application/ogg".
IsMediaMIMEType is constexpr to allow its use in static_assert's, so we will be
able to verify string literals at compile time.
MozReview-Commit-ID: InBicRRUeiP
--HG--
extra : rebase_source : 53796c130846763e979cea2757121fadc0e7b88d
Bug 1176218 made IsTypeSupported return a DOMTypeError if the type cannot be
parsed, but this was incorrect.
This was not important until now, because the basic parser accepted invalid
MIME types and therefore would never report an error there.
But the next couple of patches will introduce a stronger check that will
refuse types other that "application/...", "audio/...", and "video/...", and
would now trip the web-platform tests.
MozReview-Commit-ID: EeyFnyurEZK
--HG--
extra : rebase_source : 76f831ddc3c19e0d820454f6f949d44e15d6773c
MediaMIMEType factors out the main MIME "type/subtype" string from
MediaExtendedMIMEType, as it is often useful to deal with just that part.
Like MediaContentType and MediaExtendedMIMEType, MediaMIMEType is always valid
once constructed.
MozReview-Commit-ID: 5Urlk6OLo5q
--HG--
extra : rebase_source : aef60fde09b13befa1311c6cd712eac19c438021
This patch factors out all data handling of MIME strings from MediaContentType
to MediaExtendedMIMEType.
MediaExtendedMIMEType is pretty much a copy of the old MediaContentType, as the
functionality was fine (but will be modified in upcoming patches).
MediaContentType then just delegates the work to its embedded
MediaExtendedMIMEType field.
The main difference is that the default constructor and Populate() method have
been replaced with a single constructor that takes all the arguments at once.
MozReview-Commit-ID: GBAgPDT2DUW
--HG--
rename : dom/media/MediaContentType.cpp => dom/media/MediaMIMETypes.cpp
rename : dom/media/MediaContentType.h => dom/media/MediaMIMETypes.h
extra : rebase_source : 1c925d8e049d9d349ec4c3dd1a079f570b809970
This is required because the next patch adds new files, which changes the
unified-build order and exposes error due to this missing #include.
MozReview-Commit-ID: 3pmqNK1B2bR
--HG--
extra : rebase_source : 6e3dc2d4200aa4740b8f216ba1d1a131b94c26cb
1. ensure the 'finish' event is notified only once.
2. assert pushing items to a finished queue.
MozReview-Commit-ID: 9lYWPANVz0m
--HG--
extra : rebase_source : c05b0c77fdee324798579e0e2ebec6ce6303cbf6
extra : intermediate-source : 80be35003c76fc9cc74f206576394b46317b7880
extra : source : 14f5d5c064fddbbcf5728fb4d19e9c0a4e45fac7
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : dffab11abf7d4b57fa54475fd22e71b84375cd7b
Currently, gecko doesn't support download and installation for Widevine CDM on Android.
Returning Cdm_not_supported avoids the subsequent call to AwaitInstall() while requesting MediaKeySystemAccess.
MozReview-Commit-ID: 3mOEf9iWE1G
--HG--
extra : rebase_source : 59649e5048424c38033c3c6e6c48f89ea4997a8e
We want to call Request{Audio,Video}Data() instead of Ensure{Audio,Video}DecodeTaskQueued
which checks mState and breaks the encapsulation of the state objects.
MozReview-Commit-ID: 5oydItSvnMF
--HG--
extra : rebase_source : 5da4ad2f0fbf010a78c6b4e7cbab70378a002758
extra : intermediate-source : 0a882fb53fd51a71f9a3914074e9020d4eb87c4f
extra : source : 9927e37c9383e9204cbaf1b0dbc6fbfdff48df82
We want to call Request{Audio,Video}Data() instead of Ensure{Audio,Video}DecodeTaskQueued
which checks mState and breaks the encapsulation of the state objects.
MozReview-Commit-ID: 87CwSdtTwi4
--HG--
extra : rebase_source : a16404e208ae5cd9b008728249cea444a7b229e7
extra : intermediate-source : 3fbfa4532f6a54ea9e1aa7b0e9880539ca57c811
extra : source : 22a75175dd957605e70096b029a677b4d2ac2d42
This mostly simplifies the code, but there are two changes to the logic as well.
1) The decision to install the listener or not used to be based on if the track
existed in mUpdateTracks, while feeding the sink would look at the
StreamTracks as well. This now looks at StreamTracks since an ended track is
kept there but removed from mUpdateTracks. That means that we also
NotifyEnded() if the track was in the StreamTracks but not in mUpdateTracks.
2) I removed the code that feeds a video stream sink with the last chunk in
case the graph's current time has passed the end of the track. Tests should
be written so that we have guarantees that there will be video data when a
video stream sink gets added. If this fails we should fix the root cause of
such a timing issue instead of wallpapering it with an old frame. I think
this could be masking other issues. We'll see how this acts out on try.
MozReview-Commit-ID: KKr9JhVpxZt
--HG--
extra : rebase_source : f775fcfbe9647e29ee107ecc7b1f39c2d91f3b0d
extra : histedit_source : 4fa675ce93dc67d7db972a07bb3236f34707e7d3
BufferingState will call DispatchDecodeTasksIfNeeded() if not done buffering.
MozReview-Commit-ID: Kzqqn8lXPLm
--HG--
extra : rebase_source : fa4e4d4c4b9d637b7ca577b371e8561ffc87f9b2
extra : intermediate-source : a843f7147b2cf06bd2aebaf737e59838ad7cd20a
extra : source : 7459d72992ecbd9ea45109bf57da31c8da3b57dd
DecodingFirstFrameState needs only at most one audio or video sample.
MozReview-Commit-ID: 2pRrPlCUBSf
--HG--
extra : rebase_source : 16dfce121c1e1c151a6dbcbee49f179d3793b22b
extra : intermediate-source : 2be72f13608fd5029991f6ae79cc73c86f7f1a0b
extra : source : 61f35a1275101a222cea89d4dd6d873181f33e57
AccurateSeekingState can stop decoding once there is one sample in the queue.
MozReview-Commit-ID: 76C7vX7ua14
--HG--
extra : rebase_source : 507410f3873ed9de2166344e99e03f9b43b46ad7
extra : intermediate-source : dd7d2547486711cdd1a9c7adc2a48e1ffec168bf
extra : source : 0285b6fc5dbed808cd30375defbc415e875647a1
The media attribute in source element is no longer needed in media element case. Remove related test case.
MozReview-Commit-ID: 7ckvEAl6HL4
--HG--
extra : rebase_source : d5346029fb115a0445733c90d43af00fe4919aa8
We have |mBuffered.Ref().IsInvalid()| below to check if mBuffered is valid.
MozReview-Commit-ID: KM88fSsCTlH
--HG--
extra : rebase_source : 049951856e2d78a5c53e54a7be728b0089c8e9dc
We want to separate mechanism from policy. The policy should be encoded in
the state objects which will decided whether to call ResetDecode(). It is
also possible to add a new state which has to call ResetDecode().
MozReview-Commit-ID: 3orxW4FNuVD
--HG--
extra : rebase_source : 7f76f279624e91cbe7823acfaac11632d8da4e2e
This is done by storing the object pointer based on the exact pointee type,
instead of as hinted by the method-pointer, which could be a non-refcounted
base class.
The stored pointer type is statically-checked to be derived from (or the same
as) the class type from the method-pointer, to prevent misuses.
One change had to be done in TrackBuffersManager, as it was passing another
type and relying on implicit pointer conversions. A simple `.get()` to pass
the raw pointer type (to be stored in a RefPtr) fixed that one issue.
MozReview-Commit-ID: 4kH0XdjB5Rk
--HG--
extra : rebase_source : 3eb7fa3cb1873f71b4d5e7118d2dc48f6fdf2874
FFmpegDecoderModule and AndroidDecoderModule returns nullptr if alpha is
present, then PDMFactory rolls over to using VPXDecoder.
MozReview-Commit-ID: H2JaolEfJgR
--HG--
extra : rebase_source : a2b4bad848c6350041c2cff805803fb5728342d2
VPXDecoder initializes a second context when alpha is encountered.
MozReview-Commit-ID: FMzHFvP8YK0
--HG--
extra : rebase_source : a287670aa62949e8811f678810eb3ac5e3acdbe3
UpdateSeekTargetTime() is called only when NeedMoreVideo() is false.
if |data| is null, both |VideoQueue().IsFinished()| and |VideoQueue().GetSize() == 0| must be true
and therefore |VideoQueue().AtEndOfStream()| must also be true.
MozReview-Commit-ID: DZKiVtt6iIM
--HG--
extra : rebase_source : 084bc4d2cc8118a794cc97675d41f7010dccbe99
extra : intermediate-source : e03bfa7a48d5e3210ac00f801103b1b869b9ac2a
extra : source : d2facb5bd27127c5c3eba0b44e0cc06fb212eabd
Because !mSeekJob.mPromise.IsEmpty() now always implies NeedMoreVideo().
MozReview-Commit-ID: BN0NZzaBlCF
--HG--
extra : rebase_source : ab570336cef7fd6841835d981696d03c3cdb1f60
extra : intermediate-source : 415774b6eca227442d6773bb989443befc8d6822
extra : source : 0fc219d031b6dd0b32979a571cc87422ae1f2af9
We don't need to wait for pending audio requests before finish seeking.
MozReview-Commit-ID: BWoivb9Gjux
--HG--
extra : rebase_source : c044c8066d7dfe8b324762145977a5d7ea84702f
extra : intermediate-source : afa7a29babfeaa8df1a10e606c090d03e4fab789
extra : source : aeb0ed38110fdfc172e25d4895e81d2a4f8a1300
We runs all demuxing operations on a dedicated task queue.
MediaDataDemuxer's members using a synchronous API are handled via thread-safe copy that are updated along the operations.
The buffered range calculation is now handled separately and the entire operation is made asynchronous.
MozReview-Commit-ID: Gd4DCC8Ix6n
--HG--
extra : rebase_source : b90bad0a386c2a1e30acc00e3db9db6b6762aa3b
We only care that we will enter suspended mode after a minimal time. On slow machines (like the linux try box) there are so many things at play that could delay a particular event.
So we remove the upper time test.
MozReview-Commit-ID: IAZVyuetYVp
--HG--
extra : rebase_source : 467d6a32dff88791d1238c0654d81b6d4afafc31
We runs all demuxing operations on a dedicated task queue.
MediaDataDemuxer's members using a synchronous API are handled via thread-safe copy that are updated along the operations.
The buffered range calculation is now handled separately and the entire operation is made asynchronous.
MozReview-Commit-ID: Gd4DCC8Ix6n
--HG--
extra : rebase_source : 6a18ce2552bf4cbf88e9b8db1c9a87e70623fd15
For they are updated in MDSM::On{Audio,Video}Decoded.
MozReview-Commit-ID: 55Od3V9vIf2
--HG--
extra : rebase_source : b359dad4a9cefb2c81d097d05dda741c64447131
extra : source : 2811f9da4d1c5e55aa0d45c2be6e916bf43e3e86
They are already in MDSM::On{Audio,Video}Decoded, OnNotDecoded.
MozReview-Commit-ID: COivpHEaYdp
--HG--
extra : rebase_source : 2ca8eb2866ce54e822e44ff877b1dcb9032fb316
extra : source : 9e0e761a551d896ff1d5f7dc92d77270d8f93319
Invalid videos with negative duration. Exception had been added to handle 32 bits encoded duration, not 64 bits one.
MozReview-Commit-ID: 8jwDwpMREmc
--HG--
extra : rebase_source : 0304db69d06590b65f5c64ae481be6a75b53a24e
