Re: [rtcweb] Video codec selection - way forward

[Maik Merten <[e-mail]>]

Dear Bernhard,

I'm completely with you regarding that a reliable mechanism for 
multi-codec handling is needed, no matter the outcome of the codec 
discussion. After all, everybody will want to deploy new codec 
technology in the future.

I also think that pressure from customers will eventually lead to 
transcoding services being offered to serve as a bandaid in case no 
consensus can be achieved. I'm saying "bandaid" here, because I suspect 
that in practice such transcoding services will introduce costs (which 
may not be acceptable to new players), increase latency (always not so 
nice), and possibly introduce single points of failure (nasty for 
everyone). Reliance on such services would be a admittance of failure 
regarding P2P interoperability.

(Personally, I would consider it a grave specification bug if users 
cannot reliably establish even a basic, direct video call, with every 
involved entity adhering to the spec and network conditions permitting.)

You're of course right that mandating something without consensus cannot 
possibly be solution. I'm just hoping there's consensus that P2P 
interoperability does matter. From my point of view H.261 is an option 
that can enable (very) basic video interoperability (engineering 
perspective) and also is trouble-free regarding IPR (legal perspective, 
which appears to be what's making consensus on codecs difficult). Having 
a solution that engineers can implement and lawyers can agree to seems 
to be a rare constellation. It's up to implementers to decide if they 
are willing to make use of it to achieve basic interoperability.


Best regards,

Maik



Am 20.11.2013 18:44, schrieb Bernard Aboba:
> Maik said:
>
>  > Cisco's offer, while certainly useful in some (or even many) application
>  > contexts, cannot cover all relevant deployment scenarios.
>
> [BA] I'd note that the current IETF discussion of MTI video codecs is
> somewhat similar to a previous discussion in W3C relating to the MTI
> codec for streaming video.   In that previous discussion, advocates of
> the potential MTI codecs offered to implement their preferred codec for
> other browsers.  So if past is prologue, other offers may emerge over time.
>
>  > Without a fallback codec there will be negotiation failure in ways
> that are out of control of the affected users.
>
> [BA] In practice, negotiation failure is annoying enough that customers
> and users are going to demand that it be addressed in some fashion.
>   This could be via native implementation of multiple codecs, via codec
> plugins as Cisco has proposed, or via on-premise or cloud-based
> transcoding solutions as Justin has described.   Given the penalties
> that the marketplace will impose on services that don't address
> interoperability in some fashion, it seems to me that the issue is very
> likely to be addressed in practice, at least for commercial services.
>
> On the other hand,  attempting to impose a solution that has no real
> consensus could do real damage, by diverting resources away from
> implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the
> WebRTC protocol specifications so as to fully enable multi-codec
> support, which is going to necessary whichever camp you're in.