Mostly-mechanical replacement of MOZ_LOG with DDMOZ_LOG, usually just removing
the class name and `this` pointer (as they are already implicitly recorded).
Some files needed a bit more work when logging was done from helper classes or
static functions.
MozReview-Commit-ID: IeJJmzYqWMQ
--HG--
extra : rebase_source : 94200838dcdaf6c3bda9de30042ce2d307237eef
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
Accept av1 video in the webm decoder even when we've determined
the machine is too slow for software vp9 decoding. While we're
at an experimental stage with this codec, poor performance is
preferable to not being able to see a demo at all.
MozReview-Commit-ID: 6DJHCPfXHlA
--HG--
extra : rebase_source : 8fb5c0dac6483abf4775e3546dadd5aaa45947ac
Accept av1 video in the webm decoder even when we've determined
the machine is too slow for software vp9 decoding. While we're
at an experimental stage with this codec, poor performance is
preferable to not being able to see a demo at all.
MozReview-Commit-ID: 6DJHCPfXHlA
--HG--
extra : rebase_source : 0819c3ddd437e9e56b18ba1fc6c56d4bdaebfa77
MSE specs require that the readyState be modified during either the Initialization Segment Received or the Coded Frame Processing algorithms.
At this stage, we only handle the Initialization Segment part (readyState moving from HAVE_NOTHING to HAVE_METADATA)
MozReview-Commit-ID: KBnnWuHJ6Om
--HG--
extra : rebase_source : a4450139762d5d033438fbee2ce560fe02ed6ffc
Continuing the work of replacing MIME strings with MediaContainerType, starting
from MediaResource and following the dependencies.
Most changes are mechanical: Just change ns*String into MediaContainerType, and
MIME string literals into MEDIAMIMETYPE("a/b").
Some checks for empty/invalid strings and lowercase comparisons can go, thanks
to the always-valid always-lowercase-MIME invariants of MediaContainerType.
One special case in is MediaSourceResource, which used to have an empty string
as its type (because its own type is not relevant, but its SourceBuffers carry
types). Because the inherited GetContentType *must* be overridden, and must
return a MediaContainerType, we needed a valid type even though it should not
be seen in the real world. I've chosen "application/x.mediasource" for that.
MozReview-Commit-ID: 1aCH75Kh2e6
--HG--
extra : rebase_source : 0d9cd9b69c264e5dcfc3845f80ee107f4bcbcd9a
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
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
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
MediaContentType can only be created through MakeMediaContentType(), which
returns a Maybe<MediaContentType>.
If the return value is Nothing, parsing failed.
Otherwise the contained MediaContentType object is guaranteed to be valid;
E.g., GetMIMEType() will always return a non-empty string.
Note that this interface will change a lot in the following bugs&patches, so
please don't worry about the 'Get' in the never-failing GetMIMEType(), it will
be gone soon!
MozReview-Commit-ID: IjGKkQ6RVd4
--HG--
extra : rebase_source : 5254af80dec0beb05da49f68c12fecc28edd725e
Replace both uses of nsContentTypeParser with MediaContentType.
MozReview-Commit-ID: KV7ze3ASRf3
--HG--
extra : rebase_source : b3d102b02fa671d0a42d70ae7fe66bdd51ac5d86
Will allow to pass detailed failure causes in a followup patch.
MozReview-Commit-ID: 5yGjzZNcYWg
--HG--
extra : rebase_source : fdd76c98900320352ee3c349de1c40df29122ca9
See w3c/MSE Issue 19, 20 & 26.
Changing the duration now can never call the range removal algorithm. An explicit call to remove must be used for range removal.
This change performs the following:
- Require remove() for all Range Removals
- Error on Duration Changes that need remove first
MozReview-Commit-ID: 1fK2O1slnQ1
Some refactoring, clean-ups, etc.
The main change is that the can-play status is passed when diagnostics are
finally recorded. This will help when introducing different types of
diagnostics in future patches (e.g., Key System issues).
MozReview-Commit-ID: 182ePlrMqn4
DecoderDoctorDiagnostics are now used at places where Firefox Chrome and/or
websites checks whether some media formats may be played:
- audio|video.canPlayType()
- audio|video resource loader
- MediaSource.IsTypeSupported()
- MediaSource.AddSourceBuffer()
MozReview-Commit-ID: B1KdjXODq9j
Pass declared-but-yet-undefined DecoderDoctorDiagnostics pointer to various
routines that contribute to deciding if a media format can be played, and
those that create decoders.
Points where a DecoderDoctorDiagnostics can be injected are currently marked
with "/* DecoderDoctorDiagnostics* */ nullptr", and some will be used in
following patches.
MozReview-Commit-ID: 7u37bvY4CpW
The Benchmark class is now taking a MediaDataDemuxer argument. Options allow to decode any videos and measure the decoding speed.
MozReview-Commit-ID: C017I1cGqPL
