Defer determining whether we have usable decoders to an off-main thread in
order to avoid janking the main thread.
MozReview-Commit-ID: Ape5zEBBMrz
--HG--
extra : rebase_source : 1b77046ebb7bb2d4ff1ba53afce904d3de45c335
Currently we call HTMLMediaElement.canPlayType() in a JS function called
shortly after startup in order to collect telemetry as to how many of our users
don't have functioning decoders.
Unfortunately, HTMLMediaElement.canPlayType() checks whether we can play a
codec by instantiating a decoder, and this requires us to load the system
decoding libraries from disk. This requires disk I/O, which can cause jank. We
have some BHR reports showing that canPlayType can hang for > 8 seconds to back
this up.
So move the collection of this telemetry to an idle service observer, so that
we only collect this when the user is idle, and do it on a non-main thread so
it is less likely to cause jank.
MozReview-Commit-ID: HJQawmRxz
--HG--
extra : rebase_source : f5a8596fd9de770abd20e1a3e8ac0bcbb5b48599
This reverts part of bug 1300296. In the worse case we'll get a decoding error. But we're only trading a bad behaviour for another.
MozReview-Commit-ID: H0gF3FqZsU6
--HG--
extra : rebase_source : 3886b757f3476060067811dcb385967769a67023
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
In addition to the returned MediaResult, a special number-of-tracks value
(not just 0) indicates an unrecoverable error.
For Rust-vs-Stagefright comparison purposes, an error is considered the same
as 0 (because Stagefright never returns errors, but Rust may, so complaining
about that would be too noisy, and useless to us.)
MozReview-Commit-ID: IwadWSOIWr4
--HG--
extra : rebase_source : 29f53ee6a02a0431adb0b615a122a4e7b480108c
The returned MediaResult is used as error or warning in MP4Demuxer::Init().
MozReview-Commit-ID: Bnv4xG8bCJ4
--HG--
extra : rebase_source : c1952ed61396834b0cd7da58c9b64481a5c46ab1
If MP4Demuxer::Init detects some recoverable error (e.g., invalid tracks when
others may still be usable), it will eventually Resolve the promise with the
first warning.
Later on, errors/warnings from the MP4Metadata parser will also be handled, to
provide even better diagnostics.
MozReview-Commit-ID: E9Rly9dhXW3
--HG--
extra : rebase_source : cae214d0c80297bd61156dc1a305a186da0974fe
MP4Metadata::Metadata() contains the same code at the beginning, so calling
HasCompleteMetadata() is unnecessary, so we should just remove it completely.
(Except to get a better error message, but this will be reinstated in an
upcoming bug.)
MozReview-Commit-ID: 2C3GI5fE0Ja
--HG--
extra : rebase_source : 2bdb6199222dcb0ca4012121a3fd4694b440be3e
MP4Demuxer::Init() used to just create a minimal MP4Metadata structure, and
report success/failure from that alone. But other later-called functions
(e.g.: GetNumberTracks, GetTrackDemuxer, etc.) could still fail with no useful
error reporting, when MP4Metadata tried to gather more of the needed
information.
Also, MP4Demuxer needed to keep this MP4Metadata around forever, even though
it could contain an arbitrary amount of extra data that is not needed.
With this patch, MP4Demuxer::Init() fetches all the data that could ever be
needed, and then discards the MP4Metadata.
This ensures that no late-initialization errors could creep in, and also helps
reporting errors early and with better diagnostic information.
This bug focuses on Init(), a later bug will give MP4Metadata the ability
to report its own even-more-detailed errors.
MozReview-Commit-ID: 1NjzOeKa1JI
--HG--
extra : rebase_source : 02781395aa538cf2be984b695a7bc7e2b9b039b7
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
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 : 63eba419e5cb8a69500008145769c8e4ef99f33f
Thanks to the previous patch, MediaDataDemuxer::Seek and
SkipToNextRandomAccessPoint (and all overrides in derived demuxers) can now
take their TimeUnit parameter by const&.
MozReview-Commit-ID: 6CqfjAXZ7Yk
--HG--
extra : rebase_source : c3453e4432d9e0281cf5eba55217b0c1d6312f5b
audio/opus is a codec type, not a MP4 container one. aType can never be audio/opus
MozReview-Commit-ID: E8tONlF4COA
--HG--
extra : rebase_source : d26a4dce2adcf1f82e56a2b5c2dd5ee1500fcd84
We have this for H.264, so we may as well have it for AAC too.
MozReview-Commit-ID: 2k64ANJGUNN
--HG--
extra : rebase_source : 6fe2543788afd26682d31c0ec45b9ac80e501ab1
MP4Decoder can translate the new MediaContentType into the relevant TrackInfo
to interrogate PDMs about codec support, with extra information if present.
MozReview-Commit-ID: K0jcYm8pJrp
--HG--
extra : rebase_source : e809824285a85035b81ad7f91406bce6393384f6
Just passing the new MediaContentType struct, with no processing changes (yet).
MozReview-Commit-ID: KZ4xkCihPb1
--HG--
extra : rebase_source : e40eb72cc63e0a814306c25ea9b609178517729e
