This change was a workaround a Youtube bug that expected a particular behaviour from old TV and that we were exploiting. It was adding support for unsupported, unofficial code.
MediaCapabilities is how things should be done.
Making this code to work conditionally is too much effort. Reverting it entirely is easier.
Differential Revision: https://phabricator.services.mozilla.com/D49515
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
YouTube.com/tv uses YouTube specific extensions to MediaSource.isTypeSupported
in order to determine whether it serves 4K. It checks with bogus values, and if
we reject the bogus values, it assumes we're responding truthfully to the other
queries. So add support to reject the bogus values on YouTube.com.
With this patch, we can play 4K on YouTube.com/tv.
Differential Revision: https://phabricator.services.mozilla.com/D26655
--HG--
extra : moz-landing-system : lando
Summary:
Addtionally, change the framerate to be of type double and allow to create a MediaExtendedMIMEType based on the new dom VideoConfiguration and AudioConfiguration object.
Depends on D1622
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1623
Many video codecs use a suffix to specify level, profile and optional features,
like "avc1.42E001" or "vp09.00.41.08".
MediaCodecs::ContainsPrefix() can be used to facilitate codec identification
from their prefix alone, e.g.: "avc1" or "vp09".
MozReview-Commit-ID: D6kcjggXptS
--HG--
extra : rebase_source : 3a60c01da1d91adf29f51ce3c32f8df60282c90a
Instead of `...Codecs().AsString().EqualsASCII("...")`, one can just type
`...Codecs() == "..."`.
MozReview-Commit-ID: JS0yXhs0mz1
--HG--
extra : rebase_source : 40947ca3975ae5390d5dae5add7ed35460235545
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
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
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
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 : d0c62f39a042ef256f2a0d6aaee162e7a58c4a9e
When replacing strings with MediaContentType objects, some classes will want to
know about their size.
MozReview-Commit-ID: LNdaaUdJac3
--HG--
extra : rebase_source : 334bdca4a9b7a5db455bb731c495fa7a96b5b03c
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 : 721db464b9544959490bcaae7bd7537ffbac5baa
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 : 0d52b0deb90ddcc037f2037b68baaf0ae34f45db
`==` 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 : bc1ade528841b5fd71278b827a94edc65e9a8898
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 : c2a1a8c1ed092581204161dd5a396a7ef11ea16e
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 : c46b480b9fc63eab9170b052c7f9ea9b7bbd048e
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 : cefaeeb2a81b60c575e350cc8399af038a021dc2
Simon Giesecke
Jean-Yves Avenard
Chris Pearce
shindli
Sylvestre Ledru
Gerald Squelart
Wes Kocher