From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 2C1C3E013CB for ; Wed, 10 Jul 2013 03:41:48 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id e49so4641948eek.6 for ; Wed, 10 Jul 2013 03:41:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type:x-gm-message-state; bh=iw0Y3aEwkZengAuuttdZgNL2Fgl+QC87oqogHZ3d0pU=; b=LkK3I4JUdjwM9ATD024bTO54WnpIzS+1FDsParRrPe29XCZocwSMd/kH6Wfac+QNrd 8ypEulDXRhKfv0nWDwq5rCaRoFCL128hTCvp9dFmvg7JVZfvj0GBykKiSyYFiZ+K6sQ+ be02tjeRM8zX0+5N0LtQqblP93sWqOFg6sYpy8MY92OGG+9zzcMQBPbqhbO0uockLx5G 9yqLUl3n7XzdGO8cGwTSKGP3UVDOZt80TRsUT8yUtBvgTZuoGb5j1FlhHqHT+cLwZ9yw JiGnC2Xc2Ms8mMqpFX1fbFSgtia68FeSfvSiJhkVakDvYXETJyrHFA8rYVeqXsuzVHvi ps1g== X-Received: by 10.14.209.197 with SMTP id s45mr35733298eeo.108.1373452907388; Wed, 10 Jul 2013 03:41:47 -0700 (PDT) Received: from rudolf.localnet (ppp-82-135-84-132.dynamic.mnet-online.de. [82.135.84.132]) by mx.google.com with ESMTPSA id m1sm58820995eex.17.2013.07.10.03.41.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 03:41:46 -0700 (PDT) From: Thomas Senyk To: Philip Craig Date: Wed, 10 Jul 2013 12:41:23 +0200 Message-ID: <26413776.WqebzBdoFC@rudolf> Organization: Pelagicore AG User-Agent: KMail/4.10.4 (Linux/3.9.8-1-ARCH; KDE/4.10.4; x86_64; ; ) In-Reply-To: References: <1797012.Po2ZnTUHJW@rudolf> <5676634.rO8cD2HIon@rudolf> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQlp0CecUBao/hr1KG91FzPdNl4HdZdOqld1VmaIDDhA/9ro+J4ns0v5Il4d92vtx4UsK0gn Cc: "meta-freescale@yoctoproject.org" , Otavio Salvador , Rogerio Nunes Subject: Re: QtMultimedia on i.MX6 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: Wed, 10 Jul 2013 10:41:49 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, 10 July, 2013 20:32:05 Philip Craig wrote: > On Wed, Jul 10, 2013 at 7:52 PM, Thomas Senyk > > wrote: > > On Wednesday, 10 July, 2013 19:13:57 Philip Craig wrote: > > > On Wed, Jul 10, 2013 at 6:26 PM, Thomas Senyk > > > > > > wrote: > > > > On Wednesday, 10 July, 2013 10:25:09 Philip Craig wrote: > > > > > On Wed, Jul 10, 2013 at 9:53 AM, Rogerio Nunes > > > > > > > > wrote: > > > > > > On Tue, Jul 9, 2013 at 4:14 AM, Thomas Senyk < > > > > > > > > thomas.senyk@pelagicore.com> > > > > > > > > > > wrote: > > > > > > > On Friday, 05 July, 2013 13:16:23 Rogerio Nunes wrote: > > > > > > >> Repository is public now. > > > > > > >> I only have the code from BSP 1.1.0 there yet, but I'll add > > > > 4.0.0 > > > > > > this > > > > > > > > > > >> afternoon. > > > > > > >> > > > > > > >> BTW, I still need to update the gst-plugins-gl recipe in the > > > > > > >> meta-fsl-arm layer to point to this repo. It's cleaner than the > > > > > > > > patch > > > > > > > > > > >> we currently have in the recipe. > > > > > > > > > > > > > > Sounds wonderful! > > > > > > > If something is ready to test, let me know. > > > > > > > > > > > > Very small change from previous BSP to 4.0.0 in the gst-plugins-gl > > > > > > > > package: > > https://bitbucket.org/Freescale/gstreamer-gst-plugins-gl/commits/1d6c0abf2 > > > > > > > > 17a90e160fd7e4c45f02a23da974130?at=fsl-0.10 I've just sent a patch > > > > to > > > > > > the > > > > > > > > > > list (awaiting approval as it was big...) to update meta-fsl-arm. > > > > > > > > > > > > In the bitbucket repo, branch fsl-0.10 has commits that reflect > > > > > > "as > > > > > > is" > > > > > > packages from the BSP. > > > > > > My idea now is to work on branch 0.10 to generate a set of patches > > > > > > > > that we > > > > > > > > > > can upstream. > > > > > > I would appreciate any help. > > > > > > > > > > I can't speak for upstream, but do note that gstreamer 0.10 is no > > > > longer > > > > > > > maintained, and gst-plugins-gl has recently been updated to 1.0, so > > > > it > > > > > > > might be worth checking if upstream will accept 0.10 patches before > > > > > > > > working > > > > > > > > > on them. > > > > > > > > ... again ... a rather long mail ;) > > > > > > > > I kind a gave up on 'glupload' (and therefor on gst-plugins-gl) > > > > yesterday > > > > > > evening. > > > > It sounded very good at first, but after a while I realized it can't > > > > work > > > > > > in > > > > it's current implementation/API ... it least not without X (which is a > > > > no > > > > > > go > > > > for my in any case) > > > > > > > > What I wanted to achieve: > > > > Being able to use textures 'filled' by gst-plugins-gl within Qt's > > > > OpenGL > > > > > > SceneGraph. > > > > > > > > Why IMO it will not work: > > > > glupload has to create it's own EGLContext, for that one needs > > > > displays > > > > and > > > > window. > > > > The problem is that the current implementation does that be using the > > > > vivante- > > > > linuxfb-API which results in a separated, independent "connection" to > > > > the > > > > > > display. > > > > This means glupload's "external-opengl-context" is not usable as any > > > > provided > > > > EGLContext will be bound to another display connection (I tried and > > > > failed, if > > > > it's supposed to work but I'm doing something wrong, I'm happy to try > > > > again > > > > with help) > > > > > > > > This means you'll never be able to use the generated textures outside > > > > of > > > > > > gstreamer. ... I think ;) > > > > The only use-case left is to use glimagesink to render to framebuffer > > > > directly, > > > > maybe adding some gstreamer-gl-effects or something. > > > > > > > > This is not what I indented to achieve (although I've already marked > > > > it as > > > > > > my > > > > back-up plan and doing it in QtMultimedia is trivial, if someone wants > > > > to > > > > > > try > > > > that solution let me know and I tell you what to change) > > > > > > > > To achieve what I want I thing the only viable solution would be to > > > > replace > > > > the "external-opengl-context" with a 'makeGLContextCurrent'-callback > > > > ...so > > > > > > that the EGLContext can be created and managed by the UI-framework > > > > rather > > > > > > then > > > > the multimedia-framework... but I'm not eager to fiddle around with > > > > gst-API ;) > > > > > > > > > > > > > > > > If I'm wrong with any part and it's actually possible to use textures > > > > generated by gst-plugins-gst outside of gstreamer (without X/other > > > > 'windowing > > > > manager'), I happy to try again if someone has a hint/idea how the > > > > stack > > > > > > should look like. > > > > > > > > > > > > > > > > In the mean while I have an alternative plan: > > > > The important part the thing is replacing the cpu based texture upload > > > > (copy) > > > > with a vivante-based memory-mapping ('no-copy'/'zero-copy') > > > > Today I'm going try to implement this (using the gst-plugins-gl code > > > > as > > > > reference) within QtMultimedia. > > > > > > I'm very new to opengl, but your analysis sounds correct to me. > > > > > > You might be interested in looking at the qt-gstreamer package. It has a > > > qtglvideosink plugin which uses the context you give it, rather than > > > creating its own display etc. I did try using it, but I was trying to > > > > use a > > > > > QGLWidget to get the context, and it seems to be incompatible with > > > eglfs. > > > It displays fine on my laptop with xcb. Maybe you know an alternative > > > way > > > of getting a context when using eglfs. > > > > But this is not imx6 specific, is it? > > If it's not: we can't get to a optimized stack without using the vivante- > > opengl ui > > If it is: I'll take a look (where to find?) > > I'm not sure why it needs to be imx6 specific. Doesn't the opengl API make > it so that it doesn't need to be specific? The Qt eglfs platform is using > the vivante opengl libraries. As I understand it, the parts that need to be > imx6 specific are confined to the eglfs platform plugin. > > qt-gstreamer is at http://cgit.freedesktop.org/gstreamer/qt-gstreamer No. There is no vendor-independent way to map cpu/vpu based memory into gpu (/opengl) memory. Without 'mapping' one needs to copy/upload via glTexImage2D. This one single line(!) consumes >100% cpu of one iMX6 core for 1080p. If you 'map' the cpu load is very easily <10% Greets Thomas