The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
The MDSM currently uses the "MediaPlayback" thread pool. This is the same
thread pool used by the demuxers. If all the threads in the pool are in
use demuxing, we can end up not being able to run the A/V sync logic in
the MDSM's VideoSink. This means we end up not presenting frames we could
have potentially presented.
So move the MDSM's TaskQueue to its own SharedThreadPool of size 1. This
should allow the state transition tasks to run more independently from
the demuxing tasks.
Differential Revision: https://phabricator.services.mozilla.com/D33869
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
EME key system constants are used with UTF-8 functions where ASCII functions would do
Differential Revision: https://phabricator.services.mozilla.com/D25730
--HG--
extra : moz-landing-system : lando
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
--HG--
extra : rebase_source : 72ebe662f76fb6c9d8be1f753890601aac440061
AV1 support is behind a pref, as such, the result of canPlayType should depends on the value of that pref.
Additionally to this change we remove AOMDecoder::IsSupportedCodec as it implied confusion on what a codec mimetype is. There are two type of codec mimetype: the one describing the container content ("av1") and the one describing the codec itself "video/av1")
AOMDecoder shouldn't know anything about containers (e.g. mp4 or webm)
Summary:
We'll need it to properly build a SPS/PPS extradata later. Also, change the types used. The original data is stored on two bytes ASCII, it will always fit in a uint8_t. Additionally, this is how those values are stored in a SPS.
Depends on D1678
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1718
This prevent potential division by zero should the cast on the argument cause an overflow.
We still limit the mul and div arguments to INT64_MAX.
MozReview-Commit-ID: gHkv6m4zq0
--HG--
extra : rebase_source : 1c27f9a2ecc4c8bf6a763dedf2859e64bf79ea85
Additionally, remove no longer relevant MediaThreadType documentation as all MediaDataDecoder API are now asynchronous and we no longer have cancellable taskqueues.
MozReview-Commit-ID: 1F0YUhNniAn
--HG--
extra : rebase_source : 7b93ef24f91ccc21537e78bbb8a2d82bafacd29e
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
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
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 : f10355e7570b163473cee2548c04c6be11d9120f
The StringListRange iterator does not modify the list, and cannot be used to
modify the list, so we can make the begin&end functions const.
MozReview-Commit-ID: 4uNf6CWQ767
--HG--
extra : rebase_source : e4992a8c7e6b686004c90a335194617d2f77ca7b
By default StringListRange skips empty items.
Two new template options allow handling empty items:
- ProcessEmptyItems: Process all, *except* if string is empty.
- ProcessAll: Process all, including 1 empty item in an empty string.
MozReview-Commit-ID: WNRHU5iCHt
--HG--
extra : rebase_source : 994bf1364a705c8280473635a2a6a685d267ec44
Create a TrackInfo (VideoInfo or AudioInfo) from a codec MIME type, and
optionally with extra parameters from a MediaContentType.
MozReview-Commit-ID: JfDMQjVgCNT
--HG--
extra : rebase_source : 10eb8f14ce28a74883752c536b2312658bc0cb4d
Doing this causes a separate copy of each string to be included in each
compilation unit that includes VideoUtils.h, and since global
nsLiteralCString objects require a static constructor, injects static
constructors into all those compilation units as well. Moving the
object definitions to a source file and leaving the declarations in the
header makes everything work as expected.
Chris Pearce
Oana Pop Rus
Andreea Pavel
Noemi Erli
Khyati Agarwal
Sylvestre Ledru
Jean-Yves Avenard
Andi-Bogdan Postelnicu
Sebastian Hengst
Tristan Bourvon
Alex Chronopoulos
Gurzau Raul
JW Wang
James Cheng
Bevis Tseng
Bill McCloskey
Kaku Kuo
Gerald Squelart
Wes Kocher
Nathan Froyd