Subject: Re: [rtcweb] Video codec selection - way forward

From: Jeremy Fuller <[email-masked]>
Date: Thu, 14 Nov 2013 11:37:54 +0000

Hi,

Gaining IETF consensus on making it mandatory to support only H.264 or only VP8 has clearly failed. I would welcome anyone to share their thoughts on why they believe this situation will change anytime in the next few years.  Therefore, can I suggest that we remove items 1 and 2 from the list. Hopefully this will speed up the process by focusing efforts towards gaining agreement on one of the remaining options.

The following alternatives has been proposed:
1.      All entities MUST support H.264
2.      All entities MUST support VP8
3.      All entities MUST support both H.264 and VP8
4.      Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
5.      All entities MUST support at least one of H.264 and VP8
6.      All entities MUST support H.261
7.      There is no MTI video codec
8.      All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
Regards,
Jeremy Fuller

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Nov 2013 10:57:20 -0500

I agree with others that SHOULD implement both, or other variations on
SHOULD, are not helpful. They will anyway be ignored and amount to more or
less the no-interop situation we're in if we continue on the current path
and have no consensus.  No consensus means the various players doing as
they prefer, which is what they'd do if there is a SHOULD.

On Thu, Nov 14, 2013 at 6:37 AM, Jeremy Fuller <[email-masked]>wrote:

>  Hi,
>
> Gaining IETF consensus on making it mandatory to support only H.264 or
> only VP8 has clearly failed. I would welcome anyone to share their thoughts
> on why they believe this situation will change anytime in the next few
> years.  Therefore, can I suggest that we remove items 1 and 2 from the
> list. Hopefully this will speed up the process by focusing efforts towards
> gaining agreement on one of the remaining options.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
Jonathan Rosenberg, Ph.D.
[email-masked]
http://www.jdrosen.net

---

From: David Singer <[email-masked]>
Date: Fri, 15 Nov 2013 10:10:32 +0800

On Nov 14, 2013, at 23:57 , Jonathan Rosenberg <[email-masked]> wrote:

> I agree with others that SHOULD implement both, or other variations on SHOULD, are not helpful. They will anyway be ignored and amount to more or less the no-interop situation we're in if we continue on the current path and have no consensus.  No consensus means the various players doing as they prefer, which is what they'd do if there is a SHOULD.

I don't agree.  I think that MUST implement at least one of them, and SHOULD do both, provides both clear guidance as to the interop points, and clear pressure to implement both.  I think it's as close to interop as we are likely to get.  

I have no idea why browsers should be singled out for special pain, nor whether that is remotely reasonable, nor whether there is a good definition of one (look at the places where projects such as webkit are embedded, for example).

> 
> 
> On Thu, Nov 14, 2013 at 6:37 AM, Jeremy Fuller <[email-masked]> wrote:
> Hi,
>  
> 	• All entities MUST support H.264
> 	• All entities MUST support VP8
> 	• All entities MUST support both H.264 and VP8
> 	• Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
> 	• All entities MUST support at least one of H.264 and VP8
> 	• All entities MUST support H.261
> 	• There is no MTI video codec
> 	• All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
> Regards,
> Jeremy Fuller
>  
> 

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 15 Nov 2013 14:44:01 +0100

> I don't agree.  I think that MUST implement at least one of them, and SHOULD do both, provides both clear guidance as to the interop points, and clear pressure to implement both.  I think it's as c…

I agree that the addition of SHOULD statements makes a difference in 
perception.

There's been a push at times to have SHOULD statements accompanied with 
descriptions of the conditions under which they apply; in this case, one 
could imagine a statement like "MUST implement VP8, and SHOULD implement 
H.264 (MUST unless using a business model where it's impossible to 
comply with the requirements of the available licenses for H.264 IPR)".

Focusing on the naked MUST statements seems to me to be a strategy that 
emphasizes the battle lines.

---

From: Maik Merten <[email-masked]>
Date: Sun, 17 Nov 2013 20:54:03 +0100

Hello,

just wondering if something like

"9. All entities SHOULD support both H.264 and VP8. All entities MUST at 
least implement one of those. Entities that do not support both H.264 
and VP8 MUST implement H.261."

has already popped up. My reasoning is that implementations supporting 
both high performance codecs will always negotiate to use on of those - 
H.261 should never be relevant there.

It appears that all implementors are willing to implement either H.264 
or VP8 (but not necessarily both). This obviously means that negotiation 
failure regarding a high-performance codec is a possiblity. In this case 
H.261 is actually useful so that basic video calls can still be 
established (for instance, I guess deaf people may always appreciate a 
video connection, as long as sign language can be transmitted).

Maik

Am 14.11.2013 12:37, schrieb Jeremy Fuller:
> only VP8 has clearly failed. I would welcome anyone to share their
> thoughts on why they believe this situation will change anytime in the
> next few years.  Therefore, can I suggest that we remove items 1 and 2
> from the list. Hopefully this will speed up the process by focusing
> efforts towards gaining agreement on one of the remaining options.

---

From: Thomas Reisinger <[email-masked]>
Date: Sun, 17 Nov 2013 21:13:07 +0100

Hi,

Instead of h.261, I would recommend h.263 as a common base.

Cheers,

Thomas 
Sent from mobile device

> On 17 Nov 2013, at 20:54, Maik Merten <[email-masked]> wrote:
> 
> Hello,
> 
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those. Entities that do not support both H.264 and VP8 MUST implement H.261."
> 
> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.
> 
> It appears that all implementors are willing to implement either H.264 or VP8 (but not necessarily both). This obviously means that negotiation failure regarding a high-performance codec is a possiblity. In this case H.261 is actually useful so that basic video calls can still be established (for instance, I guess deaf people may always appreciate a video connection, as long as sign language can be transmitted).
> 
> 
> Maik
> 
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Sun, 17 Nov 2013 15:58:00 -0500

Thomas,

The reason H.261 is even being considered is because it is an old-enough
specification that any patents on it should have now expired.  Patents,
and their liability on existing video formats, are amongst the biggest
factors affecting which formats can be adopted into the rtcweb standard.

H.263 most likely (I haven't checked) still has patents associated with
it that are active and, therefore, present an issue unless the
respective owners of said patents have publicly declared them royalty-free.

-- 
Libre Video
http://librevideo.org

---

From: cowwoc <[email-masked]>
Date: Sun, 17 Nov 2013 22:06:20 -0500

Maik,

Interesting :)

+1 for adding this as a new option. It gives the H.264 and VP8 crowds 
incentive to implement each other's codecs, or suffer with an older 
codec (H.261). It's a win-win either way.

My only worry is that this option will lead to the neglect of H.261 
support. So long as the working group commits to providing a "good 
enough" H.261 implementation (with a commercially-friendly license) as 
part of the reference WebRTC implementation I think we will be okay.

Gili

On 17/11/2013 2:54 PM, Maik Merten wrote:
> "9. All entities SHOULD support both H.264 and VP8. All entities MUST 
> at least implement one of those. Entities that do not support both 
> H.264 and VP8 MUST implement H.261."
>
> both high performance codecs will always negotiate to use on of those 
> - H.261 should never be relevant there.
>
> or VP8 (but not necessarily both). This obviously means that 
> negotiation failure regarding a high-performance codec is a 
> possiblity. In this case H.261 is actually useful so that basic video 
> calls can still be established (for instance, I guess deaf people may 
> always appreciate a video connection, as long as sign language can be 
> transmitted).
>
>
> Maik
>
>

---

From: Thomas Reisinger <[email-masked]>
Date: Mon, 18 Nov 2013 07:51:53 +0100

Team,

I had the same concerns about the royalty fee, but after some research I think there aren't any more. For h.264 this still applies. H.261 is not acceptable anymore in a HD world as it is today. Maybe somebody else cloud put some light on the royalty fees for h.263. I will continue my research.

Cheers,

Thomas Reisinger

> On 17.11.2013, at 21:58, Basil Mohamed Gohar <[email-masked]> wrote:
> 
> Thomas,
>

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 17 Nov 2013 22:58:14 -0800

> has already popped up. My reasoning is that implementations supporting both high performance codecs will always negotiate to use on of those - H.261 should never be relevant there.

This looks promising.  To summarize: You're proposing that each implementation MUST implement (at least) one of the following sets of codecs:
	{VP8, H.264}
	{VP8, H.261}
	{H.264, H.261}

This guarantees that there'll never be negotiation failure (between a pair of implementations), because the intersection of any two of these sets is non-empty.

It also allows the H.264 camp to avoid any alleged additional IPR risk from implementing VP8, because they won't need to implement VP8 (they'll need to implement H.261 instead).

Similarly, it also allows the VP8 camp to avoid any H.264 licensing requirements, because they won't need to implement H.264 (they'll need to implement H.261 instead).

And people who are willing to implement both VP8 and H.264 will know that they'll always be able to negotiate high-quality video.

Who knows - this may well be something that we could reach consensus on (provided that everyone agrees that there's little IPR risk from H.261)...

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Leon Geyser <[email-masked]>
Date: Mon, 18 Nov 2013 09:13:25 +0200

Hi Thomas,

On this list there seem to be patents listed from 1997 to 2011 for H.263:
http://www.itu.int/net4/ipr/search.aspx?sector=ITU&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=anokwcvd

On 18 November 2013 08:51, Thomas Reisinger <[email-masked]> wrote:

> Team,
>
> I had the same concerns about the royalty fee, but after some research I
> think there aren't any more. For h.264 this still applies. H.261 is not
> acceptable anymore in a HD world as it is today. Maybe somebody else cloud
> put some light on the royalty fees for h.263. I will continue my research.
>
> Cheers,
>
> Thomas Reisinger
>
> at least implement one of those. Entities that do not support both H.264
> H.261 is actually useful so that basic video calls can still be established
> (for instance, I guess deaf people may always appreciate a video
> connection, as long as sign language can be transmitted).
> >>>
> >>>
> >>> Maik
> >>>
> >>>

---

From: Maik Merten <[email-masked]>
Date: Mon, 18 Nov 2013 08:57:49 +0100

Dear Ross,

thanks for providing your thoughts on this proposal. Your analysis quite 
perfectly reflects my reasoning.

I think there is consensus that both H.264 Constrained Baseline and VP8 
are capable of delivering high quality video. However...

  - the camp opposing VP8 fears that Google is not in complete control 
of the surrounding IPR situation
  - the camp opposing H.264 presented diverse examples where H.264's 
licensing is not compatible with their very operating principles

I currently do not see how this can be resolved in such a way that each 
camp is happy.

There apparently is consensus, however, that negotiation failure should 
be avoided and that high video quality is desirable, meaning that 
entities are very welcome to implement both high performance codecs. 
This does not appear to be possible for all participants, so to avoid 
negotiation failure while working around IPR issues something like H.261 
looks quite promising IMO. While some participants rightfully question 
the place such an antique codec may have in our HD world, I'm still 
fully convinced that transmitting CIF video can still be very much 
desirable over forcefully transmitting no video at all: that resolution 
still transports emotions, facial features and sign language (which is 
relevant to those concerned with accessibility).

It can also be demonstrated that objective quality measures such as PSNR 
and SSIM favor transmission of low resolution video over a static black 
picture ;)

Again in a nutshell:

  - nobody is forced to implement a codec they object to on IPR grounds
  - we never have negotiation failure and can always transmit video 
(albeit not always beautiful video)
  - implementations that are always able to transmit high quality video 
do not need to be concerned with implementing a low quality video codec

Best regards,

Maik

Am 18.11.2013 07:58, schrieb Ross Finlayson:
> This looks promising.  To summarize: You're proposing that each
> implementation MUST implement (at least) one of the following sets of
> codecs:
> {VP8, H.264}
> {VP8, H.261}
> {H.264, H.261}
>
> This guarantees that there'll never be negotiation failure (between a
> pair of implementations), because the intersection of any two of these
> sets is non-empty.
>
> It also allows the H.264 camp to avoid any alleged additional IPR risk
> from implementing VP8, because they won't need to implement VP8 (they'll
> need to implement H.261 instead).
>
> Similarly, it also allows the VP8 camp to avoid any H.264 licensing
> requirements, because they won't need to implement H.264 (they'll need
> to implement H.261 instead).
>
> And people who are willing to implement both VP8 and H.264 will know
> that they'll always be able to negotiate high-quality video.
>
> Who knows - this may well be something that we could reach consensus on
> (provided that everyone agrees that there's little IPR risk from H.261)...
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>

---

From: "Thomas Reisinger" <[email-masked]>
Date: Mon, 18 Nov 2013 09:11:09 +0100

Thank you Leon. Why should we go with h.261 (except the lower cpu
requirements for en/decoding), when we have a very popular royalty free
h.263 as a common base for most video participants?

Cheers,

Thomas Reisinger 

From: Leon Geyser [mailto:[email-masked]] 
Sent: Montag, 18. November 2013 08:13
To: [email-masked]
Cc: Basil Mohamed Gohar; Thomas Reisinger
Subject: Re: [rtcweb] Video codec selection - way forward

Hi Thomas,

http://www.itu.int/net4/ipr/search.aspx?sector=ITU
<http://www.itu.int/net4/ipr/search.aspx?sector=ITU&class=PS&country=-1&org=
-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=anokwcvd>
&class=PS&country=-1&org=-1&rec=H.263&prod=H.263&ps_country=-1&opt=-1&field=
anokwcvd

On 18 November 2013 08:51, Thomas Reisinger <[email-masked]
<mailto:[email-masked]> > wrote:

Team,

Cheers,

Thomas Reisinger

> On 17.11.2013, at 21:58, Basil Mohamed Gohar <[email-masked]
<mailto:[email-masked]> > wrote:
>>> On 17 Nov 2013, at 20:54, Maik Merten <[email-masked]
>>> "9. All entities SHOULD support both H.264 and VP8. All entities MUST at
least implement one of those. Entities that do not support both H.264 and
VP8 MUST implement H.261."
or VP8 (but not necessarily both). This obviously means that negotiation
failure regarding a high-performance codec is a possiblity. In this case
H.261 is actually useful so that basic video calls can still be established
(for instance, I guess deaf people may always appreciate a video connection,
as long as sign language can be transmitted).
>>>> [email-masked] <mailto:[email-masked]> 
>> [email-masked] <mailto:[email-masked]> 
_______________________________________________
rtcweb mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Maik Merten <[email-masked]>
Date: Mon, 18 Nov 2013 09:22:45 +0100

H.263 seems to be covered by the MPEG-4 Visual patent pool and appears 
to require licensing:

http://www.mpegla.com/main/programs/M4V/Documents/M4VCrossRef.pdf

Maik

Am 18.11.2013 09:11, schrieb Thomas Reisinger:
> *From:*Leon Geyser [mailto:[email-masked]]
> *Sent:* Montag, 18. November 2013 08:13
> *To:* [email-masked]
> *Cc:* Basil Mohamed Gohar; Thomas Reisinger
> *Subject:* Re: [rtcweb] Video codec selection - way forward
>
> Hi Thomas,
>
> <mailto:[email-masked]>> wrote:
>
>     Team,
>
>     I had the same concerns about the royalty fee, but after some
>     research I think there aren't any more. For h.264 this still
>     applies. H.261 is not acceptable anymore in a HD world as it is
>     today. Maybe somebody else cloud put some light on the royalty fees
>     for h.263. I will continue my research.
>
>     Cheers,
>
>     Thomas Reisinger
>
>
>      > On 17.11.2013, at 21:58, Basil Mohamed Gohar
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >
>      > Thomas,
>      >
>      >>> On 17 Nov 2013, at 20:54, Maik Merten
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>>
>      >>> Hello,
>      >>>
>      >>> "9. All entities SHOULD support both H.264 and VP8. All
>     entities MUST at least implement one of those. Entities that do not
>     support both H.264 and VP8 MUST implement H.261."
>      >>>
>      >>> has already popped up. My reasoning is that implementations
>     supporting both high performance codecs will always negotiate to use
>     on of those - H.261 should never be relevant there.
>      >>>
>      >>> It appears that all implementors are willing to implement
>     either H.264 or VP8 (but not necessarily both). This obviously means
>     that negotiation failure regarding a high-performance codec is a
>     possiblity. In this case H.261 is actually useful so that basic
>     video calls can still be established (for instance, I guess deaf
>     people may always appreciate a video connection, as long as sign
>     language can be transmitted).
>      >>>
>      >>>
>      >>> Maik
>      >>>
>      >>>
>      >>>> 8. All entities MUST support H.261 and all entities MUST
>     support at
>      >>>>   least one of H.264 and VP8
>      >>>>
>      >>>> Regards,
>      >>>> Jeremy Fuller
>      >>>>
>      >>>>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Nov 2013 13:42:41 +0100

Hi,

I have added this to the list of alternatives proposed.

/Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 18 Nov 2013 16:35:47 +0000

Hi,

Here is what I know or suspect regarding H.263 licensing:

Know: 

Leon is correct, there are type 2 patent declarations in the ITU against
H.263.

Maik is also correct, H.263 baseline is a subset of MPEG-4 part 2.  MPEG-4
part 2 is generally considered royalty bearing and the license has been
enforced.  However, very few (no one?) is using strict H.263 baseline, and
even for an only slightly more advanced use of H.263 (no need to go to
H.263+, for example), the MPEG-4 portfolio license would not apply.

H.263 has been the predominant codec in the video conferencing industry
for close to a decade (ca. 1996 through ca. 2005).  In all this time, I
have heard of one single instance of patent assertion by a non-troll
against several of the large video conferencing vendors.  However, since
those vendors all used a chip produced by the non-troll, they had enough
commercial leverage to fend off those assertions without the dispute ever
going to trial and, so I hear, without paying any premium for the use of
the patent.   The patent in question has now expired.

H.263 baseline is insufficient for rtcweb¹s purposes, as it does not allow
arbitrary picture sizes.  You want to have at least the PLUSPTYPE picture
header extension which allows arbitrary picture sizes.  You also probably
want a few of the optional modes, especially the bug-fixes (improved VLC)
and the deblocking filter.  Patents related to this technologies are not
covered under the MPEG-LA MPEG-4 part 2 license.

Suspect:

Since we would most likely not use strict H.263 baseline, the war-chest of
the MPEG-LA pool cannot be used to enforce a patent against our
hypothetical H.263 implementation because it is not MPEG-4 part 2
compliant.  Which, in turn, means that the MPEG-4 part 2 rightholders
would be on their own in asserting their patents.  Which, in turn, means
that there is no difference between H.263 and other non-pooled video
codecs from an MPEG-LA related risk assessment.

There have been patent assertions by trolls allegedly related to video
compression in general and H.263 in particular, but those happen all the
time and there is not much one can do about them.  Once you are a juicy
enough target (based on the troll¹s perception of relationship between
your legal competence versus your size) the troll will find you.
Technicalities such as whether the patent is actually infringed or related
to standards are secondary at best in the eye of a troll.  Their business,
at least when going against smaller companies, is to settle for a few
hundreds of thousands--an amount the alleged infringer can pay without
excessive hurt--thereby filling their war chest and then go to the next
³customer².  When they meet determined opposition (based on a combination
of legal and technical competence), they often move on to greener pastures.

As H.263 is fairly widely deployed, and I have not heard about patent
assertions except the cases mentioned above, the risk of a successful
patent assertion is probably manageable for almost everyone with
sufficient legal resources.  At least in countries that allow equitable
defenses (implied license, laches, estoppel).

So is it worth evaluating H.263 further?  IMO, probably not.  It¹s
doubtless technically better than H.261, but the risk is inproportionally
higher.  And the whole idea of this substandard baseline codec has been to
be essentially without risk.

Stephan

---

From: David Singer <[email-masked]>
Date: Mon, 18 Nov 2013 16:07:04 -0800

It's an interesting idea, but the quality of H.261, the availability of decent implementations, and its (functional) restrictions may mean that people are very loath to spend (waste) engineering time on it.  Is this a MUST that would, in fact, get respected?

David Singer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Nov 2013 17:00:02 -0800

David Singer said:

> Is this a MUST that would, in fact, get respected?

[BA] Given the level of support this option got previously (close to nil) I'd say probably not.

---

From: Maik Merten <[email-masked]>
Date: Tue, 19 Nov 2013 10:09:18 +0100

I'm sure the prospect of implementing H.261 is not a desirable one but I 
wonder if

  - implementing the codec of "the other codec camp" is more desirable
  - the end-users will appreciate spuriously failing video calls

Basically this boils down on what the question is. "Who enjoys 
implementing H.261?" clearly will be answered as "nobody". However, "who 
can live with the inconvenience of implementing H.261 for the sake of 
interoperability and accessibility" may be answered differently.

It would, of course, be preferable if H.261 can be substituted with a 
higher performing alternative, although I guess the set of codecs with a 
universally accepted status as "no worries regarding IPR or licensing" 
is limited.

Maik

---

From: Gili <[email-masked]>
Date: Tue, 19 Nov 2013 12:24:33 -0800

+1

On 19/11/2013 1:09 AM, Maik Merten wrote:
> I'm sure the prospect of implementing H.261 is not a desirable one but 
> I wonder if
>
> implementing H.261?" clearly will be answered as "nobody". However, 
> "who can live with the inconvenience of implementing H.261 for the 
> sake of interoperability and accessibility" may be answered differently.
>
> higher performing alternative, although I guess the set of codecs with 
> a universally accepted status as "no worries regarding IPR or 
> licensing" is limited.
>
>
> Maik
>
>
>> It's an interesting idea, but the quality of H.261, the availability 
>> of decent implementations, and its (functional) restrictions may mean 
>> that people are very loath to spend (waste) engineering time on it.  
>>> "9. All entities SHOULD support both H.264 and VP8. All entities 
>>> MUST at least implement one of those. Entities that do not support 
>>> both H.264 and VP8 MUST implement H.261."
>>>
>>> It appears that all implementors are willing to implement either 
>>> H.264 or VP8 (but not necessarily both). This obviously means that

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Nov 2013 19:27:08 -0800

>   - the end-users will appreciate spuriously failing video calls

[BA] The above are not the only choices, because it is not necessary to "implement the codec of the other codec camp" in order to provide support for it.  The Cisco offer of an H.264 encoder/decoder is only one example.  
 
So really, the choice is more between "support codec extensibility and allow 'the other codec camp' to take risks they are comfortable with" and "implement an inferior codec no one wants".

---

From: Gili <[email-masked]>
Date: Tue, 19 Nov 2013 22:52:18 -0800

Bernard,

Numerous stakeholders have already stated that they cannot use Cisco's 
offering (including some noteworthy open-source operating systems) so 
this is a non-starter.

No one is arguing that implementing H.261 is great. We're just saying 
that it's better than the alternative (no video).

Gili

On 19/11/2013 7:27 PM, Bernard Aboba wrote:
> [BA] The above are not the only choices, because it is not necessary 
> to "implement the codec of the other codec camp" in order to provide 
> support for it.  The Cisco offer of an H.264 encoder/decoder is only 
> one example.
>
> So really, the choice is more between "support codec extensibility and 
> allow 'the other codec camp' to take risks they are comfortable with" 
> and "implement an inferior codec no one wants".
>
>
>
>

---

From: Maik Merten <[email-masked]>
Date: Wed, 20 Nov 2013 09:58:21 +0100

Am 20.11.2013 04:27, schrieb Bernard Aboba:
> [BA] The above are not the only choices, because it is not necessary to
> "implement the codec of the other codec camp" in order to provide
> support for it.  The Cisco offer of an H.264 encoder/decoder is only one
> example.

I meant "implementing" as in "implementing and deploying support for".

Cisco's offer, while certainly useful in some (or even many) application 
contexts, cannot cover all relevant deployment scenarios. This not only 
concerns WebRTC implementation providers, but also users (for instance, 
what licensing status do machines have that are recovered from disk 
images that happen to include the binary blob implementing H.264?).

> and "implement an inferior codec no one wants".

Without a fallback codec there will be negotiation failure in ways that 
are out of control of the affected users. I think this is undesirable 
for all involved parties. Implementing support for an "IPR-safe", 
unsophisticated, well-understood, albeit sadly low-performing codec to 
me sounds like a manageable requirement for implementers to guarantee a 
minimal level of video interoperability. It's for sure an inconvenience, 
but so is firewall traversal.

Maik

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Nov 2013 09:44:07 -0800

Maik said: 

> contexts, cannot cover all relevant deployment scenarios. 
[BA] I'd note that the current IETF discussion of MTI video codecs is somewhat similar to a previous discussion in W3C relating to the MTI codec for streaming video.   In that previous discussion, advocates of the potential MTI codecs offered to implement their preferred codec for other browsers.  So if past is prologue, other offers may emerge over time. 

> Without a fallback codec there will be negotiation failure in ways that are out of control of the affected users. 

[BA] In practice, negotiation failure is annoying enough that customers and users are going to demand that it be addressed in some fashion.  This could be via native implementation of multiple codecs, via codec plugins as Cisco has proposed, or via on-premise or cloud-based transcoding solutions as Justin has described.   Given the penalties that the marketplace will impose on services that don't address interoperability in some fashion, it seems to me that the issue is very likely to be addressed in practice, at least for commercial services.  
On the other hand,  attempting to impose a solution that has no real consensus could do real damage, by diverting resources away from implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the WebRTC protocol specifications so as to fully enable multi-codec support, which is going to necessary whichever camp you're in.

---

From: Maik Merten <[email-masked]>
Date: Wed, 20 Nov 2013 19:45:41 +0100

Dear Bernhard,

I'm completely with you regarding that a reliable mechanism for 
multi-codec handling is needed, no matter the outcome of the codec 
discussion. After all, everybody will want to deploy new codec 
technology in the future.

I also think that pressure from customers will eventually lead to 
transcoding services being offered to serve as a bandaid in case no 
consensus can be achieved. I'm saying "bandaid" here, because I suspect 
that in practice such transcoding services will introduce costs (which 
may not be acceptable to new players), increase latency (always not so 
nice), and possibly introduce single points of failure (nasty for 
everyone). Reliance on such services would be a admittance of failure 
regarding P2P interoperability.

(Personally, I would consider it a grave specification bug if users 
cannot reliably establish even a basic, direct video call, with every 
involved entity adhering to the spec and network conditions permitting.)

You're of course right that mandating something without consensus cannot 
possibly be solution. I'm just hoping there's consensus that P2P 
interoperability does matter. From my point of view H.261 is an option 
that can enable (very) basic video interoperability (engineering 
perspective) and also is trouble-free regarding IPR (legal perspective, 
which appears to be what's making consensus on codecs difficult). Having 
a solution that engineers can implement and lawyers can agree to seems 
to be a rare constellation. It's up to implementers to decide if they 
are willing to make use of it to achieve basic interoperability.

Best regards,

Maik

Am 20.11.2013 18:44, schrieb Bernard Aboba:
> [BA] I'd note that the current IETF discussion of MTI video codecs is
> somewhat similar to a previous discussion in W3C relating to the MTI
> codec for streaming video.   In that previous discussion, advocates of
> the potential MTI codecs offered to implement their preferred codec for
> other browsers.  So if past is prologue, other offers may emerge over time.
>
>  > Without a fallback codec there will be negotiation failure in ways
> that are out of control of the affected users.
>
> [BA] In practice, negotiation failure is annoying enough that customers
> and users are going to demand that it be addressed in some fashion.
>   This could be via native implementation of multiple codecs, via codec
> plugins as Cisco has proposed, or via on-premise or cloud-based
> transcoding solutions as Justin has described.   Given the penalties
> that the marketplace will impose on services that don't address
> interoperability in some fashion, it seems to me that the issue is very
> likely to be addressed in practice, at least for commercial services.
>
> On the other hand,  attempting to impose a solution that has no real
> consensus could do real damage, by diverting resources away from
> implementing leading edge codecs (e.g. VP9 and HEVC) or polishing the
> WebRTC protocol specifications so as to fully enable multi-codec
> support, which is going to necessary whichever camp you're in.

---

From: David Singer <[email-masked]>
Date: Wed, 20 Nov 2013 11:42:50 -0800

I think we should think hard about H.263 instead of H.261 as the third fallback.  Why?

http://www.itu.int/rec/T-REC-H.263/

H.263 was first published in March 1996, so it's 17 years old.  The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more recent amendments deal with this (and a plethora of other issues), so we’d need to settle on which of those are mandatory (the usual profiling discussion).

There are 34 records in the patent database against H.261, mostly from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2 (reciprocity), as was one other I checked.

Rather surprisingly, there are only 31 against H.263!  The most recent is 2011, and is also option 2.  Most are 1997-2001.

On this quick glance, H.263 appears no worse than H.261. IANAL (as I am sure you have all noticed).

H.263 is much more widely supported and mandated.  It has been mandated in the 3GPP specs for years (for lots of services, including videoconf), and is effectively the fallback codec today in the industry, as I understand.  It was ubiquitous in video telephony for years, and I suspect many of those systems still ship it.

So, would “MUST implement at least two of (H.264, VP8, H.263)” work?

(I am asking the question, not even answering on behalf of my company, yet.  Let’s get the issues on the table.)

David Singer

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Nov 2013 09:55:52 +0100

Dave,

Just to be clear. I will not add any new option to the list as I
understand this is currently a discussion piece. You and any other have
until the end of 27th of November to request an addition to the list of
alternatives.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 18:22:01 +0100

Cleary H.263 is preferable from an engineering standpoint (as is, e.g., 
MPEG-1 Part 2): better performance, more deployments. The central 
question is, however, if those can actually be implemented without some 
sort of licensing.

If they can: Aweseome! However, this may not be determinable without a 
review by people who are knowledgeable in the field of IPR, i.e., 
"actual lawyers". I understand that H.263 is not yet old enough to 
automatically be considered "safe" (and neither is MPEG-1 Part 2, 
although it is closer).

Best regards,

Maik

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Nov 2013 09:30:05 -0800

> So, would “MUST implement at least two of (H.264, VP8, H.263)” work?

I have to give you a lot of credit for coming up with a "pick two of 
three" formulation. That's a clever way to guarantee overlapping codecs 
between any two pairwise implementations. I'm still not sure it's the 
right direction for *this* decision, but it sure is an interesting 
thought exercise.

/a

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 09:33:14 -0800

On Nov 21, 2013, at 9:30 , Adam Roach <[email-masked]> wrote:

> I have to give you a lot of credit for coming up with a "pick two of three" formulation. That's a clever way to guarantee overlapping codecs between any two pairwise implementations. I'm still not sure it's the right direction for *this* decision, but it sure is an interesting thought exercise.
> 
> /a

Thanks, but not my idea;  that was the H.261 “pick two of three”.  I am just suggesting H.263 may be a better choice.

David Singer

---

From: David Singer <[email-masked]>
Date: Thu, 21 Nov 2013 11:20:26 -0800

Chairs

can we add this as an option to the formal list, so we get formal feedback on its acceptability, please?

“Like option ??, pick at least two of {VP8, H.264 CBP, H.263}”

I think this may be the best (maybe only) way to tease out how much risk people perceive.

Many thanks

On Nov 21, 2013, at 9:22 , Maik Merten <[email-masked]> wrote:

> Cleary H.263 is preferable from an engineering standpoint (as is, e.g., MPEG-1 Part 2): better performance, more deployments. The central question is, however, if those can actually be implemented without some sort of licensing.
> 
> If they can: Aweseome! However, this may not be determinable without a review by people who are knowledgeable in the field of IPR, i.e., "actual lawyers". I understand that H.263 is not yet old enough to automatically be considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
> 
> Best regards,
> 
> Maik
> 

David Singer

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 11:27:37 -0800

Added a 

#11 	• MUST implement at least two of {VP8, H.264 CBP, H.263}

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 20:27:05 +0100

Btw, should any occurrence of "H.264" in the current list of options be 
substituted with "H.264 CBP"? Perhaps it is best to be very clear on the 
profile which should be implemented.

Thanks,

Maik

---

From: Maik Merten <[email-masked]>
Date: Thu, 21 Nov 2013 20:32:22 +0100

I wonder if it #10 should be rephrased into a nice and clear

MUST implement at least two of {VP8, H.264 CBP, H.261}

to highlight the structural similarity.

Maik

---

From: Leon Geyser <[email-masked]>
Date: Thu, 21 Nov 2013 21:32:47 +0200

+1

On 21 November 2013 21:27, Maik Merten <[email-masked]> wrote:

>>> MPEG-1 Part 2): better performance, more deployments. The central question
>>> is, however, if those can actually be implemented without some sort of
>>> licensing.
>>>
>>> review by people who are knowledgeable in the field of IPR, i.e., "actual
>>> lawyers". I understand that H.263 is not yet old enough to automatically be
>>> considered "safe" (and neither is MPEG-1 Part 2, although it is closer).
>>>
>>> Best regards,
>>>
>>> Maik
>>>
>>>> H.263 was first published in March 1996, so it's 17 years old.  The
>>>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, more
>>>> recent amendments deal with this (and a plethora of other issues), so we’d
>>>> need to settle on which of those are mandatory (the usual profiling
>>>> discussion).
>>>>
>>>> There are 34 records in the patent database against H.261, mostly from
>>>> 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2
>>>> (reciprocity), as was one other I checked.
>>>>
>>>> Rather surprisingly, there are only 31 against H.263!  The most recent
>>>> is 2011, and is also option 2.  Most are 1997-2001.
>>>>
>>>>
>>>> H.263 is much more widely supported and mandated.  It has been mandated
>>>> in the 3GPP specs for years (for lots of services, including videoconf),
>>>> and is effectively the fallback codec today in the industry, as I
>>>> understand.  It was ubiquitous in video telephony for years, and I suspect
>>>> many of those systems still ship it.
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 12:01:53 -0800

I would like to propose some additional alternatives.

SHOULD: Theora
MUST: Theora
SHOULD: H.261
SHOULD: H.261 Theora
MUST: Theora; SHOULD: H.261
MUST: H.261
MUST: H.261; SHOULD: Theora
MUST: H.261 Theora
SHOULD: H.263
SHOULD: H.263 Theora
MUST: Theora; SHOULD: H.263
SHOULD: H.263 H.261
SHOULD: H.263 H.261 Theora
MUST: Theora; SHOULD: H.263 H.261
MUST: H.261; SHOULD: H.263
MUST: H.261; SHOULD: H.263 Theora
MUST: H.261 Theora; SHOULD: H.263
MUST: H.263
MUST: H.263; SHOULD: Theora
MUST: H.263 Theora
MUST: H.263; SHOULD: H.261
MUST: H.263; SHOULD: H.261 Theora
MUST: H.263 Theora; SHOULD: H.261
MUST: H.263 H.261
MUST: H.263 H.261; SHOULD: Theora
MUST: H.263 H.261 Theora
SHOULD: VP8
SHOULD: VP8 Theora
MUST: Theora; SHOULD: VP8
SHOULD: VP8 H.261
SHOULD: VP8 H.261 Theora
MUST: Theora; SHOULD: VP8 H.261
MUST: H.261; SHOULD: VP8
MUST: H.261; SHOULD: VP8 Theora
MUST: H.261 Theora; SHOULD: VP8
SHOULD: VP8 H.263
SHOULD: VP8 H.263 Theora
MUST: Theora; SHOULD: VP8 H.263
SHOULD: VP8 H.263 H.261
SHOULD: VP8 H.263 H.261 Theora
MUST: Theora; SHOULD: VP8 H.263 H.261
MUST: H.261; SHOULD: VP8 H.263
MUST: H.261; SHOULD: VP8 H.263 Theora
MUST: H.261 Theora; SHOULD: VP8 H.263
MUST: H.263; SHOULD: VP8
MUST: H.263; SHOULD: VP8 Theora
MUST: H.263 Theora; SHOULD: VP8
MUST: H.263; SHOULD: VP8 H.261
MUST: H.263; SHOULD: VP8 H.261 Theora
MUST: H.263 Theora; SHOULD: VP8 H.261
MUST: H.263 H.261; SHOULD: VP8
MUST: H.263 H.261; SHOULD: VP8 Theora
MUST: H.263 H.261 Theora; SHOULD: VP8
MUST: VP8
MUST: VP8; SHOULD: Theora
MUST: VP8 Theora
 MUST: VP8; SHOULD: H.261
MUST: VP8; SHOULD: H.261 Theora
MUST: VP8 Theora; SHOULD: H.261
MUST: VP8 H.261
MUST: VP8 H.261; SHOULD: Theora
MUST: VP8 H.261 Theora
MUST: VP8; SHOULD: H.263
MUST: VP8; SHOULD: H.263 Theora
MUST: VP8 Theora; SHOULD: H.263
MUST: VP8; SHOULD: H.263 H.261
MUST: VP8; SHOULD: H.263 H.261 Theora
MUST: VP8 Theora; SHOULD: H.263 H.261
MUST: VP8 H.261; SHOULD: H.263
MUST: VP8 H.261; SHOULD: H.263 Theora
MUST: VP8 H.261 Theora; SHOULD: H.263
MUST: VP8 H.263
MUST: VP8 H.263; SHOULD: Theora
MUST: VP8 H.263 Theora
MUST: VP8 H.263; SHOULD: H.261
MUST: VP8 H.263; SHOULD: H.261 Theora
MUST: VP8 H.263 Theora; SHOULD: H.261
MUST: VP8 H.263 H.261
MUST: VP8 H.263 H.261; SHOULD: Theora
MUST: VP8 H.263 H.261 Theora
SHOULD: H.264
SHOULD: H.264 Theora
MUST: Theora; SHOULD: H.264
SHOULD: H.264 H.261
SHOULD: H.264 H.261 Theora
MUST: Theora; SHOULD: H.264 H.261
MUST: H.261; SHOULD: H.264
MUST: H.261; SHOULD: H.264 Theora
MUST: H.261 Theora; SHOULD: H.264
SHOULD: H.264 H.263
SHOULD: H.264 H.263 Theora
MUST: Theora; SHOULD: H.264 H.263
SHOULD: H.264 H.263 H.261
SHOULD: H.264 H.263 H.261 Theora
MUST: Theora; SHOULD: H.264 H.263 H.261
MUST: H.261; SHOULD: H.264 H.263
MUST: H.261; SHOULD: H.264 H.263 Theora
MUST: H.261 Theora; SHOULD: H.264 H.263
MUST: H.263; SHOULD: H.264
MUST: H.263; SHOULD: H.264 Theora
MUST: H.263 Theora; SHOULD: H.264
MUST: H.263; SHOULD: H.264 H.261
MUST: H.263; SHOULD: H.264 H.261 Theora
MUST: H.263 Theora; SHOULD: H.264 H.261
MUST: H.263 H.261; SHOULD: H.264
MUST: H.263 H.261; SHOULD: H.264 Theora
MUST: H.263 H.261 Theora; SHOULD: H.264
SHOULD: H.264 VP8
SHOULD: H.264 VP8 Theora
MUST: Theora; SHOULD: H.264 VP8
SHOULD: H.264 VP8 H.261
SHOULD: H.264 VP8 H.261 Theora
MUST: Theora; SHOULD: H.264 VP8 H.261
MUST: H.261; SHOULD: H.264 VP8
MUST: H.261; SHOULD: H.264 VP8 Theora
MUST: H.261 Theora; SHOULD: H.264 VP8
SHOULD: H.264 VP8 H.263
SHOULD: H.264 VP8 H.263 Theora
MUST: Theora; SHOULD: H.264 VP8 H.263
SHOULD: H.264 VP8 H.263 H.261
SHOULD: H.264 VP8 H.263 H.261 Theora
MUST: Theora; SHOULD: H.264 VP8 H.263 H.261
MUST: H.261; SHOULD: H.264 VP8 H.263
MUST: H.261; SHOULD: H.264 VP8 H.263 Theora
MUST: H.261 Theora; SHOULD: H.264 VP8 H.263
MUST: H.263; SHOULD: H.264 VP8
MUST: H.263; SHOULD: H.264 VP8 Theora
MUST: H.263 Theora; SHOULD: H.264 VP8
MUST: H.263; SHOULD: H.264 VP8 H.261
MUST: H.263; SHOULD: H.264 VP8 H.261 Theora
MUST: H.263 Theora; SHOULD: H.264 VP8 H.261
MUST: H.263 H.261; SHOULD: H.264 VP8
MUST: H.263 H.261; SHOULD: H.264 VP8 Theora
MUST: H.263 H.261 Theora; SHOULD: H.264 VP8
MUST: VP8; SHOULD: H.264
MUST: VP8; SHOULD: H.264 Theora
MUST: VP8 Theora; SHOULD: H.264
MUST: VP8; SHOULD: H.264 H.261
MUST: VP8; SHOULD: H.264 H.261 Theora
MUST: VP8 Theora; SHOULD: H.264 H.261
MUST: VP8 H.261; SHOULD: H.264
MUST: VP8 H.261; SHOULD: H.264 Theora
MUST: VP8 H.261 Theora; SHOULD: H.264
MUST: VP8; SHOULD: H.264 H.263
MUST: VP8; SHOULD: H.264 H.263 Theora
MUST: VP8 Theora; SHOULD: H.264 H.263
MUST: VP8; SHOULD: H.264 H.263 H.261
MUST: VP8; SHOULD: H.264 H.263 H.261 Theora
MUST: VP8 Theora; SHOULD: H.264 H.263 H.261
MUST: VP8 H.261; SHOULD: H.264 H.263
MUST: VP8 H.261; SHOULD: H.264 H.263 Theora
MUST: VP8 H.261 Theora; SHOULD: H.264 H.263
MUST: VP8 H.263; SHOULD: H.264
MUST: VP8 H.263; SHOULD: H.264 Theora
MUST: VP8 H.263 Theora; SHOULD: H.264
MUST: VP8 H.263; SHOULD: H.264 H.261
MUST: VP8 H.263; SHOULD: H.264 H.261 Theora
MUST: VP8 H.263 Theora; SHOULD: H.264 H.261
MUST: VP8 H.263 H.261; SHOULD: H.264
MUST: VP8 H.263 H.261; SHOULD: H.264 Theora
MUST: VP8 H.263 H.261 Theora; SHOULD: H.264
MUST: H.264
MUST: H.264; SHOULD: Theora
MUST: H.264 Theora
MUST: H.264; SHOULD: H.261
MUST: H.264; SHOULD: H.261 Theora
MUST: H.264 Theora; SHOULD: H.261
MUST: H.264 H.261
MUST: H.264 H.261; SHOULD: Theora
MUST: H.264 H.261 Theora
MUST: H.264; SHOULD: H.263
MUST: H.264; SHOULD: H.263 Theora
MUST: H.264 Theora; SHOULD: H.263
MUST: H.264; SHOULD: H.263 H.261
MUST: H.264; SHOULD: H.263 H.261 Theora
MUST: H.264 Theora; SHOULD: H.263 H.261
MUST: H.264 H.261; SHOULD: H.263
MUST: H.264 H.261; SHOULD: H.263 Theora
MUST: H.264 H.261 Theora; SHOULD: H.263
MUST: H.264 H.263
MUST: H.264 H.263; SHOULD: Theora
MUST: H.264 H.263 Theora
MUST: H.264 H.263; SHOULD: H.261
MUST: H.264 H.263; SHOULD: H.261 Theora
MUST: H.264 H.263 Theora; SHOULD: H.261
MUST: H.264 H.263 H.261
MUST: H.264 H.263 H.261; SHOULD: Theora
MUST: H.264 H.263 H.261 Theora
MUST: H.264; SHOULD: VP8
MUST: H.264; SHOULD: VP8 Theora
MUST: H.264 Theora; SHOULD: VP8
MUST: H.264; SHOULD: VP8 H.261
MUST: H.264; SHOULD: VP8 H.261 Theora
MUST: H.264 Theora; SHOULD: VP8 H.261
MUST: H.264 H.261; SHOULD: VP8
MUST: H.264 H.261; SHOULD: VP8 Theora
MUST: H.264 H.261 Theora; SHOULD: VP8
MUST: H.264; SHOULD: VP8 H.263
MUST: H.264; SHOULD: VP8 H.263 Theora
MUST: H.264 Theora; SHOULD: VP8 H.263
MUST: H.264; SHOULD: VP8 H.263 H.261
MUST: H.264; SHOULD: VP8 H.263 H.261 Theora
MUST: H.264 Theora; SHOULD: VP8 H.263 H.261
MUST: H.264 H.261; SHOULD: VP8 H.263
MUST: H.264 H.261; SHOULD: VP8 H.263 Theora
MUST: H.264 H.261 Theora; SHOULD: VP8 H.263
MUST: H.264 H.263; SHOULD: VP8
MUST: H.264 H.263; SHOULD: VP8 Theora
MUST: H.264 H.263 Theora; SHOULD: VP8
MUST: H.264 H.263; SHOULD: VP8 H.261
MUST: H.264 H.263; SHOULD: VP8 H.261 Theora
MUST: H.264 H.263 Theora; SHOULD: VP8 H.261
MUST: H.264 H.263 H.261; SHOULD: VP8
MUST: H.264 H.263 H.261; SHOULD: VP8 Theora
MUST: H.264 H.263 H.261 Theora; SHOULD: VP8
MUST: H.264 VP8
MUST: H.264 VP8; SHOULD: Theora
MUST: H.264 VP8 Theora
MUST: H.264 VP8; SHOULD: H.261
MUST: H.264 VP8; SHOULD: H.261 Theora
MUST: H.264 VP8 Theora; SHOULD: H.261
MUST: H.264 VP8 H.261
MUST: H.264 VP8 H.261; SHOULD: Theora
MUST: H.264 VP8 H.261 Theora
MUST: H.264 VP8; SHOULD: H.263
MUST: H.264 VP8; SHOULD: H.263 Theora
MUST: H.264 VP8 Theora; SHOULD: H.263
MUST: H.264 VP8; SHOULD: H.263 H.261
MUST: H.264 VP8; SHOULD: H.263 H.261 Theora
MUST: H.264 VP8 Theora; SHOULD: H.263 H.261
MUST: H.264 VP8 H.261; SHOULD: H.263
MUST: H.264 VP8 H.261; SHOULD: H.263 Theora
MUST: H.264 VP8 H.261 Theora; SHOULD: H.263
MUST: H.264 VP8 H.263
MUST: H.264 VP8 H.263; SHOULD: Theora
MUST: H.264 VP8 H.263 Theora
MUST: H.264 VP8 H.263; SHOULD: H.261
MUST: H.264 VP8 H.263; SHOULD: H.261 Theora
MUST: H.264 VP8 H.263 Theora; SHOULD: H.261
MUST: H.264 VP8 H.263 H.261
MUST: H.264 VP8 H.263 H.261; SHOULD: Theora
MUST: H.264 VP8 H.263 H.261 Theora
SHOULD do 1 of {H.261, Theora}
SHOULD do 1 of {H.263, Theora}
SHOULD do 1 of {H.263, H.261}
SHOULD do 1 of {H.263, H.261, Theora}
SHOULD do 2 of {H.263, H.261, Theora}
SHOULD do 1 of {VP8, Theora}
SHOULD do 1 of {VP8, H.261}
SHOULD do 1 of {VP8, H.261, Theora}
SHOULD do 2 of {VP8, H.261, Theora}
SHOULD do 1 of {VP8, H.263}
SHOULD do 1 of {VP8, H.263, Theora}
SHOULD do 2 of {VP8, H.263, Theora}
SHOULD do 1 of {VP8, H.263, H.261}
SHOULD do 2 of {VP8, H.263, H.261}
SHOULD do 1 of {VP8, H.263, H.261, Theora}
SHOULD do 2 of {VP8, H.263, H.261, Theora}
SHOULD do 3 of {VP8, H.263, H.261, Theora}
SHOULD do 1 of {H.264, Theora}
SHOULD do 1 of {H.264, H.261}
SHOULD do 1 of {H.264, H.261, Theora}
SHOULD do 2 of {H.264, H.261, Theora}
SHOULD do 1 of {H.264, H.263}
SHOULD do 1 of {H.264, H.263, Theora}
SHOULD do 2 of {H.264, H.263, Theora}
SHOULD do 1 of {H.264, H.263, H.261}
SHOULD do 2 of {H.264, H.263, H.261}
SHOULD do 1 of {H.264, H.263, H.261, Theora}
SHOULD do 2 of {H.264, H.263, H.261, Theora}
SHOULD do 3 of {H.264, H.263, H.261, Theora}
SHOULD do 1 of {H.264, VP8}
SHOULD do 1 of {H.264, VP8, Theora}
SHOULD do 2 of {H.264, VP8, Theora}
SHOULD do 1 of {H.264, VP8, H.261}
SHOULD do 2 of {H.264, VP8, H.261}
SHOULD do 1 of {H.264, VP8, H.261, Theora}
SHOULD do 2 of {H.264, VP8, H.261, Theora}
SHOULD do 3 of {H.264, VP8, H.261, Theora}
SHOULD do 1 of {H.264, VP8, H.263}
SHOULD do 2 of {H.264, VP8, H.263}
SHOULD do 1 of {H.264, VP8, H.263, Theora}
SHOULD do 2 of {H.264, VP8, H.263, Theora}
SHOULD do 3 of {H.264, VP8, H.263, Theora}
SHOULD do 1 of {H.264, VP8, H.263, H.261}
SHOULD do 2 of {H.264, VP8, H.263, H.261}
SHOULD do 3 of {H.264, VP8, H.263, H.261}
SHOULD do 1 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 2 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 3 of {H.264, VP8, H.263, H.261, Theora}
SHOULD do 4 of {H.264, VP8, H.263, H.261, Theora}
MUST do 1 of {H.261, Theora}
MUST do 1 of {H.263, Theora}
MUST do 1 of {H.263, H.261}
MUST do 1 of {H.263, H.261, Theora}
MUST do 2 of {H.263, H.261, Theora}
MUST do 1 of {VP8, Theora}
MUST do 1 of {VP8, H.261}
MUST do 1 of {VP8, H.261, Theora}
MUST do 2 of {VP8, H.261, Theora}
MUST do 1 of {VP8, H.263}
MUST do 1 of {VP8, H.263, Theora}
MUST do 2 of {VP8, H.263, Theora}
MUST do 1 of {VP8, H.263, H.261}
MUST do 2 of {VP8, H.263, H.261}
MUST do 1 of {VP8, H.263, H.261, Theora}
MUST do 2 of {VP8, H.263, H.261, Theora}
MUST do 3 of {VP8, H.263, H.261, Theora}
MUST do 1 of {H.264, Theora}
MUST do 1 of {H.264, H.261}
MUST do 1 of {H.264, H.261, Theora}
MUST do 2 of {H.264, H.261, Theora}
MUST do 1 of {H.264, H.263}
MUST do 1 of {H.264, H.263, Theora}
MUST do 2 of {H.264, H.263, Theora}
MUST do 1 of {H.264, H.263, H.261}
MUST do 2 of {H.264, H.263, H.261}
MUST do 1 of {H.264, H.263, H.261, Theora}
MUST do 2 of {H.264, H.263, H.261, Theora}
MUST do 3 of {H.264, H.263, H.261, Theora}
MUST do 1 of {H.264, VP8}
MUST do 1 of {H.264, VP8, Theora}
MUST do 2 of {H.264, VP8, Theora}
MUST do 1 of {H.264, VP8, H.261}
MUST do 2 of {H.264, VP8, H.261}
MUST do 1 of {H.264, VP8, H.261, Theora}
MUST do 2 of {H.264, VP8, H.261, Theora}
MUST do 3 of {H.264, VP8, H.261, Theora}
MUST do 1 of {H.264, VP8, H.263}
MUST do 2 of {H.264, VP8, H.263}
MUST do 1 of {H.264, VP8, H.263, Theora}
MUST do 2 of {H.264, VP8, H.263, Theora}
MUST do 3 of {H.264, VP8, H.263, Theora}
MUST do 1 of {H.264, VP8, H.263, H.261}
MUST do 2 of {H.264, VP8, H.263, H.261}
MUST do 3 of {H.264, VP8, H.263, H.261}
MUST do 1 of {H.264, VP8, H.263, H.261, Theora}
MUST do 2 of {H.264, VP8, H.263, H.261, Theora}
MUST do 3 of {H.264, VP8, H.263, H.261, Theora}
MUST do 4 of {H.264, VP8, H.263, H.261, Theora}

On Thu, Nov 21, 2013 at 11:27 AM, Cullen Jennings <[email-masked]> wrote:

> >>> H.263 is much more widely supported and mandated.  It has been
> mandated in the 3GPP specs for years (for lots of services, including
> videoconf), and is effectively the fallback codec today in the industry, as
> I understand.  It was ubiquitous in video telephony for years, and I
> suspect many of those systems still ship it.
> >>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 12:06:14 -0800

> I would like to propose some additional alternatives.

I notice that RFC 4235 and RFC 4715 are absent from that list.  Both
have been raised on the list before.  Why not include those as well?

---

From: Steve Kann <[email-masked]>
Date: Thu, 21 Nov 2013 12:14:15 -0800

Do you plan to open-source your codec option generator?   It would make modifying the list much more efficient. 

-Sent from an iOS mobile device

> On Nov 21, 2013, at 12:01 PM, Eric Rescorla <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 12:17:45 -0800

> modifying the list much more efficient.

I was thinking of distributing it as a binary module you could link into
your
mail client.

-Ekr

>> >> Cleary H.263 is preferable from an engineering standpoint (as is,
>> e.g., MPEG-1 Part 2): better performance, more deployments. The central
>> >>> There are 34 records in the patent database against H.261, mostly
>> from 1989 but one as recent as 2005 (though that is a re-file).  That's 2.2
>> >>> Rather surprisingly, there are only 31 against H.263!  The most
>> recent is 2011, and is also option 2.  Most are 1997-2001.
>> >>>
>> >>>
>> >>> (I am asking the question, not even answering on behalf of my
>> company, yet.  Let’s get the issues on the table.)
>> >>>
>> >>>
>> >>> David Singer

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 21 Nov 2013 15:20:58 -0500

> I would like to propose some additional alternatives.

Careful.  This sort of 100-way thing is how Toronto elected Rob Ford.

Monty

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 21 Nov 2013 14:21:26 -0600

I would like another option.  I cannot use that on my dynamically
deployed EC2 instances due to licensing restrictions. :-)

Matthew Fredrickson

On Thu, Nov 21, 2013 at 2:17 PM, Eric Rescorla <[email-masked]> wrote:
>>> >> question is, however, if those can actually be implemented without some sort
>>> >> of licensing.
>>> >>
>>> >>> I understand.  It was ubiquitous in video telephony for years, and I suspect

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Nov 2013 12:29:40 -0800

https://github.com/ekr/codec-options

On Thu, Nov 21, 2013 at 12:17 PM, Eric Rescorla <[email-masked]> wrote:

>>> >> If they can: Aweseome! However, this may not be determinable without
>>> a review by people who are knowledgeable in the field of IPR, i.e., "actual

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Nov 2013 12:45:23 -0800

> https://github.com/ekr/codec-options

You didn't include the 6919 options:

https://github.com/ekr/codec-options/pull/1

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 21 Nov 2013 22:05:35 +0100

I knew yesterday it was bank holiday in Brazil, didn't know today it is 
drunk holiday in US. Thanks for making that clear folks!

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 13:32:04 -0800

I assume you were joking with that but I think if we have at least a handful of people arguing that some particular choice is their first choice seems like a reasonable bar to add it. Sound reasonable ?

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 21 Nov 2013 13:41:04 -0800

+1

Matthew Kaufman

(Sent from my iPhone)

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 21 Nov 2013 14:33:15 -0800

On Nov 21, 2013, at 12:21 PM, Matt Fredrickson <[email-masked]> wrote:

>  I cannot use that on my dynamically

My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees.

---

From: Matt Fredrickson <[email-masked]>
Date: Thu, 21 Nov 2013 16:47:03 -0600

Sorry, my facetiousness didn't get through in my email.  Clearly we
need to be discussing enhancements to emoticons for email instead of
this silly MTI debate.

I concur, and I don't know of any insurmountable problems with using
the Cisco H.264 plugin on EC2 cloud instances.

Matthew Fredrickson

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 21 Nov 2013 23:47:06 +0100

On Thu, 21 Nov 2013 14:33:15 -0800

> My understanding of the legal situation is that you can use the cisco binary on your EC2 instance and have Cisco pay the MPEG-LA fees. 

The issue that was mentioned was cloned/frozen VM images that you could spawn to increase scalability. In that case, you would prepare/install an image just once, freeze it, and then launch a new one whenever you need it. Ideally you'd have the plugin installed that first time only, but then all cloned instances would fall out of the license agreement, as they'd actually be different machines with the plugin reinstalled rather than downloaded on the fly. Downloading the plugin for each new image that is spawned as it unfreezes would be a problem, as 1) the image wouldn't be ready right away, and 2) any problem in the download process would make the machine useless with respect to H.264.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: "cb.list6" <[email-masked]>
Date: Thu, 21 Nov 2013 19:14:56 -0800

your
> -Ekr

That sounds real good. Promise not to fork my private correspondence or
meta data to the NSA?

>>>> >>
>>>> >> If they can: Aweseome! However, this may not be determinable
without a review by people who are knowledgeable in the field of IPR, i.e.,
"actual lawyers". I understand that H.263 is not yet old enough to
automatically be considered "safe" (and neither is MPEG-1 Part 2, although
it is closer).
>>>> >>> H.263 was first published in March 1996, so it's 17 years old.
 The restrictions (e.g. on picture size) are no WORSE than H.261.  Yes,
more recent amendments deal with this (and a plethora of other issues), so
we’d need to settle on which of those are mandatory (the usual profiling
discussion).

---

From: cowwoc <[email-masked]>
Date: Sat, 23 Nov 2013 02:30:24 -0500

+1

In the original VP8 vs H.264 discussion, what H.264 profile was under 
discussion?

If it was not H.264 CBP, do we need to revisit the comparison? Do the 
two profiles use the same bandwidth, CPU and produce the same quality?

Thanks,
Gili

On 21/11/2013 2:27 PM, Maik Merten wrote:
> Btw, should any occurrence of "H.264" in the current list of options 
> be substituted with "H.264 CBP"? Perhaps it is best to be very clear 
> on the profile which should be implemented.
>
> Thanks,
>
> Maik
>
>>> e.g., MPEG-1 Part 2): better performance, more deployments. The 
>>> central question is, however, if those can actually be implemented 
>>> without some sort of licensing.
>>>
>>> a review by people who are knowledgeable in the field of IPR, i.e., 
>>>> restrictions (e.g. on picture size) are no WORSE than H.261.  Yes, 
>>>> more recent amendments deal with this (and a plethora of other 
>>>> issues), so we’d need to settle on which of those are mandatory 
>>>> (the usual profiling discussion).
>>>>
>>>> from 1989 but one as recent as 2005 (though that is a re-file).  
>>>> That's 2.2 (reciprocity), as was one other I checked.
>>>>
>>>> mandated in the 3GPP specs for years (for lots of services, 
>>>> including videoconf), and is effectively the fallback codec today 
>>>> in the industry, as I understand.  It was ubiquitous in video 
>>>> telephony for years, and I suspect many of those systems still ship 
>>>> it.
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Nov 2013 07:00:20 -0800

It was CBP.

I think there's some debate about the relative performance characteristics,
with
general agreement that H.264 CBP and VP8 are in the same neighborhood
and also general agreement that performance is not the important factor.

-Ekr

On Fri, Nov 22, 2013 at 11:30 PM, cowwoc <[email-masked]> wrote:

> If it was not H.264 CBP, do we need to revisit the comparison? Do the two
> profiles use the same bandwidth, CPU and produce the same quality?
>
> Thanks,
> Gili
>

---

From: Stefan Slivinski <[email-masked]>
Date: Sat, 23 Nov 2013 22:39:32 -0600

I don't know which profile was under discussion but constrained baseline profile (CBP) removes tools like FMO and ASO from baseline profile which have been unpopular because of their complexity and quality tradeoffs.

In realtime video communications High profile typically just adds cabac and 8x8 transform which in general reduce the bitrate for video communications type content (talking heads, no high action movies) by about 20-25% as compared to CBP.  Cabac in particular adds a fair amount of complexity but most modern hardware acceleration supports it meaning there is no performance hit to the CPU.

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of cowwoc
Sent: Friday, November 22, 2013 11:30 PM
To: [email-masked]
Subject: [rtcweb] H.264 CBP (was: Video codec selection - way forward)

+1

In the original VP8 vs H.264 discussion, what H.264 profile was under discussion?

If it was not H.264 CBP, do we need to revisit the comparison? Do the two profiles use the same bandwidth, CPU and produce the same quality?

Thanks,
Gili

On 21/11/2013 2:27 PM, Maik Merten wrote:
>> "Like option ??, pick at least two of {VP8, H.264 CBP, H.263}"
>>
>>
>>>> issues), so we'd need to settle on which of those are mandatory 
>>>> So, would "MUST implement at least two of (H.264, VP8, H.263)" work?
>>>>
>>>> company, yet.  Let's get the issues on the table.)
>>>>
>>>>
>>>> David Singer

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Nov 2013 12:32:38 -0700

I think for a scenario like that you would use a different approach as long as you used less than 100k virtual machines - which is a reasonable assumption for all the cloud services I am aware of. You would take the source code and compile it to form the executables on the master image for the VM. You would then distribute the VM normally and not use the Cisco binary. 

The other case that has come up is a large enterprise that makes a master copy of the image that distributed to all their desktops  and it is a case where the company has over 100k desktops.  If they own the desktops my understanding is they are the end user from that point of view and as long as the IT department downloaded a copy of the Cisco binary and put it into their master image and then put that master image on computers they own / operate then that can be made to work too. 

This stuff is all sort of subtle but there seems to be a wide range of options that can be made to work and have examples of people already doing it with H264 MPEG LA licenses.

---

From: cowwoc <[email-masked]>
Date: Tue, 26 Nov 2013 15:50:26 -0500

MPEG-LA is doing a terrible job here. The licensing rules are so poorly 
understood and enforced that they have a practical impact of companies 
ignoring them altogether (unless you're huge like Apple or Google). They 
are wasting our time, and it is costing themselves legitimate royalties.

The fact that we are being asked to pay lawyers as an insurance policy 
(to get a legal opinion on a vague license) is not right. I can 
understand why the open-source guys are finding this lack of 
transparency very disturbing.

All this is to say: Cisco's proposal is a step in the right direction 
but there remains a large gap that needs to be filled. I encourage H.264 
advocates to work with MPEG-LA to bridge this gap as opposed to pushing 
this on the rest of us.

As discussed with Cullen during the conference, we should be able to 
come up with "creative" licensing terms that allow us to buy multiple 
units in bulk and integrating the codec directly into our images. As 
opposed to manually downloading the codec each time. Similarly, we 
should get more concrete/official answers from MPEG-LA regarding the 
various questions that came up, such as what constitutes a "unit".

Gili

---

From: Roman Shpount <[email-masked]>
Date: Tue, 26 Nov 2013 16:17:13 -0500

Just a reminder that license from MPEG-LA, even though required, is not
sufficient to use H.264 codec. There are other intellectual property
holders (such as Nokia) which are not part of MPEG-LA. These property
holders are supposed to give you license under RAND terms, but you need to
negotiate with them separately. All of this before taking patent trolls
into account, which can obviously sue you at any time for any reason.

Bottom line, unless you want to spend thousands of dollars and a lot of
time negotiating, you cannot license H.264. Your choices are either use
H.264 licensed by somebody else, assuming they will be responsible for
license fee (like Cisco binary download) or hope that you are small enough
not be sued.

_____________
Roman Shpount

On Tue, Nov 26, 2013 at 3:50 PM, cowwoc <[email-masked]> wrote:

> The fact that we are being asked to pay lawyers as an insurance policy (to
> get a legal opinion on a vague license) is not right. I can understand why
> the open-source guys are finding this lack of transparency very disturbing.
>
> All this is to say: Cisco's proposal is a step in the right direction but
> there remains a large gap that needs to be filled. I encourage H.264
> As discussed with Cullen during the conference, we should be able to come
> up with "creative" licensing terms that allow us to buy multiple units in
> bulk and integrating the codec directly into our images. As opposed to
> manually downloading the codec each time. Similarly, we should get more
> concrete/official answers from MPEG-LA regarding the various questions that
> came up, such as what constitutes a "unit".
>
> Gili
>
>> I think for a scenario like that you would use a different approach as
>> long as you used less than 100k virtual machines - which is a reasonable
>> assumption for all the cloud services I am aware of. You would take the
>> source code and compile it to form the executables on the master image for
>> the VM. You would then distribute the VM normally and not use the Cisco
>> binary.
>>
>> The other case that has come up is a large enterprise that makes a master
>> copy of the image that distributed to all their desktops  and it is a case
>> where the company has over 100k desktops.  If they own the desktops my
>> understanding is they are the end user from that point of view and as long
>> as the IT department downloaded a copy of the Cisco binary and put it into
>> their master image and then put that master image on computers they own /
>> operate then that can be made to work too.
>>
>> This stuff is all sort of subtle but there seems to be a wide range of
>> options that can be made to work and have examples of people already doing
>> it with H264 MPEG LA licenses.
>>
>>
>>>> My understanding of the legal situation is that you can use the cisco
>>>> binary on your EC2 instance and have Cisco pay the MPEG-LA fees.
>>>>
>>>
>>> The issue that was mentioned was cloned/frozen VM images that you could
>>> spawn to increase scalability. In that case, you would prepare/install an
>>> image just once, freeze it, and then launch a new one whenever you need it.
>>> Ideally you'd have the plugin installed that first time only, but then all
>>> cloned instances would fall out of the license agreement, as they'd
>>> actually be different machines with the plugin reinstalled rather than
>>> downloaded on the fly. Downloading the plugin for each new image that is
>>> spawned as it unfreezes would be a problem, as 1) the image wouldn't be
>>> ready right away, and 2) any problem in the download process would make the
>>> machine useless with respect to H.264.
>>>
>>> Lorenzo
>>>
>>>