From: Chris Tapp <opensource@keylevel.com>
To: John Weber <rjohnweber@gmail.com>
Cc: meta-freescale@yoctoproject.org
Subject: Re: Gstreamer pipeline problem
Date: Fri, 12 Jul 2013 17:44:41 +0100 [thread overview]
Message-ID: <FA6C61AE-21EC-4DA9-BD68-4C73B59DF554@keylevel.com> (raw)
In-Reply-To: <51E00ECB.5090507@gmail.com>
Hi John,
On 12 Jul 2013, at 15:12, John Weber wrote:
> Hi Chris,
>
>> That's unfortunate as I need a pipeline which can run on many different platforms, including 'standard pc'. This was one reason why I was using fakesink to capture the images - v4l looked like a way to go so that I could stream the video direct to the screen and get the full benefits of any acceleration supported by a platform (zero copy, etc.).
>>
>
> I think you will probably need to build an application that creates a pipeline based on the host. For example, a desktop system probably will not have much use for V4L output devices, so they might not use v4l2sink but autovideosink. On a i.MX6 for example, you'll want to use mfw_v4lsink, which as I understand it does take advantage of some of the built-in acceleration.
>
> Also, for video decoding (H.264 decompression I mean), you'll want to change the element you use there as well. For i.MX6 this is vpudec, but for general purpose there is x264dec (think that is the name but not sure).
Yes, that's one of the reasons I've been using playbin2 and fakesink. I'm hoping that playbin will build a decent decode pipeline and I can then use the frames in fakesink to create an OpenGLES texture which I can render in my app. This also gives a portable way of rendering the video where I want, at the size I need and without and decoration.
I was hoping that glupload may help make this more efficient, but I can't even get gst-plugins-gl to build at the moment.
Chris Tapp
opensource@keylevel.com
www.keylevel.com
next prev parent reply other threads:[~2013-07-12 16:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-10 19:19 Gstreamer pipeline problem Chris Tapp
2013-07-10 19:53 ` Chris Tapp
2013-07-11 8:39 ` Thomas Senyk
2013-07-11 23:22 ` Chris Tapp
2013-07-12 0:22 ` John Weber
2013-07-12 7:50 ` Chris Tapp
2013-07-12 8:03 ` Philip Craig
2013-07-12 8:19 ` Chris Tapp
2013-07-12 14:12 ` John Weber
2013-07-12 16:44 ` Chris Tapp [this message]
2013-07-15 8:02 ` Thomas Senyk
2013-07-15 16:42 ` Chris Tapp
2013-07-12 16:35 ` Chris Tapp
2013-07-15 8:24 ` Thomas Senyk
2013-07-15 16:41 ` Chris Tapp
2013-07-15 17:11 ` Thomas Senyk
2013-07-15 20:58 ` Chris Tapp
2013-07-16 19:15 ` vpudec doe not like "queue(2)" - Was: " Chris Tapp
2013-07-16 20:18 ` John Weber
2013-07-17 19:57 ` Chris Tapp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FA6C61AE-21EC-4DA9-BD68-4C73B59DF554@keylevel.com \
--to=opensource@keylevel.com \
--cc=meta-freescale@yoctoproject.org \
--cc=rjohnweber@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.