YUVColorSpace is inseparable from the bit depth as the matrix coefficients to be calculated need the bit depth information.
So let's put the two types together. gfx namespace also makes more sense as that's where we find IntRect, IntSize and other.
The extent of the changes highlight how much similar data structures are duplicated across the code, to the point it's scary.
Differential Revision: https://phabricator.services.mozilla.com/D25347
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec: the scheme implies mode. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec --
possibly if the isProtected flag which we were tracking with mMode, is
ever changed to be more than a bool in the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Explicitly store the crypto scheme being used on our crypto structs to let us
differentiate between cenc and cbcs data. In doing so remove mMode and replace
mValid with IsEncrypted() for the following reasons:
- Different modes within the existing schemes are not currently utilized by the
spec of implementation. Having a mode and a scheme could lead to confusion
between the two. We can return mMode if ever needed by the spec.
- mValid was typically used to check if these structs contained valid crypto
data or not. With only one scheme this was often shorthand for 'IsEncrypted',
but with multiple schemes what is considered valid data for one may not be for
another. Do away with this and just explicitly have an 'IsEncrypted'.
Differential Revision: https://phabricator.services.mozilla.com/D15874
--HG--
extra : moz-landing-system : lando
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This makes it for future easier conversion for the FFmpeg and Windows WMF decoder, so that we can use their channel map directly.
Also introduce a difference between 2F2 and QUAD, cubeb supports will be added in a future change.
MozReview-Commit-ID: L5NkjeuGslI
This means that MediaInfo.h doesn't need to include StreamTracks.h, which pulls
in MediaSegment.h and the MSG and a bunch of DOM bindings stuff.
MozReview-Commit-ID: 6JSO1dxJq8k
--HG--
extra : rebase_source : c5ca38a6e0b297e4e05db3b23c7c2ead49e9f8bc
The nsRect.h and nsSize.h headers typedef nsIntRect to gfx::IntRect etc, so the
rect/size objects we use will be the same, just under a different name.
However the old headers #include a bunch of things we don't use, so we if we
use the gfx objects directly we end up with a smaller include graph.
MozReview-Commit-ID: 7S4OSqBJK9m
--HG--
extra : rebase_source : 7cc48507356ce754e8395af957fa68a28711e00a
into TrackInfoSharedPtr to better indicate what this class is about.
Adding cast operator to allow transparent conversion from TrackInfoSharedPtr to const TrackInfo*
MozReview-Commit-ID: 6RwXl5CG0fG
--HG--
extra : rebase_source : b5a7a0f06793c609e2eab60aacc4f76d96d6ec32
The patch in bug 1300069 introduced an inconsistency between what the
MediaDecoderStateMachine and the MediaFormatReader consider an encrypted
stream. The MDSM considered a stream encrypted if mInfo.IsEncrypted() is true,
and that only takes into account the PSSH. Whereas the MFR only considers the
presence of a TENC box to indicate encryptedness. This would cause the MDSM
to not wait for the CDM before trying to start decoding. So if you setup the
MediaSource before setting the MediaKeys on the MediaElement, you'll end up
trying to create an EME decoder without a CDMProxy, and that causes a null
pointer deref and crash.
This patch ensures that the MDSM and the MFR use the same logic to determine
whether a stream is encrypted.
MozReview-Commit-ID: KGuYTuP9XDL
--HG--
extra : rebase_source : 85b303597a401a69f7e4ac63a267d8c8eb52ffa5
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
Display dimensions are actually determined from the SPS NAL with h264 and as such we don't really care on what is found in the container (which may be incorrect).
MozReview-Commit-ID: 7JmxIawNOOn
--HG--
extra : rebase_source : 9454b07742af880cd992a92517880788bd18a712
Rename StreamBuffer to StreamTracks. We still need a place to keep the track information in every MediaStream, even the StreamBuffer::Track::mSegment is empty.
--HG--
rename : dom/media/StreamBuffer.cpp => StreamTracks.cpp
rename : dom/media/StreamBuffer.h => StreamTracks.h
It is considered valid for a webm video to return a decoded size different to the metadata values. ScaledImageRect will scale the cropping rectangle according to the original cropping aspect ratio.
MozReview-Commit-ID: BcpoqQhEQB1
