This adds a mochitest to verify that the max-fs constraint results in smaller
video for VP8 and H.264.
MozReview-Commit-ID: Hk6uyqoiwUY
--HG--
extra : rebase_source : 99602d3d98f8f17b8d71fd94ef3198d43abb7541
1. Pass ChromiumCDMCallback interface to ChromiumCDMParent instead of ChromiumCDMProxy directly.
2. Wrap dispatching to main thread function to clean up the redundant code.
MozReview-Commit-ID: 5HxS9Fc1yr
--HG--
extra : rebase_source : 3ac4c4b260f3196bd862e97aaf12c2422d43ad11
In patch3, we remove the minimum resolution check, now the video under 48x48 can
be playback successfully. Therefore, removing them from error test and we should
ensure they can be playback.
MozReview-Commit-ID: BvLtr4DN1hU
--HG--
extra : rebase_source : 30b9dc35f5754d6ecc7cddaf7f5a9fabf9965889
Return MediaResult instead of using nsresult, because it can contain more detailed
error information. We could also return this error with our rejected decode promise.
MozReview-Commit-ID: 80yEAbxqvWu
--HG--
extra : rebase_source : 51a56b571767c6b64f0c92353585261b28ea5616
Change mLastError type to MediaResult and send it as parameter to PDM::CreateVideoDecoder
in order to get detailed error description.
MozReview-Commit-ID: 4sIRXTHsrzr
--HG--
extra : rebase_source : 23d72cc72f5683305745024de913f44298d717d5
After bug 1392143, we won't enable HW decoding for the resolution < 132 pixels.
In addition, software decoder doesn't have the minimum resolution limit, so
we can remove the minimum resolution check.
MozReview-Commit-ID: 7MiLpwjiq3s
--HG--
extra : rebase_source : 742556f6f2fb40b3e5e69212707a606d3b22ed36
WMFDecoderModule should only focus on whether the mime type is supported or not.
Let WMFVideoMFTManager do the checking.
MozReview-Commit-ID: K6jPfrntu7s
--HG--
extra : rebase_source : f6ba055824c3a7ebac85666e3201fd6b79e8d815
We should report the more detailed error when creating the decoder failed,
instead of just reporting "can not create decoder".
MozReview-Commit-ID: 8vunP5c3zzI
--HG--
extra : rebase_source : 327a988463bf61ad17d1f93bf0a2640d9c9735c7
In patch3, we remove the minimum resolution check, now the video under 48x48 can
be playback successfully. Therefore, removing them from error test and we should
ensure they can be playback.
MozReview-Commit-ID: BvLtr4DN1hU
--HG--
extra : rebase_source : 36cdd1e18cd41516319989b56e4e83888b0ecf50
Return MediaResult instead of using nsresult, because it can contain more detailed
error information. We could also return this error with our rejected decode promise.
MozReview-Commit-ID: HrI3QKlSJC
--HG--
extra : rebase_source : 6aba73c887e3068bf2a3f031a9a3b0698decc2e3
Change mLastError type to MediaResult and send it as parameter to PDM::CreateVideoDecoder
in order to get detailed error description.
MozReview-Commit-ID: 4sIRXTHsrzr
--HG--
extra : rebase_source : 23d72cc72f5683305745024de913f44298d717d5
After bug 1392143, we won't enable HW decoding for the resolution < 132 pixels.
In addition, software decoder doesn't have the minimum resolution limit, so
we can remove the minimum resolution check.
MozReview-Commit-ID: 7MiLpwjiq3s
--HG--
extra : rebase_source : 742556f6f2fb40b3e5e69212707a606d3b22ed36
WMFDecoderModule should only focus on whether the mime type is supported or not.
Let WMFVideoMFTManager do the checking.
MozReview-Commit-ID: K6jPfrntu7s
--HG--
extra : rebase_source : f6ba055824c3a7ebac85666e3201fd6b79e8d815
We should report the more detailed error when creating the decoder failed,
instead of just reporting "can not create decoder".
MozReview-Commit-ID: 8vunP5c3zzI
--HG--
extra : rebase_source : 327a988463bf61ad17d1f93bf0a2640d9c9735c7
It will allow to blacklist all NVidia Tesla and AMD UVD3 GPU.
MozReview-Commit-ID: LaJqyIj0Yau
--HG--
extra : rebase_source : aa93c4379181e2cb09733f0053de55bf64787ef6
This fixes the data race when Seek() read mClosed off the main thread.
MozReview-Commit-ID: GO7Kk5VgVpg
--HG--
extra : rebase_source : e29353aea1e077e30fd284a80a56472d6772e9e1
extra : intermediate-source : 20a5860220a6eb54616cbe059afdaebc81e07e1f
extra : source : 0722d581e2d03eb140ea722527975534471c31b5
So we know what to pass to SetupChannelHeaders()
when the channel is redirected.
MozReview-Commit-ID: DbCPGA3qIyn
--HG--
extra : rebase_source : 4b8a5b620344fa261b243c0935ce49ebb7a9b4aa
extra : source : dfe1a9fe59a623f4d1972f3184a5861cfef62ffd
We have MediaCacheStream::mChannelOffset to keep the download positon.
We don't need 2 variables for the same purpose.
MozReview-Commit-ID: IpnEJWuA9A9
--HG--
extra : rebase_source : 8e720d878c12555d0a5528167c183ddb881b249e
extra : source : 623cf4cc3ab5ad0d9d263bac05a58699b3577277
This ensures XRE_IsContentProcess() is defined, as it's used in this file.
MozReview-Commit-ID: JFCmvZ8aZdT
--HG--
extra : rebase_source : 5852da1b4b76f767e7d36071cdfa1f97eaedbf8c
It will allow to blacklist all NVidia Tesla and AMD UVD3 GPU.
MozReview-Commit-ID: LaJqyIj0Yau
--HG--
extra : rebase_source : aa93c4379181e2cb09733f0053de55bf64787ef6
1. Pass ChromiumCDMCallback interface to ChromiumCDMParent instead of ChromiumCDMProxy directly.
2. Wrap dispatching to main thread function to clean up the redundant code.
MozReview-Commit-ID: 5HxS9Fc1yr
--HG--
extra : rebase_source : ff3227b01003398d0410bdde5f43621f44d9e477
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : ce6e27c7d422f32dec858712eba5ed8011ee8039
mIgnoreClose is always set in conjunction with a call to CloseChannel().
Since mListener->Revoke() will prevent future OnStopRequest() calls from coming,
it is unnecessary to set mIgnoreClose and therefore we can remove this member.
MozReview-Commit-ID: HEXIhIUG8WN
--HG--
extra : rebase_source : 656c1bb67fcddcca4c2c17b0bb783ad325ab52ec
extra : source : b852f796c1ba6a8bc442013b7b6058a24a33634b
MediaCacheStream::mStreamLength has been set either in Init() or InitAsClone().
MozReview-Commit-ID: L259ecDgjN7
--HG--
extra : rebase_source : 7df74d388808492faac73c3e41a972cb22cdb187
extra : intermediate-source : d834e02c15ed9361a02977349459fad079910642
extra : source : 45df347e1fd6b67d60212f2d87312d597656a7d6
The only caller is CacheClientSeek() which always passes nullptr to it.
MozReview-Commit-ID: 3CTkbF6ktp2
--HG--
extra : rebase_source : f53fe82ca0fc5e2926c4d2cf1346630098a9614f
extra : intermediate-source : a4823926a983af9293c9fe9857e39527735ea226
extra : source : 88a08faec452614217bebe80fc2b00a2b08f7f38
This is more efficient because aStreamListener won't be null.
MozReview-Commit-ID: 4b22l7cTK6y
--HG--
extra : rebase_source : 5e2366eaa79ccff2aacaf47d67805e3f939cc362
extra : intermediate-source : f6a6c58325085ce47e41a189d2e14239695bdaed
extra : source : 16b0c9ebdc4102fcd07d28a2c1a1a3b26d607f47
1. mChannel is null.
2. mCacheStream has been initialized by InitAsClone().
So ChannelMediaDecoder::Load() doesn't need to call OpenResource(nullptr) at all.
MozReview-Commit-ID: FeARp9fu65L
--HG--
extra : rebase_source : ee3ae9bfa6830ed18fea152e12da18e181870d2d
extra : intermediate-source : 6b78ae143afa325b378d7cc2cbd2e3e0bcfdfe93
extra : source : 098787b9606b70697a3b1762b35a488799995475
We also make it return void since it now always succeeds.
MozReview-Commit-ID: H1oQWoguEzF
--HG--
extra : rebase_source : b5c6714832bed6fceb80c4afcdf4a590cc7dc567
extra : intermediate-source : 01aa9da848391bbf0b39f8dca874c0234f3202fb
extra : source : af04510d8603ffe407069ef342fdb4d3bca33509
Fix the fail by patch1, so we can re-enable it.
MozReview-Commit-ID: It3JkvQzAdk
--HG--
extra : rebase_source : 5ad433012750c8f6c92b16b787e87b32ee03d7a6
For chained ogg files, the new part would contain new timestamp from zero, so
we need to add the duration of previously decoded data to make sure the current
time is correct.
MozReview-Commit-ID: Bb1lCiKz4uQ
--HG--
extra : rebase_source : 5cfd81eb092a042e6394aa5209516ad75e741a37
This changing causes the resampling rate tolerance so that the ME.current time
might not be the same as ME.duration depending on the different resampling rate.
MozReview-Commit-ID: H2dpyw5Bghv
--HG--
extra : rebase_source : 850efb46c7980ec4234e239e38bc7dbb233cd573
As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos.
MozReview-Commit-ID: 8VbZTiJO9mA
--HG--
extra : rebase_source : dcfb26420f2aa2b3b8972f2a9ad35a141b37e74a
As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos.
MozReview-Commit-ID: 8VbZTiJO9mA
--HG--
extra : rebase_source : da34be08b67716ebb84f249ead571cc171d8d2f7
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : 5dcc252160694a72e30ae41689f173cc0886edd6
The only caller is ChannelMediaDecoder::GetStatistics() which runs on the main thread.
MozReview-Commit-ID: CYg3Z3rmlHd
--HG--
extra : rebase_source : c3bf0083522256a6c4f3e83bc817ee7d0ce398bf
extra : intermediate-source : 12bad420f0f3eb9a3993fada2f919d61f60ad392
extra : source : 6044445039445631bbb6cd66607b6f7f72547f18
This is required by P3 to preserve the ordering. E.g. we want
mChannelStatistics.AddBytes() to happen before the new data is consumed
by the decoder and is made observable to the main thread. Using
SystemGroup::Dispatch() won't guarantee the ordering.
MozReview-Commit-ID: 7MP0CzTGpOs
--HG--
extra : rebase_source : 1161b7c713f57625f38b70714bb8684c2edecb2a
extra : source : 22b362b56f218acb70cc7ce3c0fd0ea113563681
As the H264 SanityTest uses a 132x132 videos to determine if the hardware decoder is working, we always use the software decoder for smaller videos.
MozReview-Commit-ID: 8VbZTiJO9mA
--HG--
extra : rebase_source : 20cf3ae8bf62709711ac0e76e348c6e28d678025
The TrackInfo [1] created in WMFDecoderModule::SupportsMimeType() doesn't contain valid image's width and height, because the TrackInfo is created without width and height [2] and the default width and height are both -1 [3].
Thesefore, we can't correctly check whether this resolution is supported by MFT [4]. We should use Supports() instead of SupportsMimeType().
[1] https://goo.gl/QV8Jgm
[2] https://goo.gl/4siShn
[3] https://goo.gl/BDoXYf
[4] https://goo.gl/BZh4QA
MozReview-Commit-ID: 4dIJ84eaytq
--HG--
extra : rebase_source : 1ac63d25d3c7473f9bfd595432273460649a26f1
When MediaCacheStream::NotifyDataReceived() runs off the main thread,
there is no guarantee that the principal will be updated before the new
data is observable to the consumer because the principal can only be
updated on the main thread while the consumer can access the data off
the main thread.
To make the code simpler, we always dispatch a task to run UpdatePrincipal()
even when CacheClientUpdatePrincipal() already runs in the main thread.
This also avoid the deadlock because ChannelMediaResource::UpdatePrincipal()
will never run with the cache monitor held.
MozReview-Commit-ID: 9CdrJnaV0hl
--HG--
extra : rebase_source : 128d54f4583199e7bfa8c72895583ab7fb668706
extra : intermediate-source : c2310f99bdc7529f1e1c67edbb8274b20b679cb2
extra : source : b6cc234d83e7b18ab69502af78d27ce5eda3b350
The default string is over 400 bytes long, it will never fit in the default 64 bytes buffer of an nsAutoCString.
MozReview-Commit-ID: 3FHPQDgCtMF
--HG--
extra : rebase_source : 13d6070acc9f29afab922d9e37c215114729aef4
The MediaRecorder should now transition to inactive immediately upon an error
being encountered. This contrasts with the previous behaviour where onerror
would be called before performing this transition. This changeset updates
tests to reflect this new behaviour.
MozReview-Commit-ID: 5V2JkoMb0wB
--HG--
extra : rebase_source : cdd61c7fe128089458fd93f18d6b133a52b9b8aa
The MediaRecorder should transition to a 'inactive' state immediately upon
error. This changeset updates the recorder to do so. Previously the recorder
would fire an error event before transitioning, resuling in the state still
being 'recording' for handling of the the thrown error.
MozReview-Commit-ID: KMkaPOnEBYx
--HG--
extra : rebase_source : 4d05d46de775029d307ac2460700ce28c4e8321a
Since the street.mp4 is a fragment mp4, the duraion is unstable when seeking in the testcase, change the test file to gizmo.mp4.
MozReview-Commit-ID: 8eQ9tfKwxZF
--HG--
extra : rebase_source : a15dfd0994456809241f9dd5a0c44239beda4e16
We now only use the Chromium CDM interface, so there is no need to check isWidevine.
We don't use WidevineAdapter anymore so remove the related check and unused classes.
MozReview-Commit-ID: 3y1lH3OMhwL
--HG--
extra : rebase_source : 955395f3bbbd523236e9ac2480ef21093a281084
We remove the instantiation of EMEVideoDecoder and GMPCDMProxy in Part1. Just delete it and its h/cpp from moz.build
MozReview-Commit-ID: 8kGQK967pR0
--HG--
extra : rebase_source : 77750e6a92e6b649c41e7a8f769fa14c810e8e18
1. Delete MediaPrefs::EMEChromiumAPIEnabled() and related logic.
2. We now only use the Chromium CDM interface so delete the opposite side check of MediaPrefs::EMEChromiumAPIEnabled().
MozReview-Commit-ID: GDFrrf4WlWf
--HG--
extra : rebase_source : 987667dd47757afd58e7da10b60c0e1e1ec89d39
The codec mimetype is now shown in the media devtools. May as well make it readable.
MozReview-Commit-ID: 6rccDiTR24m
--HG--
extra : rebase_source : 7b8d1da8f05d0c46d5fd57b5e604ec3aed36a5f2
Instead set members after initialising the child decoder, and only ever access the child decoder on the same thread.
MozReview-Commit-ID: 4mfhVWbNLEu
--HG--
extra : rebase_source : 90a8e7bc8975fd08fc6b262c81cbf43a45751a06
This makes it easier to determine the actual decoder in use within the GPU process.
MozReview-Commit-ID: 5TF6AsyXYWW
--HG--
extra : rebase_source : 0e73dc17206a83006040cf422182da560b3cf70a
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
Since MediaResourceCallback is ref-counted, we don't need nsRevocableEventPtr
to handle the case ChannelMediaResource might go away before mCallback->NotifyDataArrived()
is run. This also avoid the data race in accessing mDataReceivedEvent on different threads
when OMT data delivery is enabled.
MozReview-Commit-ID: 1Tbjxrm1ar5
--HG--
extra : rebase_source : 235bca5f578aac0e586754596eaa0e0fa6325df4
extra : source : 74edc45577859a3f4593a6957880778df732d8eb
The codec mimetype is now shown in the media devtools. May as well make it readable.
MozReview-Commit-ID: 6rccDiTR24m
--HG--
extra : rebase_source : 7b8d1da8f05d0c46d5fd57b5e604ec3aed36a5f2
Instead set members after initialising the child decoder, and only ever access the child decoder on the same thread.
MozReview-Commit-ID: 4mfhVWbNLEu
--HG--
extra : rebase_source : 90a8e7bc8975fd08fc6b262c81cbf43a45751a06
This makes it easier to determine the actual decoder in use within the GPU process.
MozReview-Commit-ID: 5TF6AsyXYWW
--HG--
extra : rebase_source : 0e73dc17206a83006040cf422182da560b3cf70a
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
GPUProcessCrashTelemetryLogger is used to report telemetry of the time used to recover a decoder from GPU crash.
It uses MediaDecoderOwnerID to identify which video we're dealing with.
It uses MediaDataDecoderID to make sure that the old MediaDataDecoder has been deleted and we're already recovered.
It reports two recovery times, one is calculated from GPU crashed (that is, the time when VideoDecoderChild::ActorDestory() is called) and the other is calculated from the MFR is notified with NS_ERROR_DOM_MEDIA_NEED_NEW_DECODER error.
MozReview-Commit-ID: 82BRc2Vs3cw
--HG--
extra : rebase_source : 8c92501f625d44e9391a2432b98842769ed8a199
When GPU process crashes, the MediaDecoder, MDSM, and MFR are all destroyed.
So, we use MediaDecoderOwner to identify which video we're dealing with.
MozReview-Commit-ID: 1cv08M7Cpcf
--HG--
extra : rebase_source : 62f7be874d97a58eb4c1d7a98b4e9fe83a9313d3
We keep the GPU crash time and send back to MFR through MediaResult.
We cannot save the information in VideoDecoderChild as a static member because we are going to read it in MFR's task queue and the data was written in VideoDecoderManager's thread. This is going to be racing.
MozReview-Commit-ID: FXqOgelWY6e
--HG--
extra : rebase_source : 5c0561e009ad16983e1ff910216f9cf7901b5542
This is a practice commit to clarify what arguments we're accepting.
MozReview-Commit-ID: 2qQbNAYzGwr
--HG--
extra : rebase_source : 26527c08c32d79f794601afdd7832fa0ed53ecf7
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : 567e01703983ef91a66fb35fdb7702d06ed3c6e4
This was used for speech recognition in b2g builds. It is no longer
enabled by default and the associated interaface code no longer
compiles.
The dom interface code remains, pref'd off. This simply removes
the third-party backend implementation we have in-tree.
MozReview-Commit-ID: Fzwp6Cs9ePE
MediaPrefs isn't initialised in the GPU process, so use gfxPrefs instead.
MozReview-Commit-ID: CgDSTtVo6GL
--HG--
extra : rebase_source : 7bac527573f8d85c0ea88334c8691d27e95ee53c
1. mCacheStream.Close() should happen after CloseChannel() to avoid data race
in reading mClosed in MediaCacheStream::NotifyDataReceived().
2. MediaCache::Update() and CloseStreamsForPrivateBrowsing() should call
ChannelMediaResource::Close() to ensure mCacheStream.Close() happens
after CloseChannel().
MozReview-Commit-ID: 1o3yPbm3Gy6
--HG--
extra : rebase_source : 0a39af9ae228bdf4098ad16793bb6eccd15c3ec7
extra : source : f4b6deb231be5915dc42318ec22d850d20562b0e
With MediaInfo.h no longer including StreamTracks.h, some things that include
MediaInfo.h now use things that are no longer included. This patch adds the
includes back in, so the build works again.
MozReview-Commit-ID: INpH3vnBAmk
--HG--
extra : rebase_source : 8b91a999c71242c1eb5030f86c2a1f1c85d5fb27
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
Move the dependent method into HLSDecoder.
Remove the class entirely.
MozReview-Commit-ID: F9eOFQvgeLQ
--HG--
extra : rebase_source : a45407d88513883245f429c5f4bd09c78bef6f10
This is required to use nsIThreadRetargetableRequest::RetargetDeliveryTo().
MozReview-Commit-ID: GFuAjovabpY
--HG--
extra : rebase_source : 4fbc7877f2548dcf0777c820ee724f41c46de688
On platforms with MOZ_SAMPLE_TYPE_S16, decode and resampling was already
performed in 16-bit arithmetic. Keeping the potentially large buffer in
16-bit format halves the memory usage.
This patch does not affect other platforms.
MozReview-Commit-ID: DWZdiPNasie
--HG--
extra : rebase_source : 5df87fd343bbfba035f6b57d3025c0b89b661a8a
for sharing with a new factory method in a future patch.
MozReview-Commit-ID: LAtbRVttMh8
--HG--
extra : rebase_source : 120f2d52ad693aa0853d5058fa7418544878aac4
This is mostly to be consistent with other nodes so that only a single
SetBuffer method is required to pass buffers from nodes to engines.
AudioChunk also has the advantage of ThreadSharedFloatArrayBufferList that it
keeps a record of the length of the buffer in the same struct, and so this is
passed to the engine with the buffer.
SharedBuffer needs one fewer allocation than ThreadSharedFloatArrayBufferList,
but this is not a hot path.
MozReview-Commit-ID: JsLcuFdFvRO
--HG--
extra : rebase_source : 1a09fd12edc2b519faac59229bf383e025008d1c
The existing infallible Create() is also changed to use operator new(size_t)
to match the non-array delete when the ref count drops to zero.
MozReview-Commit-ID: HZGjSKnV8I2
--HG--
extra : rebase_source : f327facf481fee7d2e543e3160e3aebe05885cca
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, 16 bit buffers will be permitted in a future
patch.
MozReview-Commit-ID: FPZ6VcX4C1q
--HG--
extra : rebase_source : dc0d82d5495383ab2aaca37a09d282dd3c747e83
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
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, buffers with 16-bit data will be permitted
in a future patch.
MozReview-Commit-ID: FEGKMiQOCpR
--HG--
extra : rebase_source : 29680252fac272feda26ba65dd1ca86e0e9d5883
Gecko still finds out the current driver is blacklisted or not if we set "media.wmf.deblacklisting-for-telemetry-in-gpu-process" = true.
But this is only for telemetry usage.
MozReview-Commit-ID: 2Ydg527uQhe
--HG--
extra : rebase_source : d516f12674aa5532416635d6b95950786b74f6a2
extra : intermediate-source : ed0c0f7e47aca0ab962922f5e9ac58d6486ebc87
extra : source : b24c06b2b9854f68b60ba4a73755cf65c5266ae9
Previously this would always treat the pref as false, due to a slight
mistake in how Preferences::GetBool is called, and it could try to read
prefs off the main thread in some cases.
MozReview-Commit-ID: CcnVevHvqye
--HG--
extra : rebase_source : 11a3e91c5c684e6e45b9a4f1e773a92868ec1dd5
This fixes usages of `Find`, `RFind` and the equality operator that kind of
work right now but will break with the proper type checking of a templatized
version of the string classes.
For `Find` and `RFind` it appears that `nsCString::(R)Find("foo", 0)` calls
were being coerced to the `Find(char*, bool, int, int)` versions. The intent was
probably to just start searching from position zero.
For the equality operator, the type of nullptr is nullptr_t rather than
char(16_t)* so we'd need to add an operator overload that takes nullptr_t. In
this case just using `IsVoid` is probably more appropriate.
--HG--
extra : rebase_source : 50f78519084012ca669da0a211c489520c11d6b6
We will move the implementation to sub-classes which have more details
about how to calculate the resource size.
MozReview-Commit-ID: 7lfiz5GNtPE
--HG--
extra : rebase_source : bf14ef91a6de456d65bee7cb1f53f8e542f55247
extra : source : 22640df9dd3a1491594a82b3d0bd175e46073fa3
Including these also causes us to include a bunch of headers about points,
margins, and nsISupports/XPCOM/js, which we don't need.
MozReview-Commit-ID: 167YidMaeUQ
--HG--
extra : rebase_source : ab9ab45699451bb3fef613f401ae0e3853487ef5
If TimeUnits.h includes mozilla/dom/TimeRanges.h, then the build ends up
pulling in the Gecko DOM bindings, which pulls in a whole lot of JavaScript and
DOM bindings code. That makes it trickier to import GeckoMedia into Servo, and
makes Gecko's build slower, so move the code to convert TimeIntervals into
dom::TimeRanges.
Also remove an extraneous "virtual" and add "const" to some functions in TimeRanges.
MozReview-Commit-ID: BLeehaf9gCE
--HG--
extra : rebase_source : 84ef054cf8fd5b4434dc761a1b0a39803d3231f5
We hook in kernelbase.dll rather than kernel32.dll, as hooking QueryDosDeviceW
kernel32.dll is failing on our Win8 tests, it seems because QueryDosDeviceW in
kernel32.dll redirects to kernelbase32.dll, and the redirect has insufficient
space for our hook in Win8. So hook in kernelbase.dll, where the redirect
redirects to instead.
MozReview-Commit-ID: JKRiKCd7Ibn
--HG--
extra : source : 635dedbff7ceebc1e71bf397228da87bf5c6a0dc
The libaom av1 decoder will return 16 bit per channel
aom_image_t structures with only 8 significant bits.
Detect this case and use the mSkip fields of PlanarYCbCrImage
to handle the extra data instead of allocating and performing
an extra copy to obtain the necessary 8 bit representation.
MozReview-Commit-ID: 8H9YZe86Qzu
--HG--
extra : rebase_source : 2d397bc65d410c001a33835aec2a2751ff7fe32c
The libaom av1 decoder can return high bit depth frame
data now. Handle those frames by downsampling them
to 8 bits per channel so they can be passed to our
normal playback pipeline.
MozReview-Commit-ID: 97XYeh3YvQw
--HG--
extra : rebase_source : 04592c06f2f71bd4e54cd1650a237564f76d868c
Vendor upstream commit id f5bdeac22930ff4c6b219be49c843db35970b918
to pick up changes since the last import.
--HG--
extra : rebase_source : 6c03c7fcbffbdcf07b2b2819aee6dade2f0e2a0f
Enable client/server using: media.cubeb.sandbox = true
This pref is only read at start up, so requires restarting firefox for
a change in value to take effect.
MozReview-Commit-ID: 36L4vR5QEDJ
--HG--
extra : rebase_source : 501ddea24f6425372930fbf02ca4d15bc91e5de4
* test_playback_rate.html
In the patch2, we would honestly return the value of playback rate.
* test_info_leak.html/test_load.html
According to [1], we should only dispatch event "ratechange" when playbackRate or
defaultPlaybackRate attribute has just been updated. In these tests, they didn't
change the playbackRate or defaultPlaybackRate, we should not expect for the
"ratechange" event.
[1] https://html.spec.whatwg.org/multipage/media.html#event-media-ratechange
MozReview-Commit-ID: LjVDNnf4YX4
--HG--
extra : rebase_source : 3b58649212c24ccd5e17a64c3dc7fce8a9600207
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
The VoEHardware interface has been removed upstream. This replaces it with
calls to the AudioDeviceModule through VoEBase. This code is only used on the
non-full duplex code path.
MozReview-Commit-ID: m5ftmXm3CS
--HG--
extra : rebase_source : ee99440fa6616bc52d42c01b6b264c95e8b2ad89
The data being encrypted, is nonsensical. So we always rely on the container information
MozReview-Commit-ID: 4uQ9l3Q1Ebl
--HG--
extra : rebase_source : 675f9d23d73765387735212f8894235d5ba668e5
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
Including nsCOMPtr also pulls in cycle collection stuff, which complicates the
include graph.
MozReview-Commit-ID: 7YqrkwrVfds
--HG--
extra : rebase_source : 32b865ec1e1ceecba2014d3cdfdd58a92b0ce8fb
There's nothing in nsAlgorithm.h that we're using in AudioSampleFormat.h,
though it does pull in the definition of NS_ASSERTION(), which we can
replace with an MFBT assertion to simplyfy the include graph.
MozReview-Commit-ID: EXOv2t0hKDc
--HG--
extra : rebase_source : 466afc8922dbe9c209a07073c4946c8b568fd2c1
Sub-classes should know how to pin/unpin the resource.
MozReview-Commit-ID: 50S8oSD5oEU
--HG--
extra : rebase_source : 5e1b7c657b759c0d1dfdd7b5c0a4b7dbc4077ffe
extra : intermediate-source : 3000b76a3b97c08955c2d584ac215114c8e8f59a
extra : source : a56b9846db916ff85a0cae09736c3284bd895506
On platforms with MOZ_SAMPLE_TYPE_S16, decode and resampling was already
performed in 16-bit arithmetic. Keeping the potentially large buffer in
16-bit format halves the memory usage.
This patch does not affect other platforms.
MozReview-Commit-ID: DWZdiPNasie
--HG--
extra : rebase_source : b6a7191357c64888455ee111f02da75f208d2df7
for sharing with a new factory method in a future patch.
MozReview-Commit-ID: LAtbRVttMh8
--HG--
extra : rebase_source : 72283c49fd713d0aef3add0eae344da0733149a1
This is mostly to be consistent with other nodes so that only a single
SetBuffer method is required to pass buffers from nodes to engines.
AudioChunk also has the advantage of ThreadSharedFloatArrayBufferList that it
keeps a record of the length of the buffer in the same struct, and so this is
passed to the engine with the buffer.
SharedBuffer needs one fewer allocation than ThreadSharedFloatArrayBufferList,
but this is not a hot path.
MozReview-Commit-ID: JsLcuFdFvRO
--HG--
extra : rebase_source : 00ffc0a357ec248641063e77dbe63e8d2a4a0911
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, 16 bit buffers will be permitted in a future
patch.
MozReview-Commit-ID: FPZ6VcX4C1q
--HG--
extra : rebase_source : dc0d82d5495383ab2aaca37a09d282dd3c747e83
Although the AudioChunk buffer is still always a
ThreadSharedFloatArrayBufferList, buffers with 16-bit data will be permitted
in a future patch.
MozReview-Commit-ID: FEGKMiQOCpR
--HG--
extra : rebase_source : 29680252fac272feda26ba65dd1ca86e0e9d5883
This enables VP9 decoding on Windows with AMD graphic adapters supporting it.
The AMD VP9 MFT only works 720 and more pixels high.
The system will attempt the following decoding configuration:
1- AMD VP9 MFT
2- Microsoft VP9 MFT (only if DXVA is enabled)
3- FFmpeg ffvp9 software decoder
MozReview-Commit-ID: IP2eHZEQ7Tj
--HG--
extra : rebase_source : 6d193aa8b9d22f8df5778c7e62f66c30e9dc600c
If AddMediaElementToURITable() is called after the decoder Load failed, mDecoder
will be reset and it is sufficient to assert mDecoder only.
MozReview-Commit-ID: 58WT8zFeiFj
--HG--
extra : rebase_source : 712579b544e9a9ce971778b85795d06e58bd4ea5
extra : intermediate-source : 470e2d8a20010e11d7a7dce5540957e89439811e
extra : source : 59f4b2b33212794aa1cf3e8782737a2d4af8c241
This allows us to remove the dependency on MediaResource from MDSM in P2.
MozReview-Commit-ID: I46fWXfnGQK
--HG--
extra : rebase_source : 4808c7218d8c48c7425da16fadf4fd748cb2932f
extra : source : 10ac012e4c252438db1f64bb57dff181aff42a65
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
Instead, MediaDecoder::NextFrameStatus() checks IsEnded() and returns
NEXT_FRAME_UNAVAILABLE to ensure we have HAVE_CURRENT_DATA when playback
is ended on the main thread.
This will fix the timing issue (comment 0) which causes 'waiting' to fire.
MozReview-Commit-ID: 7O21x2q0lb8
--HG--
extra : rebase_source : bbd898edfb5f4a47a5062dd2bc916c911caf0c8e
extra : intermediate-source : 2b3e413db02a7aad00d13fdf274b346bccafc414
extra : source : 6f60fad11b65e75b456e128f8414fe2ea545455f
Most ChannelMediaDecoder::CloneImpl() functions just check to see whether
their "is enabled" pref is still true, and then clone their true type.
If we had a function to check whether the decoder for an arbitrary type
was still enabled, we'd not need the "is enabled" checks in the CloneImpl()
implementations. We'd then have removed the last custom behaviour in the
ChannelMediaDecoder subclasses.
MozReview-Commit-ID: D7kW6kb6ztW
--HG--
extra : rebase_source : 88f259ea0245a4405897959d5c115b0b79dc45e2
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 505f9dce979aad0529b07d2c046dca5028af6de6
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 83d0facbe26f8385c7163dc85d5512e7a43e80f4
MediaDecoder::CreateStateMachine is only virtual so that Ogg can attach
the reader's metadata/seekable produces to its chaining event.
The MediaSourceDecoder also overrides CreateStateMachine(), but it's not
called by anything external, so its implementation doesn't actually need
to be virtual.
MozReview-Commit-ID: 2x6bpK6Fdzd
--HG--
extra : rebase_source : 5a9932bf98992e13ba850dd640d2623ad8bcccbb
When the value of data is too small to be heard, AudioData::IsAudible() should return false so that we won't show the sound indicator for silent media.
In this case, the loudness of reported video is -673 dBFS, it's impossible to be heard.
MozReview-Commit-ID: Ewiko7RpkeX
--HG--
extra : rebase_source : 692e1af570648546deabc3fe4ae4c4b36bf8f356
Most ChannelMediaDecoder::CloneImpl() functions just check to see whether
their "is enabled" pref is still true, and then clone their true type.
If we had a function to check whether the decoder for an arbitrary type
was still enabled, we'd not need the "is enabled" checks in the CloneImpl()
implementations. We'd then have removed the last custom behaviour in the
ChannelMediaDecoder subclasses.
MozReview-Commit-ID: D7kW6kb6ztW
--HG--
extra : rebase_source : 88f259ea0245a4405897959d5c115b0b79dc45e2
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 505f9dce979aad0529b07d2c046dca5028af6de6
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 83d0facbe26f8385c7163dc85d5512e7a43e80f4
MediaDecoder::CreateStateMachine is only virtual so that Ogg can attach
the reader's metadata/seekable produces to its chaining event.
The MediaSourceDecoder also overrides CreateStateMachine(), but it's not
called by anything external, so its implementation doesn't actually need
to be virtual.
MozReview-Commit-ID: 2x6bpK6Fdzd
--HG--
extra : rebase_source : 5a9932bf98992e13ba850dd640d2623ad8bcccbb
Most ChannelMediaDecoder::CloneImpl() functions just check to see whether
their "is enabled" pref is still true, and then clone their true type.
If we had a function to check whether the decoder for an arbitrary type
was still enabled, we'd not need the "is enabled" checks in the CloneImpl()
implementations. We'd then have removed the last custom behaviour in the
ChannelMediaDecoder subclasses.
MozReview-Commit-ID: D7kW6kb6ztW
--HG--
extra : rebase_source : f463785d2975adceffd62037315d169736effbc0
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 366d4e34e9c425b478b4c9058e27c9a32de36515
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 63513ce3b01546142357182f21fce56932b32f7f
MediaDecoder::CreateStateMachine is only virtual so that Ogg can attach
the reader's metadata/seekable produces to its chaining event.
The MediaSourceDecoder also overrides CreateStateMachine(), but it's not
called by anything external, so its implementation doesn't actually need
to be virtual.
MozReview-Commit-ID: 2x6bpK6Fdzd
--HG--
extra : rebase_source : 01b4a59cba8ec64480779fb6849322841646ca3b
Change where load calls are used in media recorder principals test to more
reliably force cross origin requests.
MozReview-Commit-ID: 7La6ZIRmsTQ
--HG--
extra : rebase_source : 58b8049de46ad5800300033dd4ee101e68171c70
Despite the comment, this was necessary only for a direct convolver stage,
which has been removed:
https://hg.mozilla.org/mozilla-central/rev/e66105937eef190dec073f1b9859e07a0272706b#l4.29
FFT convolver stages pad the buffer to the necessary length in
FFTBlock::PadAndMakeScaledDFT().
Trailing zeros in the impulse change the scale used in normalization
and so padding the buffer before calculating the scale led to the wrong scale
being used.
https://github.com/WebAudio/web-audio-api/issues/481
MozReview-Commit-ID: LqP1x1hmLOM
--HG--
extra : rebase_source : f902190c25a7b95594d8115e43cde91f0cf00146
In order to expose the JS stack on aync exceptions from the MediaRecorder,
these exceptions must be created at the time of the operation which led to the
exception. E.g. during the start() operation. This changeset creates the
exceptions ahead of time in order to expose the JS stack traces.
MozReview-Commit-ID: HgDJrpjgidD
--HG--
extra : rebase_source : 1d208a848308c819a209f4b5c33e3563e83b9518
MediaRecorderErrorEvent is now fired in response to async errors in the
MediaRecorder. This event wraps a DOMException and tests need to be updated to
reflect this new behaviour.
MozReview-Commit-ID: JIjIZlJJ8PE
--HG--
extra : rebase_source : b8adde26f5321b5b8a3c8e193c5744d6f3403cf5
The MediaRecorder is current not behaving as per the spec in regards to async
errors. The spec states that in such a scenario a MediaRecorderErrorEvent which
wraps a DOMException should be fired. This changeset updates the recorder to do
so.
MozReview-Commit-ID: xt4ipCmbiu
--HG--
extra : rebase_source : 50124e6c878438a84c8a440bf79e50b3b7da3998
Update the MediaRecorder principal test to behave more like
test_mixed_principals.html. This involves preloading metadata and using a
longer video to test with. This particular combination currently results in
multiple requests being made for the resource, however this is not a robust
solution in that the behaviour of the MediaCache and associated objects may
change and break this. This fixes the issue for now as best I can tell, but
a follow up gtest or may be a more sensible long term solution.
MozReview-Commit-ID: F9gnnzGt3Cu
--HG--
extra : rebase_source : 8444f135033fbed350266ebfe5faafc245ff5596
The plugin-container sig file is located in another place.
Need to handle it as a special case.
MozReview-Commit-ID: 2e2gbM4CVDG
--HG--
extra : rebase_source : 26add2e4e68a919927b9500e7e391d7bb327ee81
When playback starts, currentTime is always 0, and even if the buffered data doesn't contain currentTime it is possible for playback to progress as we always allow up to 500ms gap in the buffered data.
As such, we must use fuzzing on the interval's start time when determining if we have future data.
MozReview-Commit-ID: Ki9QxmKhfdY
--HG--
extra : rebase_source : b7a550348b61d96f91e73b171a5dd03b16a4c152
Similar to test_PlayEventsAutoPlaying.html, but here we load 10s of data and ensure autoplaying kicks in.
MozReview-Commit-ID: ImpjFIcBIo1
--HG--
extra : rebase_source : c7d280eebeb6b3398176423b9e723696c9543c7f
For the same reason as P1, we check mCanPlayThrough instead of IsExpectingMoreData().
MozReview-Commit-ID: FZAcWyJmaK6
--HG--
extra : rebase_source : 41e0918fea8d0fad8d3709701f5d39199a42db47
extra : intermediate-source : 89042ba53de0ca4694ef5b201d50ffb643ab6d1a
extra : source : c747849a17e84e9c9fcf01604633e85364aa824a
Note we don't check MediaResource::IsLiveStream/IsExpectingMoreData()
for they should be included in the CanPlayThrough condition. This allows
us to remove some methods from MediaResource.
MozReview-Commit-ID: JtmRg9VeqGv
--HG--
extra : rebase_source : 5bd77047e6413af1b88776fea74eca6bc6f1c3cf
extra : intermediate-source : 9557cc7e094367075bd262e4eac8454e610c8f8b
extra : source : 514014bfc85a79590bbc2bd5a8101162637708cc
If there were leading unaligned input elements, then excluding them from the
length count would have led to reading elements beyond the indicated array
length and summing too many squares. In practice, there were no known cases
with leading unaligned input.
This patch also fixes the calculation for the length of the array for
AudioBufferSumOfSquares_SSE(). Previously this length was based on rounding
down the total input array length. The result could be too long if there were
both leading and trailing unaligned input. The length for
AudioBufferSumOfSquares_SSE is now calculated by rounding down the number of
remaining input array elements after leading unaligned elements are excluded.
MozReview-Commit-ID: FFz5RoqUtN0
--HG--
extra : rebase_source : e4ec3d321cbf20dba0d4a91676f52f8308212043
We should be dispatching this event to a tab group so that it can be
associated with it.
MozReview-Commit-ID: FcEQD7cN2Xj
--HG--
extra : rebase_source : fbe7c17439a9434ac1c4702f0dd21e8424a7f0c7
The original duration I wrote is calculated from the m3u8 file this is too accurate without error tolerant.
The state machine will update playback position periodically(UpdatePlaybackPositionPeriodically)
according to the clockTime or max end time from A/Vsink.
So the duration will be variant that I should consider to set the value to a more relaxed value.
MozReview-Commit-ID: GGwkhvzz8sI
--HG--
extra : rebase_source : c0465f7aef7a41e999e8c4c3429957fa56336239
Ryan VanderMeulen
Dan Minor
Sebastian Hengst
Joel Maher
James Cheng
Bill McCloskey
Alastor Wu
Jean-Yves Avenard
JW Wang
Chris Pearce
Wes Kocher
Munro Mengjue Chiang
Phil Ringnalda
Bryce Van Dyk
Samael Wang
Andreas Pehrson
Chris Manchester
Karl Tomlinson
Nils Ohlmeier [:drno]
Alex Chronopoulos
Andreas Farre
bechen@mozilla.com
Kilik Kuo
Jeff Gilbert
Kaku Kuo
Navid
Ralph Giles
Nathan Froyd
Boris Zbarsky
Tim Taubert
Paul Adenot
Alfredo.Yang
Kris Maglione
Chun-Min Chang
Andrew McCreight
Jed Davis
Eric Rahm
John Lin
Gabriele Svelto
Dan Glastonbury
Andrew Halberstadt
David Major
Tom Ritter
Nicholas Hurley
Randell Jesup
Carsten "Tomcat" Book
Tom Prince
Milan Sreckovic
Geoff Brown
Masatoshi Kimura