Re: [rtcweb] Platforms that support H264

Randell Jesup <randell-ietf@jesup.org> Tue, 05 November 2013 14:58 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF321E8262 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 06:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efacs3rVmvPa for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 06:58:11 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1B11E8292 for <rtcweb@ietf.org>; Tue, 5 Nov 2013 06:58:09 -0800 (PST)
Received: from [64.114.24.114] (port=65475 helo=[142.131.18.239]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <randell-ietf@jesup.org>) id 1Vdi53-0009G7-6l for rtcweb@ietf.org; Tue, 05 Nov 2013 08:58:09 -0600
Message-ID: <52790780.6020704@jesup.org>
Date: Tue, 05 Nov 2013 06:58:08 -0800
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Thunderbird/25.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CE9E0E33.1B9A4%mzanaty@cisco.com>
In-Reply-To: <CE9E0E33.1B9A4%mzanaty@cisco.com>
Content-Type: multipart/alternative; boundary="------------020406030208020308040501"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Subject: Re: [rtcweb] Platforms that support H264
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 05 Nov 2013 14:58:17 -0000

On 11/5/2013 12:55 AM, Mo Zanaty (mzanaty) wrote:
> I'm serious. Name a device in mass production that is relevant to 
> rtcweb but does not have H.264 hardware.

Plenty have hardware is out there that might not be optimized (or 
usable) for the types of arbitrary-sized, realtime simultaneous h.264 
encode/decode.  Even just handling streaming decode on Android via OMX 
has been a year of pain for one of our engineers, because (especially 
before JB) the interfaces were unsupported, randomly 
modified/incompatible, and with lots of restrictions on what actually is 
supported.  Even with "perfect" API layers exposing them, the hardware 
layers (especially encoders) may not have the low-latency and other 
realtime characteristics needed, or knobs to tell them about things like 
packet loss reports that require IDR generation.  How many does this 
affect? who knows - and the API layers on top are inconsistent enough 
(or non-existent at the present) that it's especially hard to tell.

And many of them can handle only a single stream at a time; which makes 
"hangout"/simulcast cases more fun (need to run HW and SW in parallel, 
or drop to SW only - makes capability signaling fun too; the LCD of the 
SW and HW codecs needs to be what you offer probably, unless you want 
real pain).

>
> Your second point is valid; hardware is useless without supporting 
> software. OS APIs to access codecs (both hardware and software, 
> real-time and buffered) is an important issue. Android is the dominant 
> OS on the planet. If you are not happy with its OS APIs, just change 
> them; it's open source like VP8 right?

Not really.  You can't modify the underlying OS provided by the 
manufacturer (no rooting of phones to run webrtc should be required...)  
and even custom roms are going to get much harder or virtually 
impossible  with kitkat.  And witness my comments about the pain of 
platform decoders on Android today.

    Randell

>
> Mo
>
>
> On 11/5/13, 1:10 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>
>     I'm not sure if you're being sarcastic or not...
>
>     In any case, I had a question regarding BlackBerry 10. Are you 
> implying that every BlackBerry 10 phone includes an API for real-time 
> encoding/decoding of H.264 video streams? If so, which API is it? I 
> took a quick look but couldn't find it.
>
> Thanksm
> Gili
>
> On 04/11/2013 9:52 PM, Mo Zanaty (mzanaty) wrote:
>> I think you meant *every* phone, tablet, laptop, desktop, set-top, 
>> camera...
>>
>>
>> On 11/2/13, 7:41 PM, Kaiduan Xie <kaiduanx@gmail.com 
>> <mailto:kaiduanx@gmail.com>> wrote:
>>
>> Every BlackBerry 10 phone has H.264 hardware encoder/decoder.
>>
>> /Kaiduan
>>
>>
>> On Sat, Nov 2, 2013 at 6:18 PM, Eric Rescorla <ekr@rtfm.com 
>> <mailto:ekr@rtfm.com>> wrote:
>>
>>
>>
>>
>>     On Sat, Nov 2, 2013 at 1:01 PM, Gili <cowwoc@bbs.darktech.org
>>     <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>         Martin,
>>
>>             I fully understand why Firefox would be happy but as
>>         someone who plan to integrate WebRTC into a non-browser
>>         application, especially on iOS, Cisco's solution simply does
>>         not work. I appreciate their contribution, but again, it
>>         simply doesn't help my use-case.
>>
>>
>>     I haven't seen  you explain how your use case is different from
>>     that of
>>     a browser. Could you please do so?
>>
>>     -Ekr
>>
>>         Gili
>>
>>
>>         On 11/2/2013 11:02 AM, Martin Thomson wrote:
>>
>>             On 2 November 2013 07:37, cowwoc <cowwoc@bbs.darktech.org
>>             <mailto:cowwoc@bbs.darktech.org>> wrote:
>>
>>                      I can't think of a single platform that supports
>>                 real-time H.264
>>                 encoding/decoding natively today.
>>
>>             That's a very strange way to put the question.
>>
>>             Let me put another spin on it, and please excuse the
>>             example...
>>
>>             Skype runs on more platforms than you might think.  Those
>>             platforms
>>             can all support H.264 to the extent that Skype requires.
>>
>>             Cisco's generous offer opens almost the same capability
>>             to anyone,
>>             with the caveat that some platforms currently remain
>>             closed.  Of
>>             course, you could let your ideals get in the way of
>>             progress.  Me, I'm
>>             a pragmatist.  This gift represents a great opportunity
>>             for people who
>>             actually care about the practical outcomes.
>>
>>             There's been a lot of mouth-gazing of gift horses on this
>>             list of
>>             late.  I sure hope that this isn't representative of the real
>>             sentiment of the community.  I'd like to think that
>>             people are better
>>             than that.
>>
>>             (BTW, I understand and respect Harald's position.  From
>>             where he sits,
>>             I'm sure that his conclusion makes perfect sense.)
>>
>>


-- 
Randell Jesup
randell-ietf@jesup.org