It of course makes sense for iOS and devices that can support hardware acceleration, but device mix can change during a call. So, what happens if two iOS users start, but then they add a VP8 only device? How Twilio handles that use case will be instructive for understanding what use cases we can support with this service.
It isn't likely they are transcoding since this intro suggests a P2P architecture without distributed media servers, and we know H.264/VP8 is very expensive video transcoding - e.g. many media server vendors don't get more than one transcode per core at full HD.
I just added h264 to jumpchat on ios and android. Say A(iOS) talks to B(Android). They both support h264, they negotiate to use h264. C(chrome) joins. A triangle connection is setup where A will talk to B using h264. A & B will talk to C in VP8. It's kind of taxing on mobile when this happens.
I can't speak with any real authority here but... WebRTC requires the two end points of the connection swap information for networking and things like what codecs they support. I don't believe the MediaStreams between a->b and a->c would have anything to do with each other. They only share a common VideoSource. That would lead me to believe that it would try to encode two different ways if that was the only option. More than likely you'd probably have the vendor select a preferred single codec instead of doing things differently for each user, though that would be pretty neat if it wasn't too resource intensive.
Transcoding is expensive, but with VP8, depending on the codec parameters, you can 'strip down' the stream for less-performant clients e.g. phones, while sending the full-fidelity version to other clients. Without decoding, just by dropping certain classes of packets. There is a loss of resolution of course. So anyway that's an option.
It of course makes sense for iOS and devices that can support hardware acceleration, but device mix can change during a call. So, what happens if two iOS users start, but then they add a VP8 only device? How Twilio handles that use case will be instructive for understanding what use cases we can support with this service.
It isn't likely they are transcoding since this intro suggests a P2P architecture without distributed media servers, and we know H.264/VP8 is very expensive video transcoding - e.g. many media server vendors don't get more than one transcode per core at full HD.