From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <opensource@keylevel.com>
Received: from r109.websiteservername.com (r109.websiteservername.com
	[65.39.128.45])
	by yocto-www.yoctoproject.org (Postfix) with ESMTP id 9E556E00722
	for <meta-freescale@yoctoproject.org>;
	Wed, 10 Jul 2013 12:54:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=keylevel.com;
	s=default; 
	h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type;
	bh=iTS2pGpUL+vYg5bNQtkXfy9WDmndCLSeFP7jZQww5Bg=; 
	b=KED93/dsyLYPTr2AeIVs2F8BsMiD/cGqxFznEld1hBE10uutg0hVTy2V9Y5tdFW43Re5H8ea2u054u2Y2s4vB8LyFwtLC9yPAUWI91HLuA32Stzv0wibkTZkbOJue4Nn7mQCOE+hpcODfHWsLvCwCpFLGyDwOq96K8fvB7tru/o=;
Received: from [109.224.129.17] (port=7714
	helo=macbook-pro.durham.keylevel.com)
	by r109.websiteservername.com with esmtpa (Exim 4.80)
	(envelope-from <opensource@keylevel.com>) id 1Ux0Sd-003XkW-HQ
	for meta-freescale@yoctoproject.org; Wed, 10 Jul 2013 20:53:59 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
From: Chris Tapp <opensource@keylevel.com>
In-Reply-To: <D775EFAA-7E4F-42C0-84D0-7A8D0A85A401@keylevel.com>
Date: Wed, 10 Jul 2013 20:53:58 +0100
Message-Id: <CC208FFA-C689-4892-8764-4F5CCCACB2E0@keylevel.com>
References: <D775EFAA-7E4F-42C0-84D0-7A8D0A85A401@keylevel.com>
To: meta-freescale@yoctoproject.org
X-Mailer: Apple Mail (2.1283)
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - r109.websiteservername.com
X-AntiAbuse: Original Domain - yoctoproject.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - keylevel.com
X-Get-Message-Sender-Via: r109.websiteservername.com: authenticated_id:
	chris.tapp+keylevel.com/only user confirmed/virtual account not
	confirmed
Subject: Re: Gstreamer pipeline problem
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
	<meta-freescale.yoctoproject.org>
List-Unsubscribe: <https://lists.yoctoproject.org/options/meta-freescale>,
	<mailto:meta-freescale-request@yoctoproject.org?subject=unsubscribe>
List-Archive: <http://lists.yoctoproject.org/pipermail/meta-freescale>
List-Post: <mailto:meta-freescale@yoctoproject.org>
List-Help: <mailto:meta-freescale-request@yoctoproject.org?subject=help>
List-Subscribe: <https://lists.yoctoproject.org/listinfo/meta-freescale>,
	<mailto:meta-freescale-request@yoctoproject.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 19:54:06 -0000
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On 10 Jul 2013, at 20:19, Chris Tapp wrote:

> I've got an application which uses playbin2 to capture video. The =
pipeline is of the form:
>=20
> playbin2 uri=3D... video-sink=3D"queue2 ! videoscale ! =
video/x-raw-rgb, pixel-aspect-ratio=3D1/1, width=3D<capture-width>, =
height=3D<capture-height> ! fakesink"
>=20
> I then get the "frame" property from the pipeline and use this to grab =
the latest frame.
>=20
> This works on my development system (Ubuntu 11.10) and a Cedar Trail / =
Yocto system, but the pipeline fails on the Wandboard Quad. I think this =
is related to:
>=20
> 0:00:13.028151336  1349 0x4442d520 WARN           basetransform =
/media/SSD-RAID/build-danny-wandboard/tmp/work/armv7a-vfp-neon-poky-linux-=
gnueabi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasetransf=
orm.c:1304:gst_base_transform_setcaps:<videoscale0x2ab820> transform =
could not transform video/x-raw-yuv, width=3D(int)854, height=3D(int)480, =
framerate=3D(fraction)24/1, format=3D(fourcc)I420, =
interlaced=3D(boolean)false in anything we support
>=20
> I added an ffmpegcolorspace element betwween the queue2 and the =
videoscale to get round this and the pipeline now builds, but only a few =
frames are captured. There are different diagnostics showing:
>=20
> 0:00:02.881403000  1361   0x28da60 WARN                  vpudec =
vpudec.c:914:gst_vpudec_core_create_and_register_frames: Allocate =
Internal framebuffers!!!!
> Message Callback : Element playbin0x250b68 changed state from READY to =
PAUSED.
> 0:00:03.237675000  1361   0x28da60 WARN                  vpudec =
vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return =
0x89, 8 frames in displaying queue!!
> 0:00:03.242324334  1361   0x28da60 WARN                  vpudec =
vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return =
0x89, 8 frames in displaying queue!!
>=20
> <lots of repeats>
>=20
> 0:00:08.499914334  1382   0x28d860 WARN                  vpudec =
vpudec.c:1655:gst_vpudec_chain: Retry too many times, maybe BUG!!
> 0:00:08.500784667  1382   0x28d860 WARN                  vpudec =
vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return =
0x88, 8 frames in displaying queue!!
>=20
> <lots of repeats>
>=20
> Message Callback : Element playbin0x250aa0 changed state from PAUSED =
to PLAYING.
> 0:00:09.253202667  1382   0x28d860 WARN                  vpudec =
vpudec.c:1578:gst_vpudec_chain: Got no frame buffer message, return =
0x88, 8 frames in displaying queue!!
>=20
> 0:00:13.364523335  1460   0x142ec0 WARN             mfw_v4lsink =
mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, =
ret 2 No such file or directory queued 0
>=20
>=20
> The "Message Callback" events are my own logging to try and see what's =
happening in my app.
>=20
> Is this something I'm doing wrong, or are these messages a real issue =
somewhere?

This is when playing a .webm. The results for an .flv are as expected.

Chris Tapp

opensource@keylevel.com
www.keylevel.com