Summary: | iPadOS 15 / iOS 15 unable to decode VP9 stream | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dan Jenkins <dan> | ||||||||||
Component: | WebRTC | Assignee: | youenn fablet <youennf> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | dan, eric.carlson, jer.noble, olena.bezkrovna, sergio.garcia.murillo, webkit-bug-importer, youennf | ||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||
Version: | Other | ||||||||||||
Hardware: | iPhone / iPad | ||||||||||||
OS: | Other | ||||||||||||
Attachments: |
|
Description
Dan Jenkins
2021-09-22 01:54:36 PDT
Could you please confirm if this is new to iOS 15? Did this work in prior versions of iOS? yes, it is happening on latest iOS 15 version, can't tell about earlier versions, but vp9 support was meant to be a new feature on iOS 15 (AFAIK) Created attachment 439144 [details]
Patch
Youenn can you confirm if its just ipads that use hardware decode and not iphones? This is the line from the release notes for 15 that caused me to think that... Added hardware accelerated VP9 and WebM in MSE on all iPads that support iPadOS 15. So turns out some ipads running ipadOs 15 don't support hardware accelerated decoding of vp9? But they can encode it fine? If its just iPads that support hardware acceleration does that mean iphones are doing software based encode/decode and if thats the case would we expect older iPads to use software decode? Just looking for some clarification seeing as I don't fully understand the patch you've proposed :) thanks! Created attachment 439148 [details]
Patch
Comment on attachment 439148 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=439148&action=review r=me once the bots are happy > Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:249 > + static bool hasGPUProcessHardwareVP9; > + static std::once_flag onceFlag; > + std::call_once(onceFlag, [] { > + WebProcess::singleton().ensureGPUProcessConnection().connection().sendSync(Messages::LibWebRTCCodecsProxy::HasVP9Decoder { }, Messages::LibWebRTCCodecsProxy::HasVP9Decoder::Reply(hasGPUProcessHardwareVP9), 0); > + }); > + WebProcess::singleton().libWebRTCCodecs().setVP9VTBSupport(hasGPUProcessHardwareVP9); Instead of doing this as a synchronous message, could we push the state back from the GPUConnectionToWebProcess when it opens? Created attachment 439149 [details]
Patch
Created attachment 439349 [details]
Patch
(In reply to Eric Carlson from comment #7) > Comment on attachment 439148 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=439148&action=review > > r=me once the bots are happy > > > Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp:249 > > + static bool hasGPUProcessHardwareVP9; > > + static std::once_flag onceFlag; > > + std::call_once(onceFlag, [] { > > + WebProcess::singleton().ensureGPUProcessConnection().connection().sendSync(Messages::LibWebRTCCodecsProxy::HasVP9Decoder { }, Messages::LibWebRTCCodecsProxy::HasVP9Decoder::Reply(hasGPUProcessHardwareVP9), 0); > > + }); > > + WebProcess::singleton().libWebRTCCodecs().setVP9VTBSupport(hasGPUProcessHardwareVP9); > > Instead of doing this as a synchronous message, could we push the state back > from the GPUConnectionToWebProcess when it opens? Good idea, updated the patch accordingly > So turns out some ipads running ipadOs 15 don't support hardware accelerated
> decoding of vp9? But they can encode it fine? If its just iPads that support
> hardware acceleration does that mean iphones are doing software based
> encode/decode and if thats the case would we expect older iPads to use
> software decode?
All iOS devices support VP9 encoder in WebRTC using libvpx.
Most iOS devices support VP9 decoder via VTB, but not all, in which case we rely on libvpx.
makes sense, thanks for the clarification Youenn! Committed r283116 (242174@main): <https://commits.webkit.org/242174@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 439349 [details]. *** Bug 231074 has been marked as a duplicate of this bug. *** |