Subject: [rtcweb] Comment on Straw Poll replies

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 10 Jan 2014 21:02:44 +1100

Recently there have been a whole bunch of replies that only accepted
option 1 with the singluar rationale that it's the only option to
provide interop with legacy networks.

1.     All entities MUST support H.264
a.     Are you in favor of this option [Yes/No/Acceptable]: YES

2.     All entities MUST support VP8
a.     Are you in favor of this option [Yes/No/Acceptable]: NO
b.    Do you have any objections to this option, if so please
summarize them: interoperability with legacy networks

[all others are NO]

All these people do not want a new technology, but only want more of
what they already have.

Can I ask why you even bother with WebRTC, if you want to restrict
WebRTC to interoperability with old systems only and therefore to old
features only?

I'd like to suggest that such replies should be disregarded because
they look backwards and not forwards.

Best Regards,
Silvia.

---

From: <[email-masked]>
Date: Fri, 10 Jan 2014 14:54:36 +0000

>>Can I ask why you even bother with WebRTC, if you want to restrict WebRTC to interoperability with old systems only and therefore to old features only?
>>I'd like to suggest that such replies should be disregarded because they look backwards and not forwards.

I don't think that disregarding replies is a constructive way forward.

However if you want to go that way, and if you want to get rid of old technologies, let's start by disregarding replies from those who could live with a WebRTC technology that would specify H.261 as only  MTI codec.
Given your concerns about "old" systems and "od" features, I'm a little bit surprised that your are part of them.
http://www.ietf.org/mail-archive/web/rtcweb/current/msg10798.html
(note that there is G.711 for audio but NOT as ONLY MTI codec)

Best regards

Stéphane

-----Message d'origine-----
De : rtcweb [mailto:[email-masked]] De la part de Silvia Pfeiffer
Envoyé : vendredi 10 janvier 2014 11:03
À : [email-masked]
Objet : [rtcweb] Comment on Straw Poll replies

Recently there have been a whole bunch of replies that only accepted option 1 with the singluar rationale that it's the only option to provide interop with legacy networks.

[all others are NO]

All these people do not want a new technology, but only want more of what they already have.

Can I ask why you even bother with WebRTC, if you want to restrict WebRTC to interoperability with old systems only and therefore to old features only?

I'd like to suggest that such replies should be disregarded because they look backwards and not forwards.

Best Regards,
Silvia.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: cowwoc <[email-masked]>
Date: Fri, 10 Jan 2014 11:15:56 -0500

I am equally frustrated. People voting for one option (or multiple 
options that are equivalent) makes it impossible to find a compromise. 
The point of this exercise is to find a *compromise* that suits 
*everyone*, not just wrap your existing products in WebRTC for marketing 
purposes.

Gili

---

From: Maik Merten <[email-masked]>
Date: Fri, 10 Jan 2014 17:20:43 +0100

> I don't think that disregarding replies is a constructive way forward.

As far as I can tell, this is a poll to collect opinions on the various 
options that are on the table and I'm optimistic every opinion will be 
noted. Given this is a *straw* poll, every reply will be disregarded in 
the sense of this *not* being decision-making. ;-)

> However if you want to go that way, and if you want to get rid of old technologies, let's start by disregarding replies from those who could live with a WebRTC technology that would specify H.261 a…

As far as I recall, most people who said they could live with options 
that include "safe to implement" legacy codecs also voiced support for 
having at least one high performance codec (i.e., H.264 or VP8). If I 
read things correctly most people who went this road are not 
enthusiastic regarding old coding technology, but are willing to accept 
that compromise for the sake of finding an interoperable solution that 
can be implemented by everyone.

If I understand correctly, Silvia's point is that the "H.264, or 
nothing" camp seems to be significantly less willing to commit to such a 
compromise, employing arguments regarding interoperability with 
pre-webrtc systems, while one perhaps could argue that a) ensuring 
interoperability between designed-for-webrtc systems is already hard 
enough and b) that legacy systems should not block making progress 
regarding interoperability of designed-for-webrtc systems.

This is, of course, merely my interpretation.

Best regards,

Maik

---

From: cowwoc <[email-masked]>
Date: Fri, 10 Jan 2014 11:39:11 -0500

> (note that there is G.711 for audio but NOT as ONLY MTI codec)

This is a fallacy. No one is arguing that you should be stuck with using 
*just* H.261. What we are saying is that: if H.264 or VP8 are available 
on both end-points, great. If not, you can either:

  * Use H.261, or
  * Transcode, or
  * Drop Video

By eliminating H.261 as MTI, you lose the first option and are forced to 
either transcode or drop video. The cost to supporting H.261 is as 
simple as compiling https://github.com/Vproject/p64 and popping it on 
your device. You don't need hardware support because it's so 
computationally cheap.

And finally, we're not objecting to the use of H.264, per se, but rather 
to the fact that the majority of people who vote for it and against 
everything else use "legacy interoperability" as argument.

WebRTC is a *new* technology. If all we wanted to do was to support 
*existing* devices then we would use *existing* technologies. For that 
reason, I don't think maintaining backwards compatibility is important 
when breaking it has a noticeable benefit (and in this case, I believe 
it does).

Alternatively, please convince MPEG-LA to make H.264 available royalty-free.

Gili

---

From: Hervé W. <[email-masked]>
Date: Fri, 10 Jan 2014 20:00:05 +0100

On 10 January 2014 17:39, cowwoc <[email-masked]> wrote:
> Can I ask why you even bother with WebRTC, if you want to restrict WebRTC to
> interoperability with old systems only and therefore to old features only?
> However if you want to go that way, and if you want to get rid of old
> technologies, let's start by disregarding replies from those who could live
> with a WebRTC technology that would specify H.261 as only  MTI codec.
> *just* H.261. What we are saying is that: if H.264 or VP8 are available on
> both end-points, great. If not, you can either:
>
> Use H.261, or
> Transcode, or
> Drop Video
>
> either transcode or drop video. The cost to supporting H.261 is as simple as
> compiling https://github.com/Vproject/p64 and popping it on your device. You
> don't need hardware support because it's so computationally cheap.

Note: https://github.com/Vproject/p64 (master) is currently 2 commits
behind https://github.com/maikmerten/p64 (master)

> And finally, we're not objecting to the use of H.264, per se, but rather to
> the fact that the majority of people who vote for it and against everything
> else use "legacy interoperability" as argument.
>
> reason, I don't think maintaining backwards compatibility is important when
> breaking it has a noticeable benefit (and in this case, I believe it does).
>

+1

- Hervé

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jan 2014 11:18:25 -0800

> if you want to restrict

My impression is that the above point could indicate a very basic  point 
of confusion amongst a number of participants.

The issue is the difference between minimal, guaranteed 
interoperability, versus maximum possible capabilities.

The statement seems to be concerned about permitting maximum 
capabilities, whereas Mandatory to Implement is usually for ensuring the 
first goal of basic interoperability.

That is, it seeks to ensure that any two participants can achieve basic, 
useful interoperation.  When there is a negotiation mechanism, that is 
the way to then get mutual agreement to do something more capable.

Whether to interoperate with legacy systems is a common, strategic 
decisions.  It is hugely important and often affects success of an effort.

On the average, Internet protocols have tended to try quite hard to 
permit interoperation with legacy systems, where possible.  This has 
often been a challenge, and often has slowed down adoption of newer 
features.  These hassles are balanced against getting a larger base of 
initial users more easily.

The problem with ignoring the installed base of legacy users is the 
danger that they will continue using their legacy services and not 
switch to the wonderful new service.  Creators of wonderful new services 
often underestimate the switching barrier that impedes those legacy users.

By contrast, defining things in a way that is friendly to legacy users, 
while permitting a negotiation path to higher capabilities, is often 
successful at seducing those users, over time, to try out the more 
capable features.

Unless I've entirely misunderstood the design of webRTC, the intent is 
(or can be and should be) to support basic, legacy interoperation, while 
permitting negotiation up to newer and more wonderful capabilities.

For that model, what's most important about the core MTI requirements is 
that they permit maximum degree of interoperability; where possible that 
should include legacy systems.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 11 Jan 2014 11:26:29 +1100

options that are on the table and I'm optimistic every opinion will be
noted. Given this is a *straw* poll, every reply will be disregarded in the
sense of this *not* being decision-making. ;-)
that include "safe to implement" legacy codecs also voiced support for
having at least one high performance codec (i.e., H.264 or VP8). If I read
things correctly most people who went this road are not enthusiastic
regarding old coding technology, but are willing to accept that compromise
for the sake of finding an interoperable solution that can be implemented
by everyone.
>
> If I understand correctly, Silvia's point is that the "H.264, or nothing"
camp seems to be significantly less willing to commit to such a compromise,
employing arguments regarding interoperability with pre-webrtc systems,
while one perhaps could argue that a) ensuring interoperability between
designed-for-webrtc systems is already hard enough and b) that legacy
systems should not block making progress regarding interoperability of
designed-for-webrtc systems.
> This is, of course, merely my interpretation.

Yes, that's exactly what I meant.

Thanks,
Silvia

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 11 Jan 2014 11:39:41 +1100

Thanks for the thoughtful reply. I was indeed trying to understand
motivation and not start a flame war.

I can see where you're coming from. Backwards interoperability is an
important feature of protocols in the networking world when you're trying
to extend a protocol, e.g. from http1.1 to http2. But even here we
sometimes break with the past, e.g. token ring is not compatible with
Ethernet and the compatibility is via a different layer.

I'd just like to make sure progress on webrtc is not stalled by trying to
stay backwards compatible with technology/application situations that
webrtc doesn't actually target.

Best Regards,
Silvia.
On 11 Jan 2014 06:20, "Dave Crocker" <[email-masked]> wrote:

> The issue is the difference between minimal, guaranteed interoperability,
> versus maximum possible capabilities.
>
> The statement seems to be concerned about permitting maximum capabilities,
> whereas Mandatory to Implement is usually for ensuring the first goal of
> basic interoperability.
>
> useful interoperation.  When there is a negotiation mechanism, that is the
> way to then get mutual agreement to do something more capable.
>
> On the average, Internet protocols have tended to try quite hard to permit
> interoperation with legacy systems, where possible.  This has often been a
> challenge, and often has slowed down adoption of newer features.  These
> hassles are balanced against getting a larger base of initial users more
> easily.
>
> The problem with ignoring the installed base of legacy users is the danger
> that they will continue using their legacy services and not switch to the
> wonderful new service.  Creators of wonderful new services often
> underestimate the switching barrier that impedes those legacy users.
>
> successful at seducing those users, over time, to try out the more capable
> features.
>
> Unless I've entirely misunderstood the design of webRTC, the intent is (or
> can be and should be) to support basic, legacy interoperation, while

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Jan 2014 17:04:26 -0800

> motivation and not start a flame war.

Note that my response carefully removed references to you.  My concern 
wasn't about your posting but rather an issue that I believe it 
represents that is more general.

> important feature of protocols in the networking world when you're
> trying to extend a protocol, e.g. from http1.1 to http2. But even here
> we sometimes break with the past, e.g. token ring is not compatible with

Actually, token ring technology and ethernet were developed in parallel. 
  (Irvine Ring[1] - 1974, versus Parc Ethernet - 1975-ish.)  And 
Ethernet is a particularly intriguing example, since what is called 
Ethernet today is an interface standard, althought the underlying 
electrical stuff underneath is nothing like the original.

My general point is that deciding to be compatible with an installed 
base or deciding to be incompatible is massively important and needs to 
be done very thoughtfully and, I believe, very cautiously.

The fact that there is a significant constituency that wants to have 
webRTC support the installed base of legacy is important.  Rejecting 
that desire needs to have very strong justification, IMO.

> I'd just like to make sure progress on webrtc is not stalled by trying
> to stay backwards compatible with technology/application situations that

Again, what can seem like a barrier to progress can actually turn out to 
facilitate it, by seducing the installed base into a familiar 
environment that /also/ offers more capability.

I always invoke email for this sort of example.  (Such a surprise.)

Dumb, textual Arpanet mail was going along through the 70s and 80s, with 
everyone knowing that multi-media mail would be much better.  There were 
numerous attempts to define and deploy it, to replace the embarassingly 
limited textual Arpanet mail.  Some proprietary efforts had success, but 
all of the public ones.  In the case of X.400, the failure was 
protracted, expensive and globally spectacular.  (Please don't look 
inside MS Exchange server code...)

MIME gave the world a successful multi-media email capability 
specifically by preserving the installed base and building upon it. MIME 
mail is text, as far as any mail handling agent needs to know. Only the 
author and the recipient needed to adopt MIME.

The power of building up from the legacy base, rather than seeking to 
replace it, is really quite remarkable.

d/

[1] 
http://www.historyofcomputercommunications.info/Book/6/6.6-TokenRingDavidFarberIrvineNSF69-74.html

[2]  http://inventors.about.com/library/weekly/aa111598.htm

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 11 Jan 2014 12:15:20 +1100

> Note that my response carefully removed references to you.  My concern
wasn't about your posting but rather an issue that I believe it represents
that is more general.
> Actually, token ring technology and ethernet were developed in parallel.
 (Irvine Ring[1] - 1974, versus Parc Ethernet - 1975-ish.)  And Ethernet is
a particularly intriguing example, since what is called Ethernet today is
an interface standard, althought the underlying electrical stuff underneath
is nothing like the original.
>
> My general point is that deciding to be compatible with an installed base
or deciding to be incompatible is massively important and needs to be done
very thoughtfully and, I believe, very cautiously.
> The fact that there is a significant constituency that wants to have
webRTC support the installed base of legacy is important.  Rejecting that
desire needs to have very strong justification, IMO.
> Again, what can seem like a barrier to progress can actually turn out to
facilitate it, by seducing the installed base into a familiar environment
that /also/ offers more capability.
everyone knowing that multi-media mail would be much better.  There were
numerous attempts to define and deploy it, to replace the embarassingly
limited textual Arpanet mail.  Some proprietary efforts had success, but
all of the public ones.  In the case of X.400, the failure was protracted,
expensive and globally spectacular.  (Please don't look inside MS Exchange
server code...)

Agreed. However, I am objecting to those replies where backwards
interoperability is the *only* motivation for a reply, ruling out all other
options. That is simply stating that no compromise is possible. It would be
like remaining with text-only email forever. Not all h.264 proponents have
answered in this way and not all vp8 proponents either.

Silvia.

---

From: cowwoc <[email-masked]>
Date: Fri, 10 Jan 2014 22:11:34 -0500

Dave,

  * We are talking about convincing vendors, not end-users. End-users
    don't care whether we're using H.264 or VP8 under the hood. As to
    what entices vendors...
  * As far as I'm aware, the number of legacy systems that support H.264
    hardware decoders *and* encoders *and* exposes an API to them is
    equal to zero, or close to it. In contrast, the number of existing
    WebRTC deployments using VP8 is in the millions.

So who exactly are we trying to entice here? And how exactly does H.264 
have a market-share advantage over VP8 here?

Gili

On 10/01/2014 8:04 PM, Dave Crocker wrote:
> Actually, token ring technology and ethernet were developed in 
> parallel.  (Irvine Ring[1] - 1974, versus Parc Ethernet - 1975-ish.)  
> And Ethernet is a particularly intriguing example, since what is 
> called Ethernet today is an interface standard, althought the 
> underlying electrical stuff underneath is nothing like the original.
>
> base or deciding to be incompatible is massively important and needs 
> to be done very thoughtfully and, I believe, very cautiously.
>
> Again, what can seem like a barrier to progress can actually turn out 
> to facilitate it, by seducing the installed base into a familiar 
> Dumb, textual Arpanet mail was going along through the 70s and 80s, 
> with everyone knowing that multi-media mail would be much better.  
> There were numerous attempts to define and deploy it, to replace the 
> embarassingly limited textual Arpanet mail.  Some proprietary efforts 
> had success, but all of the public ones.  In the case of X.400, the 
> failure was protracted, expensive and globally spectacular.  (Please 
> don't look inside MS Exchange server code...)
>
> specifically by preserving the installed base and building upon it. 
> MIME mail is text, as far as any mail handling agent needs to know. 
> Only the author and the recipient needed to adopt MIME.
>

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Jan 2014 06:47:36 -0800

> have a market-share advantage over VP8 here?

End users care about having to change switch to new software or learn 
new procedures.  And they care about changes in who they can interact with.

And vendors care quite a bit about when and how they have to support new 
features.  In other words, yes, they need enticing too.

Also, I was carefully not commenting on what I thought the correct 
choice here should be.  I am only attempting to clarify the nature of 
MTI requirements, versus concern for the ability to add/use new 
capabilities.

However...

      I am curious about the claim of large-scale, existing WebRTC 
support, given that none of this working group's drafts has yet received 
IETF approval nor been published as an RFC.

d/

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 11 Jan 2014 16:16:23 +0100

> IETF approval nor been published as an RFC.

Dave, unfortunately for us who spend a big chunk of our lives in, the
IETF does not have any exclusive right over the term "WebRTC". What the
rest of the world call "WebRTC" can be roughly defined as a media stack
that is implemented in two of the four major desktop and mobile
browsers. It's hard to estimate the size of the installed base, but the
numbers floating around are in the order of 10**9.

The IETF role in this as vast as controversial field is -- as it should
be -- document running code and help the search of rough consensus to
smooth the rough edges that prevent interoperability. Video codecs being
one of them.

Enrico

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Jan 2014 08:42:17 -0800

> smooth the rough edges that prevent interoperability. Video codecs being

Enrico,

Thanks for your response It was, unfortunately, quite helpful.

That is, your note was helpful but the reality you describe highlights 
an apparently deep and long-standing problem for the working group.

I do see the non-IETF references to webrtc and implementations for it, 
such as [1][2].  (That I, as a Firefox user, have no idea how to try to 
use rtcweb from my browser speaks to some packaging and usability 
issues, but doesn't counter what you and the firefox documentation have 
said...)

There have been many IETF efforts that represented continuation of 
existing industry efforts, with the goal of documenting and enhancing 
that existing work.

      This working group's discussion record and document-development
      history look very little like one of those "document existing code
      and enhance the spec" efforts.

Such efforts might have considerable controversy, but they retain a 
foundation of the existing work.

However the working group's history matches one of a /new/ effort 
working on a complex topic and gaining relatively poor group coherence. 
  The current impasse on an MTI component looks like an example, to me.

Note that I'm not disagreeing with what you've said, but am noting the 
disparity between that apparent reality outside the IETF, versus the 
history (and present) for the IETF's rtcweb working group.

If this group is documenting and building upon existing services, it 
needs group agreement that is what it is doing, in which case 
compatibility with that existing operational base is a fundamental 
requirement.  Exceptions might make sense but they need very strong 
justification and massive consensus.

If this group is using the existing work merely for input and advice to 
a new effort -- that is, if the group feels to produce an incompatible 
service -- then that, too, needs group consensus and the effort needs a 
different name, so there is no (further) 'brand' confusion.

d/

[1]  http://en.wikipedia.org/wiki/WebRTC#cite_note-10
[2]  https://www.mozilla.org/en-US/firefox/22.0/releasenotes/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Jan 2014 08:54:16 -0800

> different name, so there is no (further) 'brand' confusion.

Sorry.  Typo.  The paragraph should have read:

If this group is using the existing work merely for input and advice to
a new effort -- that is, if the group feels it acceptable to produce an 
incompatible
service -- then that, too, needs group consensus and the effort needs a
different name, so there is no (further) 'brand' confusion.

---

From: Ron <[email-masked]>
Date: Sun, 12 Jan 2014 03:36:59 +1030

On Sat, Jan 11, 2014 at 08:42:17AM -0800, Dave Crocker wrote:
> existing industry efforts, with the goal of documenting and
> enhancing that existing work.
> 

I think you might be misunderstanding what has happened here.
This group isn't rubber stamping work that was already done,
you're looking at the experimental implementations of the work
that this group is defining.

That they are already functional, and already deployed, and
already being used, is just an indication of how far this work
has already come - and user feedback from them is certainly
valuable to figuring out what work remains to be done.

That they only support VP8 as the video codec is simply a function
of it having been impossible for them to licence H.264.

Precisely the concern that many other people here have been voicing.

That the already established user base may be the size it is puts
the lie to the idea that this will fail if we don't choose H.264.
The "legacy devices" that people say only support H.264 will already
need other compatibility shims or firmware updates to support WebRTC.
As they exist today they are already completely non-interoperable
with it.  They simply don't make herrings that are more red than this.

Any action that makes those devices interoperable with WebRTC could
equally make them interoperable with its current de-facto MTI codec.
It really is that simple.

  Ron

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Jan 2014 09:17:33 -0800

> that this group is defining.

 From the working group charter:

   This work will be done primarily by using already defined protocols or
   functionalities. If there is identification of missing protocols or
   functionalities, such work can be requested to be done in another
   working group with a suitable charter or by requests for chartering it
   in this WG or another WG.

That's not rubber-stamping (which, of course, the IETF never does...) 
but it also is not starting with a clean sheet.

Again, the tone of this groups discussion history does not match 
document-and-enhance.  It matches "starting fresh".

The latter needs a different name, to distinguish it from the installed 
base.

d/

---

From: Ron <[email-masked]>
Date: Sun, 12 Jan 2014 03:59:41 +1030

>   in this WG or another WG.

This refers to things like SDP, RTP, HTTP etc.  Protocols already
defined by the IETF (or W3C), not by the WebRTC implementations that
didn't exist yet when the charter was written.

It's just about not reinventing wheels that are already suited to
the task and already well standardised.

  Ron

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Jan 2014 13:27:09 -0800

On Sat, Jan 11, 2014 at 8:42 AM, Dave Crocker <[email-masked]> wrote:
> That is, your note was helpful but the reality you describe highlights an
> apparently deep and long-standing problem for the working group.
>
> I do see the non-IETF references to webrtc and implementations for it, such
> as [1][2].  (That I, as a Firefox user, have no idea how to try to use
> rtcweb from my browser speaks to some packaging and usability issues, but
> doesn't counter what you and the firefox documentation have said...)

Actually, I would hope you wouldn't need to know how. I.e., the
intended use mode for WebRTC is that sites just offer you
the ability to make WebRTC calls as part of their ordinary
Web UI. The users would hopefully just be able to use the
feature on a site which offered it.

-Ekr

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 13 Jan 2014 14:47:53 +0000

Legacy interoperability is important to some of us.

It is not about preserving our existing equipment.

It is about the fact the communication involves two or more parties, and we want to enable video communication between RTCWEB user and the rest of the entities in the world that are capable of video, without having to resort to transcoding video on all calls. Yes transcoding is possible, but it has a cost that someone will have to pay for, and it introduces delay, which can be catered for, but removes the possibility of someone else in the call path using that delay portion.

Currently there are a considerable number more of those users using legacy systems than there are using RTCWEB.

Keith

________________________________
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: 10 January 2014 16:39
To: [email-masked]
Subject: Re: [rtcweb] Comment on Straw Poll replies

On 10/01/2014 9:54 AM, [email-masked]<mailto:[email-masked]> wrote:

This is a fallacy. No one is arguing that you should be stuck with using *just* H.261. What we are saying is that: if H.264 or VP8 are available on both end-points, great. If not, you can either:

  *   Use H.261, or
  *   Transcode, or
  *   Drop Video

By eliminating H.261 as MTI, you lose the first option and are forced to either transcode or drop video. The cost to supporting H.261 is as simple as compiling https://github.com/Vproject/p64 and popping it on your device. You don't need hardware support because it's so computationally cheap.

And finally, we're not objecting to the use of H.264, per se, but rather to the fact that the majority of people who vote for it and against everything else use "legacy interoperability" as argument.

WebRTC is a *new* technology. If all we wanted to do was to support *existing* devices then we would use *existing* technologies. For that reason, I don't think maintaining backwards compatibility is important when breaking it has a noticeable benefit (and in this case, I believe it does).

Gili

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 12:48:57 -0500

Keith,

Even if we mandate H.264 and SDP as MTI, how in the world do you expect 
RTCWEB to be interoperable with existing video equipment? I just don't 
get this argument.

As far as I can tell, the market share of devices that:

  * Encode/decode H.264 in hardware *and* expose public APIs for doing so,
  * Understand SDP,
  * Are WebRTC compliant

is exactly zero. There is no way that legacy devices will magically 
begin supporting WebRTC. This will require *new* products to get released.

Gili

On 13/01/2014 9:47 AM, DRAGE, Keith (Keith) wrote:
> It is about the fact the communication involves two or more parties, 
> and we want to enable video communication between RTCWEB user and the 
> rest of the entities in the world that are capable of video, without 
> having to resort to transcoding video on all calls. Yes transcoding is 
> possible, but it has a cost that someone will have to pay for, and it 
> introduces delay, which can be catered for, but removes the 
> possibility of someone else in the call path using that delay portion.
> Currently there are a considerable number more of those users using 
> legacy systems than there are using RTCWEB.
> Keith
>
>     ------------------------------------------------------------------------
>     *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *cowwoc
>     *Sent:* 10 January 2014 16:39
>     *To:* [email-masked]
>     *Subject:* Re: [rtcweb] Comment on Straw Poll replies
>
>     This is a fallacy. No one is arguing that you should be stuck with
>     using *just* H.261. What we are saying is that: if H.264 or VP8
>     are available on both end-points, great. If not, you can either:
>
>       * Use H.261, or
>       * Transcode, or
>       * Drop Video
>
>     By eliminating H.261 as MTI, you lose the first option and are
>     forced to either transcode or drop video. The cost to supporting
>     H.261 is as simple as compiling https://github.com/Vproject/p64
>     and popping it on your device. You don't need hardware support
>     because it's so computationally cheap.
>
>     And finally, we're not objecting to the use of H.264, per se, but
>     rather to the fact that the majority of people who vote for it and
>     against everything else use "legacy interoperability" as argument.
>
>     WebRTC is a *new* technology. If all we wanted to do was to
>     support *existing* devices then we would use *existing*
>     technologies. For that reason, I don't think maintaining backwards
>     compatibility is important when breaking it has a noticeable
>     benefit (and in this case, I believe it does).
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Jan 2014 18:19:26 +0000

I don't understand what the two first bullets have to do with interoperability. The way my legacy device control the H.246 encoding/decoding internally is irrelevant, and the JavaScript app can implement whatever media negotiation protocol my legacy device support.

Regarding the third bullet, it is true that gateway functionality will often be needed to handle WebRTC specific features (continous consent etc). But, such gateway wouldn't have to do video transcoding.

Regards,

Christer

________________________________________
From: rtcweb [[email-masked]] on behalf of cowwoc [[email-masked]]
Sent: Monday, 13 January 2014 7:48 PM
To: DRAGE, Keith (Keith); [email-masked]
Subject: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

Keith,

Even if we mandate H.264 and SDP as MTI, how in the world do you expect RTCWEB to be interoperable with existing video equipment? I just don't get this argument.

is exactly zero. There is no way that legacy devices will magically begin supporting WebRTC. This will require *new* products to get released.

Gili

Keith

To: [email-masked]<mailto:[email-masked]>

  *   Use H.261, or
  *   Transcode, or
  *   Drop Video

Gili

---

From: Roman Shpount <[email-masked]>
Date: Mon, 13 Jan 2014 13:25:39 -0500

I think this was discussed on this list before, but there is a big
difference in implementation of simple packet forwarder which implements
ICE/DTLS and deals with WebRTC SDP peculiarities but does not have to
transcode media, and the full gateway which will need to transcode. In the
former case you do not need to re-order packets, you do not need to
introduce delays, and do not need to incur CPU transcoding costs. You can
build a solution that proxies few thousand concurrent RTP channels with
single millisecond delays on a standard server (the CPU load would be the
same order of magnitude as TURN server). On the other hand, if you need to
transcode you need a jitter buffer, you need to synchronize audio and video
when transcoded, and you need enough CPU resources to transcode. This means
40-60 ms delay plus only hundreds of channels per server. This is very
expensive to scale to any reasonable service volume.

_____________
Roman Shpount

On Mon, Jan 13, 2014 at 12:48 PM, cowwoc <[email-masked]> wrote:

> RTCWEB to be interoperable with existing video equipment? I just don't get
> this argument.
>
>    - Encode/decode H.264 in hardware *and* expose public APIs for doing
>    so,
>    - Understand SDP,
>    - Are WebRTC compliant
>
> is exactly zero. There is no way that legacy devices will magically begin
> supporting WebRTC. This will require *new* products to get released.
>
> Gili
>
> It is about the fact the communication involves two or more parties, and
> we want to enable video communication between RTCWEB user and the rest of
> the entities in the world that are capable of video, without having to
> resort to transcoding video on all calls. Yes transcoding is possible, but
> it has a cost that someone will have to pay for, and it introduces delay,
> which can be catered for, but removes the possibility of someone else in
> the call path using that delay portion.
>
>  ------------------------------
> *From:* rtcweb [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *cowwoc
> Given your concerns about "old" systems and "od" features, I'm a little bit surprised that your are part of them.http://www.ietf.org/mail-archive/web/rtcweb/current/msg10798.html
>    - Use H.261, or
>     - Transcode, or
>     - Drop Video
> either transcode or drop video. The cost to supporting H.261 is as simple
> as compiling https://github.com/Vproject/p64 and popping it on your
> device. You don't need hardware support because it's so computationally
> cheap.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 13 Jan 2014 19:28:05 +0000

Well given that the last element of your Boolean expression always equates to FALSE, yes I agree that it is zero.

But the first two elements equate to significant numbers and with the application combined with an interworking box, they can be easily communicated with by a RTCWEB endpoint. However if we have to always include a video transcoder in that box, we will all the disadvantages already identified, particularly where we need to lipsync voice.

For scenarios see

ftp://ftp.3gpp.org/Specs/html-info/22228.htm release 12 section 11 and annex H

and

ftp://ftp.3gpp.org/Specs/html-info/23701.htm

regards

Keith

________________________________
From: cowwoc [mailto:[email-masked]]
Sent: 13 January 2014 17:49
To: DRAGE, Keith (Keith); [email-masked]
Subject: There are no legacy WebRTC devices (Was: [rtcweb] Comment on Straw Poll replies)

Keith,

Gili

Keith

  *   Use H.261, or
  *   Transcode, or
  *   Drop Video

Gili

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 17:56:43 -0500

> I don't understand what the two first bullets have to do with interoperability. The way my legacy device control the H.246 encoding/decoding internally is irrelevant, and the JavaScript app can imp…

Christer,

It doesn't matter that your legacy device can play YouTube (i.e. decode 
H.264 in a web browser). My point is that unless a legacy device can do 
everything I mentioned in the top bullet points then it's not relevant 
to the MTI discussion.

> Regarding the third bullet, it is true that gateway functionality will often be needed to handle WebRTC specific features (continous consent etc). But, such gateway wouldn't have to do video transc…

I don't understand. I don't think that VP8 (or any other codec) as MTI 
implies that you would have to transcode in the gateway. If we're going 
to talk about gateways, it's important for you to explain what kind of 
devices are on either end. Please clarify.

Thanks,
Gili

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 17:58:12 -0500

Roman,

I'm not saying you are wrong, but I don't understand your argument 
(yet). Who is the gateway connected to that you think I'm asking you to 
transcode?

Thanks,
Gili

On 13/01/2014 1:25 PM, Roman Shpount wrote:
> difference in implementation of simple packet forwarder which 
> implements ICE/DTLS and deals with WebRTC SDP peculiarities but does 
> not have to transcode media, and the full gateway which will need to 
> transcode. In the former case you do not need to re-order packets, you 
> do not need to introduce delays, and do not need to incur CPU 
> transcoding costs. You can build a solution that proxies few thousand 
> concurrent RTP channels with single millisecond delays on a standard 
> server (the CPU load would be the same order of magnitude as TURN 
> server). On the other hand, if you need to transcode you need a jitter 
> buffer, you need to synchronize audio and video when transcoded, and 
> you need enough CPU resources to transcode. This means 40-60 ms delay 
> plus only hundreds of channels per server. This is very expensive to 
> scale to any reasonable service volume.
>
> _____________
> Roman Shpount
>
>
> On Mon, Jan 13, 2014 at 12:48 PM, cowwoc <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Keith,
>
>     Even if we mandate H.264 and SDP as MTI, how in the world do you
>     expect RTCWEB to be interoperable with existing video equipment? I
>     just don't get this argument.
>
>     is exactly zero. There is no way that legacy devices will
>     magically begin supporting WebRTC. This will require *new*
>     products to get released.
>
>     Gili
>
>>     It is about the fact the communication involves two or more
>>     parties, and we want to enable video communication between RTCWEB
>>     user and the rest of the entities in the world that are capable
>>     of video, without having to resort to transcoding video on all
>>     calls. Yes transcoding is possible, but it has a cost that
>>     someone will have to pay for, and it introduces delay, which can
>>     be catered for, but removes the possibility of someone else in
>>     Currently there are a considerable number more of those users
>>     using legacy systems than there are using RTCWEB.
>>     Keith
>>
>>         *To:* [email-masked] <mailto:[email-masked]>
>>         On 10/01/2014 9:54 AM, [email-masked]
>>         <mailto:[email-masked]> wrote:
>>>
>>         This is a fallacy. No one is arguing that you should be stuck
>>         with using *just* H.261. What we are saying is that: if H.264
>>         or VP8 are available on both end-points, great. If not, you
>>         can either:
>>
>>           * Use H.261, or
>>           * Transcode, or
>>           * Drop Video
>>
>>         By eliminating H.261 as MTI, you lose the first option and
>>         are forced to either transcode or drop video. The cost to
>>         supporting H.261 is as simple as compiling
>>         https://github.com/Vproject/p64 and popping it on your
>>         device. You don't need hardware support because it's so
>>         computationally cheap.
>>
>>         And finally, we're not objecting to the use of H.264, per se,
>>         but rather to the fact that the majority of people who vote
>>         for it and against everything else use "legacy
>>         interoperability" as argument.
>>
>>         technologies. For that reason, I don't think maintaining
>>         backwards compatibility is important when breaking it has a
>>         noticeable benefit (and in this case, I believe it does).
>>
>     [email-masked] <mailto:[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 18:09:19 -0500

On 13/01/2014 2:28 PM, DRAGE, Keith (Keith) wrote:
> Well given that the last element of your Boolean expression always 
> equates to FALSE, yes I agree that it is zero.

So how is H.264 market share at all relevant to the MTI discussion? If 
you have to release a new product anyway, you can make it run whatever 
codec you want.

> But the first two elements equate to significant numbers and with the 
> application combined with an interworking box, they can be easily 
> communicated with by a RTCWEB endpoint. However if we have to always 
> include a video transcoder in that box, we will all the disadvantages 
> already identified, particularly where we need to lipsync voice.

Slow down there. Do you have millions of devices that can "encode/decode 
H.264 in hardware *and* expose public APIs for doing so"? If so, please 
provide concrete examples.

To be clear, I'm as much against transcoding as you are. I'm just trying 
to understand the argument that we must choose H.264 as MTI for 
interoperability with the "millions of existing devices out there". 
That's the argument I've been hearing over and over again, which I'm 
trying to understand.

> ftp://ftp.3gpp.org/Specs/html-info/23701.htm

If I understood correctly, you're trying to connect legacy systems that 
don't speak WebRTC through some gateway that translates back and forth 
between IMS and WebRTC. Assuming this is the case, then your argument is 
actually that you want H.264 as MTI for the sake of *gateways*, not 
legacy devices. Meaning, your legacy devices will never run WebRTC but 
you want the gateways to convert from IMS to WebRTC without having to 
transcode the video. Is that correct?

What kind of devices are we talking about? Video phones with tiny 
screens? Or are we talking about something more elaborate?

Thanks,
Gili

>     *From:* cowwoc [mailto:[email-masked]]
>     *Sent:* 13 January 2014 17:49
>     *To:* DRAGE, Keith (Keith); [email-masked]
>     *Subject:* There are no legacy WebRTC devices (Was: [rtcweb]
>     Comment on Straw Poll replies)
>
>     Keith,
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 13 Jan 2014 18:21:49 -0500

On Mon, Jan 13, 2014 at 5:58 PM, cowwoc <[email-masked]> wrote:

>  Roman,
>
> I'm not saying you are wrong, but I don't understand your argument (yet).
> Who is the gateway connected to that you think I'm asking you to transcode?
>
>
Let's say we have, a legacy device which support H.264 over plain RTP/SIP
and WebRTC browser on the other end, which supports H.264 as well. It is
possible to make a gateway that will deal with WebRTC SDP signaling
negotiation, implement DTLS/SRTP and ICE to communicate with WebRTC
browser, and will forward RTP payload without ever decoding or re-encoding
H.264 video payload. Such gateway will scale to thousands of channels per
server and will only introduce delay in the range of single milliseconds.
This gateway does not need any special hardware and will not even need to
implement the video codec. I would say that complexity of such gateway is
not that different from the complexity of a TURN server. The costs of
operating such gateway are similar as well.

On the other hand if you need to transcode H.264 to VP8, your gateway
becomes a lot more resource hungry and complex. You will need to add jitter
buffer, H.264 and VP8  codec implementations, and audio/video
re-synchronization to the gateway. This gateway will require custom DSP or
it will only scale to hundreds of channels. It will introduce at least tens
of milliseconds of delay (due to the need for the jitter buffer and
audio/video resync). The costs of operating such gateway would be an order
of magnitude more then costs of operating a gateway that does not need to
transcode. In a lot of environments, operation costs of such gateway as
well as delays introduced would make it unsustainable.

For me, all of the above is mostly an argument that Web Browsers should
support as many codecs as possible. If anything, the result of this should
be that web browsers should support H.264, VP8 and H.263. The same argument
actually applies to audio codecs as well (I believe web browsers should
support AMR-WB and G.722). This being said, I believe market needs would
define which additional codecs will be supported by the browsers. Selection
of MTI cannot be driven just by legacy interop.
_____________
Roman Shpount

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 19:02:26 -0500

Roman,

I see. So now I understand the gateway situation a bit better, but I'd 
like to understand more about the legacy devices at each end of the pipe.

What video resolution do these legacy devices capture at, and render? 
Are they closed systems or general-purpose like a web browser? Do they 
support hardware encoding of H.264?

Thanks,
Gili

On 13/01/2014 6:21 PM, Roman Shpount wrote:
>
> On Mon, Jan 13, 2014 at 5:58 PM, cowwoc <[email-masked] 
>     (yet). Who is the gateway connected to that you think I'm asking
>     you to transcode?
>
>
> Let's say we have, a legacy device which support H.264 over plain 
> RTP/SIP and WebRTC browser on the other end, which supports H.264 as 
> well. It is possible to make a gateway that will deal with WebRTC SDP 
> signaling negotiation, implement DTLS/SRTP and ICE to communicate with 
> WebRTC browser, and will forward RTP payload without ever decoding or 
> re-encoding H.264 video payload. Such gateway will scale to thousands 
> of channels per server and will only introduce delay in the range of 
> single milliseconds. This gateway does not need any special hardware 
> and will not even need to implement the video codec. I would say that 
> complexity of such gateway is not that different from the complexity 
> of a TURN server. The costs of operating such gateway are similar as well.
>
> becomes a lot more resource hungry and complex. You will need to add 
> jitter buffer, H.264 and VP8  codec implementations, and audio/video 
> re-synchronization to the gateway. This gateway will require custom 
> DSP or it will only scale to hundreds of channels. It will introduce 
> at least tens of milliseconds of delay (due to the need for the jitter 
> buffer and audio/video resync). The costs of operating such gateway 
> would be an order of magnitude more then costs of operating a gateway 
> that does not need to transcode. In a lot of environments, operation 
> costs of such gateway as well as delays introduced would make it 
> unsustainable.
>
> For me, all of the above is mostly an argument that Web Browsers 
> should support as many codecs as possible. If anything, the result of 
> this should be that web browsers should support H.264, VP8 and H.263. 
> The same argument actually applies to audio codecs as well (I believe 
> web browsers should support AMR-WB and G.722). This being said, I 
> believe market needs would define which additional codecs will be 
> supported by the browsers. Selection of MTI cannot be driven just by 
> legacy interop.
> _____________
> Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2014 00:22:15 +0000

The legacy device is at one end of the pipe, not both.

For IMS endpoints, in general they are closed systems in that a dedicated application runs the codec.

However most mobile phones nowadays have all sorts of downloadable code so they are programmable in that sense. I believe most mobiles supporting H.264 have hardware support, but there are a mixture of standardised and proprietary APIs, and they are not necessarily open to any and all applications. I do not work for a mobile phone vendor so I cannot go further than that.

I'll let the enterprise people speak as to what they have out there in terms of phones supporting H.264.

regards

Keith

________________________________
From: cowwoc [mailto:[email-masked]]
Sent: 14 January 2014 00:02
To: Roman Shpount
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

Roman,

I see. So now I understand the gateway situation a bit better, but I'd like to understand more about the legacy devices at each end of the pipe.

What video resolution do these legacy devices capture at, and render? Are they closed systems or general-purpose like a web browser? Do they support hardware encoding of H.264?

Thanks,
Gili

On Mon, Jan 13, 2014 at 5:58 PM, cowwoc <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

I'm not saying you are wrong, but I don't understand your argument (yet). Who is the gateway connected to that you think I'm asking you to transcode?

Let's say we have, a legacy device which support H.264 over plain RTP/SIP and WebRTC browser on the other end, which supports H.264 as well. It is possible to make a gateway that will deal with WebRTC SDP signaling negotiation, implement DTLS/SRTP and ICE to communicate with WebRTC browser, and will forward RTP payload without ever decoding or re-encoding H.264 video payload. Such gateway will scale to thousands of channels per server and will only introduce delay in the range of single milliseconds. This gateway does not need any special hardware and will not even need to implement the video codec. I would say that complexity of such gateway is not that different from the complexity of a TURN server. The costs of operating such gateway are similar as well.

On the other hand if you need to transcode H.264 to VP8, your gateway becomes a lot more resource hungry and complex. You will need to add jitter buffer, H.264 and VP8  codec implementations, and audio/video re-synchronization to the gateway. This gateway will require custom DSP or it will only scale to hundreds of channels. It will introduce at least tens of milliseconds of delay (due to the need for the jitter buffer and audio/video resync). The costs of operating such gateway would be an order of magnitude more then costs of operating a gateway that does not need to transcode. In a lot of environments, operation costs of such gateway as well as delays introduced would make it unsustainable.

For me, all of the above is mostly an argument that Web Browsers should support as many codecs as possible. If anything, the result of this should be that web browsers should support H.264, VP8 and H.263. The same argument actually applies to audio codecs as well (I believe web browsers should support AMR-WB and G.722). This being said, I believe market needs would define which additional codecs will be supported by the browsers. Selection of MTI cannot be driven just by legacy interop.
_____________
Roman Shpount

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2014 00:25:39 +0000

I missed the bit of the equation about open APIs. I would certainly like any hardware support of codecs to be open APIs, but I do not consider that relevant for this discussion. What is relevant is that we have an endpoint supporting a telecommunications service with a video media using an H.264 codec, and wish to use that device to communicate with a webrtc endpoint, via some sort of interworking box. Because of the identified issues of transcoding we do not want that box to have to transcode every video media.

These legacy endpoints are not new products. It is every mobile phone out there that claims to support video communication.

regards

Keith

________________________________
From: cowwoc [mailto:[email-masked]]
Sent: 13 January 2014 23:09
To: DRAGE, Keith (Keith); [email-masked]
Subject: Re: There are no legacy WebRTC devices (Was: [rtcweb] Comment on Straw Poll replies)

So how is H.264 market share at all relevant to the MTI discussion? If you have to release a new product anyway, you can make it run whatever codec you want.

Slow down there. Do you have millions of devices that can "encode/decode H.264 in hardware *and* expose public APIs for doing so"? If so, please provide concrete examples.

To be clear, I'm as much against transcoding as you are. I'm just trying to understand the argument that we must choose H.264 as MTI for interoperability with the "millions of existing devices out there". That's the argument I've been hearing over and over again, which I'm trying to understand.

For scenarios see

and

If I understood correctly, you're trying to connect legacy systems that don't speak WebRTC through some gateway that translates back and forth between IMS and WebRTC. Assuming this is the case, then your argument is actually that you want H.264 as MTI for the sake of *gateways*, not legacy devices. Meaning, your legacy devices will never run WebRTC but you want the gateways to convert from IMS to WebRTC without having to transcode the video. Is that correct?

What kind of devices are we talking about? Video phones with tiny screens? Or are we talking about something more elaborate?

Thanks,
Gili

regards

Keith

To: DRAGE, Keith (Keith); [email-masked]<mailto:[email-masked]>

Keith,

Gili

Keith

  *   Use H.261, or
  *   Transcode, or
  *   Drop Video

Gili

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 14 Jan 2014 12:17:01 +1100

For all those concerns, please remember that Zingaya showcased a H.264
and VP8 real-time video conversion without transcoding. That to me
shows that we may all be over-estimating the complexity involved in
transcoding between H.264 and VP8.

Cheers,
Silvia.

On Tue, Jan 14, 2014 at 1:47 AM, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> It is about the fact the communication involves two or more parties, and we
> want to enable video communication between RTCWEB user and the rest of the
> entities in the world that are capable of video, without having to resort to
> transcoding video on all calls. Yes transcoding is possible, but it has a
> cost that someone will have to pay for, and it introduces delay, which can
> be catered for, but removes the possibility of someone else in the call path
> using that delay portion.
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 13 Jan 2014 20:39:51 -0500

> transcoding between H.264 and VP8.
First of all this was an early prototype in one direction only. Second, you
can probably get about 30% CPU reduction this way. Lastly you ca run into
some additional IPR on top of VP8 and H.264. After implementing all of this
you would still need to deal with transcoding and audio/video
synchronization same delay. Bottom line, you should avoid transcoding if
you can.

Once again, all of this being said I would still question if legacy interop
should be used as the only criteria for MTI codec selection. You would want
to support as many codecs as possible to avoid transcoding, but which one
should be selected as MTI is affected by many other factors. Once again, I
hope that major browsers will support both H.264 and VP8.
_____________
Roman Shpount

---

From: cowwoc <[email-masked]>
Date: Mon, 13 Jan 2014 21:13:18 -0500

It is relevant precisely because of what is happening on iOS. If the 
manufacturer does not bake WebRTC into the operating system (no one has, 
nor do I see any indication that anyone will) then you require a public 
API in order to implement WebRTC in user space. Baring that, you are 
forced to use software codecs (with all the associated limitations).

To date, Android is the only operating system that I've come across 
which exposes a public API for hardware video encoding/decoding, but it 
only supports hardware encoding for VP8. Until we see the same happen 
for H.264, it is hard to argue that legacy H.264 devices are candidates 
for running WebRTC natively. The only use-case that makes sense is the 
scenario you mentioned, in which a non-WebRTC device is talking to 
WebRTC device using a translating gateway.

Which brings up the question: how are those legacy devices encoding 
video if they don't have public APIs for doing so? Are they using a 
software codec?

> However most mobile phones nowadays have all sorts of downloadable 
> code so they are programmable in that sense. I believe most mobiles 
> supporting H.264 have hardware support, but there are a mixture of 
> standardised and proprietary APIs, and they are not necessarily open 
> to any and all applications. I do not work for a mobile phone vendor 
> so I cannot go further than that.

We need to get real specific here. What kind of capture/rendering 
resolution do the closed systems support? For example, most video phones 
I've seen have a tiny screen and you're unlikely to see the difference 
between a H.261 and H.264 feed. Also, at these resolutions transcoding 
is probably very cheap. Next, how many of them would realistically 
benefit from WebRTC support? My wife's company has video phones. Not 
only are they terribly expensive (so most companies don't have them) but 
also no one really uses the video feature. The screens are too small to 
make it useful and most people prefer to stick to voice-only conversations.

At the end of the day, I think we're really talking about a single 
use-case here: you want internet callers (WebRTC) to be able to jump 
into a proprietary call bridge that uses H.264 under the hood. That's 
it, that's all. I can't picture the opposite happening (proprietary 
system calling into internet) for usability reasons (having to stick a 
web browser into what should be a simple system). Nor can I see this 
being used for proprietary systems with tiny screens (like video phones).

So, how many such deployments really exist? That is, how many 
proprietary video conferencing deployments are there in total? And how 
many of them plan to allow incoming calls from WebRTC callers? Whatever 
that number is, it's a subset of total H.264 deployments. I have no 
doubt that it is an important use-case, but we need specific numbers to 
put it into perspective.

Say for a moment that these systems use H.264, and internet callers use 
VP8. The question is how often you get an incoming call from the 
internet. Perhaps transcoding would only occur in 5% of the cases. 
Another question is whether the gateways already do transcoding to 
combine multiple H.264 feeds into smaller resolution or combined video 
feeds in order to reduce bandwidth usage.

Anyway, those are just some of the questions that come to mind...

Gili

On 13/01/2014 7:25 PM, DRAGE, Keith (Keith) wrote:
> I missed the bit of the equation about open APIs. I would certainly 
> like any hardware support of codecs to be open APIs, but I do not 
> consider that relevant for this discussion. What is relevant is that 
> we have an endpoint supporting a telecommunications service with a 
> video media using an H.264 codec, and wish to use that device to 
> communicate with a webrtc endpoint, via some sort of interworking box. 
> Because of the identified issues of transcoding we do not want that 
> box to have to transcode every video media.
> These legacy endpoints are not new products. It is every mobile phone 
> out there that claims to support video communication.
> regards
> Keith
>
>     *Sent:* 13 January 2014 23:09
>     *Subject:* Re: There are no legacy WebRTC devices (Was: [rtcweb]
>>     Well given that the last element of your Boolean expression
>>     always equates to FALSE, yes I agree that it is zero.
>
>     So how is H.264 market share at all relevant to the MTI
>     discussion? If you have to release a new product anyway, you can
>     make it run whatever codec you want.
>
>>     But the first two elements equate to significant numbers and with
>>     the application combined with an interworking box, they can be
>>     easily communicated with by a RTCWEB endpoint. However if we have
>>     to always include a video transcoder in that box, we will all the
>>     disadvantages already identified, particularly where we need to
>>     lipsync voice.
>
>     Slow down there. Do you have millions of devices that can
>     "encode/decode H.264 in hardware *and* expose public APIs for
>     doing so"? If so, please provide concrete examples.
>
>     To be clear, I'm as much against transcoding as you are. I'm just
>     trying to understand the argument that we must choose H.264 as MTI
>     for interoperability with the "millions of existing devices out
>     there". That's the argument I've been hearing over and over again,
>     which I'm trying to understand.
>
>>     For scenarios see
>     If I understood correctly, you're trying to connect legacy systems
>     that don't speak WebRTC through some gateway that translates back
>     and forth between IMS and WebRTC. Assuming this is the case, then
>     your argument is actually that you want H.264 as MTI for the sake
>     of *gateways*, not legacy devices. Meaning, your legacy devices
>     will never run WebRTC but you want the gateways to convert from
>     IMS to WebRTC without having to transcode the video. Is that correct?
>
>>         Even if we mandate H.264 and SDP as MTI, how in the world do
>>         you expect RTCWEB to be interoperable with existing video
>>         equipment? I just don't get this argument.
>>
>>>         parties, and we want to enable video communication between
>>>         RTCWEB user and the rest of the entities in the world that
>>>         are capable of video, without having to resort to
>>>         transcoding video on all calls. Yes transcoding is possible,
>>>         but it has a cost that someone will have to pay for, and it
>>>         Currently there are a considerable number more of those
>>>         users using legacy systems than there are using RTCWEB.
>>>         Keith
>>>
>>>             This is a fallacy. No one is arguing that you should be
>>>             stuck with using *just* H.261. What we are saying is
>>>             that: if H.264 or VP8 are available on both end-points,
>>>             great. If not, you can either:
>>>
>>>               * Use H.261, or
>>>               * Transcode, or
>>>               * Drop Video
>>>
>>>             By eliminating H.261 as MTI, you lose the first option
>>>             and are forced to either transcode or drop video. The
>>>             cost to supporting H.261 is as simple as compiling
>>>             And finally, we're not objecting to the use of H.264,
>>>             per se, but rather to the fact that the majority of
>>>             people who vote for it and against everything else use
>>>             "legacy interoperability" as argument.
>>>
>>>             WebRTC is a *new* technology. If all we wanted to do was
>>>             to support *existing* devices then we would use
>>>             *existing* technologies. For that reason, I don't think
>>>             maintaining backwards compatibility is important when

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Jan 2014 20:04:34 -0800

On Mon, Jan 13, 2014 at 6:13 PM, cowwoc <[email-masked]> wrote:
> To date, Android is the only operating system that I've come across which
> exposes a public API for hardware video encoding/decoding, but it only
> supports hardware encoding for VP8.

Can you please provide a reference for this claim? That does not match
my understanding.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jan 2014 07:51:22 +0000

Hi,

>H.264 in a web browser). My point is that unless a legacy device can do everything I mentioned in the top bullet points then it's not relevant to the MTI discussion.

I don't agree.

> I don't understand. I don't think that VP8 (or any other codec) as MTI implies that you would have to transcode in the gateway.
>
> If we're going to talk about gateways, it's important for you to explain what kind of devices are on either end. Please clarify.

I think Keith gave IMS based networks/devices as an example, so I'll echo him.

But, of course the networks/devices on the other side could also be non-IMS SIP networks.

Regards,

Christer

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 09:49:20 +0000

Hi,

There are several aspects how WebRTC compatibility or interoperability with "legacy" or non-WebRTC devices/services is relevant. I try to summarize them below since I think they have been mixed in this conversation:

1.) WebRTC interoperability with non-WebRTC endpoints or services through a gateway

In this scenario we have WebRTC and WebRTC compliant devices on one side of the gateway, and for instance SIP/IMS/H.323/proprietary video conferencing equipment on the other. The gateway may need to do various translations related to e.g. ICE, DTLS-SRTP, SDP and so on, but if both sides use the same video codec, the heaviest part, i.e. the video transcoding, can be avoided. 

I think this is the scenario that for instance Keith and Christer have brought up in this thread, and that some people thought essential in their video codec straw poll answers. H.264 is widely used in those current non-WebRTC systems. And they are not all "legacy", but their use and deployment may grow in parallel to WebRTC. 

2.) WebRTC implemented on a "legacy" or "existing" device with HW codec support

This is the scenario where open API's and access to HW codecs matters. For instance most mobile devices have H.264 on HW, far fewer have VP8. It is clear that currently on many platforms there is no way for third party apps to use these codecs, so right now it does not help much. However, if and when WebRTC and real-time video become more relevant, it is possible for the platform vendors to make those codecs accessible. In that case it does matter what the HW can support. 

3.) WebRTC implemented on a device that supports also other video related services and standards

In this scenario WebRTC is implemented on a device (existing or future) that also supports other video services or use cases, such as 3GPP IMS video services or Wi-Fi Alliane Miracast (for streaming video over Wi-Fi to a TV screen, for instance). In this case these are all distinct apps/services that do not interoperate with each other. It is however useful the HW, OS and device vendor if all of them use the same video codec. That reduces cost (development, maintenance, possibly licensing). The abovementioned IMS and WFA standards mandate H.264, so it needs to be on devices for those services regardless of WebRTC. 

So, these are all different cases, and not all are equally relevant to all players. But they all show that what is called "legacy" interoperability/compatibility does matter, when it comes to video codecs. How much it matters compared to other factors (codec quality, cost etc.) is up to each individual or organization to valuate. 

Regards,
	Markus 

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of ext Christer
> Holmberg
> Sent: 14 January, 2014 09:51
> To: cowwoc; DRAGE, Keith (Keith); [email-masked]
> everything I mentioned in the top bullet points then it's not relevant to the
> MTI discussion.
> 
> I don't agree.
> 
> >> Regarding the third bullet, it is true that gateway functionality will often
> be needed to handle WebRTC specific features (continous consent etc). But,
> such gateway wouldn't have to do video transcoding.
> >
> implies that you would have to transcode in the gateway.
> >
> > If we're going to talk about gateways, it's important for you to explain what
> kind of devices are on either end. Please clarify.
> 
> we want to enable video communication between RTCWEB user and the rest
> of the entities in the world that are capable of video, without having to resort
> to transcoding video on all calls. Yes transcoding is possible, but it has a cost
> that someone will have to pay for, and it introduces delay, which can be
> catered for, but removes the possibility of someone else in the call path
> > On 10/01/2014 9:54 AM,
> [email-masked]<mailto:[email-masked]>
> wrote:
> >
> >
> > This is a fallacy. No one is arguing that you should be stuck with using *just*
> H.261. What we are saying is that: if H.264 or VP8 are available on both end-
> points, great. If not, you can either:
> >
> >    *   Use H.261, or
> >    *   Transcode, or
> >    *   Drop Video
> >
> compiling https://github.com/Vproject/p64 and popping it on your device.
> You don't need hardware support because it's so computationally cheap.
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2014 10:22:49 +0000

In those terms, I do not believe that is what they were showing, at least according to the reports I have seen.

Further, apart from any processing power, the critical issue is the delay involved in any conversion, and I have no figures for that from this demonstration, and I suspect you do not either. Given that you must receive frames to do the conversion, my belief is that we will still be talking both decode and encode delay at the conversion point of the order of 60 - 70 ms, whatever mechanism is used. That is a significant take from the limits specified in ITU Recommendation G.114.

Regards

Keith

> From: Silvia Pfeiffer [mailto:[email-masked]] 
> Sent: 14 January 2014 01:17
> To: DRAGE, Keith (Keith)
> Cc: cowwoc; [email-masked]
> For all those concerns, please remember that Zingaya 
> showcased a H.264 and VP8 real-time video conversion without 
> transcoding. That to me shows that we may all be 
> over-estimating the complexity involved in transcoding 
> between H.264 and VP8.
> 
> Cheers,
> Silvia.
> 
> 
> parties, 
> > WebRTC to interoperability with old systems only and 
> therefore to old features only?
> > technologies, let's start by disregarding replies from 
> those who could 
> > live with a WebRTC technology that would specify H.261 as 
> only  MTI codec.
> > Given your concerns about "old" systems and "od" features, I'm a 
> > little bit surprised that your are part of them.
> > using
> > *just* H.261. What we are saying is that: if H.264 or VP8 are 
> > available on both end-points, great. If not, you can either:
> >
> > Use H.261, or
> > Transcode, or
> > Drop Video
> >
> are forced 
> > to either transcode or drop video. The cost to supporting 
> H.261 is as 
> > your device. You don't need hardware support because it's 
> so computationally cheap.
> >
> > when breaking it has a noticeable benefit (and in this 
> case, I believe it does).
> >

---

From: Ron <[email-masked]>
Date: Tue, 14 Jan 2014 21:41:17 +1030

On Tue, Jan 14, 2014 at 09:49:20AM +0000, [email-masked] wrote:
> There are several aspects how WebRTC compatibility or interoperability with
> "legacy" or non-WebRTC devices/services is relevant. I try to summarize them
> below since I think they have been mixed in this conversation:

Clarifying this is indeed useful for helping to decide what is and isn't
important here, so thanks for doing this.

> In this scenario we have WebRTC and WebRTC compliant devices on one side of
> the gateway, and for instance SIP/IMS/H.323/proprietary video conferencing
> equipment on the other. The gateway may need to do various translations
> related to e.g. ICE, DTLS-SRTP, SDP and so on, but if both sides use the same
> video codec, the heaviest part, i.e. the video transcoding, can be avoided. 
> 
> I think this is the scenario that for instance Keith and Christer have
> brought up in this thread, and that some people thought essential in their
> video codec straw poll answers. H.264 is widely used in those current
> non-WebRTC systems. And they are not all "legacy", but their use and
> deployment may grow in parallel to WebRTC. 

I think there is a very important point about this particular class of
devices that so far people have alluded to in other discussion, but that
I haven't seen anyone really pin down precisely yet, except possibly in
the original language of the charter.

If any of these devices had actually been built using open and accessible
standards for all of their required functionality, then this particular
working group would have never needed to form in the first place to slave
over establishing a standard that was.  The needed work would have already
been done and we'd all be video conferencing to our heart's content today
with any of the numerous freely available implementation that would have
already existed.

Of all the methods of lock out used to keep them a closed shop, not the
least is the strictly guarded use of only highly encumbered codecs ...

So to say that this group must also provide the same degree of lock out
with its mandatory codec options, in order to be interoperable with these
devices, really just boils down to saying "this standard poses a grave
threat to our existing monopoly on video services, and we think that it
is very important that you do not do that".

That would seem to be in direct opposition to the chartered aims of this
group, and basically make it a complete waste of time and effort.

Which still isn't to say that transcoding isn't desirable to avoid.
But the onus should be on the closed devices to interoperate with the
open standard should they choose to -- not to cripple the open standard
and make it effectively just as closed as the things it was designed to
replace.  As you noted there are plenty of other inaccessible standards
that people could already choose from if they want that.  We certainly
shouldn't be reinventing or rubber-stamping any of those here.

Of all the options we might "consider for interworking with legacy VoIP
equipment", sabotaging the freedom of people to implement this standard
should be a clear no-brainer "thanks, but no thanks".

  hth,
  Ron

---

From: Tim Panton <[email-masked]>
Date: Tue, 14 Jan 2014 12:35:29 +0000

> Further, apart from any processing power, the critical issue is the delay involved in any conversion, and I have no figures for that from this demonstration, and I suspect you do not either. Given…

My experience of the existing mass h264 deployments in the mobile space is that they like to split the the audio and
video media paths. (You'd need to do this in any gateway to these legacy systems). 
This means that they can get out of sync. This would be made worse by transcoding the video leg.
Although there is a counter argument that they are already unacceptable, so 70ms won't make any difference.

T.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Jan 2014 14:52:19 +0100

On 01/11/2014 05:42 PM, Dave Crocker wrote:
> such as [1][2].

At the outset, there was a decision to use "RTCWEB" as a name for the 
IETF effort and "WEBRTC" as a name for the W3C effort that mirrors it. 
Somewhat later, the discussion arose on what we should call the whole 
effort (IETF, W3C and company implementations), and the consensus seemed 
to be to use the term "WebRTC" (note the different capitalizations).

For someone who enters the group at a time long after the initial 
discussions, I can see why the terminology would be confusing, even when 
it is applied consistently (something that doesn't always happen).

> (That I, as a Firefox user, have no idea how to try to use rtcweb from 
> my browser speaks to some packaging and usability issues, but doesn't 
> counter what you and the firefox documentation have said...)

Once you learn to program Javascript, it is actually quite simple to use 
it from your browser. Simpler, in my opinion, than, for instance, using 
TCP through a BSD Sockets interface.

The sentence "using TCP from my browser" is, of course, not particularly 
interesting; either it's built-in (as a substrate for what you're 
already doing), or it's unavailable (browsers cannot, by design, allow 
clients access to raw TCP sockets).

> working on a complex topic and gaining relatively poor group 
> coherence.  The current impasse on an MTI component looks like an 
> example, to me.
>

That's what happens when IETF efforts take longer than implementation 
efforts.
These things started in parallel, with the intent of arriving together. 
At the moment, the implementations seem to be in the lead.

> If this group is using the existing work merely for input and advice 
> to a new effort -- that is, if the group feels to produce an 
> incompatible service -- then that, too, needs group consensus and the 
> effort needs a different name, so there is no (further) 'brand' 
> confusion.

The group is definitely creating work that was new and incompatible to 
what existed at the time the group started working.

If the group *at this time* chooses to crash and burn, and produce 
nothing, that will not make the existing implementations go away.

---

From: cowwoc <[email-masked]>
Date: Tue, 14 Jan 2014 09:15:28 -0500

I stand corrected: 
http://developer.android.com/guide/appendix/media-formats.html

Both H.264 and VP8 encoder/decoders are supported. Thanks for catching that.

I'm still curious if anyone has seen a public API for hardware 
encoding/decoding of video outside of Android...

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 14 Jan 2014 09:30:43 -0500

Thanks for this post. It *does* help.

My original argument revolved around #2. The only platform where I can 
see the possibility of WebRTC being baked into the operating system is 
iOS. All other operating systems are open enough that they would expose 
public APIs for doing this in user space. Now, in the case of iOS: do 
any of the devices support hardware *encoding* of H.264? If so, which 
iPhone/iPad versions?

Thanks,
Gili

---

From: Ron <[email-masked]>
Date: Wed, 15 Jan 2014 01:17:07 +1030

> encoding/decoding of video outside of Android...

The more interesting question to me would be if someone could give us an
estimate of what proportion of Android devices actually have either ASIC
hardware support for both of these, or sufficiently capable CPUs to do
them in software?

If access to both of these is guaranteed on that platform, then it almost
doesn't matter what the others are doing, if we choose VP8 then we have
support on something like 80% of the mobile device market.[1]

The others will either follow along soon enough, or ...  burn their
platforms I guess.[2]

What am I missing that nobody has pointed this out for us already?

  Cheers,
  Ron

[1]  And most (or all?) of the rest have no support for using the onboard
     acceleration for either case anyway.

[2]  Unless they get a belated interest in H.261 maybe.

---

From: Cb B <[email-masked]>
Date: Tue, 14 Jan 2014 06:53:44 -0800

> >H.264 in a web browser). My point is that unless a legacy device can do
everything I mentioned in the top bullet points then it's not relevant to
the MTI discussion.
>
> I don't agree.
>
> >> Regarding the third bullet, it is true that gateway functionality will
often be needed to handle WebRTC specific features (continous consent etc).
But, such gateway wouldn't have to do video transcoding.
> >
> > If we're going to talk about gateways, it's important for you to
explain what kind of devices are on either end. Please clarify.
> But, of course the networks/devices on the other side could also be
non-IMS SIP networks.

You gave IMS as an example, but afaik IMS video calling is not widely
deployed. Afaik, it is not deployed at scale in production at all.

In fact, there may be a case that WebRTC voice and video is more widely
deployed than any pure IMS 3gpp deployment.

I lately noticed that Facebook now has voice and video calls without a
plugin (i think..)

So perhaps IMS video is not a good example of an install base since it does
not exist.

CB
> > It is about the fact the communication involves two or more parties,
and we want to enable video communication between RTCWEB user and the rest
of the entities in the world that are capable of video, without having to
resort to transcoding video on all calls. Yes transcoding is possible, but
it has a cost that someone will have to pay for, and it introduces delay,
which can be catered for, but removes the possibility of someone else in
the call path using that delay portion.
> > Given your concerns about "old" systems and "od" features, I'm a little
bit surprised that your are part of them.
> > This is a fallacy. No one is arguing that you should be stuck with
using *just* H.261. What we are saying is that: if H.264 or VP8 are
available on both end-points, great. If not, you can either:
> >
> >    *   Use H.261, or
> >    *   Transcode, or
> >    *   Drop Video
> >
> > By eliminating H.261 as MTI, you lose the first option and are forced
to either transcode or drop video. The cost to supporting H.261 is as
simple as compiling https://github.com/Vproject/p64 and popping it on your
device. You don't need hardware support because it's so computationally
cheap.
> > And finally, we're not objecting to the use of H.264, per se, but
rather to the fact that the majority of people who vote for it and against
everything else use "legacy interoperability" as argument.

---

From: Cb B <[email-masked]>
Date: Tue, 14 Jan 2014 06:59:16 -0800

[email-masked]> wrote:
> > >H.264 in a web browser). My point is that unless a legacy device can
do everything I mentioned in the top bullet points then it's not relevant
to the MTI discussion.
> >
> > I don't agree.
> >
> > >> Regarding the third bullet, it is true that gateway functionality
will often be needed to handle WebRTC specific features (continous consent
etc). But, such gateway wouldn't have to do video transcoding.
> > >
> > > I don't understand. I don't think that VP8 (or any other codec) as
MTI implies that you would have to transcode in the gateway.
plugin (i think..)
>
> So perhaps IMS video is not a good example of an install base since it
does not exist.
> CB

I have not tested facebook video calling, so lets not discuss it.

I have also never tested IMS video calling. So lets not discuss that either
unless you have a noteworthy example that is in production at scale and is
worth discussing as an install base.

CB
expect RTCWEB to be interoperable with existing video equipment? I just
don't get this argument.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 14 Jan 2014 16:55:27 +0000

On 1/14/14, 4:35, "Tim Panton" <[email-masked]> wrote:

>> In those terms, I do not believe that is what they were showing, at
>>least according to the reports I have seen.
>> 
>> Further, apart from any processing power, the critical issue is the
>>delay involved in any conversion, and I have no figures for that from
>>this demonstration, and I suspect you do not either. Given that you must
>>receive frames to do the conversion, my belief is that we will still be
>>talking both decode and encode delay at the conversion point of the
>>order of 60 - 70 ms, whatever mechanism is used. That is a significant
>>take from the limits specified in ITU Recommendation G.114.
>> 
>> Regards
>> 
>> Keith
>> 
>
>My experience of the existing mass h264 deployments in the mobile space
>is that they like to split the the audio and

RTP is designed to take care of this.

---

From: Tim Panton <[email-masked]>
Date: Tue, 14 Jan 2014 16:59:42 +0000

> RTP is designed to take care of this.

Not if audio and video are on separate calls - which seems to be what RCS/joyn 
expects.

T.

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 14 Jan 2014 17:27:33 +0000

Hi,

it¹s somewhat funny that, on an IETF RAI area mailing list, people appear
to forget about the arguably prime source of delay in any RTP receiver,
including an RTP receiver in a transcoding box: the jitter buffer.  My
understanding is that most folks who run video over RTP over the Internet
(in contrast to a private IP network) use jitter buffers of hundred
milliseconds plus in size.

Most practical video communication system over the Internet involves forms
of retransmission or forward error correction, or both.  Those add delay
in case they are invoked to recreate packets lost in transmission, in the
transcoder and separately also in the final receiver.

As for the delay introduced by the transcoding engine alone, let me note
that the single or two frame delay commonly attributed to transcoding is
realistic only for straightforward PPP type coding.  My understanding is
that VP8, in its default encoder settings, uses much more complex GOP
structures for error resilience and coding efficiency reasons.  H.264
constrained baseline certainly also allows that (it¹s even more flexible
in that regard).  Complex GOP structures are anywhere between helpful to
essential (depending on your viewpoint) for error resilience.  Complex GOP
structures do not necessarily increase the latency in an overall system
design in the absence of errors (they are not based on MPEG-2 B frame type
of thinking), but when error correction becomes necessary, a transcoder
would need to emulate receiver behavior, and that certainly would induce
delay of several hundred milliseconds which would not be observable in a
transcoder-free operation (under the assumption that the end system
chooses to display slightly distorted video) but will be observable and
unavoidable in the transcoder-based design.

I¹m very familiar with H.264 baseline, and somewhat familiar with the VP8
syntax.  Based on this knowledge, I doubt that one can transcode between
the two formats in the compressed domain, i.e. without full reconstructed
to the sample level.  I am absolutely convinced that compressed domain
transcoding in the direction from H.264 to VP8 is impossible, due to the
larger feature set of H.264.  ³Impossible² means here that I could create
an H.264 compliant bitstream that cannot be transcoded into VP8 in the
compressed domain, because there is no syntax equivalent for an H.264 tool
in VP8.  For example, H.264 constrained baseline supports more than three
reference pictures, whereas VP8 uses no more than three (last frame,
golden frame, and alternate reference frame).  It wouldn¹t take me long to
extend this list to several pages.  I¹m also fairly certain that people
more familiar with the VP8 syntax could similarly identify VP8 features
that have no direct counterpart in H.264.  Insofar, I take any statement
about ²availability² of compressed domain transcoding between the two
coding schemes with a large grain of salt.  It may be possible (I don¹t
know) to transcode in the compressed domain between H.264/VP8 bitstreams
when the respective input bitstream is specifically tailored for that
purpose, and perhaps that is what people have in mind.

Regards,
Stephan

On 1/14/14, 2:22, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

>Further, apart from any processing power, the critical issue is the delay
>involved in any conversion, and I have no figures for that from this
>demonstration, and I suspect you do not either. Given that you must
>talking both decode and encode delay at the conversion point of the order
>of 60 - 70 ms, whatever mechanism is used. That is a significant take
>from the limits specified in ITU Recommendation G.114.
>
>Regards
>
>Keith
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 14 Jan 2014 17:35:07 +0000

IMS VoLTE has them both in the same SDP session.

Not familiar enough with RCS to comment.

Regards

Keith

> From: Tim Panton [mailto:[email-masked]] 
> Sent: 14 January 2014 17:00
> To: Stephan Wenger
> >>> delay involved in any conversion, and I have no figures for that 
> >>> from this demonstration, and I suspect you do not either. 
> Given that 
> >>> you must receive frames to do the conversion, my belief 
> is that we 
> >>> will still be talking both decode and encode delay at the 
> conversion 
> >>> point of the order of 60 - 70 ms, whatever mechanism is 
> used. That 
> >>> is a significant take from the limits specified in ITU 
> Recommendation G.114.
> >>> 
> >>> Regards
> >>> 
> >>> Keith
> >>> 
> >> 
> >> My experience of the existing mass h264 deployments in the mobile 
> >> space is that they like to split the the audio and video 
> media paths. 
> >> (You'd need to do this in any gateway to these legacy systems).
> >> This means that they can get out of sync. This would be 
> made worse by 
> >> transcoding the video leg.
> > 
> Not if audio and video are on separate calls - which seems to 
> be what RCS/joyn expects.
> 
> T.
> 
>

---

From: Tim Panton <[email-masked]>
Date: Tue, 14 Jan 2014 17:40:49 +0000

> IMS VoLTE has them both in the same SDP session.

How many IMS VoLTE devices have been shipped ?

(I'm trying to gauge the value of this legacy market).

T.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 14 Jan 2014 17:54:02 +0000

> Not familiar enough with RCS to comment.
RCS has different modes. If RCS sees VoLTE is available on that device then it uses VoLTE for audio/video communications. In general RCS uses underlying audio/video calling technology that is available, per access technology (including non-3gpp access), on the device.

There is a detailed description of this in table 2 of "Rich Communication Suite 5.1 Advanced Communications Services and Client Specification Version 4.028 November 2013".
This RCS spec can be downloaded from http://www.gsma.com/futurecommunications/rcs/specs-and-product-docs/ (select "Specifications" then "RCS 5.1 UNI").

-Raju

---

From: Steve McFarlin <[email-masked]>
Date: Tue, 14 Jan 2014 10:00:23 -0800

It looks like Blackberry has API’s for H.264 encoding/decoding [1], and windows phone also looks like it may have API’s (I don’t have enough time to really look) [2]. 

[1] http://developer.blackberry.com/native/reference/core/com.qnx.doc.camera.lib_ref/topic/manual/camera_h264avc.h_enums_overview.html

[2] http://msdn.microsoft.com/en-us/library/windowsphone/develop/windows.phone.media.capture.h264encoderprofile(v=vs.105).aspx

On Jan 14, 2014, at 6:15 AM, cowwoc <[email-masked]> wrote:

> I stand corrected: http://developer.android.com/guide/appendix/media-formats.html
> 
> I'm still curious if anyone has seen a public API for hardware encoding/decoding of video outside of Android...
> 
> Gili
>

---

From: Steve McFarlin <[email-masked]>
Date: Tue, 14 Jan 2014 10:05:47 -0800

iOS has the VideoToolbox API for H.264 hardware coding, but this is a private framework. User mode applications are not allowed to create an IO channel without a Jailbreak. The framework is public in OS-X. I filed a bug report with Apple as the framework is in the public folder in the iOS SDK, but there are no headers. An engineer got back to me and said that ‘is by design’.

On Jan 14, 2014, at 6:30 AM, cowwoc <[email-masked]> wrote:

> My original argument revolved around #2. The only platform where I can see the possibility of WebRTC being baked into the operating system is iOS. All other operating systems are open enough that they would expose public APIs for doing this in user space. Now, in the case of iOS: do any of the devices support hardware *encoding* of H.264? If so, which iPhone/iPad versions?
> 
> Thanks,
> Gili
>

---

From: cowwoc <[email-masked]>
Date: Tue, 14 Jan 2014 14:31:57 -0500

I had a similar experience, which is why I don't expect iOS support 
anytime soon.

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 14 Jan 2014 14:35:06 -0500

Hi,

Can we please make a concrete list of how many legacy devices with video 
encoding/decoding capability have shipped? How many of them could 
realistically interoperate with WebRTC? How many of them have a large 
enough market-share and video resolution to make them noteworthy?

Please, if your product(s) fall into this category please mention them now.

Thanks,
Gili

On 14/01/2014 9:59 AM, Cb B wrote:
>
>
> On Jan 14, 2014 6:53 AM, "Cb B" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> >
> > On Jan 13, 2014 11:51 PM, "Christer Holmberg" 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > >
> > > Hi,
> > >
> > > >H.264 in a web browser). My point is that unless a legacy device 
> can do everything I mentioned in the top bullet points then it's not 
> relevant to the MTI discussion.
> > >
> > > I don't agree.
> > >
> > > >> Regarding the third bullet, it is true that gateway 
> functionality will often be needed to handle WebRTC specific features 
> (continous consent etc). But, such gateway wouldn't have to do video 
> transcoding.
> > > >
> > > > I don't understand. I don't think that VP8 (or any other codec) 
> as MTI implies that you would have to transcode in the gateway.
> > > >
> > You gave IMS as an example, but afaik IMS video calling is not 
> widely deployed. Afaik, it is not deployed at scale in production at all.
> >
> > In fact, there may be a case that WebRTC voice and video is more 
> widely deployed than any pure IMS 3gpp deployment.
> >
> > I lately noticed that Facebook now has voice and video calls without 
> a plugin (i think..)
> >
> > So perhaps IMS video is not a good example of an install base since 
> it does not exist.
> >
> > CB
> >
>
> I have also never tested IMS video calling. So lets not discuss that 
> either unless you have a noteworthy example that is in production at 
> scale and is worth discussing as an install base.
>
> CB
> > >
> > >
> > > > From: rtcweb [[email-masked] 
> <mailto:[email-masked]>] on behalf of cowwoc
> > > > [[email-masked] <mailto:[email-masked]>]
> > > > To: DRAGE, Keith (Keith); [email-masked] <mailto:[email-masked]>
> > > > Subject: [rtcweb] There are no legacy WebRTC devices (Was: 
> Comment on
> > > > Straw Poll replies)
> > > >
> > > > Keith,
> > > >
> magically begin supporting WebRTC. This will require *new* products to 
> get released.
> > > >
> > > > Gili
> > > >
> parties, and we want to enable video communication between RTCWEB user 
> and the rest of the entities in the world that are capable of video, 
> without having to resort to transcoding video on all calls. Yes 
> transcoding is possible, but it has a cost that someone will have to 
> pay for, and it introduces delay, which can be catered for, but 
> removes the possibility of someone else in the call path using that 
> delay portion.
> > > >
> > > > From: rtcweb [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of cowwoc
> <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]><mailto:[email-masked] 
> <mailto:[email-masked]>> wrote:
> > > >
> > > >
> > > > Can I ask why you even bother with WebRTC, if you want to 
> restrict WebRTC to interoperability with old systems only and 
> > > > I'd like to suggest that such replies should be disregarded 
> because they look backwards and not forwards.
> > > >
> > > >
> > > > However if you want to go that way, and if you want to get rid 
> of old technologies, let's start by disregarding replies from those 
> who could live with a WebRTC technology that would specify H.261 as 
> only  MTI codec.
> with using *just* H.261. What we are saying is that: if H.264 or VP8 
> forced to either transcode or drop video. The cost to supporting H.261 
> is as simple as compiling https://github.com/Vproject/p64 and popping 
> it on your device. You don't need hardware support because it's so 
> computationally cheap.
> > > >
> but rather to the fact that the majority of people who vote for it and 
> support *existing* devices then we would use *existing* technologies. 
> For that reason, I don't think maintaining backwards compatibility is 
> important when breaking it has a noticeable benefit (and in this case, 
> I believe it does).
> > > >

---

From: "Cavigioli, Chris" <[email-masked]>
Date: Tue, 14 Jan 2014 19:50:17 +0000

Why are we debating this?  There are billions of Android devices shipped in recent years and billions of PCs shipped in recent years.  They can be programmed with apps, browsers and sw programs to support WebRTC.

From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Tuesday, January 14, 2014 11:35 AM
To: [email-masked]
Subject: Re: [rtcweb] There are no legacy WebRTC devices (Was: Comment on Straw Poll replies)

Hi,

Can we please make a concrete list of how many legacy devices with video encoding/decoding capability have shipped? How many of them could realistically interoperate with WebRTC? How many of them have a large enough market-share and video resolution to make them noteworthy?

Thanks,
Gili

On Jan 14, 2014 6:53 AM, "Cb B" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> On Jan 13, 2014 11:51 PM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi,
> >
> You gave IMS as an example, but afaik IMS video calling is not widely deployed. Afaik, it is not deployed at scale in production at all.
>
> In fact, there may be a case that WebRTC voice and video is more widely deployed than any pure IMS 3gpp deployment.
>
> I lately noticed that Facebook now has voice and video calls without a plugin (i think..)
>
> So perhaps IMS video is not a good example of an install base since it does not exist.
>
> CB
>

I have also never tested IMS video calling. So lets not discuss that either unless you have a noteworthy example that is in production at scale and is worth discussing as an install base.

CB
> > > From: rtcweb [[email-masked]<mailto:[email-masked]>] on behalf of cowwoc
> > > [[email-masked]<mailto:[email-masked]>]
> > > From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of cowwoc
> > > To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > On 10/01/2014 9:54 AM, [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > >
> > [email-masked]<mailto:[email-masked]>

---

From: cowwoc <[email-masked]>
Date: Tue, 14 Jan 2014 16:25:46 -0500

Many people who answered the straw poll argued that we must use H.264 
for the sake of interoperability with legacy devices that only support 
H.264. I am trying to explore this argument.

Android is not an H.264-only device, therefore it is not relevant to 
this discussion.

Gili

On 14/01/2014 2:50 PM, Cavigioli, Chris wrote:
>
> Why are we debating this?  There are billions of Android devices 
> shipped in recent years and billions of PCs shipped in recent years.  
> They can be programmed with apps, browsers and sw programs to support 
> WebRTC.
>
> *From:*rtcweb [mailto:[email-masked]] *On Behalf Of *cowwoc
> *Sent:* Tuesday, January 14, 2014 11:35 AM
> *To:* [email-masked]
> *Subject:* Re: [rtcweb] There are no legacy WebRTC devices (Was: 
> Can we please make a concrete list of how many legacy devices with 
> video encoding/decoding capability have shipped? How many of them 
> could realistically interoperate with WebRTC? How many of them have a 
> large enough market-share and video resolution to make them noteworthy?
>
>     > > >H.264 in a web browser). My point is that unless a legacy
>     device can do everything I mentioned in the top bullet points then
>     it's not relevant to the MTI discussion.
>     > >
>     > > I don't agree.
>     > >
>     functionality will often be needed to handle WebRTC specific
>     features (continous consent etc). But, such gateway wouldn't have
>     to do video transcoding.
>     > > >
>     > > > I don't understand. I don't think that VP8 (or any other
>     codec) as MTI implies that you would have to transcode in the gateway.
>     > > >
>     > > > If we're going to talk about gateways, it's important for
>     you to explain what kind of devices are on either end. Please clarify.
>     > >
>     I have also never tested IMS video calling. So lets not discuss
>     that either unless you have a noteworthy example that is in
>     production at scale and is worth discussing as an install base.
>
>     CB
>     > >
>     > >
>     <mailto:[email-masked]>
>     user and the rest of the entities in the world that are capable of
>     video, without having to resort to transcoding video on all calls.
>     Yes transcoding is possible, but it has a cost that someone will
>     have to pay for, and it introduces delay, which can be catered
>     for, but removes the possibility of someone else in the call path
>     > > > However if you want to go that way, and if you want to get
>     rid of old technologies, let's start by disregarding replies from
>     those who could live with a WebRTC technology that would specify
>     H.261 as only  MTI codec.
>     > > > Given your concerns about "old" systems and "od" features,
>     I'm a little bit surprised that your are part of them.
>     > > >
>     stuck with using *just* H.261. What we are saying is that: if
>     H.264 or VP8 are available on both end-points, great. If not, you
>     can either:
>     > > >
>     > > >    *   Use H.261, or
>     > > >    *   Transcode, or
>     > > >    *   Drop Video
>     > > >
>     https://github.com/Vproject/p64 and popping it on your device. You
>     > > > And finally, we're not objecting to the use of H.264, per
>     se, but rather to the fact that the majority of people who vote
>     for it and against everything else use "legacy interoperability"
>     as argument.
>     > > >

---

From: John Leslie <[email-masked]>
Date: Wed, 15 Jan 2014 08:44:38 -0500

Stephan Wenger <[email-masked]> wrote:
> realistic only for straightforward PPP type coding.

   I agree that seems optimistic...

> My understanding is that VP8, in its default encoder settings, uses
> much more complex GOP structures for error resilience and coding
> efficiency reasons.  H.264 constrained baseline certainly also allows
> that (it?s even more flexible in that regard). Complex GOP structures
> are anywhere between helpful to essential (depending on your viewpoint)
> for error resilience.

   I would hope that error resilience could become orthogonal to
transcoding -- though I agree it doesn't seem to be there yet.

> Complex GOP structures do not necessarily increase the latency in an
> overall system design in the absence of errors (they are not based on
> MPEG-2 B frame type of thinking), but when error correction becomes
> necessary, a transcoder would need to emulate receiver behavior, and
> that certainly would induce delay of several hundred milliseconds
> which would not be observable in a transcoder-free operation (under
> the assumption that the end system chooses to display slightly
> distorted video) but will be observable and unavoidable in the
> transcoder-based design.

   The mistake here is optimizing for resilience assuming the same
coding/decoding rules when, in fact, the endpoints don't share the
same rules. Yes, that very much gets in the way of minimal latency.

> I?m very familiar with H.264 baseline, and somewhat familiar with the VP8
> larger feature set of H.264.  ?Impossible? means here that I could create
> in VP8.

   I agree. (And this is worth re-reading several times for anyone
participating in discussion of transcoding.)

> For example, H.264 constrained baseline supports more than three
> golden frame, and alternate reference frame).  It wouldn?t take me long to
> extend this list to several pages.  I?m also fairly certain that people
> about ?availability? of compressed domain transcoding between the two
> coding schemes with a large grain of salt.  It may be possible (I don?t

   It would also be possible to declare transcoding failure in cases like
these -- that's a tradeoff between precision and latency which should
be available at application layer.

   But, IMHO, it's probably better to disable error-resilience features
that poison transcoding when we know transcoding will be used.

   YMMV, of course...

--
John Leslie <[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Jan 2014 14:11:23 +0100

On 01/15/2014 02:44 PM, John Leslie wrote:
>> efficiency reasons. 

I have no idea where this idea comes from.

The dependency structures of VP8 when used in interactive mode are often
quite complex, with the purpose of minimizing recovery time when frames
are lost or damaged, but dependencies are always backwards-pointing;
there is no rearrangement of picture order.

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 16 Jan 2014 17:04:16 +0000

>there is no rearrangement of picture order.

That¹s what I thought, and tried to express, and apparently failed.

Additional delay over straightforward PPP coding comes in only when you
loose something and want to take advantage of your complex GOP structure.
That additional delay is certainly less than the delay you would catch by
coding an I picture and sending that over a bandwidth-limited link, which
is one reason of many why things wrt. GOP structures are as they are in
modern systems.  (That feature, by the way, is the same in modern H.264
implementations and VP8 implementations, and, obviously, it¹s an
encoder/sending system choice.)

Stephan

---

From: Randell Jesup <[email-masked]>
Date: Fri, 24 Jan 2014 18:47:37 -0500

> hardware support for both of these, or sufficiently capable CPUs to do

Note that "an encoder" != "a useful realtime interactive encoder". 
(Though many may be - but how do you tell?)  Encoders are almost 
required for local camera video capture and recording, but those don't 
need to have the sort of controls or options that a realtime interactive 
codec does.  Since these are standard blocks, they may have all the 
right knobs, but how well is that tested?  (Obviously this applies to 
all HW codecs, except that no one is using VP8 for camera video currently.)

Another caveat: HW encoders/decoders may have a limit on the number of 
streams they can process (and that limit may well be 1).  That means 
that simulcast and multi-stream conference reception might need to use 
SW codecs for some streams.  (Or so I've been told by people working 
with OMX; I assume I understood correctly.)

-- 
Randell Jesup -- rjesup a t mozilla d o t com