Subject: [rtcweb] Interoperability between browsers (MTI Video)

From: Leon Geyser <[email-masked]>
Date: Sat, 16 Mar 2013 21:14:18 +0200

In my opinion there really is a need for a MTI video codec for
interoperability between browsers.

Here are some scenarios on MTI decisions:

-- Decide on no MTI codec:
This would split the browers in two sides.
Those who support VP8 and those who support H.264. The only way these would
be able to communicate with each other is by using a a transcoding server
between the two browsers. (I don't know what the cost impact would be.)
Or
No video stream is sent when two incompatible browsers communicate. Just
audio. Not ideal.

-- Decide on H.264:
This really is not an option unless it can be royalty free with no strings
attached. Only a few browser vendors would be able to implement H.264. This
will also result in: No video stream is sent when to incompatible browsers
communicate. Just audio. Not ideal.

--Decide on VP8:
This would be the ideal choice and there shouldn't be a reason not to
implement VP8.

--Decide on H.261:
This might be old tech, but browsers might be able to use H.261 without
paying any royalties and without transcoding.
The codec can be used at 352x288 resolution from 64Kbit/s to 2Mbit/s
Remember this is just a fallback for interoperability. Browsers will still
implement VP8 and/or H.264.

Here are some examples of what might happen:
Firefox/Chrome/Opera to Firefox/Chrome/Opera: VP8
Safari/IE to Safari/IE : H.264
Firefox/Chrome/Opera to Safari/IE : H.261 fallback

Atleast there is video instead of no Video. Any opinions?

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 16 Mar 2013 20:08:40 +0000

On Mar 16, 2013, at 3:14 PM, Leon Geyser <[email-masked]> wrote:

> --Decide on VP8:
> This would be the ideal choice and there shouldn't be a reason not to implement VP8.

I believe the jury's still out on that.  From what I understand, some of the vendors are concerned that VP8 may still be encumbered by patents outside of MPEG-LA, and besides the details of the RF usage for VP8 from MPEG-LA have still not been disclosed. (e.g., the strings attached to the usage might be unacceptable to some vendors)

> --Decide on H.261:
> This might be old tech, but browsers might be able to use H.261 without paying any royalties and without transcoding.
> Remember this is just a fallback for interoperability. Browsers will still implement VP8 and/or H.264.
> ...

I agree this would be better than nothing, as mentioned on the thread titled "Video Codec MTI & User Experience == 1".
I also asked a few vendors after this week's meetings whether their existing devices support H.261, but they didn't know.  If most existing video devices do, then having H.261 as the MTI would also facilitate interop with legacy equipment.  I.e., it would follow the same rationale for why we chose G.711 as one of the MTI audio codecs.

-hadriel

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 16 Mar 2013 16:40:55 -0400

On 3/16/13 4:08 PM, Hadriel Kaplan wrote:
>> --Decide on H.261: This might be old tech, but browsers might be
>> able to use H.261 without paying any royalties and without
>> transcoding. The codec can be used at 352x288 resolution from
>> 64Kbit/s to 2Mbit/s Remember this is just a fallback for
>> interoperability. Browsers will still implement VP8 and/or H.264.
>> ... Atleast there is video instead of no Video. Any opinions?
>
> I agree this would be better than nothing, as mentioned on the thread
> titled "Video Codec MTI & User Experience == 1". I also asked a few
> vendors after this week's meetings whether their existing devices
> support H.261, but they didn't know.  If most existing video devices
> do, then having H.261 as the MTI would also facilitate interop with
> legacy equipment.  I.e., it would follow the same rationale for why
> we chose G.711 as one of the MTI audio codecs.

Not only that. It would also foster competition and innovation. Crappy 
quality when negotiation falls back on H.261 will be a big incentive for 
the communicating parties to switch to a common browser. In the end the 
fluctuations in browser market share will take care themselves to set 
the de-facto standard.

At this point crappy quality may be a feature rather than a bug..

Enrico

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Mar 2013 16:58:07 -0400

On Mar 16, 2013, at 16:08, "Hadriel Kaplan" <[email-masked]> wrote:

> I also asked a few vendors after this week's meetings whether their existing devices support H.261, but they didn't know. 

[BA] H.261 is so old and moldy that most vendors ripped it out long ago.  I went through a dozen different video clients and couldn't find any that supported it (though H.263 was included in some cases).

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Mar 2013 17:17:08 -0400

On Mar 16, 2013, at 15:18, "Leon Geyser" <[email-masked]> wrote:

> In my opinion there really is a need for a MTI video codec for interoperability between browsers.
> 

[BA] No. It just removes the stick that each side can use to beat the other side.  The need for interoperability still remains, and most likely will either be addressed by the marketplace choosing one over the other decisively, or if deployment is split, by support for (limited) codec extensibility.

---

From: Leon Geyser <[email-masked]>
Date: Sun, 17 Mar 2013 00:02:24 +0200

>
> [BA] No. It just removes the stick that each side can use to beat the
> other side.  The need for interoperability still remains, and most likely
> will either be addressed by the marketplace choosing one over the other
> decisively
>

I don't see how that would address it unless the browser vendors really
care about interoperability. My browser implements the WebRTC without a MTI
video codec spec and implements H.264; why whould I care about the others?
I mean the <video> tag has been out there for ages and the marketplace did
not dictate that H.264 or VP8 should be implemented. It still is split and
probably will stay like that.

or if deployment is split, by support for (limited) codec extensibility

Sorry, I don't really understand. How would this '(limited) codec
extensibility' work?

On 16 March 2013 23:17, Bernard Aboba <[email-masked]> wrote:

> [BA] No. It just removes the stick that each side can use to beat the
> other side.  The need for interoperability still remains, and most likely
> will either be addressed by the marketplace choosing one over the other
> decisively, or if deployment is split, by support for (limited) codec
> extensibility.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 17 Mar 2013 10:03:03 +1100

> probably will stay like that.

It's a terrible situation for video publishers having to provide two
versions of video files, or support two players (one in HTML5 and one in
Flash). It's not a model that we should follow. In fact, there is a
discussion about making VP8 the baseline codec for <video>, too. However,
everyone is waiting for more details on the MPEG-LA deal and on an update
of the VP8/VP9 license in which Google would hand on their license. It will
be a better situation for discussions then. I have a hunch on what this all
will mean, but there's no need speculating when we can just wait a few
weeks.

Regards,
Silvia.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 17 Mar 2013 08:17:35 +0100

> [BA] No. It just removes the stick that each side can use to beat the other side.  The need for interoperability still remains, and most likely will either be addressed by the marketplace choosing…
An interesting angle on codec extensibility is what license agreement 
one needs in order to deploy a codec extension; it would seem natural to 
assume that one would need an MPEG-LA license in order to deploy a H.264 
codec extension.

An API for access to raw incoming/outgoing data, and for registering a 
codec in the negotiation machinery, would need to be defined, but 
doesn't seem extremely complicated to do (although the details will take 
some care). But the license issue might mean that the first plug-in 
codecs developed would be the ASCII codec, the H.261 codec and VP8.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 17 Mar 2013 12:46:09 +0000

On Mar 17, 2013, at 3:17 AM, Harald Alvestrand <[email-masked]> wrote:

> An interesting angle on codec extensibility is what license agreement one needs in order to deploy a codec extension; it would seem natural to assume that one would need an MPEG-LA license in order to deploy a H.264 codec extension.

Sure, or an extension that uses an API embedded in the local hardware - i.e., if you're on a vendor-X phone and vendor-X provides the extension to work in your browser(s).
Or perhaps the patent holders of H.264 will convince the holdouts to accept an RF license for a browser extension, restricted to use only in browsers.

> An API for access to raw incoming/outgoing data, and for registering a codec in the negotiation machinery, would need to be defined, but doesn't seem extremely complicated to do (although the details will take some care). But the license issue might mean that the first plug-in codecs developed would be the ASCII codec, the H.261 codec and VP8.

But that's a good thing, no?  VP8 everywhere!
Besides, it might even foster innovation in new codecs - like 3D video, or *color* ASCII/ANSI-code video. :)

-hadriel

---

From: Leon Geyser <[email-masked]>
Date: Sun, 17 Mar 2013 16:07:30 +0200

>
> Sure, or an extension that uses an API embedded in the local hardware -
> i.e., if you're on a vendor-X phone and vendor-X provides the extension to
> work in your browser(s).
> Or perhaps the patent holders of H.264 will convince the holdouts to
> accept an RF license for a browser extension, restricted to use only in
> browsers.
>

This might work if such an API is consisitently the same on all phones and
even accessible. What if the hardware does not have the API or no H.264
hardware capability? or vendor-X does not want to supply such an extension
for vendor-X phone?
No interop. Back to square one.

IMO for interop to work there needs to be a common video codec available on
all WebRTC implementations that isn't a codec extension. It must be stock
standard.

> codec in the negotiation machinery, would need to be defined, but doesn't
> seem extremely complicated to do (although the details will take some
> care). But the license issue might mean that the first plug-in codecs
> developed would be the ASCII codec, the H.261 codec and VP8.
>

It isn't as easy as creating one plugin that would work on all browsers.
Browsers/CPU Architectures/Operating Systems are all different. Some
browsers might not even allow/have plug-in capabilities.
Also that would mean somebody would have to go and create one for that
browser and it might not be a user friendly experience (It might take an
advanced user to install the plug-in). If there isn't any developer willing
to create that plug-in then there won't be interop. Back to the square one.
Rather let the developers who create the browsers implement MTI codecs. It
would be nice to work out-of-the-box.

If VP8 can be MTI then there is no need for H.261. Let us see what will
happen in the next few weeks.

On 17 March 2013 14:46, Hadriel Kaplan <[email-masked]> wrote:

> Sure, or an extension that uses an API embedded in the local hardware -
> i.e., if you're on a vendor-X phone and vendor-X provides the extension to
> work in your browser(s).
> Or perhaps the patent holders of H.264 will convince the holdouts to
> accept an RF license for a browser extension, restricted to use only in
> browsers.
>
>
> codec in the negotiation machinery, would need to be defined, but doesn't
> seem extremely complicated to do (although the details will take some
> care). But the license issue might mean that the first plug-in codecs
> developed would be the ASCII codec, the H.261 codec and VP8.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>