Subject: [rtcweb] Making both VP8 and H264 MTI

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 5 Nov 2013 14:18:11 +0000

It seems to me that making both VP8 and H264 MTI might be a good option for WebRTC in terms of maximizing interoperability and would be a better decision coming out of this IETF meeting than no decision at all.

Can we have some clarification as to whether any consensus call during this week's meeting will include this option?

Previously it was stated that the questions to be asked would be:

1. If you support H.264 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

2. If you support VP8 as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

How would we conclude that the community would like both to be made MTI?

Regards
Andy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Nov 2013 06:46:45 -0800

> How would we conclude that the community would like both to be made MTI?

If I were to pretend that I am a process wonk, I might say something
like: if the objections to both questions are weak AND if the
objectors are unable to find reasons that pass muster.

---

From: Leon Geyser <[email-masked]>
Date: Tue, 5 Nov 2013 18:33:46 +0200

Both can't be made mandatory, because some parties would refuse to
implement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory
to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually None
shouldn't even be an option, because it won't solve negotiation failure.

On 5 November 2013 16:18, Hutton, Andrew <[email-masked]> wrote:

> It seems to me that making both VP8 and H264 MTI might be a good option
> for WebRTC in terms of maximizing interoperability and would be a better
> decision coming out of this IETF meeting than no decision at all.
>
> Can we have some clarification as to whether any consensus call during
> this week's meeting will include this option?
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 5 Nov 2013 17:12:12 +0000

Any implementation can refuse to implement any MTI, whether it is 1 or 2. I see more good than harm by mandating both. We mandated Opus and G.711, right? Did anyone complain that 2 MTIs would increase the chance of negotiation failure? Forcing a binary MTI decision suggests an intent to let one live and kill the other. Live and let live...

Mo

On 11/5/13, 11:33 AM, Leon Geyser <[email-masked]<mailto:[email-masked]>> wrote:

Both can't be made mandatory, because some parties would refuse to implement VP8 or H.264. This will cause negotiation failure anyway.
What about a 3?
3. If you support a codec with expired IPR(such as H.261) as the mandatory to implement codec or are
willing to live with it as the MTI, please raise your hand now.

None should only be an option if 1/2/3 can't be satisfied. Actually None shouldn't even be an option, because it won't solve negotiation failure.

On 5 November 2013 16:18, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:
It seems to me that making both VP8 and H264 MTI might be a good option for WebRTC in terms of maximizing interoperability and would be a better decision coming out of this IETF meeting than no decision at all.

Regards
Andy
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Leon Geyser <[email-masked]>
Date: Tue, 5 Nov 2013 19:21:51 +0200

>>Any implementation can refuse to implement any MTI, whether it is 1 or 2.
I see more good than harm by mandating both.
Mandating 2 is just as good as mandating 0. I just don't get the logic of
mandating 2.

>>We mandated Opus and G.711, right? Did anyone complain that 2 MTIs would
increase the chance of negotiation failure?
I disagree. Completely different situation. G.711 is there, because it has
NO IPR issues and can be implemented in like +/- 10 lines of code. Nice for
testing and has NO IPR issues. Both are royalty free codecs btw.

On 5 November 2013 19:12, Mo Zanaty (mzanaty) <[email-masked]> wrote:

>  Any implementation can refuse to implement any MTI, whether it is 1 or
> 2. I see more good than harm by mandating both. We mandated Opus and G.711,
> right? Did anyone complain that 2 MTIs would increase the chance of
> negotiation failure? Forcing a binary MTI decision suggests an intent to
> let one live and kill the other. Live and let live...
>
>  Mo
>
>
>   On 11/5/13, 11:33 AM, Leon Geyser <[email-masked]> wrote:
>

---

From: Wolfgang Beck <[email-masked]>
Date: Tue, 5 Nov 2013 18:23:58 +0100

H.264 for legacy interop, VP8 for the use cases where the MPEG LA's
licensing conditions might get into the way of a novel service.. sounds
like a good compromise. Of course this moves the complexity from the
network (video transcoding gateways) into the browser. As transcoding
gateways don't scale well, I'd prefer the browser support for both codecs.

Wolfgang Beck

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 5 Nov 2013 17:27:15 +0000

This is an important point the chairs must clarify. If there is strong
support for both questions, will the chair interpret that as support for 2
MTIs, or declare no consensus, forcing us into alternative processes? I
support both as MTI. But if raising my hand twice increases the likelihood
of an alternative process, I will only support one (despite objecting to
being forced to support only one).

Mo

On 11/5/13, 9:46 AM, Martin Thomson <[email-masked]> wrote:

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 5 Nov 2013 17:44:28 +0000

Right now there is no proposal on the table for the MTI to be both VP8 and H.264 and the deadline was back in October so it's not a topic the chairs feel ready to discuss in the thursday meeting. 

I will note that in the past when this idea was discussed, the people who were concerned about IPR for either codec pointed out that this could only increased, not decreased, the IPR concerns. 

The chairs are more concerned about neither choice being acceptable. If we found out that both are acceptable, that will be a good situation and we will find a reasonable way to proceed from there that is acceptable to the WG. Alternative process is the last resort. From a chair point of view, it really better if people actually honestly answer the question in a consensus call instead gaming the system. 

Cullen - Just one of the chairs and I hope my co-chairs add more but they are both in meetings right now

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 13:01:39 -0500

On 05/11/2013 12:21 PM, Leon Geyser wrote:
> >>Any implementation can refuse to implement any MTI, whether it is 1 
> or 2. I see more good than harm by mandating both.
> Mandating 2 is just as good as mandating 0. I just don't get the logic 
> of mandating 2.

     If new IPR issues bubble up for H.264 or VP8 we're free to drop one 
of the MTI codecs and fallback on the other. If we only have a single 
MTI codec, we have no way to drop it and therefore we're forced to pay 
royalties to whomever decided to sue.

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 13:02:33 -0500

On 05/11/2013 12:23 PM, Wolfgang Beck wrote:
> licensing conditions might get into the way of a novel service.. 
> sounds like a good compromise. Of course this moves the complexity 
> from the network (video transcoding gateways) into the browser. As 
> transcoding gateways don't scale well, I'd prefer the browser support 
> for both codecs.

     You're always free to use H.264 for legacy interop. I don't see why 
this means it should be MTI (forcing everyone to pay a license or jump 
through distribution loopholes).

Gili

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 13:06:19 -0500

Cullen,

     In light of the fact that vendors are highly polarized on this 
topic, I'd like to suggest the following voting order:

1. Should *both* H.264 and VP8 be MTI?

If there is a consensus for yes, stop here.

2a. Should *only* H.264 be MTI? or,
2b. Should *only* VP8 be MTI?

If there is a consensus for either one, stop here.

3a. Should *only* H.261 be MTI? or,
3b. Should no codec be MTI? (this implies transcoding)

     Given the final choice (H.261 or no MTI) I suspect many vendors 
would choose H.261 and upgrade to H.264/VP8 at runtime. No one really 
wants to go back to the days of transcoding.

Gili

---

From: Mohammed Raad <[email-masked]>
Date: Wed, 6 Nov 2013 08:31:40 +1100

Hi,

Given the lack of agreement on a single MTI, for business reasons
primarily, and given that the debate is really focused on two candidates, I
suggest that a transcoding function between these two codecs be defined at
the service provider level.

I suggest that the transcoding function only include the VP8 and AVC CBP to
make the development and use of this part of the service feasible.

Having such a function would allow different organizations to make their
own decision about what works for them. I sense that different experts have
become entrenched in their respective positions with very little freedom to
make a change, for multiple reasons. I think it should be clear that having
transcoding at the service level would be a reasonable compromise. Note
that no end device would be required to perform the transcoding, this would
be done at the service provider level.

BR,
Mohammed
On Nov 6, 2013 5:07 AM, "cowwoc" <[email-masked]> wrote:

> Cullen,
>
>     In light of the fact that vendors are highly polarized on this topic,
> I'd like to suggest the following voting order:
>
>     Given the final choice (H.261 or no MTI) I suspect many vendors would
> choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to go
> back to the days of transcoding.
>
> Gili
>
>> Right now there is no proposal on the table for the MTI to be both VP8
>> and H.264 and the deadline was back in October so it's not a topic the
>> chairs feel ready to discuss in the thursday meeting.
>>
>> I will note that in the past when this idea was discussed, the people who
>> were concerned about IPR for either codec pointed out that this could only
>> increased, not decreased, the IPR concerns.
>>
>> The chairs are more concerned about neither choice being acceptable. If
>> we found out that both are acceptable, that will be a good situation and we
>> will find a reasonable way to proceed from there that is acceptable to the
>> WG. Alternative process is the last resort. From a chair point of view, it
>> really better if people actually honestly answer the question in a
>> consensus call instead gaming the system.
>>

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 17:03:09 -0500

Mohammed,

     Your approach does not work for the typical browser-to-browser 
(P2P) connections.

Gili

On 05/11/2013 4:31 PM, Mohammed Raad wrote:
> primarily, and given that the debate is really focused on two 
> candidates, I suggest that a transcoding function between these two 
> codecs be defined at the service provider level.
>
> I suggest that the transcoding function only include the VP8 and AVC 
> CBP to make the development and use of this part of the service feasible.
>
> Having such a function would allow different organizations to make 
> their own decision about what works for them. I sense that different 
> experts have become entrenched in their respective positions with very 
> little freedom to make a change, for multiple reasons. I think it 
> should be clear that having transcoding at the service level would be 
> a reasonable compromise. Note that no end device would be required to 
> perform the transcoding, this would be done at the service provider level.
>
> BR,
> Mohammed
>
> On Nov 6, 2013 5:07 AM, "cowwoc" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Cullen,
>
>         Given the final choice (H.261 or no MTI) I suspect many
>     vendors would choose H.261 and upgrade to H.264/VP8 at runtime. No
>     one really wants to go back to the days of transcoding.
>
>     Gili
>
>         Right now there is no proposal on the table for the MTI to be
>         both VP8 and H.264 and the deadline was back in October so
>         it's not a topic the chairs feel ready to discuss in the
>         thursday meeting.
>
>         I will note that in the past when this idea was discussed, the
>         people who were concerned about IPR for either codec pointed
>         out that this could only increased, not decreased, the IPR
>         concerns.
>
>         The chairs are more concerned about neither choice being
>         acceptable. If we found out that both are acceptable, that
>         will be a good situation and we will find a reasonable way to
>         proceed from there that is acceptable to the WG. Alternative
>         process is the last resort. From a chair point of view, it
>         really better if people actually honestly answer the question
>         in a consensus call instead gaming the system.
>
>         Cullen - Just one of the chairs and I hope my co-chairs add
>         more but they are both in meetings right now
>
>
>         On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)"
>         <[email-masked] <mailto:[email-masked]>>
>           wrote:
>
>             On 11/5/13, 9:46 AM, Martin Thomson
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>             On 5 November 2013 06:18, Hutton, Andrew
>             <[email-masked] <mailto:[email-masked]>>
>             wrote:
>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 6 Nov 2013 00:12:25 +0100

I support this voting suggestion and don't think it violates the proposals
on the table. 

I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only one
that has a chance of reaching consensus.

Also, 
- it is the best to avoid connection failure
- it will avoid requests for transcoding in the network (which would be very
bad technically)
- with the royalty free solutions VP8 from Google and H.264 from Cisco, why
not? None of these offers are conditioned being the only MTI. It is
technically not more difficult to include both than H.264 only.
- if any real IPR issue appears for H.264 or VP8, we have a fallback by
removing the MTI for one of these.
- we will see the Cisco codec plug-in slot model at least in some popular
browsers, which could be used for future codec plug-ins; better and
innovative codecs for general or specialized usage-

In short: Why not making both MTI? We have both G.711 and Opus for Audio.  

/Karl

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]] För cowwoc
Skickat: den 5 november 2013 19:06
Till: [email-masked]
Ämne: Re: [rtcweb] Making both VP8 and H264 MTI

Cullen,

Gili

On 05/11/2013 12:44 PM, Cullen Jennings (fluffy) wrote:
> Right now there is no proposal on the table for the MTI to be both VP8 and
H.264 and the deadline was back in October so it's not a topic the chairs
feel ready to discuss in the thursday meeting.
>
> The chairs are more concerned about neither choice being acceptable. If we
found out that both are acceptable, that will be a good situation and we
will find a reasonable way to proceed from there that is acceptable to the
WG. Alternative process is the last resort. From a chair point of view, it
really better if people actually honestly answer the question in a consensus
call instead gaming the system.
>> This is an important point the chairs must clarify. If there is 
>> strong support for both questions, will the chair interpret that as 
>> support for 2 MTIs, or declare no consensus, forcing us into 
>> alternative processes? I support both as MTI. But if raising my hand 
>> twice increases the likelihood of an alternative process, I will only 
>> support one (despite objecting to being forced to support only one).
>>
>> Mo
>>
>>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Nov 2013 15:25:11 -0800

The cost equation for CPU versus network is shifted enough in favor of CPU
that considering old codecs like H.261 makes no financial sense. If you
look at AWS pricing, the CPU cost of reducing bitrate from 1 Mbps to 750
Kbps is more than made up by the network cost.

http://aws.amazon.com/ec2/pricing/
250 Kbps * 1 hour = $0.11
high-compute instance for an hour = $0.05 (1 HD transcode = 4 SD transcodes)

Transcoding isn't the bogeyman people are making it out to be.

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 18:59:42 -0500

Justin,

     What happens to P2P video chat? Are we throwing that out of the 
window? A P2P-based mesh is superior to one with AWS in the middle for a 
couple of reasons:

  * Privacy
  * Cost
  * Consistent latency
  * Ease of deployment

Gili

On 05/11/2013 6:25 PM, Justin Uberti wrote:
> The cost equation for CPU versus network is shifted enough in favor of 
> CPU that considering old codecs like H.261 makes no financial sense. 
> If you look at AWS pricing, the CPU cost of reducing bitrate from 1 
> Mbps to 750 Kbps is more than made up by the network cost.
>
> On Tue, Nov 5, 2013 at 10:06 AM, cowwoc <[email-masked]

---

From: <[email-masked]>
Date: Wed, 6 Nov 2013 00:28:48 +0000

Hi,

> removing the MTI for one of these.

Define "real IPR issue". 

Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Karl Stahl
> Sent: 06 November, 2013 01:12
> To: 'cowwoc'; [email-masked]
> Subject: Re: [rtcweb] Making both VP8 and H264 MTI
> 
> I support this voting suggestion and don't think it violates the proposals on
> the table.
> 
> I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only one that
> has a chance of reaching consensus.
> 
> Also,
> not? None of these offers are conditioned being the only MTI. It is technically
> not more difficult to include both than H.264 only.
>      In light of the fact that vendors are highly polarized on this topic, I'd like to
> suggest the following voting order:
> 
> choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to
> go back to the days of transcoding.
> 
> Gili
> 
> > and
> H.264 and the deadline was back in October so it's not a topic the chairs feel
> ready to discuss in the thursday meeting.
> >
> found out that both are acceptable, that will be a good situation and we will
> find a reasonable way to proceed from there that is acceptable to the WG.
> Alternative process is the last resort. From a chair point of view, it really
> better if people actually honestly answer the question in a consensus call
> instead gaming the system.
> >
> <[email-masked]> wrote:

---

From: [email-masked]
Date: Tue, 5 Nov 2013 16:53:45 -0800

"real IPR issue" :  ability to compile and distribute an h.264 codec
without getting a license and paying royalties.

"not real IPR issue" : claims made against Opus by Qualcomm and Huawei

---

From: Justin Uberti <[email-masked]>
Date: Tue, 5 Nov 2013 17:01:01 -0800

True P2P isn't always possible, witness TURN. So everyone deploying a
reliable WebRTC app is going to have bandwidth costs.

Those costs will be higher and/or quality much lower, when using H.261 or
comparable codecs.

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

>    - Privacy
>    - Cost
>    - Consistent latency
>    - Ease of deployment
>>> I will note that in the past when this idea was discussed, the people
>>> who were concerned about IPR for either codec pointed out that this could
>>> only increased, not decreased, the IPR concerns.
>>>

---

From: cowwoc <[email-masked]>
Date: Tue, 05 Nov 2013 20:59:11 -0500

On 05/11/2013 8:01 PM, Justin Uberti wrote:
> Those costs will be higher and/or quality much lower, when using H.261 
> or comparable codecs.

     So what? Assuming the endpoints can't agree on a codec... If you 
mandate H.261 as MTI, vendors have the choice of either:

  * Using H.261, or
  * Upgrading endpoints to H.264/VP8, and transcoding.

     The choice is theirs. If you don't mandate any codec as MTI, we are 
*forced* to transcode.

     Transcoding might be fine for the big boys, but not for indie 
developers working out of their garage. P2P calls make up the vast 
majority of cases. I might be willing to lose 5% of users due to lack of 
TURN support, if it reduces my costs and simplifies my infrastructure.

Gili

---

From: Mohammed Raad <[email-masked]>
Date: Wed, 6 Nov 2013 15:42:25 +1100

Is WebRTC only intended for P2P implementations? Granted, you can't get
pure P2P if you have a gateway in the middle, but this would only be the
case for connections between endpoints that have not implemented the same
MTI.

Mohammed
On Nov 6, 2013 9:03 AM, "cowwoc" <[email-masked]> wrote:

>  Mohammed,
>
>     Your approach does not work for the typical browser-to-browser (P2P)
> connections.
>
> Gili
>
> I suggest that the transcoding function only include the VP8 and AVC CBP
> to make the development and use of this part of the service feasible.
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: cowwoc <[email-masked]>
Date: Wed, 06 Nov 2013 00:20:23 -0500

I didn't mean to imply that we should only support the P2P 
use-case, but it is an important use-case to support. The problem with 
your solution is that for the P2P use-case where the endpoints don't 
implement the same codec, the connection would simply fail.

     Depending on your application, up to 95%+ of calls can be P2P. It 
is possible/probably that Chrome might only implement VP8 and IE/Safari 
might only implement H.264. In such a case, you have a fairly large 
probability of failure (less than 50% but still large). Whatever 
solution we could up with should have a 95% chance of success for both 
P2P and gateway use-cases.

Gili

On 05/11/2013 11:42 PM, Mohammed Raad wrote:
>
> Is WebRTC only intended for P2P implementations? Granted, you can't 
> get pure P2P if you have a gateway in the middle, but this would only 
> be the case for connections between endpoints that have not 
> implemented the same MTI.
>
> Mohammed
>
> On Nov 6, 2013 9:03 AM, "cowwoc" <[email-masked] 
>>     candidates, I suggest that a transcoding function between these
>>     two codecs be defined at the service provider level.
>>
>>     I suggest that the transcoding function only include the VP8 and
>>     AVC CBP to make the development and use of this part of the
>>     service feasible.
>>
>>     Having such a function would allow different organizations to
>>     make their own decision about what works for them. I sense that
>>     different experts have become entrenched in their respective
>>     positions with very little freedom to make a change, for multiple
>>     reasons. I think it should be clear that having transcoding at
>>     the service level would be a reasonable compromise. Note that no
>>     end device would be required to perform the transcoding, this
>>     would be done at the service provider level.
>>
>>     BR,
>>     Mohammed
>>
>>             In light of the fact that vendors are highly polarized on
>>         this topic, I'd like to suggest the following voting order:
>>
>>         vendors would choose H.261 and upgrade to H.264/VP8 at
>>         runtime. No one really wants to go back to the days of
>>         transcoding.
>>
>>         Gili
>>
>>             Right now there is no proposal on the table for the MTI
>>             to be both VP8 and H.264 and the deadline was back in
>>             October so it's not a topic the chairs feel ready to
>>             discuss in the thursday meeting.
>>
>>             I will note that in the past when this idea was
>>             discussed, the people who were concerned about IPR for
>>             either codec pointed out that this could only increased,
>>             not decreased, the IPR concerns.
>>
>>             acceptable. If we found out that both are acceptable,
>>             that will be a good situation and we will find a
>>             reasonable way to proceed from there that is acceptable
>>             to the WG. Alternative process is the last resort. From a
>>             chair point of view, it really better if people actually
>>             honestly answer the question in a consensus call instead
>>             gaming the system.
>>
>>             Cullen - Just one of the chairs and I hope my co-chairs
>>             add more but they are both in meetings right now
>>
>>
>>                 <[email-masked]
>>                 <mailto:[email-masked]>> wrote:
>>

---

From: Ron <[email-masked]>
Date: Wed, 6 Nov 2013 19:14:23 +1030

> topic, I'd like to suggest the following voting order:

I don't think it's really all that relevant for rough consensus if
'vendors are highly polarised' on the question at all.

If you make that a consideration, I'm sure you can find some vendors
(who may or may not be present here) who strongly wish that WebRTC
will never exist at all in the form that this group's charter has
envisaged, since its success would pose a very real threat to their
current business monopolies.  That doesn't give them a right of veto
to this work, though their input, like everyone else's, still merits
consideration for its technical contribution to best achieving the
charter's aims.

Having a favourite horse in a race is fine.  Having that horse be the
fittest to win is a far more objective measurement.

The question of choosing a MTI codec hinges on interoperability, and
we have established consensus that having a viable MTI codec is quite
crucial for this.

Right now we have 2 proposed candidates.  So the important questions
are:

 - Are either of those candidates suitable?
 - Is one clearly more suitable than the other?

And the present question has been framed by the WG chairs as:

 - Are there reasons that people could not possibly use either choice?

The reasons that people cannot possibly use H.264 are well established.
Its licencing simply does not permit people to use it in all the varied
ways that implementors and users of WebRTC would require.

The Cisco announcement was clearly an attempt to mitigate this fatal
constraint for their preferred choice, and while it goes some way toward
doing that - and is certainly a bold and perceptive step for them to
take to maintain the value of their existing investment - they are still
constrained by these same licencing terms to only be able to offer a
very limited solution, of limited use, to a limited number of people.
And they still can't offer the sort of indemnity that the H.264 camp
has demanded from VP8 in draft-dbenham-webrtc-videomti-02, and they
aren't even offering a licence to _all_ of the known IPR covering H.264,
only to that covered by the MPEG LA pool - which the Nokia portfolio,
some of which was already disclosed, is notably outside of.

The reasons that people cannot possibly use VP8 are far less clear.
None of the objections beyond "we don't want to" so far have any
grounding in reality.  The "but but submarine IPR!!" argument applies
equally to *anything* that any WG might chose to do or use.

Nokia tried to pull some out of their hat, but they lost in court.
If they couldn't torpedo this, then the chances of anyone else being
able to seem significantly diminished.  But the validity of their
claims over H.264 are not challenged at all, and remain a clear and
present danger for anyone using H.264.  Perhaps even more so now
than ever, given their current financial situation and being the
subject of a takeover bid.

This is why I believe that although we have 2 proposals, only one
of them can seriously stand up to scrutiny for being an acceptable
choice that passes the muster of rough consensus.

"We don't want to" is not a blocker for consensus.

"The licence of this does not permit us to" is a very real blocker.

Given we have consensus for picking an MTI codec, the only reason
not to pick that remaining choice would be if someone springs yet
another last minute surprise which would delay that decision again.

If that actually happens, then maybe we can once again have the
H.261 vs Theora debate - but if it doesn't, then VP8 is still the
no-brainer choice that can stand up to the full test of having
rough consensus and working code that meets the goals of this WG.

Re this suggestion:

> would choose H.261 and upgrade to H.264/VP8 at runtime. No one
> really wants to go back to the days of transcoding.

You might want to review the list archives.  This question has already
been debated, and I thought the result of that was conclusive, and why
we have only the current proposals that we do today.

  Cheers,
  Ron

---

From: David Singer <[email-masked]>
Date: Wed, 06 Nov 2013 17:53:57 +0900

On Nov 6, 2013, at 9:53 , [email-masked] wrote:

> 
> "real IPR issue" :  ability to compile and distribute an h.264 codec without getting a license and paying royalties.
> 

where does Nokia's statement fall, in your opinion?

> On Tue, Nov 5, 2013 at 4:28 PM, <[email-masked]> wrote:

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: cowwoc <[email-masked]>
Date: Wed, 06 Nov 2013 04:01:38 -0500

> "We don't want to" is not a blocker for consensus.

     Nice in theory, but that's not how things work in practice. Vendors 
have some very good (albeit subjective) reasons to align themselves with 
VP8 or H.264 and I don't fault them for doing so. Ignoring this reality 
will lead to a never-ending lack of consensus.

     Knowing that everyone will continue pushing their favorite horse 
regardless of the facts, I reiterate my proposal for a multi-phased 
vote, making it clear in advance that if we reach the last phase without 
a compromise we are implicitly voting for transcoding. The vote should 
end with a decision being made, one way or the other.

     TokBox enumerated some concrete compromises needed from either 
side: http://www.tokbox.com/blog/is-webrtc-ready-for-h-264/ ... We need 
to start moving down that road in order to meet in the middle.

Gili

---

From: cowwoc <[email-masked]>
Date: Wed, 06 Nov 2013 04:07:59 -0500

I don't understand why we are playing these semantic games.

     If we mandate multiple codecs as MTI, and "something goes wrong" 
(be it an IPR issue, security issue, etc) we have the ability remove 
that codec from MTI without breaking interoperability. If we only 
mandate a single codec as MTI, there is no such ability.

Gili

---

From: Daniel-Constantin Mierla <[email-masked]>
Date: Wed, 06 Nov 2013 10:30:53 +0100

On 11/6/13 10:07 AM, cowwoc wrote:
> (be it an IPR issue, security issue, etc)
As it stands today, there are well known IPR issues with h264. Cisco's 
move doesn't lift them.

So why to choose it if falls under the rules to remove it?

With both on board, I still expect the majority of the apps will 
implement only the most convenient for them, eventually expecting the 
other to have both. Then responsibility is getting divided, like "it's 
not _only_ my fault", blaming the other end point as well.

Daniel

> we have the ability remove that codec from MTI without breaking 
> interoperability. If we only mandate a single codec as MTI, there is 
> no such ability.
>
> Gili
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
   - more details about Kamailio trainings at http://www.asipto.com -

---

From: cowwoc <[email-masked]>
Date: Wed, 06 Nov 2013 05:10:43 -0500

> So why to choose it if falls under the rules to remove it?

     No one says it has to be H.264 and VP8. It could be H.261 and VP8.

> not _only_ my fault", blaming the other end point as well. 

     That is a reasonable concern, and one that we need to address. 
Implementations that violate these rules will make it harder for us to 
replace older MTI codecs without breaking backwards compatibility.

Gili

---

From: Mohammed Raad <[email-masked]>
Date: Thu, 7 Nov 2013 07:33:58 +1100

Hi,

There isn't much new in the arguments for and against VP8 vs H.264. Its
clear that there are concerns that are beyond how well each codec performs
and whether or not it is free. Although I recognize that the transcoding
option does not address the P2P use case, I do think that the goal of
interoperability can be better achieved through a two phase approach. The
first is enabling end-points to inter-operate through the availability of
transcoding from the service provider. The second is to make one of the
codecs the defacto MTI because of the its higher level of adoption. Yes, we
may never get to a single MTI if we follow this path but at least we will
have endpoints inter-operating. Besides, there are multiple other
difficulties in getting seamless P2P communications working all the time,
so I would suggest focusing on the service provider centered use case first.

BR,
Mohammed

On Wed, Nov 6, 2013 at 9:10 PM, cowwoc <[email-masked]> wrote:

>> implement only the most convenient for them, eventually expecting the other
>> to have both. Then responsibility is getting divided, like "it's not _only_
>> my fault", blaming the other end point as well.
>>
>

-- 
Mohammed Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: [email-masked]

---

From: David Singer <[email-masked]>
Date: Thu, 07 Nov 2013 15:04:06 +0900

On Nov 7, 2013, at 5:33 , Mohammed Raad <[email-masked]> wrote:

> Hi,
> 
> There isn't much new in the arguments for and against VP8 vs H.264. Its clear that there are concerns that are beyond how well each codec performs and whether or not it is free. Although I recognize that the transcoding option does not address the P2P use case, I do think that the goal of interoperability can be better achieved through a two phase approach. The first is enabling end-points to inter-operate through the availability of transcoding from the service provider. The second is to make one of the codecs the defacto MTI because of the its higher level of adoption. Yes, we may never get to a single MTI if we follow this path but at least we will have endpoints inter-operating. Besides, there are multiple other difficulties in getting seamless P2P communications working all the time, so I would suggest focusing on the service provider centered use case first.

You know, you're right.  

We could suggest or even recommend both, and mandate you must implement at least one of the two. That would identify precisely two interoperability points in an otherwise much larger space, at least, and make it fairly simple for those that can and wish to, to offer transcoding, since the two ends are now defined.  It's not ideal, but it might be better than saying nothing at all.

> As it stands today, there are well known IPR issues with h264. Cisco's move doesn't lift them.
> 
> With both on board, I still expect the majority of the apps will implement only the most convenient for them, eventually expecting the other to have both. Then responsibility is getting divided, like "it's not _only_ my fault", blaming the other end point as well. 
> 
>     That is a reasonable concern, and one that we need to address. Implementations that violate these rules will make it harder for us to replace older MTI codecs without breaking backwards compatibility.
> 
> Gili
> 

David Singer

---

From: Ron <[email-masked]>
Date: Thu, 7 Nov 2013 21:57:24 +1030

On Thu, Nov 07, 2013 at 03:04:06PM +0900, David Singer wrote:
> We could suggest or even recommend both, and mandate you must implement at
> least one of the two. That would identify precisely two interoperability
> points in an otherwise much larger space, at least, and make it fairly simple
> for those that can and wish to, to offer transcoding, since the two ends are
> now defined.  It's not ideal, but it might be better than saying nothing at
> all.

I thought the performance and other problems with forcing _everyone_ through
a central relay server were well known?  I would have thought David at least
would be somewhat aware of them.  Adding that to a guaranteed interop failure
outcome might be a cunning plan, but I wouldn't call it a good one.

http://arstechnica.com/tech-policy/2013/08/report-after-patent-loss-apple-tweaks-facetime-and-logs-500000-complaints/

The whole point of a MTI codec is there will be no "otherwise larger space"
if we choose one that all implementors are free to use.

  Ron

---

From: Mohammed Raad <[email-masked]>
Date: Fri, 8 Nov 2013 01:01:07 +1100

Hi,

If I have understood the content of the story at the link you provided
correctly, either you run through (what the story calls) "relay servers" or
you are exposed to a large patent licensing fee. Is that a correct
understanding?

Best Regards,
Mohammed

---

From: cowwoc <[email-masked]>
Date: Thu, 07 Nov 2013 09:56:23 -0500

> We could suggest or even recommend both, and mandate you must implement at least one of the two. That would identify precisely two interoperability points in an otherwise much larger space, at leas…

     I can't believe you guys are actually trying to convince us that 
being forced to use a transcoder is actually a *good* thing! Any 
solution that does not address the P2P use-case is a non-starter. Feel 
free to use this model in your own deployments, just don't force it on us.

Gili

---

From: David Singer <[email-masked]>
Date: Fri, 08 Nov 2013 09:14:20 +0900

On Nov 7, 2013, at 23:56 , cowwoc <[email-masked]> wrote:

>    I can't believe you guys are actually trying to convince us that being forced to use a transcoder is actually a *good* thing! Any solution that does not address the P2P use-case is a non-starter. Feel free to use this model in your own deployments, just don't force it on us.

For a start, not everyone would have to transcode, only those cases where there the two ends implement only one, and different, codecs.  Secondly, I didn't say it was ideal, I I said it was better than saying nothing.  Third, if you implement both, you would never need to use a transcoder for this reason, but you nonetheless might use a bridge or intermediary for a whole host of other reasons.

David Singer

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 08 Nov 2013 16:45:42 +0900

On 2013/11/08 9:14, David Singer wrote:

> For a start, not everyone would have to transcode, only those cases where there the two ends implement only one, and different, codecs.
 > Secondly, I didn't say it was ideal, I I said it was better than 
saying nothing.
 > Third, if you implement both, you would never need to use a 
transcoder for this reason, but you nonetheless might use a bridge or 
intermediary for a whole host of other reasons.

Would Apple implement both? Would Google implement both?

(As I understand it, Mozilla will implement both.)

Regards,   Martin.