Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <sslivinski@lifesize.com> Thu, 21 November 2013 21:06 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 B94791AE325 for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 13:06:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.7
X-Spam-Level:
X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 dPT_G5CB2PeZ for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 13:06:41 -0800 (PST)
Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id 8246D1AE092 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 13:06:41 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKUo512cmCapHruxMelNNnJEzkzlSJnj7a@postini.com; Thu, 21 Nov 2013 13:06:35 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; Thu, 21 Nov 2013 14:52:21 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: "'juberti@google.com'" <juberti@google.com>
Date: Thu, 21 Nov 2013 14:52:20 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m+Wkuj2mIHLT6RqGggeJ08Fj8vwAAikvT
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7E1@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <CAOJ7v-151K2UoeMOhY-UUDzZwE=89qzbAQdrhQXYb72W+ZxQOw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7949EED078736C4881C92F656DC6F6C130EA8AD7E1ausmsex00aust_"
MIME-Version: 1.0
Cc: "'rtcweb@ietf.org'" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Video Selection Process
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: Thu, 21 Nov 2013 21:06:44 -0000

I think this has deviated from my original question but...that's not to suggest apple wouldn't expose a webrtc api in the future given adequate support for codecs they do support in hardware

Back to my original point, are we voting on both encoders and decoders or just the decoder for the mandatory supported codecs.


From: Justin Uberti [mailto:juberti@google.com]
Sent: Thursday, November 21, 2013 02:36 PM
To: Stefan Slivinski
Cc: rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Video Selection Process

iOS doesn't expose APIs for said hardware decoding, so you're doing software no matter what, and VP8 and H.264 are therefore on level ground.

That said, I think the general understanding here is that this is no longer a technical decision.


On Thu, Nov 21, 2013 at 12:28 PM, Stefan Slivinski <sslivinski@lifesize.com<mailto:sslivinski@lifesize.com>> wrote:
So this is my concern.  On iOS for example it's pretty easy do decode large resolutions in software only using either h.264 or vp8 (and for that matter vp9 and h.265).  So making both h264 and vp8 decoders mandatory isn't a big technical problem.  The encoder however is a bigger issue.  A reasonably good implementation requires roughly 3x the compute to do this in software.  iOS however supports hardware encoding using H264 so there is an obvious advantage to using that specific codec on that device.  The same might be true for VP8 on other architectures.

So requiring all webrtc implementations to support H264 and VP8 gives the flexibility to pick the most appropriate encoder for a given architecture.


----- Original Message -----
From: Basil Mohamed Gohar [mailto:basilgohar@librevideo.org<mailto:basilgohar@librevideo.org>]
Sent: Thursday, November 21, 2013 02:15 PM
To: rtcweb@ietf.org<mailto:rtcweb@ietf.org> <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/2013 03:02 PM, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video codec.  My question was around whether we are voting on requiring decoders (my assumption) or both encoders and decoders

The discussions, up to this point, have been about choosing an MTI video
format so that rtcweb endpoints can communicate with one-another.  I am
not sure how this goal can be achieved without having an encoder and a
decoder on both ends, sharing at least one common format, whether it is
H.261, Theora, H.264, VP8, or something else.

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