Re: [rtcweb] H.261

Stefan Slivinski <sslivinski@lifesize.com> Fri, 22 November 2013 21:20 UTC

Return-Path: <sslivinski@lifesize.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7F1AE265 for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 13:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZjOSxl5zq9i for <rtcweb@ietfa.amsl.com>; Fri, 22 Nov 2013 13:20:37 -0800 (PST)
Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 3046F1AE0E5 for <rtcweb@ietf.org>; Fri, 22 Nov 2013 13:20:37 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUo/KnZu0qrlG9c8okfhpxiAsstYOZKbx@postini.com; Fri, 22 Nov 2013 13:20:30 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 15:14:07 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: Basil Mohamed Gohar <basilgohar@librevideo.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Fri, 22 Nov 2013 15:14:05 -0600
Thread-Topic: [rtcweb] H.261
Thread-Index: Ac7nxWRRSQF7DzXhQqSnP8XnwIp+JQAAdJrg
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA9E6731@ausmsex00.austin.kmvtechnologies.com>
References: <CEB4350B.1E7B2%mzanaty@cisco.com> <20131122171020.GY3245@audi.shelbyville.oz> <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FB79F.8090405@gmail.com> <7949EED078736C4881C92F656DC6F6C130EA9E670F@ausmsex00.austin.kmvtechnologies.com> <528FBC43.5000409@librevideo.org> <7949EED078736C4881C92F656DC6F6C130EA9E671A@ausmsex00.austin.kmvtechnologies.com> <528FC513.4020903@librevideo.org>
In-Reply-To: <528FC513.4020903@librevideo.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] H.261
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2013 21:20:41 -0000

Why don't we add the "must support both H.264 and VP8 decode and must support at least one of H.264 or VP8 encode" to the list of options and ask for a show of hands as to what people are in favor of.  This would be non-binding, simply a status check.  Maybe no one is in favor of H.261 except for a vocal minority in which case we're wasting time arguing about it.

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Basil Mohamed Gohar
Sent: Friday, November 22, 2013 12:57 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] H.261

On 11/22/2013 03:44 PM, Stefan Slivinski wrote:
> Thank you for the link.
> 
> The point I'm trying to make is H.261 will harm the proliferation of webrtc far more than it will help.  This is purely a technical argument speaking to quality and error resiliency.
> 
> Has anyone listed the concerns surrounding H.264 and have these been raised with mpeg-la to see if they can make adjustments to the license agreement.  They have certainly done so in the past.

Believe it or not, the MPEG-LA is currently trying to establish a royalty-free subset of H.264 called "Constrained Baseline Profile", which is very similar to the most commonly-used subset of H.264 features out there.

The problem is, it's not done yet, and there's no indication whether or not it will be successful or not.  This would require all existing stakeholders in H.264 licensing to agree to this royalty-free variant for it to matter.

There's another effort to do the same with one using MPEG-1 as a base.

The problem is, none of these formally exist in royalty-free forms as of yet.  Everything else we've discussed, though, does, including H.261.

And, for what it's worth, I disagree about H.261.  Yes, H.264 and/or VP8 (and a whole list of other codecs) will look *better*, but I think being able to communicate via video over H.261 is better than not being able to all.

And we are at a point where "not at all" is going to happen because the WG is effectively split over using VP8 and H.264.

--
Libre Video
http://librevideo.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb