Subject: Re: [dispatch] Codec standardization (Re: [RTW] Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

From: Heinrich Sinnreich <[email-masked]>
Date: Sun, 26 Dec 2010 21:12:37 -0500

>I think we should consider the balance
> between cost, risk, quality, and existing adoption, and it would be foolish to
> omit cost-bearing codecs from that analysis, as H.264 is widely used already.

I am not sure where this discussion is going, though it reminds us of the
discussions when arguing about SIP vs. H.323 in the IETF.
"Everybody" was shipping H.323 in overwhelming quantity, but somehow the
IETF did not buy it.

As an hopeless optimist; maybe H.264 will have the same fate since at least
it's considerable IP baggage is so well known...

It is hard to imagine the IETF and indeed the market will ignore the
creativity of all the codec developers out there and the evolving technology
that empowers them. Plain self interest should motivate embracing new
IP-free a/v codecs for the RTC Web. They will arrive anyway one way or
another. 

[Well deployed technology has a proven way to make it over the threshold
into history :-)] 

Henry

On 12/22/10 5:46 PM, "David Singer" <[email-masked]> wrote:

> I should say that I am perfectly happy to have the discussion about whether,
> and what, to mandate codec(s).  If the placeholder is there to spark the
> discussion, you succeeded!
> 
> For me, significant IPR risk is worse than a payment -- free but risky is not
> an improvement on costs-but-low-risk.  But others may differ, of course.
> 
> I do think we should be looking carefully at layered design.  Ideally, we
> define the missing technology bits -- HTML, Javascript/DOM, and so on;  and
> then, perhaps, we write an umbrella specification that uses those, and other
> technology pieces, to achieve an interoperable end.  But the pieces should
> 'make sense' by themselves, and be usable with other assemblages, I think, if
> the specs are to have 'legs' and survive over years.  The pieces are ideally
> stable standards/publications in their own right (and I agree, sometimes,
> rarely, something is stable and well-known enough, such as ZIP or ID3 tags,
> without being a 'standard').
> 
> I also agree that RF codecs are happening and are here to stay.  Those of you
> who know me from MPEG will have heard this before.  They will exist, and they
> will have a place. MPEG is working (slowly) on RF codecs as well.
> 
> As to what MPEG-LA is doing, I am afraid I don't actually know. We'd have to
> ask them, and they tend not to reply. The silence is strange, but I don't
> think that mitigates the possibility that there is an IPR entanglement.
> 
> Despite Henry's position (that mentioning VP8 results in no rat-holes and
> flames, and that mentioning H.264 will) I think we should consider the balance
> between cost, risk, quality, and existing adoption, and it would be foolish to
> omit cost-bearing codecs from that analysis, as H.264 is widely used already.
> 
> The link between open-source and royalty-free is not perfect;  there are
> quality open-source implementations of non-free codecs, for a start, and there
> are companies who license proprietary systems royalty-free.  Let's not confuse
> the two, even if they often occur together.
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: David Singer <[email-masked]>
Date: Wed, 29 Dec 2010 20:07:33 -0800

Heinrich,

'best' is not always IPR-cost-free.  Sometimes it is, sometimes it isn't.  You seem unable to see any other possibility than your own, alas.  I could wish for 'fates' for any number of technologies, but I don't: I choose them when they suit, and others when they don't.  I suggest we do the same.

I have no objection to the development and deployment of new codecs, with varying terms, quality, complexity, and so on. This is a varied market that deserves varied tools.  I do object to making decisions based on only one criterion, however.

David Singer

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 29 Dec 2010 22:09:46 -0800

For video codecs, "self interest" may be influenced by a number of factors.

For example, for a mobile applications developer, "self interest" may focus
on
aspects such as performance, battery life and maintenance costs.  If a given
codec is
supported in the hardware or operating system of their target platform, then
the developer
may perceive it being low "cost" to them. 

For a chipset manufacturer, "self interest" may be determined by the demand
for chipsets
incorporating a given codec, as well as the associated licensing fees.
Typically the goal
is to maximize revenue minus cost, not just to minimize "cost". 

These concepts of "self interest" not necessarily align with each other, let
alone with the 
"self interest" of users, who may primarily care about how many other users
they can connect 
with. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Singer
Sent: Wednesday, December 29, 2010 8:08 PM
To: Heinrich Sinnreich
Cc: [email-masked]; [email-masked]
Subject: Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version
Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)

Heinrich,

'best' is not always IPR-cost-free.  Sometimes it is, sometimes it isn't.
You seem unable to see any other possibility than your own, alas.  I could
wish for 'fates' for any number of technologies, but I don't: I choose them
when they suit, and others when they don't.  I suggest we do the same.

I have no objection to the development and deployment of new codecs, with
varying terms, quality, complexity, and so on. This is a varied market that
deserves varied tools.  I do object to making decisions based on only one
criterion, however.

David Singer

_______________________________________________
RTC-Web mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/rtc-web

---

From: <[email-masked]>
Date: Thu, 30 Dec 2010 15:52:26 +0000

Hi, 

A couple of questions and comments on draft-alvestrand-dispatch-rtcweb-datagram-00:

* Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it expected that all clients MUST support all of these? I suppose the reason why both UDP and TCP are included is that depending on the types of middleboxes the peers are behind, they may get just one or the other working. I.e. first try out UDP, if it does not work, attempt TCP. Is that correct?

* Section 4.5 states that TURN and relaying are needed. How about things like HTTP/TLS tunneling? In many cases that is the only way to get the transport channel working. TURN may be helpful in some, hopefully increasing, amount of cases, but that alone will still leave a lot of corporate users unserved.

* Section 3 mentions that things like pseudoTCP can be run over the datagram transport. In case only UDP works end-to-end that seems useful. However, if we can get a "native" TCP connection up, it seems natural to use that as is rather than via some kind of generic datagram abstraction layer. I think we probably should define both datagram and bytestream services separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do datagram service, leave the whole pseudoTCP reference out.

* Section 6 defines a URI with a number of IP address:transport:port candidates. I'm not too clear on how that URI would be used. It looks to me as something that is received as a result of gathering the candidates (with STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or some proprietary protocol were used to pass the candidate information to the other peer, that information would be encoded according to that particular protocol. So is this specific URI just meant for local representation at the API and not something that is passed over the network as such? What's the need or benefit of making it a URI?

Thanks,
	Markus

---

From: <[email-masked]>
Date: Thu, 30 Dec 2010 16:10:45 +0000

Hi,

A few comments and questions on rtcweb-protocols-00:

In general I believe we need a framework document that describes how the various protocol and API specs are used to build an interoperable "RTC-Web" implementation. In my opinion that document should not be like RFC 5411 (Hitchhiker's guide to SIP), which is merely listing of different SIP related standards. Instead, the RTC-Web framework document should define what is the minimum set that everyone needs to implement to get interop at a reasonable level. (What that reasonable level is needs to be agreed upon, of course. I assume it includes at least transport and NAT traversal for audio/video streams.)

I understand that the current document is not yet intended for that purpose, but it is just trying to get discussion started. But if we pick this draft as a baseline going forward, it would be useful to make the use of language more consistent. At the moment some things are defined with "MUST" statements while others are more vague. I think the "MUST" statements are good and everything that is really required by an implementation needs to be expressed that way. (It is naturally good to have some descriptive text around the exact requirements, as long as the requirements are clear.)

Section 4 defines data framing and security. I believe the challenging part of data framing will be to ensure we get the video calls interoperable. I don't have that much experience on the details, but I know that getting RTP/AVPF stuff implemented and interoperable is not that trivial. Various groups such as IMTC and UCIF have worked on interoperability profiles for video calls. The easy approach might be just to mandate the basics (RTP/AVP), get that well working across browsers and then extend based on that experience. If those other groups come up with something useful and public, those profiles could be borrowed. 

Section 6 is about connection management. That will be the really hard part of this exercise. I do support the notion that at least initially we should focus on transport, framing and formats of media, and say that those can be setup in proprietary ways (presumably the browser using HTTP or websocket as transport for the actual setup). For that the APIs would "only" need to support what is input/output to ICE/STUN/TURN and codec selection, while the rest happens in Javascript within the application. But going forward I think we do need to pick up either SIP/SDP or XMPP/Jingle as the baseline, in order to make things easy to use. 

Markus

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 30 Dec 2010 11:02:42 -0600

This should mark a good progress for the discussion ending this year and we

> "self interest" of users, who may primarily care about how many other users

The interests of users must be first and foremost in mind for defining a
standard for the default video codec.

It includes not passing the cost of licensing in perpetuity along to users.

Given a choice for open source and/or free video codecs such as Theora and
VP8, the IETF has several good options to choose from, also defining of a
video codec from ground up.

Thanks,

Henry

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 30 Dec 2010 12:38:52 -0500

I'm with Bernard and David on this one.

This is different from the audio case, as hardware acceleration is much more
important for video, particularly for mobile.

Stephen Botzko

On Thu, Dec 30, 2010 at 12:02 PM, Henry Sinnreich <[email-masked]
> wrote: