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

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.

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.

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.

Daniel

>  better
> than any other proposal to date, as such it merits support.
>
> On 10 Nov 2014, at 02:08, Adam Roach <adam@nostrum.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda