When reading samples from plain file resource, if we can't get the duration from sample, that means it's the last sample. Therefore, the next timestamp should be the track's duration.
Differential Revision: https://phabricator.services.mozilla.com/D6217
--HG--
extra : moz-landing-system : lando
As audio track sample and video track sample are both using the same code pattern, we can eliminate
redundant codes.
Differential Revision: https://phabricator.services.mozilla.com/D6216
--HG--
extra : moz-landing-system : lando
WebMs with encrypted tracks may have unencrypted samples in these tracks.
Previously we would populate some of the crypto metadata on these samples. This
data was correct, but it was potentially misleading to include crypto metadata on
clear samples.
This changeset alters the behaviour so that we do not populate any such data for
unencrypted packets. This should not alter existing behaviour, notably the
Widevine CDM version 9 should continue to work. However, this change makes our
samples easier to feed to version 10 of the CDM. Without this change, we would
need to do extra conversion steps to appease the new CDM.
Differential Revision: https://phabricator.services.mozilla.com/D6183
--HG--
extra : moz-landing-system : lando
Should mStreamLength be > 2^32, we could have overflowed leading to false positive test.
Differential Revision: https://phabricator.services.mozilla.com/D6235
--HG--
extra : moz-landing-system : lando
When calling resume() on a running AudioContext, there is no need to discard current AudioChannelAgent and then create a new one.
Differential Revision: https://phabricator.services.mozilla.com/D5799
--HG--
extra : moz-landing-system : lando
Prior bug 1416085, reads were clamped to the content's duration (if known). It appears that the new code relied on MediaCacheReadBlockFromCache to properly account for the end of content.
However, this was not the case, the MediaCache always reads (and write) one full block at a time regardles of the size requested (a block is 32768 bytes).
Rather than clamping in the Read() method as it used to be, we clamp in ReadBlockFromCache as such safety will benefit other callers that would have otherwise also returned garbage reads.
Differential Revision: https://phabricator.services.mozilla.com/D5964
--HG--
extra : moz-landing-system : lando
In the ideal situation, sites should create AudioContext only when sites are going to produce
sound, so we would show doorhanger to ask users whether they want to allow autoplay.
We delay the AudioContext's state transition from `suspended` to `running` until
(1) user click 'Allow' button in doorhanger
(2) user interact with sites, and then AudioContext calls resume() again
Differential Revision: https://phabricator.services.mozilla.com/D5610
--HG--
extra : moz-landing-system : lando
With UA Widget, the videocontrols container is created lazily.
It won't be a problem for WebVTT.processCues() in vtt.jsm, so
TextTrackManager::UpdateCueDisplay() should not early return there, but pass
nullptr to it.
Differential Revision: https://phabricator.services.mozilla.com/D3667
--HG--
extra : moz-landing-system : lando
I want to know how many sites will have that scenario which is to create AudioContext in advance and produces sound later (ex. when user click the page or certain button).
I will add a Telemetry probe to meausure how long the AudioContext would become audible since it was created.
Differential Revision: https://phabricator.services.mozilla.com/D5453
--HG--
extra : moz-landing-system : lando
Implement a compatibility layer so that we can expose a CDM10 interface while
still using CDM9. Notably, this layer checks to make sure the new encryption
scheme introduced with CDM10 is not used with CDM9.
Depends on D5630
Differential Revision: https://phabricator.services.mozilla.com/D5631
--HG--
extra : moz-landing-system : lando
The CDM10 interface makes 2 notable changes here:
1) Instead of the binary choice between unencrypted and encrypted (which assumed
cenc encryption), the interface now allows for specification of encryption used.
Practically this means we will eventually need to support choosing between not
encrypted, cenc, or cbcs.
2) The interface adds a bool for hardware secure codecs for use when
initializing the CDM.
This changeset adjusts the IPDL for the CDM to accommodate these changes. The
changes are also supported in surrounding code, but are not fully plumbed to
either the web, or the CDM.
Fully supporting new encryption schemes and hardware secure codecs will require
further work which is beyond the scope of this bug.
Some formatting drive bys so new formatting and old formatting both match
expected formatting by clang-format.
Depends on D5629
Differential Revision: https://phabricator.services.mozilla.com/D5630
--HG--
extra : moz-landing-system : lando
Remove members only used by CDM8 from the IPDL and remove code that depended on
the removed IPDL. Rename various instances of 'error' to 'exception' as from
CDM9 'exception' is used exclusively to refer to promise failure states.
Depends on D5628
Differential Revision: https://phabricator.services.mozilla.com/D5629
--HG--
extra : moz-landing-system : lando
Update content_decryption_module.h and other Widevine headers. This removes the
CDM8 interface and adds in the CDM10 and CDM11 interfaces. As such this patch
removes references to CDM8 from the code and adds some of the foundations for
supporting CDM10. Most of the CDM10 code will be implemented in another bug, but
there are a number of cases where it was straight forward to shuffle CDM8+9 code
-> CDM9+10, rather than deleting it and replacing it later.
Differential Revision: https://phabricator.services.mozilla.com/D5628
--HG--
extra : moz-landing-system : lando
While the MP4 parser correctly handles the av01* codec string, it
is then converted to a video/av01* mimetype to search for a PDM.
The libaom PDM only accepts video/av1, so always produce a video/av1
MIME type from a codecs=av01 string.
Differential Revision: https://phabricator.services.mozilla.com/D5744
--HG--
extra : moz-landing-system : lando
On some platforms where a hardware decoder is present, but non functioning, we would fail to initialize the video stride, leading to the frames being incorrectly displayed later.
Also delete the DXVA2 manager early under those circumstances
Differential Revision: https://phabricator.services.mozilla.com/D5402
--HG--
extra : moz-landing-system : lando
> dom/media/gmp/CDMStorageIdProvider.cpp(63,10): warning:
> local variable 'storageId' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClip.cpp(581,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/DisplayItemClipChain.cpp(88,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> layout/painting/nsDisplayList.cpp(179,10): warning:
> local variable 'str' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> gfx/thebes/gfxWindowsPlatform.cpp(454,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Will remove std::move().
> gfx/thebes/gfxFontEntry.cpp(245,20): warning:
> local variable 'name' will be copied despite being returned by name [-Wreturn-std-move]
nsAutoCString -> nsCString, will add std::move().
> netwerk/cookie/nsCookieService.cpp(4460,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
GetPathFromURI() result is stored in an nsAutoCString, so it might as well return that type.
> toolkit/components/extensions/WebExtensionPolicy.cpp(462,12): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
> toolkit/components/extensions/WebExtensionPolicy.cpp(475,10): warning:
> local variable 'result' will be copied despite being returned by name [-Wreturn-std-move]
`result` may be empty or may be arbitrarily long, so I'll use nsCString inside the function.
> toolkit/xre/CmdLineAndEnvUtils.h(349,10): warning:
> moving a local object in a return statement prevents copy elision [-Wpessimizing-move]
Returning an UniquePtr, will remove std::move().
Also will `return s` instead of `return nullptr` when `(!s)`, to avoid extra construction which could also prevent elision (not entirely sure, but it's at least not worse!); and it's clearer that the two `return`s return the same already-constructed on-stack object.
> tools/profiler/core/shared-libraries-win32.cc(111,10): warning:
> local variable 'version' will be copied despite being returned by name [-Wreturn-std-move]
nsPrintfCString -> nsCString, will add std::move().
> xpcom/glue/FileUtils.cpp(179,10): warning:
> local variable 'fullName' will be copied despite being returned by name [-Wreturn-std-move]
> xpcom/glue/FileUtils.cpp(209,10): warning:
> local variable 'path' will be copied despite being returned by name [-Wreturn-std-move]
nsAuto{,C}String -> ns{,C}String, will add std::move().
This allowed removals of 'AllowCompilerWarnings' from layout/painting,
netwerk/cookie, and toolkit/components/extensions.
Differential Revision: https://phabricator.services.mozilla.com/D5425
--HG--
extra : moz-landing-system : lando
