From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 43849E00A03; Mon, 25 May 2015 02:27:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id AFFEDE0051B for ; Mon, 25 May 2015 02:27:10 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id 82CA560014E4; Mon, 25 May 2015 12:27:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1432546027; bh=0LhmLq6WMnSYB45fcTfWppNo+4MmmhmOBpu/ZY7ivVA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=so6lm9g2bt5R4+7SSYiCOYEKhXLj+c8MyE0S47Szo+QLzYdgtJ2gbYOvYIIMki9qU +aVNl2DkvRgelyPqfJO+MxOpQEoQv3ReGd4HzSmz+0nK3+CdvE4+Nz7YTO3kqBLHeQ rSUFNH7rNWlJ00sYBvdOh4OszrbVZVgIqhkOAfko= Message-ID: <5562EAEB.7080200@mail.bg> Date: Mon, 25 May 2015 12:27:07 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Marco Trillo References: <555B61DF.2000903@mail.bg> <555CC752.6060706@mail.bg> <555D1C21.6020402@mail.bg> <555D3C7D.7020406@mail.bg> <555E892B.1010904@mail.bg> <5562D379.4010503@arantia.com> In-Reply-To: <5562D379.4010503@arantia.com> Cc: "meta-freescale@yoctoproject.org" Subject: Re: Video overlay on sabresd 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: Mon, 25 May 2015 09:27:16 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Marco, On 05/25/2015 10:47 AM, Marco Trillo wrote: > Hi, > > On 05/22/2015 03:40 AM, Nikolay Dimitrov wrote: >>>>> Thanks for sharing. This works, but I'm trying to achieve exactly the >>>>> opposite. >>>>> >>>>> I need to have my UI on the FG layer (which imho means X rendering to >>>>> /dev/fb1), and my video player must render on BG layer (/dev/video16, >>>>> which imho corresponds to /dev/fb0). > Actually you should be able to achieve what you want by using either one > of the MXCFB_SET_GBL_ALPHA, MXCFB_SET_LOC_ALPHA or MXCFB_SET_OVERLAY_POS > ioctls on /dev/fb0, so that this layer renders atop the /dev/video17 at > /dev/fb1 (with a global alpha with the first one, or a pixel-based alpha > with the second one which needs 32bpp). Exactly. Regarding the MXCFB_SET_OVERLAY_POS - I was thinking this ioctl is related to X/Y position of the layer and not about the layers' Z-order (at least this is the impression I have looking at the mxcfb driver and imx lib code). Please correct me if I'm wrong, but I thing the Z-order of the BG/FG IPU layers is not programmable. >> - Chroma keying is buggy: opening the V4L2 device file (/dev/video16) >> on the BG layer resets the chroma key. Here are steps to reproduce: >> >> 1. Start Xorg on /dev/fb1. >> 2. Start a X11 app, which draws a solid-colored rectangle containing >> the chroma key (0xFF00FF in my case). >> 3. Run a console app, which programs the chroma key to 0xFF00FF and >> global alpha to 0x80. >> 4. Observe that the chroma-key colored rectangle is now >> fully transparent, as expected. >> 5. Start gstreamer with imxv4l2sink, using /dev/video16 >> 6. Observe that chroma-key colored rectangle is opaque. This is an >> issue. >> >> If #3 is executed while the video is playing, the colored rectangle >> becomes fully transparent, as expected. > > I think this is more an issue with the `imxv4l2sink' plug-in, which > resets the global alpha of the layer, than the /dev/video* node itself. > Unfortunately, the `imxv4l2sink' plug-in seems to be written so that it > manages the layers itself, containing incomplete code for setting the > global alpha, the local alpha, and the color key, but not fully exposing > these options via gstreamer properties. You may want to try the sink > based on the IPU lib directly (`mfw_isink' IIRC) and see how it behaves. Yes, I was also thinking along the same lines that the issue could be caused by several things (xorg, video sink). I'll look around and probably I can fix this in the gst plugin. Btw, I'm using the V4L2 sink because in the past I had performance issues when the screen was rotated at 180 degrees, and the V4L2 performed much better in both 0 and 180 degrees. But I'll definitely try it out. Regards, Nikolay