From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id D0CFBE0084F; Tue, 23 Sep 2014 10:51:39 -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=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, SPF_HELO_PASS autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from ptmx.org (ptmx.org [178.63.28.110]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 83096E00786 for ; Tue, 23 Sep 2014 10:51:30 -0700 (PDT) Received: from [192.168.178.14] (chello062178118086.5.14.vie.surfer.at [62.178.118.86]) by ptmx.org (Postfix) with ESMTPSA id C140D23706; Tue, 23 Sep 2014 19:51:28 +0200 (CEST) Message-ID: <5421B320.40007@pseudoterminal.org> Date: Tue, 23 Sep 2014 19:51:28 +0200 From: Carlos Rafael Giani User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: =?windows-1252?Q?Alfonso_Tam=E9s?= , Prabhu S References: <020a01cfd6e7$40280df0$c07829d0$@tekmagic.net> <3A8E1855-6288-49E4-9D89-7B8C19B38E1E@tekmagic.net> <54217CF4.8090004@pseudoterminal.org> <02c301cfd73b$22224fb0$6666ef10$@tekmagic.net> <542189E0.9080105@pseudoterminal.org> <9623C504-372D-4750-9A84-7A8ADF7679A3@tames.com> In-Reply-To: <9623C504-372D-4750-9A84-7A8ADF7679A3@tames.com> Cc: "meta-freescale@yoctoproject.org" Subject: Re: Any hope of vblank-synchronized rendering (from vivante) on i.MX6 soon? 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, 23 Sep 2014 17:51:39 -0000 Content-Type: multipart/alternative; boundary="------------020003050100020301010700" --------------020003050100020301010700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit This is probably because v4l somehow uses vsync directly. Keep in mind that v4l bypasses X11. Also, you can use qt5 with pure framebuffer output. There, vsync works. On 2014-09-23 19:19, Alfonso Tamés wrote: > > > Yes, the attached test video is tearing in EGL FB without X11/wayland. > > This tears: > > gst-launch-1.0 -v filesrc location=vttest.mp4 typefind=true ! qtdemux > ! h264parse ! imxvpudec ! imxeglvivsink > > This does not tear: > > gst-launch -v filesrc location=vttest.mp4 typefind=true ! aiurdemux ! > queue ! vpudec ! mfw_v4lsink > > I was jut starting a project using qt-gst gl video sink. I guess it > will be a dead end > > :( > > > > > > On Sep 23, 2014, at 11:48 AM, Prabhu S > wrote: > >> i.MX6 X11 EGL is single buffered and there is no support for VSYNC. >> The tearing with X11 is a known issue. We did investigate to fix >> this, but the solution becomes too hacky and cannot be used in >> production systems. >> >> We are adding VSYNC support in Wayland. eglSwapInterval will be >> supported for FBDEV and Wayland backends in the upcoming release(in >> january). So Ozone-wayland can take advantage of this. >> >> On Tue, Sep 23, 2014 at 9:55 AM, Carlos Rafael Giani >> > wrote: >> >> On 09/23/2014 04:50 PM, Daiane Angolini wrote: >> >> On Tue, Sep 23, 2014 at 11:31 AM, Gerard Bucas >> > wrote: >> >> I agree Carlos! >> >> This is a show-stopper for applications in markets like >> the Digital Signage market - which could be huge for the >> i.MX6. The i.MX6 could be the best "media player" out >> there but the problems related to video playback in a >> browser (like Chrome/Chromium) needs to be solved wih the >> highest priority and at the highest level. >> >> There seem to be TWO main issues: >> >> Do you have only 2 issues? Have you double checked if they >> are/are not >> reported in bugzilla? >> >> Do you have the detailed step-by-step? I want to reproduce them. >> >> Daiane >> >> >> Daiane, >> >> try out the attached HTML example. It draws a white vertical bar >> on a black background, and moves that bar horizontally. Run this >> on an imx6 in Chromium in X11, and you will see how severe the >> tearing is. >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> >> https://lists.yoctoproject.org/listinfo/meta-freescale >> >> >> -- >> _______________________________________________ >> meta-freescale mailing list >> meta-freescale@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/meta-freescale > --------------020003050100020301010700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
This is probably because v4l somehow uses vsync directly. Keep in mind that v4l bypasses X11.
Also, you can use qt5 with pure framebuffer output. There, vsync works.

On 2014-09-23 19:19, Alfonso Tamés wrote:


Yes, the attached test video is tearing in EGL FB without X11/wayland.

This tears:

gst-launch-1.0 -v filesrc location=vttest.mp4 typefind=true ! qtdemux ! h264parse ! imxvpudec ! imxeglvivsink

This does not tear:

gst-launch -v filesrc location=vttest.mp4 typefind=true ! aiurdemux ! queue ! vpudec ! mfw_v4lsink

I was jut starting a project using qt-gst gl video sink. I guess it will be a dead end

:(





On Sep 23, 2014, at 11:48 AM, Prabhu S <prabhusundar@gmail.com> wrote:

i.MX6 X11 EGL is single buffered and there is no support for VSYNC. The tearing with X11 is a known issue. We did investigate to fix this, but the solution becomes too hacky and cannot be used in production systems.

We are adding VSYNC support in Wayland. eglSwapInterval will be supported for FBDEV and Wayland backends in the upcoming release(in january). So Ozone-wayland can take advantage of this.

On Tue, Sep 23, 2014 at 9:55 AM, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
On 09/23/2014 04:50 PM, Daiane Angolini wrote:
On Tue, Sep 23, 2014 at 11:31 AM, Gerard Bucas <gerard.b@tekmagic.net> wrote:
I agree Carlos!

This is a show-stopper for applications in markets like the Digital Signage market - which could be huge for the i.MX6. The i.MX6 could be the best "media player" out there but the problems related to video playback in a browser (like Chrome/Chromium) needs to be solved wih the highest priority and at the highest level.

There seem to be TWO main issues:
Do you have only 2 issues? Have you double checked if they are/are not
reported in bugzilla?

Do you have the detailed step-by-step? I want to reproduce them.

Daiane

 Daiane,

try out the attached HTML example. It draws a white vertical bar on a black background, and moves that bar horizontally. Run this on an imx6 in Chromium in X11, and you will see how severe the tearing is.

--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


--
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale


--------------020003050100020301010700--