Theora is not a valid choice for a video chat/conferencing codec. It has far too much internal delay and doesn't come close to the real-time performance of vp8/libvpx or H.264.<div><br></div><div>-Aron<br clear="all"><div>

<br></div><div>Aron Rosenberg</div><div>Sr. Director, Engineering</div><div>Logitech Inc. (SightSpeed Group)</div><br>
<br><br><div class="gmail_quote">On Fri, Jan 7, 2011 at 10:02 AM, Henry Sinnreich <span dir="ltr"><<a href="mailto:henry.sinnreich@gmail.com">henry.sinnreich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Though gateways are a key component in the web architecture and critical<br>
indeed for connectivity with other networks, I believe the scope as outlined<br>
here by Harald is the correct first step.<br>
<br>
As for interoperability at the video codec level, several items have to be<br>
balanced<br>
<br>
1. The benefits for users (includes cost and performance) first and foremost<br>
2. Give a chance to new and free codec technologies such as VP8 or Theora<br>
3. Interoperability with existing H.264 based systems<br>
<br>
Or does anyone think "H.264 for ever"?<br>
<br>
Thanks, Henry<br>
<br>
<br>
On 1/7/11 11:38 AM, "Elwell, John" <<a href="mailto:john.elwell@siemens-enterprise.com">john.elwell@siemens-enterprise.com</a>><br>
wrote:<br>
<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: Harald Alvestrand [mailto:<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>]<br>
>> Sent: 07 January 2011 14:25<br>
>> To: Elwell, John<br>
>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;<br>
>> <a href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</a>; <a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
>> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:<br>
>> New Version Notification for<br>
>> draft-alvestrand-dispatch-rtcweb-protocols-00)<br>
>><br>
>> On 01/07/11 14:41, Elwell, John wrote:<br>
>>><br>
>>><br>
>>>> -----Original Message-----<br>
>>>> From: Harald Alvestrand [mailto:<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>]<br>
>>>> Sent: 07 January 2011 13:07<br>
>>>> To: Elwell, John<br>
>>>> Cc: Stephen Botzko; Henry Sinnreich; Bernard Aboba;<br>
>>>> <a href="mailto:rtc-web@alvestrand.no">rtc-web@alvestrand.no</a>; <a href="mailto:dispatch@ietf.org">dispatch@ietf.org</a><br>
>>>> Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd:<br>
>>>> New Version Notification for<br>
>>>> draft-alvestrand-dispatch-rtcweb-protocols-00)<br>
>>>><br>
>>>> On 01/07/11 10:56, Elwell, John wrote:<br>
>>>>> I also agree that codecs such as H.264 AVC need to be<br>
>>>> considered, because of interworking with non-RTC-web users,<br>
>>>> conference bridges, etc.. An important part of the proposed<br>
>>>> charter is:<br>
>>>>> "* interoperate with compatible voice and video systems<br>
>>>> that are not web<br>
>>>>> based"<br>
>>>> This can turn out to be seriously problematic if we don't<br>
>>>> constrain it<br>
>>>> carefully - when we wrote this, my thinking was that it meant "if<br>
>>>> devices send and receive media in formats that we support,<br>
>>>> and the setup<br>
>>>> is performed in a reasonable way through intermediaries,<br>
>> we should be<br>
>>>> able to send media directly to them".<br>
>>>><br>
>>>> I see the use case that we *have* to support as the<br>
>>>> browser-to-browser<br>
>>>> use case. If we are able to support other use cases too, that<br>
>>>> is a good<br>
>>>> thing, but very much a lower priority to me. Opinions may differ.<br>
>>> [JRE] I disagree. I believe the ability to work with<br>
>> non-RTP-web users is equally important. Take enterprises for<br>
>> example - they don't want a flag day when every user changes<br>
>> to RTP-web at the same time - they need to migrate users at a<br>
>> convenient pace.<br>
>> We have the same situation today when people migrate off PABXes onto<br>
>> either VOIP-phones or onto mobile phones; the answer in those cases<br>
>> seems to be gateways. Why wouldn't that work in this case?<br>
>>> One of the benefits of reusing existing protocols such as<br>
>> RTP is that interworking with non-RTP-web users and other<br>
>> equipment (such as MCUs) should be feasible. But this also<br>
>> means using appropriate codecs, to avoid having to insert transcoders.<br>
>> Can you be more specific about what devices you're thinking<br>
>> of, and how<br>
>> many of them there are?<br>
>> In particular, which devices do you expect to see that don't support<br>
>> RTCWeb, but do support STUN?<br>
> [JRE] It is true that a lot of existing devices do not support STUN, and rely<br>
> on intermediaries (SBC) to achieve NAT traversal. However, those<br>
> intermediaries could be made to mediate between RTC-Web devices and other<br>
> devices. Getting those intermediaries to handle STUN on the RTC-Web side is<br>
> feasible - getting them to do transcoding, particularly for video, is an<br>
> entirely different matter. So in other words, it depends how much<br>
> functionality we are prepared to put into the gateway.<br>
><br>
> John<br>
><br>
><br>
><br>
>><br>
>>                         Harald<br>
>><br>
<br>
<br>
_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
</blockquote></div><br></div>