On Wed, Mar 3, 2010 at 6:44 PM, Vincent Torri <vtorri@...> wrote:
> On Wed, 3 Mar 2010, Gustavo Sverzut Barbieri wrote:
>> On Wed, Mar 3, 2010 at 3:20 PM, Thomas Sachau <tommy@...> wrote:
>>>
>>> Hi,
>>>
>>> i tried to compile all packages, which are as ebuilds in official Gentoo
>>> enlightenment overlay from
>>> svn and i found some issues, which i will list below:
>>
>> Hi Thomas! Thanks for the report.
>>
>>
>>> Missing README file, when README.in exists, lets automake bail out:
>>>
>>> eet
>>> embryo
>>> imlib2_loaders
>>> ecore
>>> evas
>>
>> This is quite tricky as these projects would like to have README with
>> the version filled in in the generated packages. As such, I don't see
>> committing them to SVN as an option :-/
>>
>>
>>> autogen.sh containing lines, which hide issues in svn (like removing
>>> autotools related files or
>>> touching README), the issues should be fixed themselves, not worked
>>> around in autogen.sh:
>>>
>>> eet
>>> embryo
>>> imlib2_loaders
>>> ecore
>>> evas
>>
>> I don't know why those rm for cache must be explicit. I'd remove them.
>> Anyone know why these are required? Maybe these should go into
>> MAINTAINERCLEANFILES?
>
> raster had certainly problems 10 years ago and is reluctant to modify
> something that "works".
>
> Just a note : Evil is using autoreconf -f -i as autogen.sh and does nothing
> more, nor there are deleted files at the beginning of configure.ac. And it
> works quite well. No strange hacks.
>
> We are in 2010 and autoreconf is working for several years now.
yes, and the point with autoreconf is that it is updated to match new
requirements and changes, unlike our scripts that may miss
something... IOW it is more reliable. :-)
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

On Wed, 3 Mar 2010, Gustavo Sverzut Barbieri wrote:
> On Wed, Mar 3, 2010 at 3:20 PM, Thomas Sachau <tommy@...> wrote:
>> Hi,
>>
>> i tried to compile all packages, which are as ebuilds in official Gentoo enlightenment overlay from
>> svn and i found some issues, which i will list below:
>
> Hi Thomas! Thanks for the report.
>
>
>> Missing README file, when README.in exists, lets automake bail out:
>>
>> eet
>> embryo
>> imlib2_loaders
>> ecore
>> evas
>
> This is quite tricky as these projects would like to have README with
> the version filled in in the generated packages. As such, I don't see
> committing them to SVN as an option :-/
>
>
>> autogen.sh containing lines, which hide issues in svn (like removing autotools related files or
>> touching README), the issues should be fixed themselves, not worked around in autogen.sh:
>>
>> eet
>> embryo
>> imlib2_loaders
>> ecore
>> evas
>
> I don't know why those rm for cache must be explicit. I'd remove them.
> Anyone know why these are required? Maybe these should go into
> MAINTAINERCLEANFILES?
raster had certainly problems 10 years ago and is reluctant to modify
something that "works".
Just a note : Evil is using autoreconf -f -i as autogen.sh and does
nothing more, nor there are deleted files at the beginning of
configure.ac. And it works quite well. No strange hacks.
We are in 2010 and autoreconf is working for several years now.
So....
Vincent

On Wed, Mar 3, 2010 at 3:20 PM, Thomas Sachau <tommy@...> wrote:
> Hi,
>
> i tried to compile all packages, which are as ebuilds in official Gentoo enlightenment overlay from
> svn and i found some issues, which i will list below:
Hi Thomas! Thanks for the report.
> Missing README file, when README.in exists, lets automake bail out:
>
> eet
> embryo
> imlib2_loaders
> ecore
> evas
This is quite tricky as these projects would like to have README with
the version filled in in the generated packages. As such, I don't see
committing them to SVN as an option :-/
> autogen.sh containing lines, which hide issues in svn (like removing autotools related files or
> touching README), the issues should be fixed themselves, not worked around in autogen.sh:
>
> eet
> embryo
> imlib2_loaders
> ecore
> evas
I don't know why those rm for cache must be explicit. I'd remove them.
Anyone know why these are required? Maybe these should go into
MAINTAINERCLEANFILES?
> Packages checking for ecore-data, which is now disabled by default:
>
> ewl
> wlan module
wlan was fixed this night, ewl is an unknown situation. I don't hear
much from their developers in a while, no commits to svn recently,
they are not moving to eina but their own solution.
> Makefile.am containing "ACLOCAL_AMFLAGS = -I m4", also that dir does not exist:
>
> execwatch module
> mpdule module
> winselector module
I'll let their maintainer to comment on those. Thanks for pointing.
BR,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri@...
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

Hi,
i tried to compile all packages, which are as ebuilds in official Gentoo enlightenment overlay from
svn and i found some issues, which i will list below:
Missing README file, when README.in exists, lets automake bail out:
eet
embryo
imlib2_loaders
ecore
evas
autogen.sh containing lines, which hide issues in svn (like removing autotools related files or
touching README), the issues should be fixed themselves, not worked around in autogen.sh:
eet
embryo
imlib2_loaders
ecore
evas
Packages checking for ecore-data, which is now disabled by default:
ewl
wlan module
Makefile.am containing "ACLOCAL_AMFLAGS = -I m4", also that dir does not exist:
execwatch module
mpdule module
winselector module
--
Thomas Sachau
Gentoo Linux Developer

On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 3 Mar 2010 13:39:40 +0100 (CET) Vincent Torri <vtorri@...>
> said:
>
>>
>>
>> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
>>
>>> On Wed, 3 Mar 2010 12:41:19 +0100 Jorge Luis Zapata Muga
>>> <jorgeluis.zapata@...> said:
>>>
>>>> On Wed, Mar 3, 2010 at 6:32 AM, Vincent Torri <vtorri@...> wrote:
>>>>>
>>>>>
>>>>> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
>>>>>
>>>>>> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri
>>>>>> <vtorri@...> said:
>>>>>>>
>>>>>>> I've attached a tarball containing the evas sink for gstreamer, a small
>>>>>>> test example and a small video (ogg/theora, 48 frames). You must have
>>>>>>> gstreamer and gstreamer-plugins-base dev packages to build everything
>>>>>>>
>>>>>>> 1) Create the directory ~/.gstreamer-0.10/plugins
>>>>>>>
>>>>>>> 2) make (to build the sink and the test, and install the plugin)
>>>>>>>
>>>>>>> 3) ./test (to run the test)
>>>>>>>
>>>>>>> The plugin is not complete yet, but it's a good start. What is
>>>>>>> remaining, mainly, is to managed YUV files and maybe adding mor
>>>>>>> properties. I'll add it later.
>>>>>>>
>>>>>>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
>>>>>>> is, could it be used elsewhere (like in webkit-efl, for example) ?
>>>>>>>
>>>>>>> Vincent
>>>>>>>
>>>>>>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
>>>>>>> understand that stuff...
>>>>>>
>>>>>> imoh - it probably belongs in emotion... but right now its a rgb(a) sink
>>>>>> only
>>>>>
>>>>> Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
>>>>> alpha). They are all the same except the padding which is 3 or 4. For
>>>>> example, there is a deadlock in the new code. I don't want to add features
>>>>> until the problem is solved.
>>>>>
>>>>>> which means its really not of any great use. once its yuv... you can
>>>>>> finally get acceleration for yuv->rgb+scale (right now yuv->rgb will be
>>>>>> done by gstreamer in software and then if you use evas's gl engine - u
>>>>>> could get scaling accel - but its an rgba upload of pixels - and as such
>>>>>> thats 32bit per pixel not the 12 bits that yuv would be - so more than
>>>>>> double the upload bandwidth).
>>>>>
>>>>> I know how to deal with YUV (YV12 or I420) as i did it in emotion.
>>>>> I'll add that support later (note the caps that are commented at the
>>>>> beginning of evassink.c).
>>>>>
>>>>>> i'd say make it do yuv and put it in emotion as part of the
>>>>>> gtsremaer module. expose the sink to gst runtime inside emotion (it
>>>>>> doesnt need a .so installed if u supply your own sink from the app -
>>>>>> right?)
>>>>>
>>>>> There are several locations where gstreamer searches the modules :
>>>>>
>>>>> * the prefix of gstreamer + lib/gstreamer-0.10
>>>>> * $HOME/.gstreamer-0.10/plugins
>>>>> * the value of the env var GST_PLUGIN_PATH
>>>>> * the path passed to the command line option --gst-plugin-path (if
>>>>> the app uses argc/argv and if gst is correctly initialized)
>>>>>
>>>>
>>>> You can always make a static plugin, that is, register the gst element
>>>> once the emotion lib is initialized (and the gstreamer backend). It
>>>> will be part of the gst runtime, no need to create a .so.
>>>
>>> thats what i was talking about :)
>>
>> but then, it can not be used elsewhere. Why do you think that emotion is
>> the only lib that should use it ?
>
> because its the only need i see
yes, that *you* see.
Vincent
> - why would anything else use gstreamer
> directly when emotion already handles abstracting that for you? you dont need
> to know or deal with gst api - it's simpler and more flexible. gst still (last
> i checked) didnt do dvd's (properly). for example. so now u want to do a dvd
> player - u need to use a completely different api (emotion or libxine)? it
> makes very little sense.
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler) raster@...
>
>

On Wed, 3 Mar 2010, Nicolas Aguirre wrote:
> I think that you should install evassink.so in gstreamer plugins
> directory, during make install of emotion. So you can use it in
> emotion itself, and if someone want use evassink directly in his apps,
> he can.
why ? emotion can use it too. I do nothing specific that allows the test
in tarball to choose the .so that i copied in ~/.gstreamer-0.10/plugins.
That directory is one of those where gst searches the plugins.
Vincent

On Wed, 3 Mar 2010 13:39:40 +0100 (CET) Vincent Torri <vtorri@...>
said:
>
>
> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
>
> > On Wed, 3 Mar 2010 12:41:19 +0100 Jorge Luis Zapata Muga
> > <jorgeluis.zapata@...> said:
> >
> >> On Wed, Mar 3, 2010 at 6:32 AM, Vincent Torri <vtorri@...> wrote:
> >>>
> >>>
> >>> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
> >>>
> >>>> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri
> >>>> <vtorri@...> said:
> >>>>>
> >>>>> I've attached a tarball containing the evas sink for gstreamer, a small
> >>>>> test example and a small video (ogg/theora, 48 frames). You must have
> >>>>> gstreamer and gstreamer-plugins-base dev packages to build everything
> >>>>>
> >>>>> 1) Create the directory ~/.gstreamer-0.10/plugins
> >>>>>
> >>>>> 2) make (to build the sink and the test, and install the plugin)
> >>>>>
> >>>>> 3) ./test (to run the test)
> >>>>>
> >>>>> The plugin is not complete yet, but it's a good start. What is
> >>>>> remaining, mainly, is to managed YUV files and maybe adding mor
> >>>>> properties. I'll add it later.
> >>>>>
> >>>>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
> >>>>> is, could it be used elsewhere (like in webkit-efl, for example) ?
> >>>>>
> >>>>> Vincent
> >>>>>
> >>>>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
> >>>>> understand that stuff...
> >>>>
> >>>> imoh - it probably belongs in emotion... but right now its a rgb(a) sink
> >>>> only
> >>>
> >>> Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
> >>> alpha). They are all the same except the padding which is 3 or 4. For
> >>> example, there is a deadlock in the new code. I don't want to add features
> >>> until the problem is solved.
> >>>
> >>>> which means its really not of any great use. once its yuv... you can
> >>>> finally get acceleration for yuv->rgb+scale (right now yuv->rgb will be
> >>>> done by gstreamer in software and then if you use evas's gl engine - u
> >>>> could get scaling accel - but its an rgba upload of pixels - and as such
> >>>> thats 32bit per pixel not the 12 bits that yuv would be - so more than
> >>>> double the upload bandwidth).
> >>>
> >>> I know how to deal with YUV (YV12 or I420) as i did it in emotion.
> >>> I'll add that support later (note the caps that are commented at the
> >>> beginning of evassink.c).
> >>>
> >>>> i'd say make it do yuv and put it in emotion as part of the
> >>>> gtsremaer module. expose the sink to gst runtime inside emotion (it
> >>>> doesnt need a .so installed if u supply your own sink from the app -
> >>>> right?)
> >>>
> >>> There are several locations where gstreamer searches the modules :
> >>>
> >>> * the prefix of gstreamer + lib/gstreamer-0.10
> >>> * $HOME/.gstreamer-0.10/plugins
> >>> * the value of the env var GST_PLUGIN_PATH
> >>> * the path passed to the command line option --gst-plugin-path (if
> >>> the app uses argc/argv and if gst is correctly initialized)
> >>>
> >>
> >> You can always make a static plugin, that is, register the gst element
> >> once the emotion lib is initialized (and the gstreamer backend). It
> >> will be part of the gst runtime, no need to create a .so.
> >
> > thats what i was talking about :)
>
> but then, it can not be used elsewhere. Why do you think that emotion is
> the only lib that should use it ?
because its the only need i see - why would anything else use gstreamer
directly when emotion already handles abstracting that for you? you dont need
to know or deal with gst api - it's simpler and more flexible. gst still (last
i checked) didnt do dvd's (properly). for example. so now u want to do a dvd
player - u need to use a completely different api (emotion or libxine)? it
makes very little sense.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Wed, Mar 3, 2010 at 1:39 PM, Vincent Torri <vtorri@...> wrote:
>
> but then, it can not be used elsewhere. Why do you think that emotion is the
> only lib that should use it ?
>
> Vincent
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
I think that you should install evassink.so in gstreamer plugins
directory, during make install of emotion. So you can use it in
emotion itself, and if someone want use evassink directly in his apps,
he can.
--
Nicolas Aguirre
Mail: aguirre.nicolas@...
Web: http://www.digital-corner.org

On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 3 Mar 2010 12:41:19 +0100 Jorge Luis Zapata Muga
> <jorgeluis.zapata@...> said:
>
>> On Wed, Mar 3, 2010 at 6:32 AM, Vincent Torri <vtorri@...> wrote:
>>>
>>>
>>> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
>>>
>>>> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri <vtorri@...>
>>>> said:
>>>>>
>>>>> I've attached a tarball containing the evas sink for gstreamer, a small
>>>>> test example and a small video (ogg/theora, 48 frames). You must have
>>>>> gstreamer and gstreamer-plugins-base dev packages to build everything
>>>>>
>>>>> 1) Create the directory ~/.gstreamer-0.10/plugins
>>>>>
>>>>> 2) make (to build the sink and the test, and install the plugin)
>>>>>
>>>>> 3) ./test (to run the test)
>>>>>
>>>>> The plugin is not complete yet, but it's a good start. What is remaining,
>>>>> mainly, is to managed YUV files and maybe adding mor properties. I'll add
>>>>> it later.
>>>>>
>>>>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
>>>>> is, could it be used elsewhere (like in webkit-efl, for example) ?
>>>>>
>>>>> Vincent
>>>>>
>>>>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
>>>>> understand that stuff...
>>>>
>>>> imoh - it probably belongs in emotion... but right now its a rgb(a) sink
>>>> only
>>>
>>> Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
>>> alpha). They are all the same except the padding which is 3 or 4. For
>>> example, there is a deadlock in the new code. I don't want to add features
>>> until the problem is solved.
>>>
>>>> which means its really not of any great use. once its yuv... you can
>>>> finally get acceleration for yuv->rgb+scale (right now yuv->rgb will be
>>>> done by gstreamer in software and then if you use evas's gl engine - u
>>>> could get scaling accel - but its an rgba upload of pixels - and as such
>>>> thats 32bit per pixel not the 12 bits that yuv would be - so more than
>>>> double the upload bandwidth).
>>>
>>> I know how to deal with YUV (YV12 or I420) as i did it in emotion.
>>> I'll add that support later (note the caps that are commented at the
>>> beginning of evassink.c).
>>>
>>>> i'd say make it do yuv and put it in emotion as part of the
>>>> gtsremaer module. expose the sink to gst runtime inside emotion (it doesnt
>>>> need a .so installed if u supply your own sink from the app - right?)
>>>
>>> There are several locations where gstreamer searches the modules :
>>>
>>> * the prefix of gstreamer + lib/gstreamer-0.10
>>> * $HOME/.gstreamer-0.10/plugins
>>> * the value of the env var GST_PLUGIN_PATH
>>> * the path passed to the command line option --gst-plugin-path (if
>>> the app uses argc/argv and if gst is correctly initialized)
>>>
>>
>> You can always make a static plugin, that is, register the gst element
>> once the emotion lib is initialized (and the gstreamer backend). It
>> will be part of the gst runtime, no need to create a .so.
>
> thats what i was talking about :)
but then, it can not be used elsewhere. Why do you think that emotion is
the only lib that should use it ?
Vincent

On Wed, 3 Mar 2010 12:41:19 +0100 Jorge Luis Zapata Muga
<jorgeluis.zapata@...> said:
> On Wed, Mar 3, 2010 at 6:32 AM, Vincent Torri <vtorri@...> wrote:
> >
> >
> > On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
> >
> >> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri <vtorri@...>
> >> said:
> >>>
> >>> I've attached a tarball containing the evas sink for gstreamer, a small
> >>> test example and a small video (ogg/theora, 48 frames). You must have
> >>> gstreamer and gstreamer-plugins-base dev packages to build everything
> >>>
> >>> 1) Create the directory ~/.gstreamer-0.10/plugins
> >>>
> >>> 2) make (to build the sink and the test, and install the plugin)
> >>>
> >>> 3) ./test (to run the test)
> >>>
> >>> The plugin is not complete yet, but it's a good start. What is remaining,
> >>> mainly, is to managed YUV files and maybe adding mor properties. I'll add
> >>> it later.
> >>>
> >>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
> >>> is, could it be used elsewhere (like in webkit-efl, for example) ?
> >>>
> >>> Vincent
> >>>
> >>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
> >>> understand that stuff...
> >>
> >> imoh - it probably belongs in emotion... but right now its a rgb(a) sink
> >> only
> >
> > Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
> > alpha). They are all the same except the padding which is 3 or 4. For
> > example, there is a deadlock in the new code. I don't want to add features
> > until the problem is solved.
> >
> >> which means its really not of any great use. once its yuv... you can
> >> finally get acceleration for yuv->rgb+scale (right now yuv->rgb will be
> >> done by gstreamer in software and then if you use evas's gl engine - u
> >> could get scaling accel - but its an rgba upload of pixels - and as such
> >> thats 32bit per pixel not the 12 bits that yuv would be - so more than
> >> double the upload bandwidth).
> >
> > I know how to deal with YUV (YV12 or I420) as i did it in emotion.
> > I'll add that support later (note the caps that are commented at the
> > beginning of evassink.c).
> >
> >> i'd say make it do yuv and put it in emotion as part of the
> >> gtsremaer module. expose the sink to gst runtime inside emotion (it doesnt
> >> need a .so installed if u supply your own sink from the app - right?)
> >
> > There are several locations where gstreamer searches the modules :
> >
> > * the prefix of gstreamer + lib/gstreamer-0.10
> > * $HOME/.gstreamer-0.10/plugins
> > * the value of the env var GST_PLUGIN_PATH
> > * the path passed to the command line option --gst-plugin-path (if
> > the app uses argc/argv and if gst is correctly initialized)
> >
>
> You can always make a static plugin, that is, register the gst element
> once the emotion lib is initialized (and the gstreamer backend). It
> will be part of the gst runtime, no need to create a .so.
thats what i was talking about :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

On Wed, Mar 3, 2010 at 6:32 AM, Vincent Torri <vtorri@...> wrote:
>
>
> On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
>
>> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri <vtorri@...>
>> said:
>>>
>>> I've attached a tarball containing the evas sink for gstreamer, a small
>>> test example and a small video (ogg/theora, 48 frames). You must have
>>> gstreamer and gstreamer-plugins-base dev packages to build everything
>>>
>>> 1) Create the directory ~/.gstreamer-0.10/plugins
>>>
>>> 2) make (to build the sink and the test, and install the plugin)
>>>
>>> 3) ./test (to run the test)
>>>
>>> The plugin is not complete yet, but it's a good start. What is remaining,
>>> mainly, is to managed YUV files and maybe adding mor properties. I'll add
>>> it later.
>>>
>>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
>>> is, could it be used elsewhere (like in webkit-efl, for example) ?
>>>
>>> Vincent
>>>
>>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
>>> understand that stuff...
>>
>> imoh - it probably belongs in emotion... but right now its a rgb(a) sink only
>
> Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
> alpha). They are all the same except the padding which is 3 or 4. For
> example, there is a deadlock in the new code. I don't want to add features
> until the problem is solved.
>
>> which means its really not of any great use. once its yuv... you can finally
>> get acceleration for yuv->rgb+scale (right now yuv->rgb will be done by
>> gstreamer in software and then if you use evas's gl engine - u could get
>> scaling accel - but its an rgba upload of pixels - and as such thats 32bit per
>> pixel not the 12 bits that yuv would be - so more than double the upload
>> bandwidth).
>
> I know how to deal with YUV (YV12 or I420) as i did it in emotion.
> I'll add that support later (note the caps that are commented at the
> beginning of evassink.c).
>
>> i'd say make it do yuv and put it in emotion as part of the
>> gtsremaer module. expose the sink to gst runtime inside emotion (it doesnt need
>> a .so installed if u supply your own sink from the app - right?)
>
> There are several locations where gstreamer searches the modules :
>
> * the prefix of gstreamer + lib/gstreamer-0.10
> * $HOME/.gstreamer-0.10/plugins
> * the value of the env var GST_PLUGIN_PATH
> * the path passed to the command line option --gst-plugin-path (if
> the app uses argc/argv and if gst is correctly initialized)
>
You can always make a static plugin, that is, register the gst element
once the emotion lib is initialized (and the gstreamer backend). It
will be part of the gst runtime, no need to create a .so.
> Vincent
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

On Wed, 3 Mar 2010, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri <vtorri@...>
> said:
>>
>> I've attached a tarball containing the evas sink for gstreamer, a small
>> test example and a small video (ogg/theora, 48 frames). You must have
>> gstreamer and gstreamer-plugins-base dev packages to build everything
>>
>> 1) Create the directory ~/.gstreamer-0.10/plugins
>>
>> 2) make (to build the sink and the test, and install the plugin)
>>
>> 3) ./test (to run the test)
>>
>> The plugin is not complete yet, but it's a good start. What is remaining,
>> mainly, is to managed YUV files and maybe adding mor properties. I'll add
>> it later.
>>
>> Question: should this sink goes to emotion dir, or gstreamer repo ? That
>> is, could it be used elsewhere (like in webkit-efl, for example) ?
>>
>> Vincent
>>
>> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
>> understand that stuff...
>
> imoh - it probably belongs in emotion... but right now its a rgb(a) sink only
Yes. First, i want to make it solid with BGR or BGRA or BGRx (4 chans, no
alpha). They are all the same except the padding which is 3 or 4. For
example, there is a deadlock in the new code. I don't want to add features
until the problem is solved.
> which means its really not of any great use. once its yuv... you can finally
> get acceleration for yuv->rgb+scale (right now yuv->rgb will be done by
> gstreamer in software and then if you use evas's gl engine - u could get
> scaling accel - but its an rgba upload of pixels - and as such thats 32bit per
> pixel not the 12 bits that yuv would be - so more than double the upload
> bandwidth).
I know how to deal with YUV (YV12 or I420) as i did it in emotion.
I'll add that support later (note the caps that are commented at the
beginning of evassink.c).
> i'd say make it do yuv and put it in emotion as part of the
> gtsremaer module. expose the sink to gst runtime inside emotion (it doesnt need
> a .so installed if u supply your own sink from the app - right?)
There are several locations where gstreamer searches the modules :
* the prefix of gstreamer + lib/gstreamer-0.10
* $HOME/.gstreamer-0.10/plugins
* the value of the env var GST_PLUGIN_PATH
* the path passed to the command line option --gst-plugin-path (if
the app uses argc/argv and if gst is correctly initialized)
Vincent

On Tue, 2 Mar 2010 10:20:18 +0100 (CET) Vincent Torri <vtorri@...>
said:
>
> Hey,
>
> I've attached a tarball containing the evas sink for gstreamer, a small
> test example and a small video (ogg/theora, 48 frames). You must have
> gstreamer and gstreamer-plugins-base dev packages to build everything
>
> 1) Create the directory ~/.gstreamer-0.10/plugins
>
> 2) make (to build the sink and the test, and install the plugin)
>
> 3) ./test (to run the test)
>
> The plugin is not complete yet, but it's a good start. What is remaining,
> mainly, is to managed YUV files and maybe adding mor properties. I'll add
> it later.
>
> Question: should this sink goes to emotion dir, or gstreamer repo ? That
> is, could it be used elsewhere (like in webkit-efl, for example) ?
>
> Vincent
>
> PS: thanks to Nicolas Aguirre for his help with cond/mutex. I'll never
> understand that stuff...
imoh - it probably belongs in emotion... but right now its a rgb(a) sink only
which means its really not of any great use. once its yuv... you can finally
get acceleration for yuv->rgb+scale (right now yuv->rgb will be done by
gstreamer in software and then if you use evas's gl engine - u could get
scaling accel - but its an rgba upload of pixels - and as such thats 32bit per
pixel not the 12 bits that yuv would be - so more than double the upload
bandwidth). i'd say make it do yuv and put it in emotion as part of the
gtsremaer module. expose the sink to gst runtime inside emotion (it doesnt need
a .so installed if u supply your own sink from the app - right?)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details