There are also some implications on the capture pipeline side of things in order to support pixel formats other than NV12 without un-necessary conversions.Īs for HEVC, it looks like Safari will start with H.264 support since it is based upon Chromium's WebRTC implementation.
#Iphone video codec how to
We are still considering how to offer this feature to developers (possibly as an opt-in to start, becoming the default in scenarios where it performs well).
The first place we would like to use H.264 is in 1:1 Peer-to-Peer Rooms. It's possible for other apps and/or Airplay to use them in parallel with your video app. One thing to note though, is that hardware H.264 encoders and decoders are a limited resource. I don't think we will be using the software VP9 encoder any time soon on iOS as the performance is pretty poor, but H.264 provides some significant performance wins. We have been testing VP9, and H.264 internally and generally agree with your assessment. I realize that cross-platform support for these different encodings may be more difficult, but is it possible that you could allow them as opt-in via SDP? It also can save ~20% network bandwidth over main profile h.264. H.264 high profile is also available in iOS WebRTC by toggling a field trial flag at runtime, and in my tests performed well all the way down to A6 processor (iPhone 5 and 5C), and perhaps older. H.264 main profile is standard and performs reasonably well and similar to VP8, but with reduced CPU strain and power consumption. VP9 is an optional compilation flag when building WebRTC for iOS, but I could not get it to perform well on anything but an A10 ↔ A10 processor call due to software decoding, borderline on A9 calls. Ooof! I am disappointed with vanilla WebRTC performance on iOS, and was looking to try the Twilio SDK instead, but VP8 software decoding is a bit of a blocker for my use case (I have a lot of chrome and other CPU intensive processes going on during video calls.)