Regarding GStreamer-1.x status on iMX6Q

Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

Hi,

Can anyone give a status update on the stability/functionality of
gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
alpha for a while.

For the application that I am working on, it would be more beneficial
to use 1.x.  If their is still work to be done with porting it over, I
would be available to help as long as someone points me in the right
direction.

Thanks,
Josh Kurland

Re: Regarding GStreamer-1.x status on iMX6Q

[Otavio Salvador]

(adding Carlos in Cc)

On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
<joshua.kurland@adtecdigital.net> wrote:
> Can anyone give a status update on the stability/functionality of
> gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
> alpha for a while.
>
> For the application that I am working on, it would be more beneficial
> to use 1.x.  If their is still work to be done with porting it over, I
> would be available to help as long as someone points me in the right
> direction.

Carlos did the current public work for 1.0 support. He may provided a
good status update on this.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

On 2013-11-18 17:07, Otavio Salvador wrote:
> (adding Carlos in Cc)
>
> On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
> <joshua.kurland@adtecdigital.net> wrote:
>> Can anyone give a status update on the stability/functionality of
>> gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
>> alpha for a while.
>>
>> For the application that I am working on, it would be more beneficial
>> to use 1.x.  If their is still work to be done with porting it over, I
>> would be available to help as long as someone points me in the right
>> direction.
> Carlos did the current public work for 1.0 support. He may provided a
> good status update on this.
>

I prefer this email address :)

Current status: decoder has been running stable for me. h264 encoder has 
been working stable too. mpeg2,h263,mpeg4p2 encoders haven't been tested 
as much.
There are a few known bugs in the IPU transform and eglvivsink transform 
plugins. The reason why it is still alpha is that some features are 
missing (second deinterlace mode, some element properties, and 3D 
support). Once this is done, I'll switch to beta. The planned release of 
the beta version is end of November.

Carlos

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

That's great news!  At this point in time decoding is the only thing
important to me.  Have you pushed the stable version of the decoder to the
gstreamer-imx repo?

Thanks,
Josh Kurland


On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani <dv@pseudoterminal.org
> wrote:

> On 2013-11-18 17:07, Otavio Salvador wrote:
>
>> (adding Carlos in Cc)
>>
>> On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>> <joshua.kurland@adtecdigital.net> wrote:
>>
>>> Can anyone give a status update on the stability/functionality of
>>> gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
>>> alpha for a while.
>>>
>>> For the application that I am working on, it would be more beneficial
>>> to use 1.x.  If their is still work to be done with porting it over, I
>>> would be available to help as long as someone points me in the right
>>> direction.
>>>
>> Carlos did the current public work for 1.0 support. He may provided a
>> good status update on this.
>>
>>
> I prefer this email address :)
>
> Current status: decoder has been running stable for me. h264 encoder has
> been working stable too. mpeg2,h263,mpeg4p2 encoders haven't been tested as
> much.
> There are a few known bugs in the IPU transform and eglvivsink transform
> plugins. The reason why it is still alpha is that some features are missing
> (second deinterlace mode, some element properties, and 3D support). Once
> this is done, I'll switch to beta. The planned release of the beta version
> is end of November.
>
> Carlos
>

[-- Attachment #2: Type: text/html, Size: 2285 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

Yes, the current status in Github is what I was talking about. The only 
thing missing from the decoder atm is VC1/WMV3 support. I have to figure 
out some parsing details there.
My current focus is on the video transform element (bugfixes & second 
deinterlace mode).

I forgot to mention one other thing that already works: transcoding with 
zerocopy. Meaning, pictures decoded by the VPU can be passed to the 
encoder directly without having to copy the pixels. Initial tests show 
that real-time 1080p transcoding to h264 baseline is feasible with this.

On 2013-11-18 19:20, Joshua Kurland wrote:
> That's great news!  At this point in time decoding is the only thing 
> important to me.  Have you pushed the stable version of the decoder to 
> the gstreamer-imx repo?
>
> Thanks,
> Josh Kurland
>
>
> On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani 
> <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>
>     On 2013-11-18 17:07, Otavio Salvador wrote:
>
>         (adding Carlos in Cc)
>
>         On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>         <joshua.kurland@adtecdigital.net
>         <mailto:joshua.kurland@adtecdigital.net>> wrote:
>
>             Can anyone give a status update on the
>             stability/functionality of
>             gstreamer-1.x plugin on the imx6Q?  The readme page has
>             listed it in
>             alpha for a while.
>
>             For the application that I am working on, it would be more
>             beneficial
>             to use 1.x.  If their is still work to be done with
>             porting it over, I
>             would be available to help as long as someone points me in
>             the right
>             direction.
>
>         Carlos did the current public work for 1.0 support. He may
>         provided a
>         good status update on this.
>
>
>     I prefer this email address :)
>
>     Current status: decoder has been running stable for me. h264
>     encoder has been working stable too. mpeg2,h263,mpeg4p2 encoders
>     haven't been tested as much.
>     There are a few known bugs in the IPU transform and eglvivsink
>     transform plugins. The reason why it is still alpha is that some
>     features are missing (second deinterlace mode, some element
>     properties, and 3D support). Once this is done, I'll switch to
>     beta. The planned release of the beta version is end of November.
>
>     Carlos
>
>


[-- Attachment #2: Type: text/html, Size: 4394 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

If you have some time today, could you answer one last question?  *How* do
I include 1.x into my build?  I switched repos from Dora to Master and
added these packages:
    gstreamer1.0
    gstreamer1.0-plugins-base
    gstreamer1.0-plugins-good

I am able to confirm that all three have been added to my project, but
gst-inspect-1.0 only shows me gst-core has actually been installed.  Plus I
don't think this includes anything from the gstreamer-imx repo.  If you
could give some basic instructions I would greatly appreciate it.

Thank you,
Josh Kurland


On Wed, Nov 20, 2013 at 8:24 AM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

>  Yes, the current status in Github is what I was talking about. The only
> thing missing from the decoder atm is VC1/WMV3 support. I have to figure
> out some parsing details there.
> My current focus is on the video transform element (bugfixes & second
> deinterlace mode).
>
> I forgot to mention one other thing that already works: transcoding with
> zerocopy. Meaning, pictures decoded by the VPU can be passed to the encoder
> directly without having to copy the pixels. Initial tests show that
> real-time 1080p transcoding to h264 baseline is feasible with this.
>
>
> On 2013-11-18 19:20, Joshua Kurland wrote:
>
> That's great news!  At this point in time decoding is the only thing
> important to me.  Have you pushed the stable version of the decoder to the
> gstreamer-imx repo?
>
>  Thanks,
>  Josh Kurland
>
>
> On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani <
> dv@pseudoterminal.org> wrote:
>
>> On 2013-11-18 17:07, Otavio Salvador wrote:
>>
>>> (adding Carlos in Cc)
>>>
>>> On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>>> <joshua.kurland@adtecdigital.net> wrote:
>>>
>>>> Can anyone give a status update on the stability/functionality of
>>>> gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
>>>> alpha for a while.
>>>>
>>>> For the application that I am working on, it would be more beneficial
>>>> to use 1.x.  If their is still work to be done with porting it over, I
>>>> would be available to help as long as someone points me in the right
>>>> direction.
>>>>
>>> Carlos did the current public work for 1.0 support. He may provided a
>>> good status update on this.
>>>
>>>
>>  I prefer this email address :)
>>
>> Current status: decoder has been running stable for me. h264 encoder has
>> been working stable too. mpeg2,h263,mpeg4p2 encoders haven't been tested as
>> much.
>> There are a few known bugs in the IPU transform and eglvivsink transform
>> plugins. The reason why it is still alpha is that some features are missing
>> (second deinterlace mode, some element properties, and 3D support). Once
>> this is done, I'll switch to beta. The planned release of the beta version
>> is end of November.
>>
>> Carlos
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5072 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 5232 bytes --]

You'll want to add gstreamer1.0-plugins-base-meta and 
gstreamer1.0-plugins-good-meta . Note the difference between packages 
and recipes in OE.

As for building gstreamer-imx , you first set up these environment 
variables:
* CC
* CFLAGS
* LDFLAGS
* PKG_CONFIG_PATH
* PKG_CONFIG_SYSROOT_DIR
* PATH

then, you call ./waf configure --kernel-headers=<path to kernel 
headers>  build . This produces binaries in a newly created build/ folder.

Here is a script I've made for myself (building for a Sabre SD here):

export ROOT="/path/to/my/OE/dir"
export CFLAGS="--sysroot=${ROOT}/tmp/sysroots/imx6dlsabresd"
export LDFLAGS="--sysroot=${ROOT}/tmp/sysroots/imx6dlsabresd"
export 
CC="${ROOT}/tmp/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc"
export 
PKG_CONFIG_PATH="${ROOT}/tmp/sysroots/imx6dlsabresd/usr/lib/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR="${ROOT}/tmp/sysroots/imx6dlsabresd"
export PATH="${ROOT}/tmp/sysroots/x86_64-linux/usr/bin:${PATH}"
./waf configure 
--kernel-headers=${ROOT}/tmp/sysroots/imx6dlsabresd/usr/src/kernel/include/ 
build

The produced binaries are:
build/src/eglvivsink/libgsteglvivsink.so
build/src/ipu/libgstimxipu.so
build/src/vpu/libgstimxvpu.so
build/src/common/libgstimxcommon.so

Copy libgstimxcommon.so to your device's /usr/lib/ directory. The other 
three go to /usr/lib/gstreamer-1.0 .
Note that you need the GLES/EGL headers from Vivante to build the 
eglvivsink . The IPU plugin needs kernel headers (an unfortunate 
necessity). The VPU needs libfslvpuwrap .

I will add an OE recipe for this soon. It would make things a lot easier.



On 2013-11-20 16:25, Joshua Kurland wrote:
> If you have some time today, could you answer one last question? 
> *How* do I include 1.x into my build?  I switched repos from Dora to 
> Master and added these packages:
>     gstreamer1.0
>     gstreamer1.0-plugins-base
>     gstreamer1.0-plugins-good
>
> I am able to confirm that all three have been added to my project, but 
> gst-inspect-1.0 only shows me gst-core has actually been installed. 
>  Plus I don't think this includes anything from the gstreamer-imx 
> repo.  If you could give some basic instructions I would greatly 
> appreciate it.
>
> Thank you,
> Josh Kurland
>
>
> On Wed, Nov 20, 2013 at 8:24 AM, Carlos Rafael Giani 
> <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>
>     Yes, the current status in Github is what I was talking about. The
>     only thing missing from the decoder atm is VC1/WMV3 support. I
>     have to figure out some parsing details there.
>     My current focus is on the video transform element (bugfixes &
>     second deinterlace mode).
>
>     I forgot to mention one other thing that already works:
>     transcoding with zerocopy. Meaning, pictures decoded by the VPU
>     can be passed to the encoder directly without having to copy the
>     pixels. Initial tests show that real-time 1080p transcoding to
>     h264 baseline is feasible with this.
>
>
>     On 2013-11-18 19:20, Joshua Kurland wrote:
>>     That's great news!  At this point in time decoding is the only
>>     thing important to me.  Have you pushed the stable version of the
>>     decoder to the gstreamer-imx repo?
>>
>>     Thanks,
>>     Josh Kurland
>>
>>
>>     On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani
>>     <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>>
>>         On 2013-11-18 17:07, Otavio Salvador wrote:
>>
>>             (adding Carlos in Cc)
>>
>>             On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>>             <joshua.kurland@adtecdigital.net
>>             <mailto:joshua.kurland@adtecdigital.net>> wrote:
>>
>>                 Can anyone give a status update on the
>>                 stability/functionality of
>>                 gstreamer-1.x plugin on the imx6Q?  The readme page
>>                 has listed it in
>>                 alpha for a while.
>>
>>                 For the application that I am working on, it would be
>>                 more beneficial
>>                 to use 1.x.  If their is still work to be done with
>>                 porting it over, I
>>                 would be available to help as long as someone points
>>                 me in the right
>>                 direction.
>>
>>             Carlos did the current public work for 1.0 support. He
>>             may provided a
>>             good status update on this.
>>
>>
>>         I prefer this email address :)
>>
>>         Current status: decoder has been running stable for me. h264
>>         encoder has been working stable too. mpeg2,h263,mpeg4p2
>>         encoders haven't been tested as much.
>>         There are a few known bugs in the IPU transform and
>>         eglvivsink transform plugins. The reason why it is still
>>         alpha is that some features are missing (second deinterlace
>>         mode, some element properties, and 3D support). Once this is
>>         done, I'll switch to beta. The planned release of the beta
>>         version is end of November.
>>
>>         Carlos
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 9839 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Philip Craig]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

On Thu, Nov 21, 2013 at 1:25 AM, Joshua Kurland
<joshua.kurland@adtecdigital.net> wrote:
> If you have some time today, could you answer one last question?  How do I
> include 1.x into my build?  I switched repos from Dora to Master and added
> these packages:
>     gstreamer1.0
>     gstreamer1.0-plugins-base
>     gstreamer1.0-plugins-good
>
> I am able to confirm that all three have been added to my project, but
> gst-inspect-1.0 only shows me gst-core has actually been installed.

The plugins are split out into a separate package for each plugin. To
get all the plugins you need to include the -meta packages (eg
gstreamer1.0-plugins-base-meta). The base packages only include the
files that are common to all plugins, which is likely none.

> Plus I
> don't think this includes anything from the gstreamer-imx repo.  If you
> could give some basic instructions I would greatly appreciate it.

I've attached a recipe for gstreamer-imx that I used for testing. I
only tested the vpu plugin with this recipe. It's probably a bit rough
still, but should be okay as a starting point. The SRCREV might be old
too.

[-- Attachment #2: gstreamer1.0-imx_git.bb --]
[-- Type: application/octet-stream, Size: 694 bytes --]

DESCRIPTION = "GStreamer 1.0 plugins for i.MX platforms"
LICENSE = "LGPLv2+"
LIC_FILES_CHKSUM = "file://LICENSE;md5=55ca817ccb7d5b5b66355690e9abc605"

SRC_URI = "git://github.com/Freescale/gstreamer-imx.git;branch=master;protocol=git"
SRCREV = "7632254df4ebd0dc52b95928118e1a8ada6a2e96"
S = "${WORKDIR}/git"

DEPENDS = "gstreamer1.0 gstreamer1.0-plugins-base libfslvpuwrap virtual/kernel"

inherit waf

COMPATIBLE_MACHINE = "(mx6)"
PACKAGE_ARCH = "${MACHINE_ARCH}"

CFLAGS += "-I${STAGING_KERNEL_DIR}/include"

LIBV = "1.0"
require recipes-multimedia/gstreamer/gst-plugins-package.inc

PACKAGES_DYNAMIC = "^${PN}-.*"

FILES_${PN} += "${libdir}/libgstimxcommon${SOLIBSDEV}"
FILES_${PN}-dev = ""

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 2495 bytes --]

Hello,

due to unforessen difficulties and some subtle but severe bugs that were 
found, I have to postpone the release date by a few days. December 5th 
to be exact. Sorry for the inconvenience. It is not that much work until 
I have a beta release.

I will also scrap the 3D support, since GStreamer itself does not have 
proper support for it yet. This is under discussion by the GStreamer 
developers ( https://bugzilla.gnome.org/show_bug.cgi?id=611157#c75 ). 3D 
is far from trivial, so it is best to follow the discussion at this time.

regards

On 2013-11-18 19:20, Joshua Kurland wrote:
> That's great news!  At this point in time decoding is the only thing 
> important to me.  Have you pushed the stable version of the decoder to 
> the gstreamer-imx repo?
>
> Thanks,
> Josh Kurland
>
>
> On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani 
> <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>
>     On 2013-11-18 17:07, Otavio Salvador wrote:
>
>         (adding Carlos in Cc)
>
>         On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>         <joshua.kurland@adtecdigital.net
>         <mailto:joshua.kurland@adtecdigital.net>> wrote:
>
>             Can anyone give a status update on the
>             stability/functionality of
>             gstreamer-1.x plugin on the imx6Q?  The readme page has
>             listed it in
>             alpha for a while.
>
>             For the application that I am working on, it would be more
>             beneficial
>             to use 1.x.  If their is still work to be done with
>             porting it over, I
>             would be available to help as long as someone points me in
>             the right
>             direction.
>
>         Carlos did the current public work for 1.0 support. He may
>         provided a
>         good status update on this.
>
>
>     I prefer this email address :)
>
>     Current status: decoder has been running stable for me. h264
>     encoder has been working stable too. mpeg2,h263,mpeg4p2 encoders
>     haven't been tested as much.
>     There are a few known bugs in the IPU transform and eglvivsink
>     transform plugins. The reason why it is still alpha is that some
>     features are missing (second deinterlace mode, some element
>     properties, and 3D support). Once this is done, I'll switch to
>     beta. The planned release of the beta version is end of November.
>
>     Carlos
>
>


[-- Attachment #2: Type: text/html, Size: 4573 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1.1: Type: text/plain, Size: 2888 bytes --]

I am having a bit of difficulty compiling the gstreamer-imx binaries using
waf.  I set up the environment variables and ran waf, but it was unable to
find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in my
sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
 I am adding libfslvpuwrap as a package under the IMAGE_INSTALL section of
my image recipe, is this not the correct way?  I've attached my environment
script as well as the error log, I would appreciate any help I can get.

Thanks,
Josh Kurland


On Sun, Dec 1, 2013 at 8:36 PM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

>  Hello,
>
> due to unforessen difficulties and some subtle but severe bugs that were
> found, I have to postpone the release date by a few days. December 5th to
> be exact. Sorry for the inconvenience. It is not that much work until I
> have a beta release.
>
> I will also scrap the 3D support, since GStreamer itself does not have
> proper support for it yet. This is under discussion by the GStreamer
> developers ( https://bugzilla.gnome.org/show_bug.cgi?id=611157#c75 ). 3D
> is far from trivial, so it is best to follow the discussion at this time.
>
> regards
>
>
> On 2013-11-18 19:20, Joshua Kurland wrote:
>
> That's great news!  At this point in time decoding is the only thing
> important to me.  Have you pushed the stable version of the decoder to the
> gstreamer-imx repo?
>
>  Thanks,
>  Josh Kurland
>
>
> On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani <
> dv@pseudoterminal.org> wrote:
>
>> On 2013-11-18 17:07, Otavio Salvador wrote:
>>
>>> (adding Carlos in Cc)
>>>
>>> On Mon, Nov 18, 2013 at 1:48 PM, Joshua Kurland
>>> <joshua.kurland@adtecdigital.net> wrote:
>>>
>>>> Can anyone give a status update on the stability/functionality of
>>>> gstreamer-1.x plugin on the imx6Q?  The readme page has listed it in
>>>> alpha for a while.
>>>>
>>>> For the application that I am working on, it would be more beneficial
>>>> to use 1.x.  If their is still work to be done with porting it over, I
>>>> would be available to help as long as someone points me in the right
>>>> direction.
>>>>
>>> Carlos did the current public work for 1.0 support. He may provided a
>>> good status update on this.
>>>
>>>
>>  I prefer this email address :)
>>
>> Current status: decoder has been running stable for me. h264 encoder has
>> been working stable too. mpeg2,h263,mpeg4p2 encoders haven't been tested as
>> much.
>> There are a few known bugs in the IPU transform and eglvivsink transform
>> plugins. The reason why it is still alpha is that some features are missing
>> (second deinterlace mode, some element properties, and 3D support). Once
>> this is done, I'll switch to beta. The planned release of the beta version
>> is end of November.
>>
>> Carlos
>>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 5100 bytes --]

[-- Attachment #2: gstreamer-imx-script.sh --]
[-- Type: application/x-sh, Size: 766 bytes --]

[-- Attachment #3: config.log --]
[-- Type: text/x-log, Size: 10301 bytes --]

# project  configured on Mon Dec  9 14:56:12 2013 by
# waf 1.7.11 (abi 98, python 20703f0 on linux2)
# using ./waf configure --kernel-headers=/opt/poky/1.5+gst/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/src/kernel/include/build
#
----------------------------------------
Setting top to
/home/josh-adtec/yocto/gstreamer-imx-master
----------------------------------------
Setting out to
/home/josh-adtec/yocto/gstreamer-imx-master/build
----------------------------------------
Checking for 'gcc' (c compiler)
find program=['gcc', 'cc'] paths=['/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/bin', '/usr/lib/lightdm/lightdm', '/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/games'] var='CC' -> '/usr/bin/gcc'
find program=['ar'] paths=['/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/bin', '/usr/lib/lightdm/lightdm', '/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/games'] var='AR' -> '/usr/bin/ar'
/usr/bin/gcc
----------------------------------------
Checking for compiler switch -O2
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_3a0786e39d65052393eb7386bd27fdee/test.c -> build/.conf_check_3a0786e39d65052393eb7386bd27fdee/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_3a0786e39d65052393eb7386bd27fdee/testbuild/test.c.1.o -> build/.conf_check_3a0786e39d65052393eb7386bd27fdee/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_3a0786e39d65052393eb7386bd27fdee/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for compiler switch -DPIC
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_b970d372ec4c721f2733c421b16dab38/test.c -> build/.conf_check_b970d372ec4c721f2733c421b16dab38/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_b970d372ec4c721f2733c421b16dab38/testbuild/test.c.1.o -> build/.conf_check_b970d372ec4c721f2733c421b16dab38/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_b970d372ec4c721f2733c421b16dab38/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for compiler switch -fPIC
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_fb2d20e409968f49aa132023965e8758/test.c -> build/.conf_check_fb2d20e409968f49aa132023965e8758/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_fb2d20e409968f49aa132023965e8758/testbuild/test.c.1.o -> build/.conf_check_fb2d20e409968f49aa132023965e8758/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_fb2d20e409968f49aa132023965e8758/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for compiler switch -std=gnu99
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_aedbab85d361d8afae06549c1e10bee6/test.c -> build/.conf_check_aedbab85d361d8afae06549c1e10bee6/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-fPIC', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_aedbab85d361d8afae06549c1e10bee6/testbuild/test.c.1.o -> build/.conf_check_aedbab85d361d8afae06549c1e10bee6/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_aedbab85d361d8afae06549c1e10bee6/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for compiler switch -Wall
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_21ad586ab3ce734c21602a0fed58020c/test.c -> build/.conf_check_21ad586ab3ce734c21602a0fed58020c/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-std=gnu99', '-fPIC', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_21ad586ab3ce734c21602a0fed58020c/testbuild/test.c.1.o -> build/.conf_check_21ad586ab3ce734c21602a0fed58020c/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_21ad586ab3ce734c21602a0fed58020c/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for compiler switch -Wextra
==>

int main()
{
	float f = 4.0;
	char c = f;
	return c - 4;
}

<==
[1/2] ^[[32mc: build/.conf_check_055b3a9bac37e8f528f8f0ab0abb0552/test.c -> build/.conf_check_055b3a9bac37e8f528f8f0ab0abb0552/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-Wall', '-std=gnu99', '-fPIC', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_055b3a9bac37e8f528f8f0ab0abb0552/testbuild/test.c.1.o -> build/.conf_check_055b3a9bac37e8f528f8f0ab0abb0552/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_055b3a9bac37e8f528f8f0ab0abb0552/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic']
yes
----------------------------------------
Checking for library m
==>

int main(int argc, char **argv) {
	(void)argc; (void)argv;
	return 0;
}

<==
[1/2] ^[[32mc: build/.conf_check_fe5fb2e31b57ba5f0ed25de6fc2a5683/test.c -> build/.conf_check_fe5fb2e31b57ba5f0ed25de6fc2a5683/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-Wextra', '-Wall', '-std=gnu99', '-fPIC', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_fe5fb2e31b57ba5f0ed25de6fc2a5683/testbuild/test.c.1.o -> build/.conf_check_fe5fb2e31b57ba5f0ed25de6fc2a5683/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_fe5fb2e31b57ba5f0ed25de6fc2a5683/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lm']
yes
----------------------------------------
Checking for library pthread
==>

int main(int argc, char **argv) {
	(void)argc; (void)argv;
	return 0;
}

<==
[1/2] ^[[32mc: build/.conf_check_2b7360a909b095483144b7ecb95bbbdd/test.c -> build/.conf_check_2b7360a909b095483144b7ecb95bbbdd/testbuild/test.c.1.o
^[[0m
['/usr/bin/gcc', '-Wextra', '-Wall', '-std=gnu99', '-fPIC', '-DPIC', '-O2', '../test.c', '-c', '-o', 'test.c.1.o']
[2/2] ^[[33mcprogram: build/.conf_check_2b7360a909b095483144b7ecb95bbbdd/testbuild/test.c.1.o -> build/.conf_check_2b7360a909b095483144b7ecb95bbbdd/testbuild/testprog
^[[0m
['/usr/bin/gcc', 'test.c.1.o', '-o', '/home/josh-adtec/yocto/gstreamer-imx-master/build/.conf_check_2b7360a909b095483144b7ecb95bbbdd/testbuild/testprog', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lpthread']
yes
----------------------------------------
Checking for program pkg-config
/usr/bin/pkg-config
find program=['pkg-config'] paths=['/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin', '/home/josh-adtec/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin_cache', '/home/josh-adtec/bin', '/usr/lib/lightdm/lightdm', '/usr/local/sbin', '/usr/local/bin', '/usr/sbin', '/usr/bin', '/sbin', '/bin', '/usr/games'] var='PKGCONFIG' -> '/usr/bin/pkg-config'
----------------------------------------
Checking for 'gstreamer-1.0 >= 1.0.0'
['/usr/bin/pkg-config', '--cflags', '--libs', 'gstreamer-1.0', '>=', '1.0.0']
out: -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -pthread -lgstreamer-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  

yes
------------------------------------------
Checking for 'gstreamer-base-1.0 >= 1.0.0'
['/usr/bin/pkg-config', '--cflags', '--libs', 'gstreamer-base-1.0', '>=', '1.0.0']
out: -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -pthread -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  

yes
-------------------------------------------
Checking for 'gstreamer-video-1.0 >= 1.0.0'
['/usr/bin/pkg-config', '--cflags', '--libs', 'gstreamer-video-1.0', '>=', '1.0.0']
out: -pthread -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -pthread -lgstvideo-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0  

yes
-------------------------------------------
Checking for 'libfslvpuwrap'
['/usr/bin/pkg-config', '--cflags', '--libs', 'libfslvpuwrap']
err: Package libfslvpuwrap was not found in the pkg-config search path.
Perhaps you should add the directory containing `libfslvpuwrap.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libfslvpuwrap' found

not found
from /home/josh-adtec/yocto/gstreamer-imx-master: The configuration failed

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On 2013-12-09 21:05, Joshua Kurland wrote:
> I am having a bit of difficulty compiling the gstreamer-imx binaries 
> using waf.  I set up the environment variables and ran waf, but it was 
> unable to find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in my 
> sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc. 
>  I am adding libfslvpuwrap as a package under the IMAGE_INSTALL 
> section of my image recipe, is this not the correct way?  I've 
> attached my environment script as well as the error log, I would 
> appreciate any help I can get.
>
> Thanks,
> Josh Kurland
>

The environment variables look wrong to me.
1. export 
CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi" 
: sysroot is not supposed to point to the cross compiler directory, but 
to the sysroot of the *device* (same goes for the LDFLAGS, the 
PKG_CONFIG_SYSROOT_DIR, and the kernel headers path)
2. the "/build" part of the kernel headers path needs to be removed
3. do you use hardfloat or softfloat? In one place, you use cortexa9, in 
another, cortexa9hf

I attached an example script that may be clearer (at successfully builds 
the plugins). It builds for the Sabre SD DualLite platform.

cheers

[-- Attachment #2: build-gstimx.sh --]
[-- Type: application/x-sh, Size: 624 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

Thanks Carlos, that script helped out a lot and I am able to compile the
binaries.  I modified your script to use the wandboard-quad sysroots and
ran the script.  I then ran ./waf and  sudo ./waf install.  I copied the
binaries from /usr/local/lib to my board in /usr/lib and
/usr/lib/gstreamer-1.0.  Everything seemed fine, but when I use
gst-inspect-1.0 to find mfw_v4lsink nothing is found.  The same can be said
for other Freescale elements that I had been using in Gstreamer-0.10.

Thanks,
Josh Kurland


On Mon, Dec 9, 2013 at 3:31 PM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

> On 2013-12-09 21:05, Joshua Kurland wrote:
>
>> I am having a bit of difficulty compiling the gstreamer-imx binaries
>> using waf.  I set up the environment variables and ran waf, but it was
>> unable to find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in my
>> sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
>>  I am adding libfslvpuwrap as a package under the IMAGE_INSTALL section of
>> my image recipe, is this not the correct way?  I've attached my environment
>> script as well as the error log, I would appreciate any help I can get.
>>
>> Thanks,
>> Josh Kurland
>>
>>
> The environment variables look wrong to me.
> 1. export CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/
> usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi" : sysroot is not supposed
> to point to the cross compiler directory, but to the sysroot of the
> *device* (same goes for the LDFLAGS, the PKG_CONFIG_SYSROOT_DIR, and the
> kernel headers path)
> 2. the "/build" part of the kernel headers path needs to be removed
> 3. do you use hardfloat or softfloat? In one place, you use cortexa9, in
> another, cortexa9hf
>
> I attached an example script that may be clearer (at successfully builds
> the plugins). It builds for the Sabre SD DualLite platform.
>
> cheers
>

[-- Attachment #2: Type: text/html, Size: 2450 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Thats because they have different names. They all start with "imx" (with 
the exception of the eglvivsink).
These are entirely different plugins, written from scratch.

On 2013-12-09 22:14, Joshua Kurland wrote:
> Thanks Carlos, that script helped out a lot and I am able to compile 
> the binaries.  I modified your script to use the wandboard-quad 
> sysroots and ran the script.  I then ran ./waf and  sudo ./waf 
> install.  I copied the binaries from /usr/local/lib to my board in 
> /usr/lib and /usr/lib/gstreamer-1.0.  Everything seemed fine, but when 
> I use gst-inspect-1.0 to find mfw_v4lsink nothing is found.  The same 
> can be said for other Freescale elements that I had been using in 
> Gstreamer-0.10.
>
> Thanks,
> Josh Kurland
>
>
> On Mon, Dec 9, 2013 at 3:31 PM, Carlos Rafael Giani 
> <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>
>     On 2013-12-09 21:05, Joshua Kurland wrote:
>
>         I am having a bit of difficulty compiling the gstreamer-imx
>         binaries using waf.  I set up the environment variables and
>         ran waf, but it was unable to find 'libfslvpuwrap'.  But
>          libfslvpuwrap.pc is found in my
>         sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
>          I am adding libfslvpuwrap as a package under the
>         IMAGE_INSTALL section of my image recipe, is this not the
>         correct way?  I've attached my environment script as well as
>         the error log, I would appreciate any help I can get.
>
>         Thanks,
>         Josh Kurland
>
>
>     The environment variables look wrong to me.
>     1. export
>     CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi"
>     : sysroot is not supposed to point to the cross compiler
>     directory, but to the sysroot of the *device* (same goes for the
>     LDFLAGS, the PKG_CONFIG_SYSROOT_DIR, and the kernel headers path)
>     2. the "/build" part of the kernel headers path needs to be removed
>     3. do you use hardfloat or softfloat? In one place, you use
>     cortexa9, in another, cortexa9hf
>
>     I attached an example script that may be clearer (at successfully
>     builds the plugins). It builds for the Sabre SD DualLite platform.
>
>     cheers
>
>


[-- Attachment #2: Type: text/html, Size: 3869 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

Ah, okay.  Gst-inspect-1.0 now shows imxvpu, imxipu, etc.  In order to
decode a simple video from a file, what would the new pipeline look like?
 Normally I would run something like 'gst-launch-0.10 playbin2
uri=file:///myfile video-sink=mfw_v4lsink'.  Can I make a one-to-one
conversion from the old mfw_v4lsink to some other custom element?


On Mon, Dec 9, 2013 at 4:17 PM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

>  Thats because they have different names. They all start with "imx" (with
> the exception of the eglvivsink).
> These are entirely different plugins, written from scratch.
>
>
> On 2013-12-09 22:14, Joshua Kurland wrote:
>
> Thanks Carlos, that script helped out a lot and I am able to compile the
> binaries.  I modified your script to use the wandboard-quad sysroots and
> ran the script.  I then ran ./waf and  sudo ./waf install.  I copied the
> binaries from /usr/local/lib to my board in /usr/lib and
> /usr/lib/gstreamer-1.0.  Everything seemed fine, but when I use
> gst-inspect-1.0 to find mfw_v4lsink nothing is found.  The same can be said
> for other Freescale elements that I had been using in Gstreamer-0.10.
>
>  Thanks,
> Josh Kurland
>
>
> On Mon, Dec 9, 2013 at 3:31 PM, Carlos Rafael Giani <dv@pseudoterminal.org
> > wrote:
>
>> On 2013-12-09 21:05, Joshua Kurland wrote:
>>
>>> I am having a bit of difficulty compiling the gstreamer-imx binaries
>>> using waf.  I set up the environment variables and ran waf, but it was
>>> unable to find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in my
>>> sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
>>>  I am adding libfslvpuwrap as a package under the IMAGE_INSTALL section of
>>> my image recipe, is this not the correct way?  I've attached my environment
>>> script as well as the error log, I would appreciate any help I can get.
>>>
>>> Thanks,
>>> Josh Kurland
>>>
>>>
>>  The environment variables look wrong to me.
>> 1. export
>> CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi"
>> : sysroot is not supposed to point to the cross compiler directory, but to
>> the sysroot of the *device* (same goes for the LDFLAGS, the
>> PKG_CONFIG_SYSROOT_DIR, and the kernel headers path)
>> 2. the "/build" part of the kernel headers path needs to be removed
>> 3. do you use hardfloat or softfloat? In one place, you use cortexa9, in
>> another, cortexa9hf
>>
>> I attached an example script that may be clearer (at successfully builds
>> the plugins). It builds for the Sabre SD DualLite platform.
>>
>> cheers
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 4366 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

Try:  DISPLAY=:0 gst-launch-1.0 playbin uri=file:///myfile 
video-sink=eglvivsink

This assumes you have X11 built and running on your machine.
egvivsink support for Wayland and rendering to framebuffer will come in 
a later version.
Please also check your CPU usage. If it is much higher with some videos, 
I'd like to know. There is one area where an unfortunate design 
limitation of the VPU libraries (and potentially the VPU itself) can 
cause this problem. I am thinking about workarounds, but its uncertain 
if it can be overcome. Worst case, some videos require tweaking of one 
GStreamer element property.

cheers

On 2013-12-09 22:26, Joshua Kurland wrote:
> Ah, okay.  Gst-inspect-1.0 now shows imxvpu, imxipu, etc.  In order to 
> decode a simple video from a file, what would the new pipeline look 
> like?  Normally I would run something like 'gst-launch-0.10 playbin2 
> uri=file:///myfile video-sink=mfw_v4lsink'.  Can I make a one-to-one 
> conversion from the old mfw_v4lsink to some other custom element?
>
>
> On Mon, Dec 9, 2013 at 4:17 PM, Carlos Rafael Giani 
> <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>
>     Thats because they have different names. They all start with "imx"
>     (with the exception of the eglvivsink).
>     These are entirely different plugins, written from scratch.
>
>
>     On 2013-12-09 22:14, Joshua Kurland wrote:
>>     Thanks Carlos, that script helped out a lot and I am able to
>>     compile the binaries.  I modified your script to use the
>>     wandboard-quad sysroots and ran the script.  I then ran ./waf and
>>      sudo ./waf install.  I copied the binaries from /usr/local/lib
>>     to my board in /usr/lib and /usr/lib/gstreamer-1.0.  Everything
>>     seemed fine, but when I use gst-inspect-1.0 to find mfw_v4lsink
>>     nothing is found.  The same can be said for other Freescale
>>     elements that I had been using in Gstreamer-0.10.
>>
>>     Thanks,
>>     Josh Kurland
>>
>>
>>     On Mon, Dec 9, 2013 at 3:31 PM, Carlos Rafael Giani
>>     <dv@pseudoterminal.org <mailto:dv@pseudoterminal.org>> wrote:
>>
>>         On 2013-12-09 21:05, Joshua Kurland wrote:
>>
>>             I am having a bit of difficulty compiling the
>>             gstreamer-imx binaries using waf.  I set up the
>>             environment variables and ran waf, but it was unable to
>>             find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in
>>             my
>>             sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
>>              I am adding libfslvpuwrap as a package under the
>>             IMAGE_INSTALL section of my image recipe, is this not the
>>             correct way?  I've attached my environment script as well
>>             as the error log, I would appreciate any help I can get.
>>
>>             Thanks,
>>             Josh Kurland
>>
>>
>>         The environment variables look wrong to me.
>>         1. export
>>         CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi"
>>         : sysroot is not supposed to point to the cross compiler
>>         directory, but to the sysroot of the *device* (same goes for
>>         the LDFLAGS, the PKG_CONFIG_SYSROOT_DIR, and the kernel
>>         headers path)
>>         2. the "/build" part of the kernel headers path needs to be
>>         removed
>>         3. do you use hardfloat or softfloat? In one place, you use
>>         cortexa9, in another, cortexa9hf
>>
>>         I attached an example script that may be clearer (at
>>         successfully builds the plugins). It builds for the Sabre SD
>>         DualLite platform.
>>
>>         cheers
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 7412 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 4612 bytes --]

I think the problem I am having is because of the X11 requirement.  Without
it, running a simple pipeline using eglvivsink immediately crashes.  Is it
possible to run without X?  I don't currently use it on my system.  I will
have to try again with X running on a new build later today, but until I
get that working would you mind if I ask you a few more questions?

1.)  The project I have been working on made use of the multi overlay
support from mfw_isink.  Specifically it was used for overlaying static
jpeg images on top of a playing video.  Will this or something like it be
possible using eglvivsink?

2.)  When I was using mfw_isink, I noticed that their was a five second
buffer time between two consecutive pipelines.  What kind of delays can be
expected from eglvivsink?  On my x86_64 development desktop with
gstreamer-1.0.8 I am able to use features in playbin to seamlessly play
files back to back by changing the source URI.  Would this be possible
using the new framework?

Thank you for all the hard work,
Josh Kurland




On Mon, Dec 9, 2013 at 4:31 PM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

>  Try:  DISPLAY=:0 gst-launch-1.0 playbin uri=file:///myfilevideo-sink=eglvivsink
>
> This assumes you have X11 built and running on your machine.
> egvivsink support for Wayland and rendering to framebuffer will come in a
> later version.
> Please also check your CPU usage. If it is much higher with some videos,
> I'd like to know. There is one area where an unfortunate design limitation
> of the VPU libraries (and potentially the VPU itself) can cause this
> problem. I am thinking about workarounds, but its uncertain if it can be
> overcome. Worst case, some videos require tweaking of one GStreamer element
> property.
>
> cheers
>
>
> On 2013-12-09 22:26, Joshua Kurland wrote:
>
> Ah, okay.  Gst-inspect-1.0 now shows imxvpu, imxipu, etc.  In order to
> decode a simple video from a file, what would the new pipeline look like?
>  Normally I would run something like 'gst-launch-0.10 playbin2 uri=
> file:///myfile video-sink=mfw_v4lsink'.  Can I make a one-to-one
> conversion from the old mfw_v4lsink to some other custom element?
>
>
> On Mon, Dec 9, 2013 at 4:17 PM, Carlos Rafael Giani <dv@pseudoterminal.org
> > wrote:
>
>>  Thats because they have different names. They all start with "imx"
>> (with the exception of the eglvivsink).
>> These are entirely different plugins, written from scratch.
>>
>>
>> On 2013-12-09 22:14, Joshua Kurland wrote:
>>
>> Thanks Carlos, that script helped out a lot and I am able to compile the
>> binaries.  I modified your script to use the wandboard-quad sysroots and
>> ran the script.  I then ran ./waf and  sudo ./waf install.  I copied the
>> binaries from /usr/local/lib to my board in /usr/lib and
>> /usr/lib/gstreamer-1.0.  Everything seemed fine, but when I use
>> gst-inspect-1.0 to find mfw_v4lsink nothing is found.  The same can be said
>> for other Freescale elements that I had been using in Gstreamer-0.10.
>>
>>  Thanks,
>> Josh Kurland
>>
>>
>> On Mon, Dec 9, 2013 at 3:31 PM, Carlos Rafael Giani <
>> dv@pseudoterminal.org> wrote:
>>
>>> On 2013-12-09 21:05, Joshua Kurland wrote:
>>>
>>>> I am having a bit of difficulty compiling the gstreamer-imx binaries
>>>> using waf.  I set up the environment variables and ran waf, but it was
>>>> unable to find 'libfslvpuwrap'.  But  libfslvpuwrap.pc is found in my
>>>> sysroot/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/pkgconfig/libfslvpuwrap.pc.
>>>>  I am adding libfslvpuwrap as a package under the IMAGE_INSTALL section of
>>>> my image recipe, is this not the correct way?  I've attached my environment
>>>> script as well as the error log, I would appreciate any help I can get.
>>>>
>>>> Thanks,
>>>> Josh Kurland
>>>>
>>>>
>>>  The environment variables look wrong to me.
>>> 1. export
>>> CFLAGS="--sysroot=/opt/poky/1.5+gst/sysroots/x86_64-linux/usr/bin/cortexa9-vfp-neon-poky-linux-gnueabi"
>>> : sysroot is not supposed to point to the cross compiler directory, but to
>>> the sysroot of the *device* (same goes for the LDFLAGS, the
>>> PKG_CONFIG_SYSROOT_DIR, and the kernel headers path)
>>> 2. the "/build" part of the kernel headers path needs to be removed
>>> 3. do you use hardfloat or softfloat? In one place, you use cortexa9, in
>>> another, cortexa9hf
>>>
>>> I attached an example script that may be clearer (at successfully builds
>>> the plugins). It builds for the Sabre SD DualLite platform.
>>>
>>> cheers
>>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 8398 bytes --]

Re: Regarding GStreamer-1.x status on iMX6Q

[Carlos Rafael Giani]

On 2013-12-10 19:52, Joshua Kurland wrote:
> I think the problem I am having is because of the X11 requirement. 
>  Without it, running a simple pipeline using eglvivsink immediately 
> crashes.  Is it possible to run without X?  I don't currently use it 
> on my system.  I will have to try again with X running on a new build 
> later today, but until I get that working would you mind if I ask you 
> a few more questions?

Not yet. It is on my list. For the time being, you can try out 
imxipusink instead. Please note that this sink has one known problem 
(due to an IPU limitation) and does not work well together with X11 
(both render to the framebuffer). But for testing and debugging 
purposes, it should work fine.

> 1.)  The project I have been working on made use of the multi overlay 
> support from mfw_isink.  Specifically it was used for overlaying 
> static jpeg images on top of a playing video.  Will this or something 
> like it be possible using eglvivsink?

How exactly did you use this? I am not that familiar with this feature. 
mfw_isink is similar to imxipusink though, so I suppose it could work.

> 2.)  When I was using mfw_isink, I noticed that their was a five 
> second buffer time between two consecutive pipelines.  What kind of 
> delays can be expected from eglvivsink?  On my x86_64 development 
> desktop with gstreamer-1.0.8 I am able to use features in playbin to 
> seamlessly play files back to back by changing the source URI.  Would 
> this be possible using the new framework?

Five seconds? Hm, thats not what I saw. I didn't run such tests yet, but 
I suspect the buffer time should be shorter. Seamless playback should 
also work. Did this only happen with mfw_isink ? Note that playbin 
itself also has several buffers and queues, which have nothing to do 
with the sink you use.

Also, be careful about interlaced video. While the IPU can deinterlace - 
and it is strongly recommended to do so instead of deinterlacing in 
software, at least for real-time playback - playbin currently has the 
software deinterlacer hardcoded. I talked with GStreamer developers 
about this, and they are thinking about a way to plug in custom 
deinterlacers, color space converters etc. For now, I have an idea I 
didnt have the chance to test yet if you use eglvivsink: specify 
"imxipuvideotransform ! eglvivsink" . If you use the imxipusink instead, 
you don't have to do any of this, because the deinterlacing is included.

cheers

Re: Regarding GStreamer-1.x status on iMX6Q

[Joshua Kurland]

[-- Attachment #1: Type: text/plain, Size: 3348 bytes --]

On Tue, Dec 10, 2013 at 2:01 PM, Carlos Rafael Giani
<dv@pseudoterminal.org>wrote:

> On 2013-12-10 19:52, Joshua Kurland wrote:
>
>> I think the problem I am having is because of the X11 requirement.
>>  Without it, running a simple pipeline using eglvivsink immediately
>> crashes.  Is it possible to run without X?  I don't currently use it on my
>> system.  I will have to try again with X running on a new build later
>> today, but until I get that working would you mind if I ask you a few more
>> questions?
>>
>
> Not yet. It is on my list. For the time being, you can try out imxipusink
> instead. Please note that this sink has one known problem (due to an IPU
> limitation) and does not work well together with X11 (both render to the
> framebuffer). But for testing and debugging purposes, it should work fine.
>
> Great, I will give imxipusink a try.  I am on the Wandboard-Quad, so I
want to confirm that my problems are with X11 and not something deeper.

>
>  1.)  The project I have been working on made use of the multi overlay
>> support from mfw_isink.  Specifically it was used for overlaying static
>> jpeg images on top of a playing video.  Will this or something like it be
>> possible using eglvivsink?
>>
>
> How exactly did you use this? I am not that familiar with this feature.
> mfw_isink is similar to imxipusink though, so I suppose it could work.
>
> This document has some information about multioverlay
https://community.freescale.com/docs/DOC-93788.  Essentially it allows
multiple isink elements to be created at the same time.  To use it with a
jpeg, link the jpeg source with the jpegdec element, imagefreeze and
mfw_isink.

>
>  2.)  When I was using mfw_isink, I noticed that their was a five second
>> buffer time between two consecutive pipelines.  What kind of delays can be
>> expected from eglvivsink?  On my x86_64 development desktop with
>> gstreamer-1.0.8 I am able to use features in playbin to seamlessly play
>> files back to back by changing the source URI.  Would this be possible
>> using the new framework?
>>
>
> Five seconds? Hm, thats not what I saw. I didn't run such tests yet, but I
> suspect the buffer time should be shorter. Seamless playback should also
> work. Did this only happen with mfw_isink ? Note that playbin itself also
> has several buffers and queues, which have nothing to do with the sink you
> use.
>
> Yep, I had five seconds regardless of the video quality, overlays, etc.
 It was only with mfw_isink, mfw_v4lsink had a short delay of less than a
second without me having to do anything to it.


> Also, be careful about interlaced video. While the IPU can deinterlace -
> and it is strongly recommended to do so instead of deinterlacing in
> software, at least for real-time playback - playbin currently has the
> software deinterlacer hardcoded. I talked with GStreamer developers about
> this, and they are thinking about a way to plug in custom deinterlacers,
> color space converters etc. For now, I have an idea I didnt have the chance
> to test yet if you use eglvivsink: specify "imxipuvideotransform !
> eglvivsink" . If you use the imxipusink instead, you don't have to do any
> of this, because the deinterlacing is included.
>

Thanks for the heads up on that one!

>
> cheers
>

[-- Attachment #2: Type: text/html, Size: 5117 bytes --]