Re: [rtcweb] MTI Video Codec: a novel proposal

[Tim Panton <[e-mail]>]

> On 10 Nov 2014, at 16:51, Daniel-Constantin Mierla <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On 10/11/14 11:29, tim panton wrote:
>> Adam, thanks for sticking you head above the parapet ! 
>> I’m largely in favour of this solution, further, I think it represents the realities on the ground
> 
> It looks more like the reality on the ground of a few groups of
> interests (e.g, GSMA, telco vendors) trying to protect themselves. But
> again, in the web/internet world I don't see the same reality, they must
> stay competitive with features, not with restrictions or barriers to
> potential competitors.

On the subject of codecs, I discount the opinion of the GSMA utterly,
they have had 10 years  to make video calling (and wideband audio)
a desirable user proposition and have failed completely. 

The realities I’m thinking of are the ones facing someone building a
video enabled pet phone (for example). I can get H264 hardware very
cheaply (eg a raspberry Pi) and have it communicate with an ios App
or firefox on a laptop without any license (as far as I can tell).
Getting the same setup to work with VP8 will consume significantly 
more battery power at both ends.

I wish this were not the case, but that’s the reality I see.

> 
> If something costly or with other restrictions is technically better or
> improving the user experience a lot in some medium of communication,
> then the developer of some app can decide to use/implement it. There is
> no reason of enforcing limits and financial constraints to everyone in
> open web via specs supposed to become standard.

If we mandate both codecs for devices, I agree, we are imposing an unacceptable
burden on everyone.
However I’m doubtful that any entity who can afford to build a new
w3c standards compatible browser will be unable to afford the (capped) h264 fee,
that’s simply a measure of how much work I think it is to do a new user agent now.
So the penalty in terms of restricting new browser innovation is small  (IMHO)
I’m much more worried about innovative devices.

> 
> Rather than forcing now something inconvenient to be re-evaluated later
> for removal, better don't force anything now and re-evaluate later for
> inclusion. It will allow the market (besides the big players) to decide
> freely where it wants to move. The current proposal looks like: let's
> close the group now and later decide if we allow others in. Why not the
> other way around, keep the market fully open for new comers now and see
> what is going to be out there in few years, whether it makes sense to
> start building the walls at that moment.

That’s where we disagree. I really do not want to have to have a complex
matrix of versions of my parrot phone that correctly interop with other devices and
other pairings that don’t.

(E.G. buy a new android tablet and our android app if you use chrome, but if you reuse
an old ipad, you’ll have to use firefox).

We need an MTI statement. If we don’t get one we will be stuck with little
facetime-like islands again.

> 
> Daniel
> 
>> better
>> than any other proposal to date, as such it merits support.
>> 
>> On 10 Nov 2014, at 02:08, Adam Roach <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents. 
>> I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will 
>> always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
>> of a webRTC device.
>> 
>> I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
>> but that devices can’t necessarily communicate video between each other without a transcoding middle man.
>> 
>> This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
>> don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a 
>> clearer separation.
>> 
>> This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
>> know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
>> says that it will work with any user agent. 
>> 
>> With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.
>> 
>> Tim.
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> -- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#!/miconda> - http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rtcweb

Tim Panton - Web/VoIP consultant and implementor
www.westhawk.co.uk <http://www.westhawk.co.uk/>