Re: [rtcweb] A different perspective on the video codec MTI discussion

[Cameron Byrne <[e-mail]>]

On Wed, Mar 13, 2013 at 9:18 PM, Daryl Malas <[e-mail]> wrote:
> I would like to add my support to Jonathan's comments.  I have had
> discussions with multiple cable operators, which are evaluating the
> potential use cases of deploying webRTC.  The resounding comment is that if
> webRTC supports H.264, their flexibility to deploy it in the near-term on a
> number of devices improves dramatically.  If VP8 is the only allowable
> codec, this will significantly limit the deployment, because the relevant
> devices out there already support H.264 and not VP8.
>

You can negotiate any codec you want
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03#section-3.2

There is now limitation on the number of codecs that you may support.

I hope this helps.

CB

ps.  my position remains that the idea of MTI needs be dropped,
consensus will not be found.  Let the market figure it out.


> In addition, by saying that we will only support a royalty-free codec (VP8),
> it is effectively saying we will not allow people to pay the necessary
> license fees (whether new or already realized) at their choosing in order to
> deploy more webRTC clients and further the overall adoption of webRTC.
>
> Does it really increase the complexity so dramatically by supporting two
> video codecs that it outweighs the potential for faster adoption and
> deployment of webRTC?
>




> I also second Jonathan's comments related to, "I applaud your efforts and
> thank you for them."  This is absolutely valuable from my perspective, and
> it has great potential for future use.
>
> Regards,
>
> Daryl
>
> From: Jonathan Rosenberg <[e-mail]>
> Date: Wednesday, March 13, 2013 6:06 PM
> To: "[e-mail]" <[e-mail]>
> Subject: [rtcweb] A different perspective on the video codec MTI discussion
>
> I’d like to put a different perspective on the video MTI discussion.
>
> Much of the discussion has been around video quality, IPR, and
> standardization status. While those are all important factors, to me they
> are secondary to the core question: how does the choice impact uptake of the
> webRTC APIs and protocols by developers who build applications ontop of it?
> In this regard, I would like to suggest that, at this time, adoption of VP8
> as MTI will slow down adoption of webRTC by turning off developers that
> would otherwise embrace it if H.264 were selected.
>
> The reason is simple. For many application developers, what is interesting
> about webRTC is NOT just browser to browser communications, but connecting
> users in a browser to users elsewhere - on other devices, in other networks.
> After all, the vast majority of web application developers do not have the
> luxury of a massive social graph, or the luxury of their users being parked
> persistently on their website and thus able to receive an incoming call.
> Many websites that have customer support or service needs would love to be
> able to allow their users to have a video call with an agent. However, those
> agents are probably sitting on existing agent systems which are not web
> based, and it’s almost certainly true that they do not today support VP8,
> but rather H.264. Many developers would probably love to connect users on
> the web with users on mobile apps. Most mobile platforms today support H264
> based hardware acceleration for decode and sometimes encode, but not yet
> VP8. Developers who want to build business communications clients will need
> to connect those users with other users in the business, who may be using
> videophones, PC clients, telepresence units or video room systems, the vast
> majority of which do not support VP8 today, but many of which do support
> H.264.
>
> The reality is – today’s Internet and IP communications systems are built on
> H.264. And unless the developer cares only about living within the island of
> the web browser – a VP8 based solution will simply not meet their
> requirements.
>
> This may not be true down the road. I applaud Google for working hard (and
> spending much money no doubt) to secure an RF license for VP8 from these
> patent holders. I think they should continue pushing and promoting the
> technology because a  free, high quality video codec would be great for the
> Internet. But today, it is not the video codec of the Internet. And, given
> the relatively early days of video, I am sure there will be video codecs
> after VP8. Maybe H.265, maybe the new video codec being developed here at
> the IETF. And once those codecs become more broadly implemented and
> available on the endpoints that matter, we can revise our specs and mandate
> support for them. But this is not about the web of five years from now, its
> about the web today. And if we mandate usage of a codec which is not widely
> implemented in all the endpoints that matter (not just the browser), I fear
> that it will hold developers back from using webRTC and thus prevent us from
> ever having the opportunity to add these video codecs in the future.
>
>
>
> And so – to the supporters of VP8 – I applaud your efforts and thank you for
> them. Please continue. And when the industry is ready, we can make VP8 MTI
> in the browser. But we are not there yet.  I ask you to please put the needs
> of the developers ahead of your own, and do not hold back webRTC for the
> benefit of your ideals around an RF and open source video codec. WebRTC is
> too important for that.
>
> I have one more thing to say - speaking now as a developer.
>
> As some of you may know, I recently returned to Cisco as CTO of the cloud
> collaboration group, which is responsible for Webex. Webex was one of the
> first services to do voice and video on the web, using plugins of course.
> For our business, a key requirement is interoperability with other video
> systems in the Cisco portfolio, including our video clients and telepresence
> units. Those are all based on H.264. Consequently, much as I would like to
> avoid the need for a plugin, the benefits of eliminating the plugin do not
> outweigh the drawbacks of having to transcode from VP8 to H.264. If IETF
> selects VP8 as the MTI codec, this will make it dramatically more difficult
> and expensive for us to use webRTC. If H.264 is the MIT codec, it will make
> it much easier for us to use webRTC.
>
>
> Thx,
>
> Jonathan R.
>
> --
> Jonathan Rosenberg, Ph.D.
> [e-mail]
> http://www.jdrosen.net
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>