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

[Daniel-Constantin Mierla <[e-mail]>]

On 10/11/14 18:40, Tim Panton wrote:
>
>> 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.

Very cheaply for one user, but can be very costly for a service or an
app distributed to the masses. Then it was not clear (unless I missed
some resolution on the topic during the summer) if you can rely on the
license given to the hardware.

Why not standardize the h264 and vp8 hardware control API, the
manufactures of hardware devices have to implement it and the app
developers have to use them?!? Then practically, the apps devs don't
need to mess with ipr of h264 or vp8 -- if there is hardware support
with appropriate API, then will be enabled.

>
>>
>> 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,

You can have one in minutes by making own built of firefox or chromium,
discarding the non-source-code licensed/copyrighted items such as logos,
icons, etc ... then tailor it for your specific needs (e.g., more
privacy, no automatic reports, etc.) The problem is that the new built
app doesn't have the financial power as the original one, but still
distributed to the masses in an uncontrollable way (e.g., linux distros,
with mirrors, etc.).

I already pointed that such cases exists already (e.g., debian). Also,
repeating, some those big browsers started as forks from rather small
and non-financial-powerful projects.

I see I missed to follow up on a previous discussion thread -- KHTML is
on more or less the same level with WebKit (which started as a fork of
the former, getting on board some extra libs), the browsers relies on
them as html/js engines. Now opera is using chorme html engine and
benefits of all webrtc features chrome has -- in reality they are still
different browsers with the specific features mainly related to
interaction to the users rather than the protocol or other specific
technical aspects (html/http).

> 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.

Otherwise we get stuck to some browsers that can vanish your
expectations on security.

And if there is a different set of requirements for a WebRTC device and
a WebRT UA, you still have to keep a matrix: it is working with Chrome,
but not working with X-Lite Communicator. I don't see an easy way to
explain to an end user that webrtc endpoints don't have same
capabilities on media.

There are benefits on having a MTI for video codec, but one that doesn't
impose any kind of restrictions, otherwise it brings more disadvantages
now and in long term.

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/#%21/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>
>
>
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com