[RTW] Gateways and does anyone think "H.264 for ever"?

[Aron Rosenberg]

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.

-Aron

Aron Rosenberg
Sr. Director, Engineering
Logitech Inc. (SightSpeed Group)



On Fri, Jan 7, 2011 at 10:02 AM, Henry Sinnreich
<henry.sinnreich at gmail.com>wrote:

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