[meta-freescale] Regarding GStreamer-1.x status on iMX6Q
Carlos Rafael Giani
dv at pseudoterminal.org
Wed Nov 20 10:52:21 PST 2013
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
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):
The produced binaries are:
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:
> 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 at pseudoterminal.org <mailto:dv at 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?
>> Josh Kurland
>> On Mon, Nov 18, 2013 at 11:54 AM, Carlos Rafael Giani
>> <dv at pseudoterminal.org <mailto:dv at 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 at adtecdigital.net
>> <mailto:joshua.kurland at 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the meta-freescale