This allows for decoding VP9 profile 2 and 3.
At this stage, it is not possible to render the decoded frames.
MozReview-Commit-ID: DFXMvaM8Ynb
--HG--
extra : rebase_source : d9a639c2a65b1fd37d44336310af999e420155fe
Use ErrorName() as it provides more useful information for the error detail.
MozReview-Commit-ID: BQUPQGcLd8L
--HG--
extra : rebase_source : 734825c88dfbe79de1e61498dcc24606c50314ee
MediaRawData::mKeyframe is now only set when both the alpha channel and standard channel are keyframes. Causing this assertion to be often false.
MozReview-Commit-ID: 5zYtFNyJSQB
--HG--
extra : rebase_source : 8b49e5e33ad33268185b80d011bcc3c95bed7a15
The NS_LITERAL_CSTRING macro creates a temporary nsLiteralCString to encapsulate the string literal and its length, but AssignLiteral() can determine the string literal's length at compile-time without nsLiteralCString.
MozReview-Commit-ID: F750v6NN81s
--HG--
extra : rebase_source : 714dd78df0f4c33e23e5b117615bd8fd561674c5
extra : source : 742bda9e6b1ddaf34d09894204ad18ce798b79b7
Continuation on bug 1397307 which was incomplete.
MozReview-Commit-ID: JGGHQyjnALI
--HG--
extra : rebase_source : 067652250dcd0904c8436eebc50068c7fb8d8cbb
Only the Windows H264 decoder supports CreateDecoderParam::mError, all the other PDM leave the value untouched.
As such, it can't be assumed that in case of failure, the mError attribute will be set.
MozReview-Commit-ID: GWHGP6Wv3fl
--HG--
extra : rebase_source : 081b71c7a53c41d9a13904e4182e3cfdb876ae43
In some Android ROMs, MediaCodec doesn't allocate additional buffers to reduce
consumer starvation and will not work when MDSM grips most recently returned
frame before rearching seek target. Implement SetSeekThreshold() to get actual
seek target to check if video buffers can be released back to remote decoder
immediately.
MozReview-Commit-ID: 7IetuVxCXc0
--HG--
extra : rebase_source : 8e8643dbde757d41a26de45663a8232b4c66c386
We unfortunately can't store this information in the VideoInfo as typically the framerate isn't found in the container's metadata. Additionally, the VideoInfo object is readable-only as it is shared across threads.
As such, we can only estimate it as we demux samples.
MozReview-Commit-ID: 5HB33ubfGAs
--HG--
extra : rebase_source : 1d6d09da76a99524422b14d50db477a9aa222da0
Automatic conversion (say from int to bool) makes DecoderParam difficult to extend.
MozReview-Commit-ID: G0T7jPogskN
--HG--
extra : rebase_source : 59437fd2b430ccd6be50b18c98b5a5c4ed2c8240
It will allow to blacklist all NVidia Tesla and AMD UVD3 GPU.
MozReview-Commit-ID: LaJqyIj0Yau
--HG--
extra : rebase_source : aa93c4379181e2cb09733f0053de55bf64787ef6
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
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
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
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
This is a practice commit to clarify what arguments we're accepting.
MozReview-Commit-ID: 2qQbNAYzGwr
--HG--
extra : rebase_source : 26527c08c32d79f794601afdd7832fa0ed53ecf7
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
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
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
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
This will allow to modify the string returned later.
MozReview-Commit-ID: Giw1JyukE4v
--HG--
extra : rebase_source : d126b8b956ff1f54c33a838834aee9cc6340de95
MediaPrefs isn't initialised in the GPU process, so use gfxPrefs instead.
MozReview-Commit-ID: CgDSTtVo6GL
--HG--
extra : rebase_source : 7bac527573f8d85c0ea88334c8691d27e95ee53c
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
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
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
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
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 IMFTransform interface used by MFTDecoder is documented to require to run
on an MTA threads:
https://msdn.microsoft.com/en-us/library/windows/desktop/ee892371(v=vs.85).aspx#components
We're currently using IMFTransform objects on the main thread, which is STA.
So delegate calls to the IMFTransform to the MTA thread when necessary, to
ensure it always runs on an MTA thread.
The existing uses of IMFTransform objects in the decode thread pool threads
will be fine, as those threads are already MTA.
We also defer initialization of WMF to the MTA thread, so that we're always
interacting with WMF on an MTA thread.
MozReview-Commit-ID: Dm8XpdvJLkS
--HG--
extra : rebase_source : 0807241c8cdd01c1b99bf946ea4728996ac61f68
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
This function now always returns false (since bug 1253395), so
WMFDecoderModule::HasH264 doesn't need to call it anymore.
Note that we are keeping the code, as we will slightly modify it in the next
patch for a different use.
MozReview-Commit-ID: 7fzktsnFU2m
--HG--
extra : rebase_source : e7538ae792b7c31393079244a286c340d798588d
As well as the obvious #ifdefs, this allows DOMHwMediaStream to be
removed, and also the "phone-state-changed" observer.
--HG--
extra : rebase_source : 373280183e228bd4b9bd9d866959409f2444c77e
It's silly to use prmem.h within Firefox code given that in our configuration
its functions are just wrappers for malloc() et al. (Indeed, in some places we
mix PR_Malloc() with free(), or malloc() with PR_Free().)
This patch removes all uses, except for the places where we need to use
PR_Free() to free something allocated by another NSPR function; in those cases
I've added a comment explaining which function did the allocation.
--HG--
extra : rebase_source : 0f781bca68b5bf3c4c191e09e277dfc8becffa09
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : a96fe0c70416d38690b0c2f1dee567b0b025e947
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : b204723cdbb599d4f0a227871ed28f5da39e9cff
Additionally, we disable hardware decoding on those systems.
MozReview-Commit-ID: 9zzUJ0utqQm
--HG--
extra : rebase_source : 0e7fdaf166a47969338018dea0d5fd9f1efb8d4b
Allow to get rid of the mPendingSample member, making the logic easier to follow.
MozReview-Commit-ID: F7a25p1TP8J
--HG--
extra : rebase_source : 9413f8a685df44b6e93e7382a0eda77dce27056f
The next version of the Widevine CDM (970) has a new H.264 decoder and it does
not appear to be outputing frames it decodes in presentation order, so we need
to reorder the frames output by the CDM.
MozReview-Commit-ID: HMsQVN3NCIU
--HG--
extra : rebase_source : 68ef406556087434fa12b72ae5ed5c2e1bce2b64
The VP9 decoder doesn't properly set the sample duration, leading to all samples being marked as having a zero duration.
The compositor drops those frames incorrectly. This issue will be addressed in bug 1222874.
MozReview-Commit-ID: JQdtTL4nAN
--HG--
extra : rebase_source : 7c69cd3522c4b2231a07ab3f3c1d012843ac2f69
Using a float to store the last duration was unwise (as it has only a 24 bits mantissa), luckily it wasn't used except very particular circumstances.
MozReview-Commit-ID: BpL8ufQFNeR
--HG--
extra : rebase_source : b4a5a1301be4a0a81d1907b6296cbb4b6c4877d9
SupportsMimeType is called in the content process, for which, following bug 1338011, dxva is marked as disabled.
CanCreateWMFDecoder already performs the check of allowing VP9 only if it's hardware accelerated, so we don't need to test if dxva is enabled prior.
MozReview-Commit-ID: 7Jvaop6ZznU
--HG--
extra : rebase_source : 854e7b09718863e710843d11c9327de47abf1076
Prior bug 1313398, the only time we would call H264Converter::CreateDecoderAndInit was if we encountered AVC3 content where the H264 extradata didn't exist in the metadata.
AVC3 was the only situation where mDecoder would be null after construction.
However, now, it is possible for the construction of the decoder to be interrupted, which would leave mDecoder null. For AVC1 content, if this happened, we wouldn't have in-band SPS/PPS necessary for CreateDecoderAndInit to complete.
So we use whichever extradata is available.
MozReview-Commit-ID: 702xj045LAv
--HG--
extra : rebase_source : e85077cedfece066398e36d8a4dd16f4bd406db6
This is a simpler approach required as both InitPromise and FlushPromise are exclusives.
It's in practice simpler too.
MozReview-Commit-ID: ItaAhC0Bk8T
--HG--
extra : rebase_source : 2c68b8843cfccd784bfcf1ae4fd08407ee891349
On android and devices supporting decoder recycling the decoder would be reset for every new sample not containing inband SPS/PPS
MozReview-Commit-ID: 8BHALsDgPvg
--HG--
extra : rebase_source : 11802954ec0dac885d61aebb9983588daff88dc2
When building Fennec using clang, the following build error occurs.
0:17.02 /mozilla/mobile/media/webrtc/signaling/src/media-conduit/WebrtcMediaCodecVP8VideoCodec.cpp:1099:27: error: 'GetNative' is a protected member of 'mozilla::jni::NativeImpl<mozilla::java::CodecProxy::NativeCallbacks, mozilla::JavaCallbacksSupport>'
0:17.02 JavaCallbacksSupport::GetNative(mJavaCallbacks)->Cancel();
0:17.02 ^
0:17.02 /mozilla/objdir-android/dist/include/mozilla/jni/Natives.h:821:18: note: declared protected here
0:17.02 static Impl* GetNative(const typename Cls::LocalRef& instance) {
0:17.02 ^
We should define GetNative as public into JavaCallbacksSupport.h.
MozReview-Commit-ID: DYEyB2dRK8y
--HG--
extra : rebase_source : 8f77cac02800149aef814ce5fcd7bd3d23b56193
Update our in-tree copy of the aom reference implementation
of the av1 video codec to upstream git commit id
aadbb0251996c8ebb8310567bea330ab7ae9abe4.
This picks up recent changes and addresses a build issue on win64.
MozReview-Commit-ID: 34LXXzFtEFN
--HG--
extra : rebase_source : 0face926928de6bd1c6a1726df912bd20e363e60
Upstream has removed the requirement to set this when
initializing the stream_info struct.
MozReview-Commit-ID: 24OJ550Ral
--HG--
extra : rebase_source : 501fd9f51084a4b6f779462536e94c71cf8c5bb7
If the pending first frame decoding was cancelled, the next call to decode could lead to a crash.
MozReview-Commit-ID: 6Q4eKUzqOly
--HG--
extra : rebase_source : 3640a2edd07fdbd4811295c0088a4086ac579b26
If the pending first frame decoding was cancelled, the next call to decode could lead to a crash.
MozReview-Commit-ID: 6Q4eKUzqOly
--HG--
extra : rebase_source : 620efb39265944998c23c184e831a5b71f9b437f
We enable by default the VP9 hardware decoder on intel GPU.
MozReview-Commit-ID: FzMzbpZErjQ
--HG--
extra : rebase_source : f34c969f7dda1ef24224e982f31d5e43cfae7cc0
When av1 video playback is enabled, declare it as supported
in the webm container in MediaSource.IsTypeSupported.
Also support special mime types of the form
video/webm; codecs=vp9.experimental.<git-commit-id>
so test sites can verify playback support of particular encodings
while the av1 bitstream is under development.
MozReview-Commit-ID: GS4n7cPxfQ7
--HG--
extra : rebase_source : a595942242304ccf97a341474b6e2e1e869e7a77
On android, where decoders can sometimes be recycled, the h264converter can be fed over its lifetime MediaRawData with different mExtraData.
So we need to ensure that not only, the inband ones don't change, but that the out of band one hasn't changed either.
This is a condition we could totally ignore on desktop, as when the resolution change the H264Converter is destroyed.
MozReview-Commit-ID: 7w6ku6by1Qi
--HG--
extra : rebase_source : d35f07b372ef0623dbd74384aa5d3a865a3e067a
The value never changes on a system, so there's no point checking it every single time
MozReview-Commit-ID: KTSslluQsKw
--HG--
extra : rebase_source : 40274727d0e7202087a8282eedb2c78404212f31
The format member isn't set when an audio frame hasn't been decoded yet.
MozReview-Commit-ID: IgUj6bjVzdF
--HG--
extra : rebase_source : bb47fa523384f9a85ee7d0ed5b6de4fe2c73526a
This works around an Android 4.2.2 bug that reports incorrect sizes for hardware buffers.
MozReview-Commit-ID: 4rAu8d1RwOJ
--HG--
extra : rebase_source : f63ad96427b90dc24e0cb84319f256d1ec354b5e
The duration is rounded down to 0 if |frames| is smaller than |mInfo.mRate|.
We should call FramesToTimeUnit() instead.
MozReview-Commit-ID: E7eOQuD48x2
--HG--
extra : rebase_source : 1edabb9a9fe495f89a13df71d73d3b9aef49fa9d
This was working because of the unified build, but passing
--enable-av1 changed the source partitioning in such a way
that the referenced defines and symbols were no longer available.
MozReview-Commit-ID: CRjyhLtOhoM
--HG--
extra : rebase_source : bce3810fcff39669c4578f1b545fb619be691e38
Since RefPtr<T>&& can't be converted to T* implicitly, we need to change
T* to RefPtr<T> in resolve/reject callbacks to make it compile again.
We should review the changes later to look for the opportunity to
optimize away unnecessary AddRef/Release pairs.
MozReview-Commit-ID: 22rHQ8dhxJv
--HG--
extra : rebase_source : 1b09f353d6e86d60c93a2746333585ec0dba8526
Conditionally enable the AV1 decoder as part of the
agnostic PlatformDecoderModule factory.
MozReview-Commit-ID: ApZ1CMvdLE
--HG--
extra : rebase_source : 33cedc6bd6243ccd2019ea40dc9b989921c63b98
Port the VPXDecoder interface to libaom which uses
the same api with the names changed. I've removed
the alpha support for now.
MozReview-Commit-ID: IdxcVWhNgVl
--HG--
extra : rebase_source : 5f3a84fb9a827f01c80057eb520bde184c41f0b9
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : e0a27e946a60e0c33ecf4908f1e09436f836e123
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : fc7769c9650c59f52bfd8611e6cabb8e5b6d7068
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: LRz9d4yKBYJ
--HG--
extra : rebase_source : 1f73f1f338142b3183491d04726821a881ccabbe
extra : intermediate-source : 88e167b7b06303d10d92cd5317502f405d1c553e
extra : source : 98deb30ec93d395f9951f5fc488170ae35e29675
Encapsulate code from WebMDemuxer to query keyframe and frame
resolution inside VPXDecoder, so we have a clean wrapper for
all the libvpx functions we use.
MozReview-Commit-ID: ASRRhNl0A41
--HG--
extra : rebase_source : a1421462f6fc66a2abd965782ec408a8bcf7fe1f
Use the enum we already have here instead of converting
to an int when we pass it around, giving us better
type checking.
MozReview-Commit-ID: Gj4xmtQnzw2
--HG--
extra : rebase_source : 95f582e655f1a942dfb68cbba588c44afbb8a38f
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
