gstreamer-embedded — GStreamer on embedded platforms

Re: [gst-embedded] aacparse and amrparse license in gst-plugin-bad

[LIANG Z. <e3...@mo...>]

Yes, I agree, but gst-plugin-base and gst-plugin-good can be considered as
"safety" in practice?

2010/4/25 Stefan Kost <en...@ho...>

> Am 22.04.2010 04:31, schrieb LIANG ZHAO:
> > Thanks Stefan.
> >
> > I am not familiar with OSS license, but I know the LGPL has
> > "Redistribute" feature. That means if some commercial products have
> > integrated it, we can use it freely and safety according "Redistribute".
> >
> > By my search on google, I find maemo5 and Fedora have integrated
> > gst-plugin-bad, so by my understanding, it should be ok for me too on
> > gst-plugin-bad.
> >
> > From gstreamer website, it describes gst-plugin-bad not like
> > gst-plugin-ugly.
> >
> > "GStreamer Ugly Plug-ins is a set of plug-ins that have good quality and
> > correct functionality, but distributing them might pose problems. The
> > license on either the plug-ins or the supporting libraries might not be
> > how we'd like. The code might be widely known to present patent problems.
>  "
> >
> > " GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par
> > compared to the rest. They might be close to being good quality, but
> > they're missing something - be it a good code review, some
> > documentation, a set of tests, a real live maintainer, or some actual
> > wide use. "
> >
> > Seems gst-plugin-bad has no license issues but not good quality than
> > gst-plugin-ugly.
>
> gst-plugin-bad can have both license and/or quality issues. Anyway if you
> want
> to use those plugins in a commerical product review the code with IPR/Legal
> persons - it is not only the license that matters.
>
> Stefan
>
>
> >
> >
> > 2010/4/21 Stefan Kost <en...@ho...
> > <mailto:en...@ho...>>
> >
> >     Liang Zhao wrote:
> >     > Hi,
> >     >
> >     > Could someone help me on aacparse and amrparse license in
> >     > gst-plugin-bad? I want to integrate these 2 elements into our
> product,
> >     > but I don't know whether the LGPL is the license issue?
> >
> >     You find the lices stated in the plugin and also at thye top of the
> >     source files. It is up to you to decide wheter LGPL is fine for you
> >     or not.
> >     >
> >     > I find in maemo5 SDK ARMEL binary, they are integrated into it, and
> >     > marked as LGPL, does that mean I can use it freely and safely on
> law?
> >     > I also find no mp3parse and asfdemux in it, does that mean it is
> have
> >     > issues on the LGPL license? or I need to re-implement it with
> >     > proprietary license.
> >     mp3parse should be fine as LGPLK and should be moved out
> >     gst-plugins-ugly. for asf you find licese details on microsoft
> webpages.
> >
> >     Stefan
> >
> >     >
> >     > Thanks
> >     >
> >     > --
> >     > BRs.
> >     > Zhao Liang
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     >
> >
> ------------------------------------------------------------------------------
> >     >
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     > _______________________________________________
> >     > Gstreamer-embedded mailing list
> >     > Gst...@li...
> >     <mailto:Gst...@li...>
> >     > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >     >
> >
> >
> >
> ------------------------------------------------------------------------------
> >     _______________________________________________
> >     Gstreamer-embedded mailing list
> >     Gst...@li...
> >     <mailto:Gst...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> >
> >
> >
> > --
> > Zhao Liang
> >
> > No.1 Wang Jing East Road Chao Yang District
> > Beijing, 100102 China
> > +86-10-84733698
>
>


-- 
Zhao Liang

No.1 Wang Jing East Road Chao Yang District
Beijing, 100102 China
+86-10-84733698

Re: [gst-embedded] aacparse and amrparse license in gst-plugin-bad

[Stefan K. <en...@ho...>]

Am 22.04.2010 04:31, schrieb LIANG ZHAO:
> Thanks Stefan.
> 
> I am not familiar with OSS license, but I know the LGPL has
> "Redistribute" feature. That means if some commercial products have
> integrated it, we can use it freely and safety according "Redistribute".
> 
> By my search on google, I find maemo5 and Fedora have integrated
> gst-plugin-bad, so by my understanding, it should be ok for me too on
> gst-plugin-bad.
> 
> From gstreamer website, it describes gst-plugin-bad not like
> gst-plugin-ugly.
> 
> "GStreamer Ugly Plug-ins is a set of plug-ins that have good quality and
> correct functionality, but distributing them might pose problems. The
> license on either the plug-ins or the supporting libraries might not be
> how we'd like. The code might be widely known to present patent problems.  "
> 
> " GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par
> compared to the rest. They might be close to being good quality, but
> they're missing something - be it a good code review, some
> documentation, a set of tests, a real live maintainer, or some actual
> wide use. "
> 
> Seems gst-plugin-bad has no license issues but not good quality than
> gst-plugin-ugly.

gst-plugin-bad can have both license and/or quality issues. Anyway if you want
to use those plugins in a commerical product review the code with IPR/Legal
persons - it is not only the license that matters.

Stefan


> 
> 
> 2010/4/21 Stefan Kost <en...@ho...
> <mailto:en...@ho...>>
> 
>     Liang Zhao wrote:
>     > Hi,
>     >
>     > Could someone help me on aacparse and amrparse license in
>     > gst-plugin-bad? I want to integrate these 2 elements into our product,
>     > but I don't know whether the LGPL is the license issue?
> 
>     You find the lices stated in the plugin and also at thye top of the
>     source files. It is up to you to decide wheter LGPL is fine for you
>     or not.
>     >
>     > I find in maemo5 SDK ARMEL binary, they are integrated into it, and
>     > marked as LGPL, does that mean I can use it freely and safely on law?
>     > I also find no mp3parse and asfdemux in it, does that mean it is have
>     > issues on the LGPL license? or I need to re-implement it with
>     > proprietary license.
>     mp3parse should be fine as LGPLK and should be moved out
>     gst-plugins-ugly. for asf you find licese details on microsoft webpages.
> 
>     Stefan
> 
>     >
>     > Thanks
>     >
>     > --
>     > BRs.
>     > Zhao Liang
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Gstreamer-embedded mailing list
>     > Gst...@li...
>     <mailto:Gst...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>     >
> 
> 
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Gstreamer-embedded mailing list
>     Gst...@li...
>     <mailto:Gst...@li...>
>     https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> 
> 
> 
> 
> -- 
> Zhao Liang
> 
> No.1 Wang Jing East Road Chao Yang District
> Beijing, 100102 China
> +86-10-84733698

[gst-embedded] How to play youtube video by gst-launch

[Yang F. <fel...@ho...>]

Dear All:

    Cound anybody tell me how to play youtube video by using gst-launch?
 If it is possible, give me a example plese. Thanks 		 	   		  
_________________________________________________________________
Hotmail 強大的垃圾信件管理功能，值得你信賴。
https://signup.live.com/signup.aspx?id=60969

Re: [gst-embedded] GStreamer on mobile devices and "out of memory" handling

[Stefan K. <en...@ho...>]

hi,

Martin Olsson wrote:
> Hi,
>
> I'm aware of the sane arguments for not adding explicit OOM handling to most apps (i.e. http://0pointer.de/blog/projects/on-oom.html etc).
> However, I'm working with various mobile devices, sometimes with no virtual memory or peculiar OOM killers. Further, my app is the "main application" on the device
> meaning that if it's killed there is no more GUI making a reboot the only way out. So I need to handle OOM gracefully in this app and I have
> good mechanisms for doing that.
>
> I'm looking for a video/audio playback solution for this application and I'd love to use GStreamer, and ideally without maintaining a GStreamer/GLib
> fork so I'd like to avoid making changes to g_malloc etc.
>
> Has anything like this been done before? Is there any GStreamer forks for mobile devices? Is there any other media playback framework that is
> more suited for mobile devices? Can you recommend any particular approach to this problem?
>   
What we do in gstreamer for it is to use g_try_malloc when doing
allocations where the size is based on input data. There might be places
where this is not done. Also objects are allocated using g_slice and
would terminate the app if you run out of memory.

If you get termination on low memory, it would be a good idea to check
the backtrace and file a bug if the code is using g_malloc for data.

Stefan

> So far what I was thinking was maybe I could use setjmp/longjmp to jump out of a modified g_malloc up through the stack to the point where my
> application calls into GStreamer but this of course requires changes to g_malloc (though maybe not so big changes).
>
>
>
> 		Martin
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>   

Re: [gst-embedded] aacparse and amrparse license in gst-plugin-bad

[LIANG Z. <e3...@mo...>]

Thanks Stefan.

I am not familiar with OSS license, but I know the LGPL has "Redistribute"
feature. That means if some commercial products have integrated it, we can
use it freely and safety according "Redistribute".

By my search on google, I find maemo5 and Fedora have integrated
gst-plugin-bad, so by my understanding, it should be ok for me too on
gst-plugin-bad.

>From gstreamer website, it describes gst-plugin-bad not like
gst-plugin-ugly.

"GStreamer Ugly Plug-ins is a set of plug-ins that have good quality and
correct functionality, but distributing them might pose problems. The
license on either the plug-ins or the supporting libraries might not be how
we'd like. The code might be widely known to present patent problems.  "

" GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared
to the rest. They might be close to being good quality, but they're missing
something - be it a good code review, some documentation, a set of tests, a
real live maintainer, or some actual wide use. "

Seems gst-plugin-bad has no license issues but not good quality than
gst-plugin-ugly.


2010/4/21 Stefan Kost <en...@ho...>

> Liang Zhao wrote:
> > Hi,
> >
> > Could someone help me on aacparse and amrparse license in
> > gst-plugin-bad? I want to integrate these 2 elements into our product,
> > but I don't know whether the LGPL is the license issue?
>
> You find the lices stated in the plugin and also at thye top of the
> source files. It is up to you to decide wheter LGPL is fine for you or not.
> >
> > I find in maemo5 SDK ARMEL binary, they are integrated into it, and
> > marked as LGPL, does that mean I can use it freely and safely on law?
> > I also find no mp3parse and asfdemux in it, does that mean it is have
> > issues on the LGPL license? or I need to re-implement it with
> > proprietary license.
> mp3parse should be fine as LGPLK and should be moved out
> gst-plugins-ugly. for asf you find licese details on microsoft webpages.
>
> Stefan
>
> >
> > Thanks
> >
> > --
> > BRs.
> > Zhao Liang
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Gstreamer-embedded mailing list
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>



-- 
Zhao Liang

No.1 Wang Jing East Road Chao Yang District
Beijing, 100102 China
+86-10-84733698

Re: [gst-embedded] aacparse and amrparse license in gst-plugin-bad

[Stefan K. <en...@ho...>]

Liang Zhao wrote:
> Hi,
>
> Could someone help me on aacparse and amrparse license in
> gst-plugin-bad? I want to integrate these 2 elements into our product,
> but I don't know whether the LGPL is the license issue?

You find the lices stated in the plugin and also at thye top of the
source files. It is up to you to decide wheter LGPL is fine for you or not.
>
> I find in maemo5 SDK ARMEL binary, they are integrated into it, and
> marked as LGPL, does that mean I can use it freely and safely on law?
> I also find no mp3parse and asfdemux in it, does that mean it is have
> issues on the LGPL license? or I need to re-implement it with
> proprietary license.
mp3parse should be fine as LGPLK and should be moved out
gst-plugins-ugly. for asf you find licese details on microsoft webpages.

Stefan

>
> Thanks
>
> -- 
> BRs.
> Zhao Liang
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gstreamer-embedded mailing list
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>   

[gst-embedded] aacparse and amrparse license in gst-plugin-bad

[Liang Z. <lia...@gm...>]

Hi,

Could someone help me on aacparse and amrparse license in gst-plugin-bad? I
want to integrate these 2 elements into our product, but I don't know
whether the LGPL is the license issue?

I find in maemo5 SDK ARMEL binary, they are integrated into it, and marked
as LGPL, does that mean I can use it freely and safely on law?
I also find no mp3parse and asfdemux in it, does that mean it is have issues
on the LGPL license? or I need to re-implement it with proprietary license.

Thanks

-- 
BRs.
Zhao Liang

Re: [gst-embedded] Play 2 mp3 file at same time.

[Paul F. <pa...@xp...>]

2010/4/20 Giorgio Marinangeli <gi...@ma...>:
> //
> // link the elements together
> //
>
> gst_element_link_many (source1, decoder1, conv1, source2, decoder2,
> conv2, adder, sink, NULL);

> I can compile the program but I can't play any one mp3 file with this
> pipeline.
>
> How Can I link the element in my code to add an ADDER element before the
> sink element?

You need to link the elements properly. gst_element_link_many connects
the elements like a chain. In your example the following pipeline will
be created:

source1 -> decoder1 -> conv1 -> source2 -> decoder2 -> conv2 -> adder -> sink

That does obviously not work. I would think that using two link calls
should do the trick:

gst_element_link_many (source1, decoder1, conv1, adder, sink, NULL);
gst_element_link_many(source2, decoder2, conv2, adder, NULL);

The first call builds the following pipeline:

source1 -> decoder1 -> conv1 -> adder ->sink

While the second call results in the following pipeline:

source1 -> decoder1 -> conv1 ->
                                                        adder -> sink
source2 -> decoder2 -> conv2 ->

Which is the pipeline you are expecting.

Hope it works.

Cheers,
Paul

Re: [gst-embedded] Play 2 mp3 file at same time.

[Paul F. <pa...@xp...>]

2010/4/20 giorgio <gi...@ke...>:
> So I think the only way to play two differetne mp3 at same time for my
> hardware is to realize a pipe line with an aggregator ( or audio
> Mixer) .
>
> Src -> Decode ->\
>                 ----> AGGREGATOR -> AUDIO SINK
> Src -> Decode ->/
>
> Someone could explain me, how to realize a similar pipe line?
> How can I create an Aggregator ( or Audio mixer) element?
> Is Agregator a factory standard element provided with gstream
> framework?.

The "adder" element does exactly what you want. A little example:

gst-launch filesrc location=file1.mp3 ! mp3parse ! mad name=stream1 \
filesrc location=file2.mp3 ! mp3parse ! mad name=stream2 ! adder
name=adder ! alsasink \
stream1. ! adder.

Cheers,
Paul

[gst-embedded] Play 2 mp3 file at same time.

[giorgio <gi...@ke...>]

Hi, 
I would like to play 3 Mp3 file at same time using a gStreamer
framework.

I tried to  create two different pipe line with different sounce and the
same audio sink but my audio sound driver dosen't permit to open two
different audio channel at same time.
So I can get playng only the first pipe line.
src1 --> decode1 --> audio sunk
src2 --> decode2 --> audio sink

So I think the only way to play two differetne mp3 at same time for my
hardware is to realize a pipe line with an aggregator ( or audio
Mixer) .

Src -> Decode ->\
                 ----> AGGREGATOR -> AUDIO SINK
Src -> Decode ->/

Someone could explain me, how to realize a similar pipe line?
How can I create an Aggregator ( or Audio mixer) element?
Is Agregator a factory standard element provided with gstream
framework?.

Tanks. 

[gst-embedded] GStreamer on mobile devices and "out of memory" handling

[Martin O. <mn...@mi...>]

Hi,

I'm aware of the sane arguments for not adding explicit OOM handling to most apps (i.e. http://0pointer.de/blog/projects/on-oom.html etc).
However, I'm working with various mobile devices, sometimes with no virtual memory or peculiar OOM killers. Further, my app is the "main application" on the device
meaning that if it's killed there is no more GUI making a reboot the only way out. So I need to handle OOM gracefully in this app and I have
good mechanisms for doing that.

I'm looking for a video/audio playback solution for this application and I'd love to use GStreamer, and ideally without maintaining a GStreamer/GLib
fork so I'd like to avoid making changes to g_malloc etc.

Has anything like this been done before? Is there any GStreamer forks for mobile devices? Is there any other media playback framework that is
more suited for mobile devices? Can you recommend any particular approach to this problem?

So far what I was thinking was maybe I could use setjmp/longjmp to jump out of a modified g_malloc up through the stack to the point where my
application calls into GStreamer but this of course requires changes to g_malloc (though maybe not so big changes).



		Martin

Re: [gst-embedded] Need Help On gst-omapfb built from openembedded

[Arnout V. <ar...@mi...>]

On Friday 02 April 2010 06:41:12, Tejas wrote:
> Now I would like to make it work into playbin architecture. But in
> playbin it is calling ffmpegcolorspace and other Plugins. Is it possible
> I can remove videoscale and ffmpegcolorspace from that  pipeline ?

 Set the native-video flag in the flags property of playbin2.  Or if you're 
using the old playbin: don't use playbin, use playbin2 :-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[gst-embedded] Cross compiling error for gst-plugins-good-0.10.17

[Ratheendran R <rat...@gm...>]

Hi All,

I am cross compiling GStreamer for embedded application,I have
successfully cross compiled glib, gstreamer,gst-plugins-base, However
I get the below error on compiling gst-plugins-good-0.10.17.

/*******************************Error Message
Start***********************************************/
Failed to load source "xml::/etc/gconf/gconf.xml.schemas": Failed:
Couldn't locate backend module for `xml::/etc/gconf/gconf.xml.schemas'

GConf-ERROR **: file gconftool.c: line 918 (main): assertion failed:
(err == NULL)
aborting...
/bin/sh: line 5:  4802 Aborted
GCONF_CONFIG_SOURCE=xml::/etc/gconf/gconf.xml.schemas
/usr/bin/gconftool-2 --makefile-install-rule ./gstreamer-0.10.schemas

*****************************************************
Installation of schemas failed, install them manually
*****************************************************
 /usr/bin/install -c -m 644 gstreamer-0.10.schemas '/opt/gst/etc/gconf/schemas'


Since I am new in this domain,Can any one suggest how this can be fixed.

Thanks and Regards,
Ratheendran

[gst-embedded] Need Help On gst-omapfb built from openembedded

[Tejas <te...@pi...>]

Hello All/Arnout Vandecappelle,

               First of all I am really sorry for creating new chain of
mail. My system crashes and I could not take any back up of previous mails.


 

As last discussed by Arnout , I found that my decoder was allocating memory
for internal buffers with g_malloc and at the time of pushing buffer I
allocated buffer with buffer alloc of omapfbsink of the size (width * height
* 3/2). That memory is allocated from buffer_alloc of omapfbsink. But I was
pushing buffer of my internal decoder. So I was doing mistakes at that side
and I improve allocation buffers. So now my following pipeline is working
fine and no memcpy is called in between.

 

$gst-launch-0.10 filesrc location=1.flv ! myparser  ! mydecoder !
omapfbsink. 

 

Now I would like to make it work into playbin architecture. But in playbin
it is calling ffmpegcolorspace and other Plugins. Is it possible I can
remove videoscale and ffmpegcolorspace from that  pipeline ? 

 

 

-Tejas.

Re: [gst-embedded] Need Help On gst-omapfb built from openembedded

[Arnout V. <ar...@mi...>]

 omapfbsink requires a chunk of memory that is accessible by the video 
hardware.  It allocates one of those in omapfbsink->buffer.  It also has a 
specific buffer_alloc function, so that upstream elements can write directly 
into this memory area.

 If the memcpy is still taking place (have you verified that it is?), it 
means that the upstream element is not using the buffer_alloc function.  I 
can think of two things that could go wrong.

- The upstream element is a queue: because of the queue, more than one 
buffer will be allocated by the upstream element.  However, the omapfbsink 
has only one hardware-accelerated buffer, so the other ones will use a 
normal malloc.

- The upstream element is something like a TIViddec.  Although these 
elements are supposed to accelerate the video encoding/decoding, the 
implementation is slightly braindead and introduces a lot of memcpy's.  More 
specifically, it allocates a hardware-accelerated buffer itself, but 
omapfbsink doesn't understand that it's hardware-accelerated so goes on 
memcpy-ing.


 In this particular case, I think there's an easy work-around.  (Warning: I 
haven't verified that this will work!)  The only constraint that the video 
hardware really has is that the buffer must be aligned at a 32-byte 
boundary, IIRC.  So, you can replace the condition

if(data != omapfbsink->buffer && ...)

with

if ((data & 0x1F) != 0)  /* Must be aligned on 32-byte boundary */

to make sure the memcpy is only done if it's not already aligned.  Then, use 
the patch in https://bugzilla.gnome.org/show_bug.cgi?id=596832 to make sure 
that most allocations are aligned (configure gstreamer core with --with-
buffer-alignment=32).


 Let me know if this helps :-)

 Regards,
 Arnout

On Saturday 27 March 2010 10:33:48, Tejas wrote:
> Hello All,
> 
>                Is it possible to pass decoder output buffer directly to
> color conversion routine. The snap shot of render function is as
> followed.
> 
> 
> 
> static GstFlowReturn
> 
> render (GstBaseSink * bsink, GstBuffer * buf)
> 
> {
> 
>     int i, w, h;
> 
>     GstOmapFbSink *omapfbsink = GST_OMAPFB_SINK(bsink);
> 
>     __uint8_t *fb = omapfbsink->framebuffer, *data =
> GST_BUFFER_DATA(buf);
> 
>        long iTime=0;
> 
>    struct timeval tempo1, tempo2;
> 
> 
> 
>     if(omapfbsink->plane_info.enabled == 2)
> 
>     {
> 
>         omapfbsink->plane_info.enabled = 1;
> 
> 
> 
>         g_mutex_lock (omapfbsink->x_lock);
> 
>         gst_omapfbsink_update_plane(omapfbsink);
> 
>         g_mutex_unlock (omapfbsink->x_lock);
> 
>     }
> 
> 
> 
>     g_print("\n Address in render function = %x\n", (unsigned
> int)GST_BUFFER_DATA(buf));
> 
>     /* If a buffer which wasn't supplied by us is given to us to render
> with,
> 
>        we need to copy to our buffer first so that memory alignment
> constraints
> 
>        are met. */
> 
> 
> 
>     if(data != omapfbsink->buffer && GST_BUFFER_SIZE(buf) <=
> omapfbsink->buffer_size)
> 
>     {
> 
>         memcpy(omapfbsink->buffer, data, GST_BUFFER_SIZE(buf));
> 
>         data = omapfbsink->buffer;
> 
>     }
> 
> 
> 
>     /* buffer_alloc gave a direct buffer, so we have nothing to
> 
>        do here... */
> 
>     if(omapfbsink->row_skip)
> 
>         return GST_FLOW_OK;
> 
> 
> 
>     switch(omapfbsink->image_format) {
> 
>         case GST_MAKE_FOURCC('I', '4', '2', '0'):
> 
>             /* Convert to YUV422 and send to FB */
> 
> 
> 
>             h = GST_VIDEO_SINK_HEIGHT (omapfbsink);
> 
>             w = GST_VIDEO_SINK_WIDTH (omapfbsink);
> 
> 
> 
>             __uint8_t *y, *u, *v;
> 
>             y = data;
> 
>             u = y + w * h;
> 
>             v = u + w / 2 * h / 2;
> 
> 
> 
>             yuv420_to_yuv422(fb, y, u, v, w & ~15, h, w, w / 2,
> omapfbsink->fixinfo.line_length);
> 
>             break;
> 
> 
> 
>         case GST_MAKE_FOURCC('U', 'Y', 'V', 'Y'):
> 
>             /* Send to FB, taking into account line_length */
> 
> 
> 
>             w = 2 * GST_VIDEO_SINK_WIDTH (omapfbsink);
> 
>             for(i = 0; i < GST_VIDEO_SINK_HEIGHT (omapfbsink); i++)
> 
>             {
> 
>                 memcpy(fb, data, w);
> 
> 
> 
>                 fb += omapfbsink->fixinfo.line_length;
> 
>                 data += w;
> 
>             }
> 
> 
> 
>             break;
> 
>     }
> 
> 
> 
>     return GST_FLOW_OK;
> 
> }
> 
>                Here buf which is passed is my decoder output buffer
> having size = (width * height *1.5). I would like to replace memcpy
> seprated by blue color in above function. Is there any possibility to
> assign buf pointer directly to Y pointer which later go to color
> conversion.
> 
> 
> 
>                I am laking of some understanding of buffer_alloc of base
> sink. If any where I am wrong please correct me and try to guide me in
> right direction. In other way I was thinking to use dma transfer, but I
> am completely new for dma and will take much time to understand and
> write transfer function. If I can get some other solution, will be
> helpful in my project.
> 
> 
> 
> -Tejas.
> 
> 
> 
> 
> 
> From: Tejas [mailto:te...@pi...]
> Sent: Friday, March 26, 2010 3:33 PM
> To: 'gst...@li...'
> Subject: Need Help On gst-omapfb built from openembedded
> 
> 
> 
> Hello All,
> 
>                I am using gst-omapfb plugin built from openembedded which
> contains X-overlay patch on normal omapfb plugin as my video sink. My
> normal pipeline is as followed.
> 
> 
> 
> 
> 
> $gst-launch-0.10 filesrc location=1.mp4 ! myparser ! mydecoder !
> omapfbsink.
> 
> 
> 
> Src pad of my decoder is set as following caps .
> 
> 
> 
> ("video/x-raw-yuv",
> 
>  "width", G_TYPE_INT, mpeg4dec->info.width,
> 
> "height", G_TYPE_INT, mpeg4dec->info.height,
> 
> "framerate", GST_TYPE_FRACTION, mpeg4dec->fps_nu, mpeg4dec->fps_de,
> 
> "format", GST_TYPE_FOURCC, GST_MAKE_FOURCC ('I', '4', '2', '0'),
> 
> "pixel-aspect-ratio", GST_TYPE_FRACTION,1,1,i NULL);
> 
> 
> 
>                Omapfbsink will accept I420 format and convert it to UYVY
> format  and copy it to frame buffer. In these all process it is using
> memcpy which copy data from buffer pushed from my decoder to buffer
> allocated locally. Here in omapfbsink memcpy is time consuming. Instead
> of using memcpy I would like to use some other method. But I am getting
> how can I replace memcpy.
> 
> 
> 
>                If anyone can guide me to replace memcpy, I will be
> pleasure for me.
> 
> 
> 
> 
> 
> -Tejas.

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

Re: [gst-embedded] scracthbox2 Gstreamer cross compilation issues

[Felipe C. <fel...@gm...>]

On Sat, Mar 27, 2010 at 8:37 PM, Ratheendran R <rat...@gm...> wrote:
> Hi All,
>
> I am trying to use Gstreamer for mini2440 and using
> arm-linux-gcc-4.3.2.tgz as the cross compiler.
>
> I followed this blog
> http://felipec.wordpress.com/2009/06/07/installing-scratchbox-1-and-2-for-arm-cross-compilation/
>  for scratchbox2 installation I made only changes in the cross
> compiler’s path.the changes are as below.
>
> QEMU
>
> sb2 doesn't include QEMU, you must have it already, this is how I compile it:
> git clone git://git.savannah.nongnu.org/qemu.git
> cd qemu
> git checkout -b stable v0.10.5
> ./configure --prefix=/opt/qemu --target-list=arm-linux-user
> make install
>
> sbox2
>
> Compile and install like this:
> git clone git://anongit.freedesktop.org/git/sbox2
> cd sbox2
> ./configure --prefix=/opt/sb2
> make install
>
> Add sb2 to the PATH:
> export PATH=/opt/sb2/bin:$PATH
>
>  target
>
> I am using arm-linux-gcc-4.3.2.tgz installed in this path '/usr/local/arm/4.3.2'
>
> cd /usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/
> sb2-init -c /opt/qemu/bin/qemu-arm armv4t
> /usr/local/arm/4.3.2/bin/arm-none-linux-gnueabi-gcc
>
> where ‘/usr/local/arm/’ is the path of cross compiler.
>
> Now when I cross compile Gstreamer,it is compiled using some different
> compiler.this is conclution I have drawn as we run gst-inspect I get
> the below message.
> [root@Hiteg bin]# ./gst-inspect
> Illegal instruction
>
> kindly Guide me in fixing this issue.

Have you tried to cross-compile a minimal test both inside and outside
scratchbox? Something like 'int main(void) { return 0; }'.

Cheers.

-- 
Felipe Contreras

[gst-embedded] scracthbox2 Gstreamer cross compilation issues

[Ratheendran R <rat...@gm...>]

Hi All,

I am trying to use Gstreamer for mini2440 and using
arm-linux-gcc-4.3.2.tgz as the cross compiler.

I followed this blog
http://felipec.wordpress.com/2009/06/07/installing-scratchbox-1-and-2-for-arm-cross-compilation/
 for scratchbox2 installation I made only changes in the cross
compiler’s path.the changes are as below.

QEMU

sb2 doesn't include QEMU, you must have it already, this is how I compile it:
git clone git://git.savannah.nongnu.org/qemu.git
cd qemu
git checkout -b stable v0.10.5
./configure --prefix=/opt/qemu --target-list=arm-linux-user
make install

sbox2

Compile and install like this:
git clone git://anongit.freedesktop.org/git/sbox2
cd sbox2
./configure --prefix=/opt/sb2
make install

Add sb2 to the PATH:
export PATH=/opt/sb2/bin:$PATH

 target

I am using arm-linux-gcc-4.3.2.tgz installed in this path '/usr/local/arm/4.3.2'

cd /usr/local/arm/4.3.2/arm-none-linux-gnueabi/libc/
sb2-init -c /opt/qemu/bin/qemu-arm armv4t
/usr/local/arm/4.3.2/bin/arm-none-linux-gnueabi-gcc

where ‘/usr/local/arm/’ is the path of cross compiler.

Now when I cross compile Gstreamer,it is compiled using some different
compiler.this is conclution I have drawn as we run gst-inspect I get
the below message.
[root@Hiteg bin]# ./gst-inspect
Illegal instruction

kindly Guide me in fixing this issue.

Thanks,
Ratheendran

Re: [gst-embedded] Need Help On gst-omapfb built from openembedded

[Tejas <te...@pi...>]

Hello All,

               Is it possible to pass decoder output buffer directly to
color conversion routine. The snap shot of render function is as followed.

 

static GstFlowReturn

render (GstBaseSink * bsink, GstBuffer * buf)

{

    int i, w, h;

    GstOmapFbSink *omapfbsink = GST_OMAPFB_SINK(bsink);

    __uint8_t *fb = omapfbsink->framebuffer, *data = GST_BUFFER_DATA(buf);

       long iTime=0;

   struct timeval tempo1, tempo2;

 

    if(omapfbsink->plane_info.enabled == 2)

    {

        omapfbsink->plane_info.enabled = 1;

 

        g_mutex_lock (omapfbsink->x_lock);

        gst_omapfbsink_update_plane(omapfbsink);

        g_mutex_unlock (omapfbsink->x_lock);

    }

 

    g_print("\n Address in render function = %x\n", (unsigned
int)GST_BUFFER_DATA(buf));

    /* If a buffer which wasn't supplied by us is given to us to render
with,

       we need to copy to our buffer first so that memory alignment
constraints

       are met. */

 

    if(data != omapfbsink->buffer && GST_BUFFER_SIZE(buf) <=
omapfbsink->buffer_size)

    {

        memcpy(omapfbsink->buffer, data, GST_BUFFER_SIZE(buf));

        data = omapfbsink->buffer;

    }

 

    /* buffer_alloc gave a direct buffer, so we have nothing to

       do here... */

    if(omapfbsink->row_skip)

        return GST_FLOW_OK;

 

    switch(omapfbsink->image_format) {

        case GST_MAKE_FOURCC('I', '4', '2', '0'):

            /* Convert to YUV422 and send to FB */

 

            h = GST_VIDEO_SINK_HEIGHT (omapfbsink);

            w = GST_VIDEO_SINK_WIDTH (omapfbsink);

 

            __uint8_t *y, *u, *v;

            y = data;

            u = y + w * h;

            v = u + w / 2 * h / 2;

 

            yuv420_to_yuv422(fb, y, u, v, w & ~15, h, w, w / 2,
omapfbsink->fixinfo.line_length);

            break;

 

        case GST_MAKE_FOURCC('U', 'Y', 'V', 'Y'):

            /* Send to FB, taking into account line_length */

 

            w = 2 * GST_VIDEO_SINK_WIDTH (omapfbsink);

            for(i = 0; i < GST_VIDEO_SINK_HEIGHT (omapfbsink); i++)

            {

                memcpy(fb, data, w);

 

                fb += omapfbsink->fixinfo.line_length;

                data += w;

            }

 

            break;

    }

 

    return GST_FLOW_OK;

}

               Here buf which is passed is my decoder output buffer having
size = (width * height *1.5). I would like to replace memcpy seprated by
blue color in above function. Is there any possibility to assign buf pointer
directly to Y pointer which later go to color conversion. 

 

               I am laking of some understanding of buffer_alloc of base
sink. If any where I am wrong please correct me and try to guide me in right
direction. In other way I was thinking to use dma transfer, but I am
completely new for dma and will take much time to understand and write
transfer function. If I can get some other solution, will be helpful in my
project.

 

-Tejas.

 

 

From: Tejas [mailto:te...@pi...] 
Sent: Friday, March 26, 2010 3:33 PM
To: 'gst...@li...'
Subject: Need Help On gst-omapfb built from openembedded

 

Hello All,

               I am using gst-omapfb plugin built from openembedded which
contains X-overlay patch on normal omapfb plugin as my video sink. My normal
pipeline is as followed.

 

 

$gst-launch-0.10 filesrc location=1.mp4 ! myparser ! mydecoder ! omapfbsink.

 

Src pad of my decoder is set as following caps .

 

("video/x-raw-yuv",

 "width", G_TYPE_INT, mpeg4dec->info.width,

"height", G_TYPE_INT, mpeg4dec->info.height,

"framerate", GST_TYPE_FRACTION, mpeg4dec->fps_nu, mpeg4dec->fps_de,

"format", GST_TYPE_FOURCC, GST_MAKE_FOURCC ('I', '4', '2', '0'),

"pixel-aspect-ratio", GST_TYPE_FRACTION,1,1,i NULL);

 

               Omapfbsink will accept I420 format and convert it to UYVY
format  and copy it to frame buffer. In these all process it is using memcpy
which copy data from buffer pushed from my decoder to buffer allocated
locally. Here in omapfbsink memcpy is time consuming. Instead of using
memcpy I would like to use some other method. But I am getting how can I
replace memcpy. 

 

               If anyone can guide me to replace memcpy, I will be pleasure
for me.

 

 

-Tejas.

[gst-embedded] Need Help On gst-omapfb built from openembedded

[Tejas <te...@pi...>]

Hello All,

               I am using gst-omapfb plugin built from openembedded which
contains X-overlay patch on normal omapfb plugin as my video sink. My normal
pipeline is as followed.

 

 

$gst-launch-0.10 filesrc location=1.mp4 ! myparser ! mydecoder ! omapfbsink.

 

Src pad of my decoder is set as following caps .

 

("video/x-raw-yuv",

 "width", G_TYPE_INT, mpeg4dec->info.width,

"height", G_TYPE_INT, mpeg4dec->info.height,

"framerate", GST_TYPE_FRACTION, mpeg4dec->fps_nu, mpeg4dec->fps_de,

"format", GST_TYPE_FOURCC, GST_MAKE_FOURCC ('I', '4', '2', '0'),

"pixel-aspect-ratio", GST_TYPE_FRACTION,1,1,i NULL);

 

               Omapfbsink will accept I420 format and convert it to UYVY
format  and copy it to frame buffer. In these all process it is using memcpy
which copy data from buffer pushed from my decoder to buffer allocated
locally. Here in omapfbsink memcpy is time consuming. Instead of using
memcpy I would like to use some other method. But I am getting how can I
replace memcpy. 

 

               If anyone can guide me to replace memcpy, I will be pleasure
for me.

 

 

-Tejas.

Re: [gst-embedded] Waiting for new version of gst-player

[Tejas <te...@pi...>]

Hi felipe,

	Nice to have reply back.

	If we can avoid giving argument with gst-player executable. It will be nice if you can give file opening option in the main widget of gst-player.

-Tejas.

-----Original Message-----
From: Felipe Contreras [mailto:fel...@gm...] 
Sent: Wednesday, March 24, 2010 4:46 PM
To: Tejas
Cc: gst...@li...
Subject: Re: [gst-embedded] Waiting for new version of gst-player

Hi Tejas,

On Tue, Mar 23, 2010 at 11:50 AM, Tejas <te...@pi...> wrote:
> I have downloaded gst-player-0.0.0 from
> http://code.google.com/p/gst-player/downloads/list and is working fine. In
> the plan.txt it has been mentioned for gst-player version 0.1 or 0.2. Is
> there any possibility for latest version of gst-player to come out..

Thanks for reminding me, I do have that in my to-do list. Is there
anything specific you are looking for?

-- 
Felipe Contreras

Re: [gst-embedded] Waiting for new version of gst-player

[Felipe C. <fel...@gm...>]

Hi Tejas,

On Tue, Mar 23, 2010 at 11:50 AM, Tejas <te...@pi...> wrote:
> I have downloaded gst-player-0.0.0 from
> http://code.google.com/p/gst-player/downloads/list and is working fine. In
> the plan.txt it has been mentioned for gst-player version 0.1 or 0.2. Is
> there any possibility for latest version of gst-player to come out..

Thanks for reminding me, I do have that in my to-do list. Is there
anything specific you are looking for?

-- 
Felipe Contreras

Re: [gst-embedded] Gstreamer fails loading core plugins

[Fabio M. <fab...@gm...>]

Hi all,

   I managed to find the answer:

the problem was due to a wrong configuration of glib-2.22.4 while
cross-compiling.

I set in config.cache glib_cv_uscore=yes,
while it must be set to no.

I found this having a look to debug logs of gstreamer and to the code source
of gstplugin.c.
Now it works.

Regards.

-- 
Fabio Mauri

Re: [gst-embedded] Gstreamer fails loading core plugins

[Fabio M. <fab...@gm...>]

Hi all,

   I managed to find the answer:

the problem was due to a wrong configuration of glib-2.22.4 while
cross-compiling.

I set in config.cache glib_cv_uscore=yes,
while it must be set to no.

I found this having a look to debug logs of gstreamer and to the code source
of gstplugin.c.
Now it works.

Regards.

-- 
Fabio Mauri

[gst-embedded] Waiting for new version of gst-player

[Tejas <te...@pi...>]

Hello All,

               

I have downloaded gst-player-0.0.0 from
http://code.google.com/p/gst-player/downloads/list and is working fine. In
the plan.txt it has been mentioned for gst-player version 0.1 or 0.2. Is
there any possibility for latest version of gst-player to come out..

 

-Tejas.

Re: [gst-embedded] how to pass Mp2/Mp3 packets to gstreamer pipeline application

[Felipe C. <fel...@no...>]

Hi,

On Thu, Feb 25, 2010 at 05:12:13AM +0100, ext Gaurang T wrote:
> I want to pass real-time chunk-data (like mp2/mp3 type packets from my
> application)  to  gstreamer pipeline application.

Have you looked into the appsrc element?

-- 
Felipe Contreras