From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 7FD63E007BA; Tue, 6 Jan 2015 14:15:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [135.245.210.22 listed in list.dnswl.org] Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 35339E002F9 for ; Tue, 6 Jan 2015 14:14:55 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 62F291A220ABD; Tue, 6 Jan 2015 22:14:50 +0000 (GMT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t06MEpIN031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Jan 2015 17:14:52 -0500 Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id t06MEpsI024550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Jan 2015 16:14:51 -0600 Received: from [135.222.138.133] (Ed-PC.mh.lucent.com [135.222.138.133]) by umail.lucent.com (8.13.8/TPES) with ESMTP id t06MEoLq025024; Tue, 6 Jan 2015 16:14:50 -0600 (CST) Message-ID: <54AC5D4A.2080501@alcatel-lucent.com> Date: Tue, 06 Jan 2015 17:10:18 -0500 From: Ed Sutter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Dmitriy B." , "meta-freescale@yoctoproject.org" References: <54AC1D12.5040603@alcatel-lucent.com> <54AC324F.1010301@alcatel-lucent.com> In-Reply-To: Subject: Re: webrtc question X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 22:15:00 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Dmitry, Questions embedded, Thanks Ed > > From your description it seems that the webRTC will be the > 'communication channel' and the processing of the packages > will be a > second step (audio / video / whatever). For VP8 it does work, > as it is > supported in Chromium. > > > Unfortunately, it is not that simple. webrtc & libjingle is a long > going project from Google that is done as a big C++ framework that has > everything you need: encoding, decoding libs, communication libs and > debug stuff. Chrome is just hooked up to use that framework when > webrtc actions appear in users javascript. webrtc does not depend on > HTML5 video playback for example, where we have with patches imx-vpu > in action. At least that is how it did work around a year ago. Similarly, HTML5 doesn't use VP8 unless webrtc is involved right? I'm hoping I don't need to get near any HTML at all, and can use libjingle along with the audio and video engines to do this. > > Yea, the first step is to make my iMX6 based device be compatible > with the > communication channels (and data formats, i.e. VP8/opus/etc..) > used/supported > by webrtc. The difference will be that (in certain modes) there > is no user on > the device; it will be headless and autonomous, so I need to be > able to feed > media to and extract media from the underlying webrtc base > platform on the iMX6. > Does Chromium provide any non-browser type of hooks into webrtc > down below? > > > No, chromium links with webrtc which links with libvpx for > encoding/decoding. Libvpx then decides what to use. > > I investigated this some time ago while working on a similar device > (webrtc app linked with Qt5 front end on ARM linux-native device > communicating other similar devices, it was a robotics project). You > need to integrate imx vpu encoding/decoding support to webrtc/libvpx > internals or use Android where it should be passed through from > standard video acceleration frameworks. So does that imply that there is no hardware (imx-vpu) acceleration support for VP8? If this is true, is there any data on how the impacts CPU usage when VP8 is used? BTW... did you ever complete that project? If not, was it due to iMX6/webrtc issues?