Re: [rtcweb] Platforms that support H264

Gili <cowwoc@bbs.darktech.org> Sat, 02 November 2013 22:15 UTC

Return-Path: <cowwoc@bbs.darktech.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 C6B9211E824F for <rtcweb@ietfa.amsl.com>; Sat, 2 Nov 2013 15:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 RTY34y3zQOht for <rtcweb@ietfa.amsl.com>; Sat, 2 Nov 2013 15:15:53 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id E043311E824E for <rtcweb@ietf.org>; Sat, 2 Nov 2013 15:15:52 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id tp5so9702297ieb.2 for <rtcweb@ietf.org>; Sat, 02 Nov 2013 15:15:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=FyQCJZE4jrbiEBj47PhoKzsuuUykUbxkeLpG1vC7f1o=; b=NiDWz87BWNKB3gGf9b8XYUaohqOgcwcTBcaEsvPOchrlnHTl0MrJktYlDw48Rii5lq JIDr3ittmviCAsKfeX25/abnyBnrDw5UUY9bwSZk1HR8BPoUfRanf/BddMFOnzbiz7Tk THU5s++zX+5Wbh/iJvI6IE0OafvrOzjOu+BKBKnSNYHWmqYgDYhnibC32MDwvhCwjyEE ngLSyBPK33PcFtRJ/Q98mWBG0/Ey7s4z0F5Q0T9gPFNq6EFbdVcEaUGBap0zAPYaqxl1 oFelIoSeEFzuZ8cpOMoubX0m0MduyWKVK9D72kWmgAvDSmlYHtgStviVh4/8TNZscCfP QgAg==
X-Gm-Message-State: ALoCoQkXcd+35fGGblhH9Pw1cc9YLLhZFnHelQlllG1JIU4rim9/Z1okmLo1Er3pOIO/9PDt+X7E
X-Received: by 10.42.67.74 with SMTP id s10mr5892950ici.1.1383430552048; Sat, 02 Nov 2013 15:15:52 -0700 (PDT)
Received: from [192.168.123.174] ([70.28.107.51]) by mx.google.com with ESMTPSA id ka1sm12429176igb.7.2013.11.02.15.15.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 15:15:51 -0700 (PDT)
Message-ID: <52757985.3080306@bbs.darktech.org>
Date: Sat, 02 Nov 2013 18:15:33 -0400
From: Gili <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Bossiel <bossiel@yahoo.fr>
References: <CAOqqYVEER_HprgauRawO+_gGdLdMY1MUY8jrMhhi3yVDL31bFg@mail.gmail.com> <52740478.6030109@nostrum.com> <CAOJ7v-2+_4QZwc8vEtdwVDWSP-d-z+ggB0u+VM6WnA=f-k4-XA@mail.gmail.com> <BLU404-EAS261C783EDA4575EE1A7E53593F40@phx.gbl> <52750E3C.9060206@bbs.darktech.org> <CABkgnnVR9=oWVzRaRuD701tvZCtp+SO1n6c65hJELLVfB8QcOA@mail.gmail.com> <C21C6AC2-29F8-4DFF-BB48-5E3D625DCD65@phonefromhere.com> <CAPvvaaK-bKt-zDEq2qibRrm51VbRGAV=95JShKFdCpJszw5Tww@mail.gmail.com> <1383413266.41025.YahooMailNeo@web171304.mail.ir2.yahoo.com> <5275395B.5060709@bbs.darktech.org> <FD8DFEEC-300B-46EE-B922-F7394BFBA826@yahoo.fr> <52755B30.8070506@bbs.darktech.org> <A53E44E5-798C-4B30-89FA-DB540B4BC815@yahoo.fr>
In-Reply-To: <A53E44E5-798C-4B30-89FA-DB540B4BC815@yahoo.fr>
Content-Type: multipart/alternative; boundary="------------030101070008020307070203"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.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: Sat, 02 Nov 2013 22:15:58 -0000
X-List-Received-Date: Sat, 02 Nov 2013 22:15:58 -0000

     According to 
http://www.tekrevue.com/2013/08/19/nvidia-takes-62-of-discrete-gpu-market-share-in-q2-2013/ 
NVidia owns 62% of the market, while according to 
http://www.cpubenchmark.net/market_share.html Intel owns 75.6% of the 
market.

     Whether the union of these two translates to 99% market share 
remains to be seen, but one thing is sure:  it sounds like a deployment 
nightmare. I'd have build an abstraction layer on top of CUDA + Intel 
Quick Sync and update device drivers on each user machine. This is 
hardly trivial stuff. Don't get me wrong, VP8 is even worse when it 
comes to hardware-acceleration. For this reason, I'd probably forgo 
hardware acceleration on Windows 7 and use software codecs for the sake 
of simplicity. Desktop PCs are fast enough anyway.

     When it comes to software-based codecs, VP8 is in a much better 
position than H.264. It has a better royalty, licensing and deployment 
story. I think both VP8 and H.264 need a better story when it comes to a 
portable hardware accelerated APi.

     So when it comes to hardware-accelerated real-time H.264 
encoding/decoding support, here is what we've got:

Windows 7: Yes, if you jump through many hoops
Windows 8: Yes
OSX: No
iOS: No
Android: No

     By last check, Windows 8 had approximately 10% market share.

     When it comes to software-based H.264 codecs, I'm not aware of a 
single portable implementation with a commercially-friendly license. On 
the flip side, the software-based VP8 codec is available on all these 
platforms (today, not in some distant future) with very reasonable 
performance and ease of deployment.

     My point is, when considering using H.264 vs VP8 for MTI it's not 
clear that H.264 has any real advantage over VP8. H.264 has 
industry-wide support when it comes to playing pre-recorded YouTube 
videos, but that's hardly relevant to our discussion. WebRTC requires 
real-time encoding/decoding support and in that context, the two codecs 
are on equal footing.

Gili

On 11/2/2013 4:27 PM, Bossiel wrote:
> CUDA works on windows XP and later. The developer needs the SDK and 
> the end-user up-to-date drivers.
>
> For Intel QuickSync there is an SDK but not needed if you're using 
> Microsoft Media Foundation (Windows Platform SDK).
>
> With CUDA, Intel Quick Sync, Win8-builtin- encoder, Webcams with UVC 
> 1.5... you can have native H264 in 99% cases. We have a x264 fallback 
> plugin in our open source products but rarely used.
>
> Also note that Windows *Phone* 8 natively support H264 
> encoding/decoding. For reference implementation (open source SIP video 
> client) you can follow the links I sent.
>
> Sent from my iPhone
>
> On Nov 2, 2013, at 21:06, Gili <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>
>> Hi Bossiel,
>>
>>     Thanks for the clarification. Are there existing libraries on top 
>> of CUDA and Intel Quick Sync that provide real-time H.264 
>> encoding/decoding (with a reasonable license), or is this something 
>> we'd need to build ourselves?
>>
>>     Also, please note that not all video cards support CUDA (only 
>> NVidia by last count), or run Intel CPUs (in spite of the fact that 
>> many do), so we still have a portability problem.
>>
>> Thanks,
>> Gili
>>
>> On 11/2/2013 2:00 PM, Bossiel wrote:
>>> On windows 7 you have CUDA and Intel Quick Sync
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 2, 2013, at 18:41, Gili <cowwoc@bbs.darktech.org 
>>> <mailto:cowwoc@bbs.darktech.org>> wrote:
>>>
>>>>
>>>>     So... the only platform that supports H.264 natively (real-time 
>>>> encoding/decoding) is Windows 8? Any others?
>>>>
>>>> Gili
>>>>
>>>> On 11/2/2013 1:27 PM, Bossiel thioriguel wrote:
>>>>> @Emil
>>>>> Both Windows 8 and 7 natively contain H.264 *encoder* (Thanks for 
>>>>> Media foundation). The only issue with Windows 7 is the the 
>>>>> encoder doesn't support realtime encoding (up to 3s delay).
>>>>> You can also rely on the GPU (Cuda for Nvidia and Intel Quick Sync 
>>>>> for Intel). Nothing to install for the end-user.
>>>>> If you want reference code:
>>>>> Media Foundation (Windows OS and Intel Quick Sync): 
>>>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginWinMF
>>>>> Nvidia Cuda: 
>>>>> https://code.google.com/p/doubango/source/browse/#svn%2Fbranches%2F2.0%2Fdoubango%2Fplugins%2FpluginCUDA
>>>>>
>>>>>
>>>>>
>>>>> Le Samedi 2 novembre 2013 18h14, Emil Ivov <emcho@jitsi.org> a écrit :
>>>>> Same questions for OS X and Windows actually. Last time we checked 
>>>>> (which was also some time ago) there was no way to get the OS to 
>>>>> *encode* H.264 for you.
>>>>> --sent from my mobile
>>>>> On 2 Nov 2013 17:57, "tim panton" <tim@phonefromhere.com 
>>>>> <mailto:tim@phonefromhere.com>> wrote:
>>>>>
>>>>>
>>>>>     On 2 Nov 2013, at 15:02, Martin Thomson
>>>>>     <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
>>>>>     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.
>>>>>
>>>>>     Martin, can I ask you to talk with your Skype engineering team
>>>>>     and check up on
>>>>>     the exact way that works on iOS. Last time I looked, it seemed
>>>>>     you couldn’t use the
>>>>>     Apple supplied (hardware accelerated) h264 library for
>>>>>     realtime encode/decode and
>>>>>     it wasn’t at all clear to me that the hardware encoder licence
>>>>>     covered any soft implementation of h264 we
>>>>>     added.
>>>>>
>>>>>     I’d like to caveat that:
>>>>>      1) it was a while ago. 2) I’m not a lawyer. 3) it was a
>>>>>     thought experiment.
>>>>>     So it would be interesting to get a current view from the
>>>>>     trenches.
>>>>>
>>>>>     T.
>>>>>
>>>>>     _______________________________________________
>>>>>     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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> 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
>>