From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id F0C70E016CA for ; Tue, 15 Oct 2013 12:16:17 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kl14so9446211pab.25 for ; Tue, 15 Oct 2013 12:16:17 -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 :content-transfer-encoding; bh=2qTcDIDChbmWSXsaTLVQFgKmQ2j+lcpNRpHxPJ8yb3M=; b=mYYsQ6U/1nsqYya8N2b03LSHGprFmWWFVqJWLOyo43Em4Y8poN0pFsJo6+0lYXMePD fH66VuYhOaSrscf6YESRiJEZCOnfE+izRP30uqUFGFEFo506oTLH5uxG9Lm1l1tG9ogl dbm3TiNJZx8x9sQFamzGTM6GbYaL6Y5b4kVbgPrYb4qbI2KH6T2lLLrgy6gSnzi53Sxd RDz31fv2o4ao1VhEseMXuKoKKViMEuNJ3YNZjls3sdRyfXpAZriSLF64Ek6GHBSqfELF IeBpoxjURecqmQBMgM64HmPU+cbzOnvrCft7yqHTarmp+SsFQIL4jew7UFPEPHdyEPzv d7uQ== X-Gm-Message-State: ALoCoQlPRR6TwWmcUbRtDM51Po15s+otmN9LU1HKQsd9PLPpxExcSRWZuVpBzz6IXRpoGoRHLT/G X-Received: by 10.68.163.33 with SMTP id yf1mr9884182pbb.143.1381864577173; Tue, 15 Oct 2013 12:16:17 -0700 (PDT) Received: from [192.168.0.53] ([70.96.116.236]) by mx.google.com with ESMTPSA id qf7sm100942308pac.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 12:16:16 -0700 (PDT) Message-ID: <525D947D.4060703@boundarydevices.com> Date: Tue, 15 Oct 2013 12:16:13 -0700 From: Eric Nelson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Carlos Rafael Giani , Otavio Salvador References: <3C992F0204517E4C884B3303F27BC47CF0E0D9D6@EX2K10MB1.vb.loc> <525D7555.1010003@freescale.com> <3C992F0204517E4C884B3303F27BC47CF0E0DCE4@EX2K10MB1.vb.loc> <525D7EFD.9040708@freescale.com> <525D8747.1050207@boundarydevices.com> <525D8782.6010509@freescale.com> <525D8E49.9090703@pseudoterminal.org> In-Reply-To: <525D8E49.9090703@pseudoterminal.org> Cc: "meta-freescale@yoctoproject.org" , Ashwin Kirpalani Subject: Re: gstreamer 1.x freescale plugings 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, 15 Oct 2013 19:16:18 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for the update Carlos, On 10/15/2013 11:49 AM, Carlos Rafael Giani wrote: > Hi, > > I have been working on these plugins in my spare time. Currently, there > are two IPU plugins (a videotransform element and a sink), a GLES based > sink using Vivante's direct textures (for smooth HD playback), a VPU > decoder plugin, and several VPU encoder plugins. These work, but there > are several things left to do. The encoders are relatively unfinished > (they can encode, but need coniderably more testing), and h264 > reordering and input<->output frame association is not established yet, > potentially messing up the timestamps. > Nice work getting this far! > That said, I can reliably playback 1080p video with this. This is _not_ > a port of the existing 0.10 plugins, but written from scratch. The 0.10 > plugins have several conceptual flaws, and most importantly, are not > built on top of the GStreamer video en/decoder base classes. A rewrite > was just easier. > It's funny how that works. > One detail that was very important to me was to avoid buffer copies as > much as possible. With GStreamer 1.0 , defining custom allocators and > attaching metadata to buffers is much easier to do. So for example a > pipeline which decodes MPEG2, rotates the frame with the IPU, and > encodes this to h264 automatically ensures the data is not unnecessarily > copied around by the CPU. It directly wanders from VPU to IPU and VPU > again through DMA. > > I am running into problems with the existing VPU wrapper library there > (I am not directly using imx-lib). I need some way to pass user data > through the VPU en- and decoder. That is, when I for example specify > input data for the decoder, I need a way to also give it a user-defined > void pointer, that is then passed through and placed into the output > frame that corresponds to the input frame I just specified. If the > authors of the VPU wrapper could be contacted, it would be ideal. I > hesitate to fork it and make my fork a dependency. > > Also, a documentation for the VPU wrapper would be very welcome :) > Have you seen the file "i.MX_6Dual6Quad_VPU_API_Reference_Manual.pdf" within the 'docs' package here (item #1): https://community.freescale.com/docs/DOC-94809