For HandleAudioCanceled():
1. IsRequestingAudioData() is false because mAudioDataRequest is completed in MDSM::RequestAudioData().
2. IsWaitingAudioData() is false because data promsie and wait promise are mutually exclusive.
3. IsAudioDecoding() is true because we wouldn't have requested audio data otherwise.
Likewise, we can prove EnsureAudioDecodeTaskQueued() can be reduced to mMaster->RequestAudioData()
in HandleAudioWaited.
MozReview-Commit-ID: 1i63IMfZaUh
--HG--
extra : rebase_source : ac389a7ccc74d969ecfc5f5f622c1c90e2d9b118
extra : intermediate-source : 50bb6d229443be0c410daf7c9553e84cd21fd929
extra : source : f4c3f02f3741c49eed38c2aaab5c872d18fb74ff
Note we remove the checks for mState.
MozReview-Commit-ID: 7uzjzjKDCIj
--HG--
extra : rebase_source : a3c18a977a96edf64b44598cd2244ea20d5f9363
extra : intermediate-source : 294a139aa91dcaaa2d3c2654cbae0fce5317fcbd
extra : source : 1ac775ae3fbb65146c28024e6c19d33b2dd55f66
States that expect this event should override the function.
MozReview-Commit-ID: AmqktrDyVH5
--HG--
extra : rebase_source : 610dec3def2944c6234fd18cf71d9ee02998ad4d
extra : intermediate-source : 28ed7fa9991588b4ba131856cab0ff239f0b24e5
extra : source : 6e5d3a1d32985b6eba449f76e99538b0589bd200
States that expect this event should override the function.
MozReview-Commit-ID: 5Zhcu1m2MMm
--HG--
extra : rebase_source : 4462e34f5c063fdfc201f0f27e2caa8ba8d2fdc2
extra : intermediate-source : a91db7dd4a3d832f8c7b32ac87f8a8d5e518bec3
extra : source : 4499e663ce6821b98057454c8d6f06fe2cb762e0
If the wait promise is rejected, we probably won't be able to finish
decoding after seeking. So we should just raise an error immediately.
MozReview-Commit-ID: GKXo9ZooBfV
--HG--
extra : rebase_source : 257a2724d1d2f3266e17b2de3f7d80fa385a2782
extra : intermediate-source : 150ce8e05dc887b7ed2b71cdc5ab77fb117775d2
extra : source : 6ff0dea0afabd57ea53ea3571020cdea3d4b0eca
States that expect this event should override the function.
MozReview-Commit-ID: IjmR7F1UOiU
--HG--
extra : rebase_source : a83f4a96838e7358df8d0579163002ade53b5cc7
extra : intermediate-source : 2db95ef2473440ad2ec9130cf24f959291b18bef
extra : source : 78ae9269f4f09986a14e498843a7638f81dbc440
States expect this event should override this function.
MozReview-Commit-ID: 8Y4ngn4X7MS
--HG--
extra : rebase_source : 705affda97d3ee919f560a76c3858fa3564bfbe4
extra : intermediate-source : 9139df5e241af72bc75544ae3d1df27a7cc514aa
extra : source : b7c803ea73a1b1af0ee40a64d7710c52186c3c25
1. States (DecodeMetadataState and WaitForCDMState) happen before
DecodingFirstFrameState should never receive this event because they don't
decode at all.
2. DormantState and ShutdownState shouldn't receive this event because
they call ResetDecode() in the entry action.
3. CompletedState should never receive this event because it happens after
HandleEndOf{Audio,Video} which happens before Handle{Audio,Video}Canceled.
MozReview-Commit-ID: LdwpWlFHtRp
--HG--
extra : rebase_source : d48b8c7b2347fa745de006fcd1aff640cb474aa1
extra : intermediate-source : 981305f87ff796060666227cf89a23b51e607b54
extra : source : ee5e78f761568bea438c51b9e70eef9b83e14626
Bug 1295053 removed most uses of NS_METHOD and NS_CALLBACK, but one use was
unintentionally left behind (in the XPIDL parser) and another has since crept
in (in MediaDrmCDMProxy.h).
So this patch removes NS_METHOD and NS_CALLBACK. NS_METHOD_(nsresult) and
NS_CALLBACK_(nsresult, T) can still be used for the same purpose, but those
alternatives are less likely to be used unintentionally.
--HG--
extra : rebase_source : a50fc7b2a64a36d1ca9beda81bc0edb8f2ec1934
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 : 40ad68820cfce469ecda272f430062f05dfcd09f
When we want to decode with DXVA2 aPI directly instead of using it by MFT, we need to take responsibility for
creating a decoder and handle the related decoding operations by ourself. So implement a method to create and
hold a ref to DXVA2 decoder for DXVA2Manager.
MozReview-Commit-ID: 4EyrsjzEyYK
--HG--
extra : rebase_source : 6719bfe15243395711984d66919baca2bb74699e
The same reason as P6. We would like to avoid virtual functions calls
inside a virtual function.
MozReview-Commit-ID: EYCk6tKPYSs
--HG--
extra : rebase_source : 8482799473e4cf856238b9fa7897e432b4e3a674
extra : source : 17769cff12ccc2157adc91c4fce7e4030f303b00
Since DecodingState is the only one that overrides the function, we will let it
just override HandleWaitingFor{Audio,Video}. We also reduce the code complexity
because it is hard to trace the code when one virtual function calls another
virtual function.
MozReview-Commit-ID: AdLXpDgvOyx
--HG--
extra : rebase_source : a8c2aef15537044d904f576976e08264524c26e4
extra : source : 60c230cff746f91653922223dc1f56e48c0d6120
1. requestLongerTimeout() is not needed because we don't have slow machines as B2G anymore.
2. Bug 634747 and 846769 are already fixed.
MozReview-Commit-ID: JbKtxHLdr8I
--HG--
extra : rebase_source : 7603c61637b8b142c8013bb8f431a49a93fac0c1
Avoid crashing in the case that cubeb stream start fails and report
an error instead.
MozReview-Commit-ID: 75M392POyHo
--HG--
extra : rebase_source : 2c083cf129f12ad1e18d9065152cfee13987b071
For mSentFirstFrameLoadedEvent is true in DecodingState.
MozReview-Commit-ID: 8zpsMAME8p6
--HG--
extra : rebase_source : fea2a795481628b5bd7eaf841fcf6a8bc377fbbc
extra : source : d54b4f06b497408a0225d708bc749101d778ca4f
1. mSentFirstFrameLoadedEvent is true in BufferingState.
2. mMinimizePreroll is false in BufferingState for buffering happens after playback starts and we reset mMinimizePreroll once playback starts.
MozReview-Commit-ID: ABE7TvNEetD
--HG--
extra : rebase_source : 53c507ff9cd8ea028c5ff7f8b5b8c049cb8a7ebf
extra : source : e87a70953f6eb8d4a9e31ab06ac73afcc90da923
mMinimizePreroll is false in BufferingState because we enter buffering only
after playback starts.
MozReview-Commit-ID: 9vRuogzvV7x
--HG--
extra : rebase_source : f43eb5af15d6ae969a6269c7adf68780d9b3b659
extra : intermediate-source : 0dd36842a3ae6ad9b5421bbd277e9ee05ec2e110
extra : source : eae56fe516563a2675f0492c56c6a01b6f38149f
Then and ThenPromise can now be given only one function object, which takes a
`const MozPromise::ResolveOrRejectValue&`.
MozReview-Commit-ID: BEtc3spK9Yh
--HG--
extra : rebase_source : 1b16ad15ebfcdfb653d8d98073adee0f8b27b46e
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
