Menu
▾
▴
gstreamer-openmax — Development list for GStreamer OpenMax plugins
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
(11) |
Aug
(31) |
Sep
(2) |
Oct
(21) |
Nov
(16) |
Dec
(56) |
| 2009 |
Jan
(12) |
Feb
(5) |
Mar
(34) |
Apr
(9) |
May
(5) |
Jun
(7) |
Jul
(18) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(50) |
Dec
|
| 2010 |
Jan
(3) |
Feb
(67) |
Mar
(135) |
Apr
(30) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(18) |
Sep
(12) |
Oct
(4) |
Nov
(17) |
Dec
(11) |
| 2011 |
Jan
(14) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Clark, R. <ro...@ti...> - 2010-02-23 02:42:51
|
On Feb 22, 2010, at 9:37 AM, Felipe Contreras wrote:
> On Mon, Feb 22, 2010 at 5:29 PM, Clark, Rob <ro...@ti...> wrote:
>> That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it.
>
> I don't think there's any need for a complicated structure, so XML is
> overkill, specially if some systems don't have libxml2. Moreover I
> would like the file to be human readable; some people might like to
> modify it (for testing purposes or whatever).
>
> Personally I would write a simpler parser, but if anyone has better
> ideas/patches, I'm open for them.
Ok, attached is a work-in-progress for what I'm thinking.. the basic idea is that the config file is just a list of GstStructure's, so no parser needed, just gst_structure_from_string(). These get stored within a parent GstStructure (so could be cached w/ gst_plugin_{get,set}_cache_data(), although that is not implemented yet. The config file looks like:
-----8<----------8<-----
omx_mp3dec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.mp3, rank=256;
omx_aacdec, library-name=libOMX_Core.so, component-name=OMX.TI.AUDIO.DECODE, component-role=audio_decode.dsp.aac, rank=256;
omx_volume, library-name=libomxil-bellagio.so.0, component-name=OMX.st.volume.component, rank=0;
...
----->8---------->8-----
(the component-role field is optional, others are mandatory)
I left for now the library-name/component-name/component-role properties in the base src/filter/sink elements. But now they are just read-only properties, showing what is configured via the config file. I think this is useful to see in output of gst-inspect, diagrams generated from .dot files of the pipeline, etc.
Right now I have a small default config, in case no config file is found.. but I could go either way on this, either making it complete or removing it altogether. Anyone have any preference about whether the config file should just override a complete default table, or whether the config file should be mandatory?
The patch won't apply as-is on the gst-openmax tree from freedesktop.org (in our tree we've added component-role and some other stuff), but I'm just sending it as an RFC. If people like the idea, I'll rebase it on current master from fd.o (after cleaning up a couple of quick-n-dirty aspects of the patch).
I've pushed the patch here, if this is an easier way for you to review:
http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1
and since the patch seems to be too big and caused my original email to bounce, here it the link to the patch:
http://gitorious.org/robclark-gstreamer/gst-openmax/commit/4a8e4064c9b698d03ffce735257758cd0b8999f1.patch
BR,
-R
|
|
From: Clark, R. <ro...@ti...> - 2010-02-22 17:06:09
|
On Feb 22, 2010, at 10:47 AM, Stephen M. Webb wrote: > On 22/02/10 09:32, Clark, Rob wrote: >> >> On requirements side, do you think any of following are needed: >> >> * Detect changes in registry at runtime? Or just check if file has >> changed at plugin_init() time? > > Our requirements are definitely limited to plugin_init() time. > >> Anything else? > > Another thing that came up recently was the ability to specify some OpenMAX > parameters with default values on a per-plugin basis. Even better, some way > to specify rules for different parameters values to handle cases such as the > WMVFileType setting for the TI video decoder. would it be sufficient to (a) expose more setting via properties, and (b) have some generic (not specific to gst-openmax) way to config default values for element's properties BR, -R > > -- > Stephen M. Webb > Xandros > ste...@xa... > www.xandros.com |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 16:58:25
|
On Feb 22, 2010, at 10:15 AM, Stefan Kost wrote: > Clark, Rob wrote: >> On Apr 1, 2009, at 11:21 AM, Felipe Contreras wrote: >> >> >>> On Wed, Apr 1, 2009 at 6:45 PM, Stephen M. Webb <ste...@xa...> wrote: >>> >>>> On 01/04/09 11:15, Felipe Contreras wrote: >>>> >>>>> Yeah, that's the next step, I plan to implement something like: >>>>> ./configure MAPPING=maemo >>>>> >>>>> Would that fit your use case? >>>>> >>>> No, configuring at compile time won't help, I need to configure at runtime. I >>>> want to be able to distribute a single gstreamer-openmax library binary >>>> package for, say, Cortex-A8 and be able to configure it at runtime (well, >>>> install time) for the actual hardware it's running on, say OMAP3, i.MX51, or >>>> QSD8x50. Just for example. >>>> >>>> >>>>> I am planning to do that soon, but of course I would not get mad if >>>>> you beat me to it :) >>>>> >>>> I was hoping you'd say you were just about to check in the changes. I will >>>> now frown and grumble and see what I can come up with. >>>> >>> Ah, I see. >>> >>> Well, there's definitely plans on that, but it's pretty low on my >>> priority list =/ >>> >>> My idea was to create a gst-openmax registry, with this API: >>> http://bugzilla.gnome.org/show_bug.cgi?id=350477 >>> >> >> >> I was starting to think again about gst-openmax registry.. >> >> On implementation side, what are your thoughts about using libxml2? It seems a bit overkill, but it is already a dependency of gstreamer core. >> > > Please no xml for a registry cache. Maybe you can sketch the data first > and then we can discuss the file format. well, it isn't really a cache.. more of a config file. At a minimum consisting of the data in the table in gstomx.c. maybe registry is a bad word for it in the GStreamer context, because the main registry is not really a config file, and more of a cache. btw, after looking at gst_plugin_{get,set}_cache_data, I have a real simple idea to avoid writing a new parser. (Not that an .ini style parser would be hard. But it just seems ugly to have multiple different parsers in gst of different formats of data.) instead, just re-use the parsing in GstStructure. So, if we didn't add any new requirements beyond what is currently in gstomx.c component table, then I'd propose something like: -----8<----------8<----- omx_mp3dec, library=libOMX_Core.so, component=OMX.TI.AUDIO.DECODE, role=audio_decode.dsp.mp3; omx_aacdec, library=libOMX_Core.so, component=OMX.TI.AUDIO.DECODE, role=audio_decode.dsp.aac; .... ----->8---------->8----- to get the GType corresponding to component name, it could use dlsym(RTLD_SELF, "gst_" + component_name + "_get_type") I'd propose that in g_omx_core_init(), to check: cache_valid = TRUE; if (config file is newer/different timestamp from before) { g_object_unref (element_table); cache_valid = FALSE; } if (!element_table) { if (is in gst registry cache && cache_valid) { element_table = gst_plugin_get_cache_data (plugin); } else { ... parse config file using gst_structure_from_string() and populate element_table ... gst_plugin_set_cache_data (plugin, element_table); } } this way, at runtime it would detect config file changes, as long as they happened before the element is created can a GstStructure recursively contain elements that are GstStructures? BR, -R >> On requirements side, do you think any of following are needed: >> >> * Detect changes in registry at runtime? Or just check if file has changed at plugin_init() time? >> > runtime changes should be possible. Hopefully the gstomx registry can be > chained to gst_update_registry(). > > Stefan >> * Dynamic class instances.. Ie. be able to introduce new OMX components without creating a new GstOmx subclass? (Hypothetically you could put template caps and compression format in registry.. although I think it would be only extremelly simple cases where you could avoid writing any code.) >> * multiple different OMX components filling same role? (Ie. different MP3 decoder components.) Again, I don't really see immediately how this could work, but I'm just brainstorming here. >> >> >> Anything else? >> |
|
From: Stephen M. W. <ste...@xa...> - 2010-02-22 16:35:11
|
On 22/02/10 09:32, Clark, Rob wrote: > > On requirements side, do you think any of following are needed: > > * Detect changes in registry at runtime? Or just check if file has > changed at plugin_init() time? Our requirements are definitely limited to plugin_init() time. > Anything else? Another thing that came up recently was the ability to specify some OpenMAX parameters with default values on a per-plugin basis. Even better, some way to specify rules for different parameters values to handle cases such as the WMVFileType setting for the TI video decoder. -- Stephen M. Webb Xandros ste...@xa... www.xandros.com |
|
From: Stefan K. <en...@ho...> - 2010-02-22 16:15:20
|
Clark, Rob wrote: > On Apr 1, 2009, at 11:21 AM, Felipe Contreras wrote: > > >> On Wed, Apr 1, 2009 at 6:45 PM, Stephen M. Webb <ste...@xa...> wrote: >> >>> On 01/04/09 11:15, Felipe Contreras wrote: >>> >>>> Yeah, that's the next step, I plan to implement something like: >>>> ./configure MAPPING=maemo >>>> >>>> Would that fit your use case? >>>> >>> No, configuring at compile time won't help, I need to configure at runtime. I >>> want to be able to distribute a single gstreamer-openmax library binary >>> package for, say, Cortex-A8 and be able to configure it at runtime (well, >>> install time) for the actual hardware it's running on, say OMAP3, i.MX51, or >>> QSD8x50. Just for example. >>> >>> >>>> I am planning to do that soon, but of course I would not get mad if >>>> you beat me to it :) >>>> >>> I was hoping you'd say you were just about to check in the changes. I will >>> now frown and grumble and see what I can come up with. >>> >> Ah, I see. >> >> Well, there's definitely plans on that, but it's pretty low on my >> priority list =/ >> >> My idea was to create a gst-openmax registry, with this API: >> http://bugzilla.gnome.org/show_bug.cgi?id=350477 >> > > > I was starting to think again about gst-openmax registry.. > > On implementation side, what are your thoughts about using libxml2? It seems a bit overkill, but it is already a dependency of gstreamer core. > Please no xml for a registry cache. Maybe you can sketch the data first and then we can discuss the file format. > On requirements side, do you think any of following are needed: > > * Detect changes in registry at runtime? Or just check if file has changed at plugin_init() time? > runtime changes should be possible. Hopefully the gstomx registry can be chained to gst_update_registry(). Stefan > * Dynamic class instances.. Ie. be able to introduce new OMX components without creating a new GstOmx subclass? (Hypothetically you could put template caps and compression format in registry.. although I think it would be only extremelly simple cases where you could avoid writing any code.) > * multiple different OMX components filling same role? (Ie. different MP3 decoder components.) Again, I don't really see immediately how this could work, but I'm just brainstorming here. > > > Anything else? > > > BR, > -R > > > > ------------------------------------------------------------------------------ > 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-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > |
|
From: Felipe C. <fel...@gm...> - 2010-02-22 15:37:32
|
On Mon, Feb 22, 2010 at 5:29 PM, Clark, Rob <ro...@ti...> wrote: > That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it. I don't think there's any need for a complicated structure, so XML is overkill, specially if some systems don't have libxml2. Moreover I would like the file to be human readable; some people might like to modify it (for testing purposes or whatever). Personally I would write a simpler parser, but if anyone has better ideas/patches, I'm open for them. Cheers. -- Felipe Contreras |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 15:29:28
|
On Feb 22, 2010, at 8:44 AM, Tim-Philipp Müller wrote: > On Mon, 2010-02-22 at 08:32 -0600, Clark, Rob wrote: > >> On implementation side, what are your thoughts about using libxml2? It >> seems a bit overkill, but it is already a dependency of gstreamer >> core. > > For what it's worth, this dependency only exists for the > serialisation/deserialisation API that no one really uses (not least > because we don't recommend that) and which only works partially anyway. > > On many embedded systems GStreamer will likely be built with > --disable-loadsave and hence without the libxml2 dependency. GstFileIndex? does anyone use that? That said, I don't mind doing something like a simple ini file syntax or some other similar syntax. Especially if the preference is to reduce dependency on libxml2. But if the dependency would be there anyways, might as well reuse it. BR, -R |
|
From: Tim-Philipp M. <t....@ze...> - 2010-02-22 14:44:33
|
On Mon, 2010-02-22 at 08:32 -0600, Clark, Rob wrote: > On implementation side, what are your thoughts about using libxml2? It > seems a bit overkill, but it is already a dependency of gstreamer > core. For what it's worth, this dependency only exists for the serialisation/deserialisation API that no one really uses (not least because we don't recommend that) and which only works partially anyway. On many embedded systems GStreamer will likely be built with --disable-loadsave and hence without the libxml2 dependency. Cheers -Tim |
|
From: Clark, R. <ro...@ti...> - 2010-02-22 14:32:31
|
On Apr 1, 2009, at 11:21 AM, Felipe Contreras wrote: > On Wed, Apr 1, 2009 at 6:45 PM, Stephen M. Webb <ste...@xa...> wrote: >> On 01/04/09 11:15, Felipe Contreras wrote: >>> >>> Yeah, that's the next step, I plan to implement something like: >>> ./configure MAPPING=maemo >>> >>> Would that fit your use case? >> >> No, configuring at compile time won't help, I need to configure at runtime. I >> want to be able to distribute a single gstreamer-openmax library binary >> package for, say, Cortex-A8 and be able to configure it at runtime (well, >> install time) for the actual hardware it's running on, say OMAP3, i.MX51, or >> QSD8x50. Just for example. >> >>> I am planning to do that soon, but of course I would not get mad if >>> you beat me to it :) >> >> I was hoping you'd say you were just about to check in the changes. I will >> now frown and grumble and see what I can come up with. > > Ah, I see. > > Well, there's definitely plans on that, but it's pretty low on my > priority list =/ > > My idea was to create a gst-openmax registry, with this API: > http://bugzilla.gnome.org/show_bug.cgi?id=350477 I was starting to think again about gst-openmax registry.. On implementation side, what are your thoughts about using libxml2? It seems a bit overkill, but it is already a dependency of gstreamer core. On requirements side, do you think any of following are needed: * Detect changes in registry at runtime? Or just check if file has changed at plugin_init() time? * Dynamic class instances.. Ie. be able to introduce new OMX components without creating a new GstOmx subclass? (Hypothetically you could put template caps and compression format in registry.. although I think it would be only extremelly simple cases where you could avoid writing any code.) * multiple different OMX components filling same role? (Ie. different MP3 decoder components.) Again, I don't really see immediately how this could work, but I'm just brainstorming here. Anything else? BR, -R |
|
From: Felipe C. <fel...@gm...> - 2010-02-22 12:09:20
|
On Mon, Feb 22, 2010 at 2:00 PM, Tejas <te...@pi...> wrote: > Hello Felipe, > As I was not able to play any video content with the help of omapfbsink plugin. Later I found that memory from frame buffer 1 was not mapped , because memory for fb1 has not been allocated. After my system of beagle board boots I am running following commands to allocate memory. > > My boot args is as followed. > > "setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omapfb.mode=dvi:1280x720MR-32@60 vram=12M'" I add "omapfb.vram=0:2M,1:4M". I'm not sure if you need that in recent DSS2. > $echo 8000000 > /sys/class/graphics/fb1/size > $fbset -fb /dev/fb1 -nonstd 1 > $echo "1" > /sys/devices/platform/omapdss/overlay1/enabled > $echo "$1,$2" > /sys/devices/platform/omapdss/overlay1/output_size > $echo "0,0" > /sys/devices/platform/omapdss/overlay1/position > $fbset -fb /dev/fb0 -xres $1 -yres $2 > $echo "0,0" > /sys/devices/platform/omapdss/overlay0/position > $echo "0" > /sys/devices/platform/omapdss/display0/enabled > $echo "" > /sys/devices/platform/omapdss/manager0/display > $echo "0" > /sys/devices/platform/omapdss/overlay1/enabled > $ > $echo "1" > /sys/devices/platform/omapdss/overlay1/enabled > $echo "dvi" > /sys/devices/platform/omapdss/manager0/display > $echo "1" > /sys/devices/platform/omapdss/display0/enabled > > I put all these command into one disp.sh file and run it as ./disp.sh 640 480, then 640x480 display comes and rest comes as black. Now I can run following command smoothly. > > $gst-launch-0.10 playbin uri=file:///648x480.mp4 AFAIK omapfbsink would do most of those sysctl commands. However maybe you are using and old version of gst-omapfb. > After that when I run following command, that display doesn't come properly. That video content is of resolution 1280 x 720. > > $gst-launch-0.10 playbin uri=file:///1280x720.mp4 > > After that I run ./disp.sh 1280 720 and then run above command I can play video properly. > > But when I run 1280 x 720 video file into totem movie player nothing is coming and only blue screen throught entire video play back. After getting log file it gives following error. > "omapdss MANAGER error: dispc_setup_plane failed for ovl 1" > > Can any one guide me to come out this error. That's really strange. Totem shouldn't be doing anything different... well, I't using playbin2 instead of playbin. Can you try that? Anyway, I would add debugging in gst-omapfb to find out what parameters are being used to setup the plane that make it fail. Cheers. -- Felipe Contreras |
|
From: Tejas <te...@pi...> - 2010-02-22 11:58:02
|
Hello Felipe, As I was not able to play any video content with the help of omapfbsink plugin. Later I found that memory from frame buffer 1 was not mapped , because memory for fb1 has not been allocated. After my system of beagle board boots I am running following commands to allocate memory. My boot args is as followed. "setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait omapfb.mode=dvi:1280x720MR-32@60 vram=12M'" $echo 8000000 > /sys/class/graphics/fb1/size $fbset -fb /dev/fb1 -nonstd 1 $echo "1" > /sys/devices/platform/omapdss/overlay1/enabled $echo "$1,$2" > /sys/devices/platform/omapdss/overlay1/output_size $echo "0,0" > /sys/devices/platform/omapdss/overlay1/position $fbset -fb /dev/fb0 -xres $1 -yres $2 $echo "0,0" > /sys/devices/platform/omapdss/overlay0/position $echo "0" > /sys/devices/platform/omapdss/display0/enabled $echo "" > /sys/devices/platform/omapdss/manager0/display $echo "0" > /sys/devices/platform/omapdss/overlay1/enabled $ $echo "1" > /sys/devices/platform/omapdss/overlay1/enabled $echo "dvi" > /sys/devices/platform/omapdss/manager0/display $echo "1" > /sys/devices/platform/omapdss/display0/enabled I put all these command into one disp.sh file and run it as ./disp.sh 640 480, then 640x480 display comes and rest comes as black. Now I can run following command smoothly. $gst-launch-0.10 playbin uri=file:///648x480.mp4 After that when I run following command, that display doesn't come properly. That video content is of resolution 1280 x 720. $gst-launch-0.10 playbin uri=file:///1280x720.mp4 After that I run ./disp.sh 1280 720 and then run above command I can play video properly. But when I run 1280 x 720 video file into totem movie player nothing is coming and only blue screen throught entire video play back. After getting log file it gives following error. "omapdss MANAGER error: dispc_setup_plane failed for ovl 1" Can any one guide me to come out this error. -Tejas. -----Original Message----- From: Felipe Contreras [mailto:fel...@gm...] Sent: Wednesday, February 17, 2010 7:13 PM To: Stefan Kost Cc: gst...@li... Subject: Re: [Gstreamer-openmax] AV Sync with Gst-OpenMax pluggin Hey Stefan, On Wed, Feb 17, 2010 at 2:55 PM, Stefan Kost <en...@ho...> wrote: > Felipe Contreras wrote: >> Because we need omx functionality. I guess it would be possible to >> forget about omx base classes and re-implement all the omx stuff >> inside audio and video base sinks, but I don't think we'll get any >> advantage from that. But then again, I haven't really spent that much >> time in sources and sinks; only encoders and decoders. >> >> > I have been thinking about this also. As we don't have multiple > inheritance, we need to implemnt this using a delegate pattern. E.g. > OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not > sure if that would work in your case. Yes, that seems to be the appropriate way to do it. There's already helper stuff in gstomx_util, but it doesn't have much GStreamer stuff; state changes, properties, events, interface stuff, etc. that currently the omx base classes are dealing with. -- Felipe Contreras ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Gstreamer-openmax mailing list Gst...@li... https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax |
|
From: Daniel C. <dch...@gm...> - 2010-02-18 15:29:31
|
Hi 2010/2/18 Victor Manuel Jáquez Leal <ce...@gm...>: > Hi all, > > On Wed, Feb 17, 2010 at 1:55 PM, Stefan Kost <en...@ho...> wrote: >> I have been thinking about this also. As we don't have multiple >> inheritance, we need to implemnt this using a delegate pattern. E.g. >> OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not >> sure if that would work in your case. > > Did I hear libgoo? :P AFAIR, libgoo did have an attempt to use the dasfsink plugin to run the OMX Clock and share to gstreamer. dasfsink is a GstBaseAudioSink plugin. It may need some more tweaking but it should work. > > cheers > > vmjl > > ------------------------------------------------------------------------------ > 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-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > |
|
From: Felipe C. <fel...@no...> - 2010-02-18 15:28:47
|
On Thu, Feb 18, 2010 at 11:27:53AM +0100, ext Victor Manuel Jáquez Leal wrote: > On Wed, Feb 17, 2010 at 1:55 PM, Stefan Kost <en...@ho...> wrote: > > I have been thinking about this also. As we don't have multiple > > inheritance, we need to implemnt this using a delegate pattern. E.g. > > OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not > > sure if that would work in your case. > > Did I hear libgoo? :P libgoo wouldn't do what gst-omx base clases help do: properties, events, state changes, interfaces. -- Felipe Contreras |
|
From: Victor M. J. L. <ce...@gm...> - 2010-02-18 10:28:03
|
Hi all, On Wed, Feb 17, 2010 at 1:55 PM, Stefan Kost <en...@ho...> wrote: > I have been thinking about this also. As we don't have multiple > inheritance, we need to implemnt this using a delegate pattern. E.g. > OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not > sure if that would work in your case. Did I hear libgoo? :P cheers vmjl |
|
From: HariGopal G. <har...@lg...> - 2010-02-17 15:01:40
|
|
From: Felipe C. <fel...@gm...> - 2010-02-17 14:12:15
|
Hey Stefan, On Wed, Feb 17, 2010 at 2:55 PM, Stefan Kost <en...@ho...> wrote: > Felipe Contreras wrote: >> Because we need omx functionality. I guess it would be possible to >> forget about omx base classes and re-implement all the omx stuff >> inside audio and video base sinks, but I don't think we'll get any >> advantage from that. But then again, I haven't really spent that much >> time in sources and sinks; only encoders and decoders. >> >> > I have been thinking about this also. As we don't have multiple > inheritance, we need to implemnt this using a delegate pattern. E.g. > OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not > sure if that would work in your case. Yes, that seems to be the appropriate way to do it. There's already helper stuff in gstomx_util, but it doesn't have much GStreamer stuff; state changes, properties, events, interface stuff, etc. that currently the omx base classes are dealing with. -- Felipe Contreras |
|
From: Stefan K. <en...@ho...> - 2010-02-17 12:54:55
|
Hi, Felipe Contreras wrote: > On Wed, Feb 17, 2010 at 1:33 PM, Nitin PAI <nit...@gm...> wrote: > >> Thanks a lot for your reply. >> I am looking into the alternatives to implement this. Just wanted to make >> sure I am not re-inventing the wheel. >> If anyone has better ideas or has implemented this let me know. >> >> Can you tell me why the audio sink implementation uses GstBaseSink instead >> of GstAudioBaseSink which might have provided clock features to implement >> and set the master clock? >> > > Because we need omx functionality. I guess it would be possible to > forget about omx base classes and re-implement all the omx stuff > inside audio and video base sinks, but I don't think we'll get any > advantage from that. But then again, I haven't really spent that much > time in sources and sinks; only encoders and decoders. > > I have been thinking about this also. As we don't have multiple inheritance, we need to implemnt this using a delegate pattern. E.g. OmxAudioSink would *be *a GstBaseAudioSink and *have* a OmxHelper. Not sure if that would work in your case. Stefan |
|
From: Felipe C. <fel...@gm...> - 2010-02-17 11:56:00
|
On Wed, Feb 17, 2010 at 1:33 PM, Nitin PAI <nit...@gm...> wrote: > Thanks a lot for your reply. > I am looking into the alternatives to implement this. Just wanted to make > sure I am not re-inventing the wheel. > If anyone has better ideas or has implemented this let me know. > > Can you tell me why the audio sink implementation uses GstBaseSink instead > of GstAudioBaseSink which might have provided clock features to implement > and set the master clock? Because we need omx functionality. I guess it would be possible to forget about omx base classes and re-implement all the omx stuff inside audio and video base sinks, but I don't think we'll get any advantage from that. But then again, I haven't really spent that much time in sources and sinks; only encoders and decoders. >>>Then there's the problem of A/V sync. This has been discussed in the >>>past and the consensus is that the best way to implement this would be >>>to map OpenMAX IL clock to GStreamer's clock. > I will go through this. Please give me more pointers if we have a plugin for > clock component in gst-openmax? I'm not sure I get the question. Are you asking if there's any work on a clock in gst-openmax? If so, not AFAIK. Cheers. -- Felipe Contreras |
|
From: Nitin P. <nit...@gm...> - 2010-02-17 11:33:39
|
Hi Felipe, Thanks a lot for your reply. I am looking into the alternatives to implement this. Just wanted to make sure I am not re-inventing the wheel. If anyone has better ideas or has implemented this let me know. Can you tell me why the audio sink implementation uses GstBaseSink instead of GstAudioBaseSink which might have provided clock features to implement and set the master clock? >>Then there's the problem of A/V sync. This has been discussed in the >>past and the consensus is that the best way to implement this would be >>to map OpenMAX IL clock to GStreamer's clock. I will go through this. Please give me more pointers if we have a plugin for clock component in gst-openmax? Thanks, Nitin On Wed, Feb 17, 2010 at 4:40 PM, Felipe Contreras < fel...@gm...> wrote: > Hi Nitin, > > On Mon, Feb 8, 2010 at 11:25 AM, Nitin PAI <nit...@gm...> wrote: > > I am working on adding gstreamer support for our proprietary openmax > > multimedia stack. So the best choice is to use gst-openmax pluggin. > > I am facing problems with Audio Video Synchronization. > > > > Basically, > > 1) How is startup AV sync handled in gst-openmax pluggin? There is a > deep > > pipeline in our audio stack. Just EmptyBufferDone call from audio sink > > doesnt imply that the audio is played. This is handled via > FirstAudioFrame > > played event from the openmax core. > > 2) How is AV sync done. I mean basically the decision to do video frame > > drops or video frame hold? > > > > I will really appreciate some writeup on this. > > Well, first of all, tunneling is not implemented yet in gst-openmax, > there are some proposed patches but apparently some big changes are > needed since GStreamer's base classes don't seem to consider these > cases. > > Then there's the problem of A/V sync. This has been discussed in the > past and the consensus is that the best way to implement this would be > to map OpenMAX IL clock to GStreamer's clock. > > I don't have plans to implement this, so somebody else would need to do > that. > > -- > Felipe Contreras > -- “Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te sango stav karmani” - Krishna |
|
From: Felipe C. <fel...@gm...> - 2010-02-17 11:10:15
|
Hi Nitin, On Mon, Feb 8, 2010 at 11:25 AM, Nitin PAI <nit...@gm...> wrote: > I am working on adding gstreamer support for our proprietary openmax > multimedia stack. So the best choice is to use gst-openmax pluggin. > I am facing problems with Audio Video Synchronization. > > Basically, > 1) How is startup AV sync handled in gst-openmax pluggin? There is a deep > pipeline in our audio stack. Just EmptyBufferDone call from audio sink > doesnt imply that the audio is played. This is handled via FirstAudioFrame > played event from the openmax core. > 2) How is AV sync done. I mean basically the decision to do video frame > drops or video frame hold? > > I will really appreciate some writeup on this. Well, first of all, tunneling is not implemented yet in gst-openmax, there are some proposed patches but apparently some big changes are needed since GStreamer's base classes don't seem to consider these cases. Then there's the problem of A/V sync. This has been discussed in the past and the consensus is that the best way to implement this would be to map OpenMAX IL clock to GStreamer's clock. I don't have plans to implement this, so somebody else would need to do that. -- Felipe Contreras |
|
From: Nitin P. <nit...@gm...> - 2010-02-08 09:25:34
|
Hi , I am working on adding gstreamer support for our proprietary openmax multimedia stack. So the best choice is to use gst-openmax pluggin. I am facing problems with Audio Video Synchronization. Basically, 1) How is startup AV sync handled in gst-openmax pluggin? There is a deep pipeline in our audio stack. Just EmptyBufferDone call from audio sink doesnt imply that the audio is played. This is handled via FirstAudioFrame played event from the openmax core. 2) How is AV sync done. I mean basically the decision to do video frame drops or video frame hold? I will really appreciate some writeup on this. Thanks, Nitin |
|
From: Felipe C. <fel...@gm...> - 2010-02-01 14:55:19
|
On Thu, Jan 28, 2010 at 9:13 PM, Stephen M. Webb <ste...@xa...> wrote: > I have stumbled upon the need to add new components (eg. video_decoder.mpeg2, > video_decoder.xvid, etc.). Is it true that I will have to add an all-new set > of classes derived from GstOmxBaseVideoDec, one for each component, or is > there another preferred way? XVid should be covered by mpeg4dec. But for MPEG-2 yeah, you would need a new class, but as you can see it's very simple to add them. -- Felipe Contreras |
|
From: Stephen M. W. <ste...@xa...> - 2010-01-28 19:40:34
|
I have stumbled upon the need to add new components (eg. video_decoder.mpeg2, video_decoder.xvid, etc.). Is it true that I will have to add an all-new set of classes derived from GstOmxBaseVideoDec, one for each component, or is there another preferred way? -- Stephen M. Webb Xandros ste...@xa... www.xandros.com |
|
From: Felipe C. <fel...@no...> - 2010-01-22 15:10:28
|
On Thu, Jan 21, 2010 at 01:05:53PM +0100, ext spa...@si... wrote: > Is there any plan to wrap GStreamer to OpenMax AL interface Not as far as I know, but it would be an interesting project. -- Felipe Contreras |
|
From: <spa...@si...> - 2010-01-21 12:09:13
|
Is there any plan to wrap GStreamer to OpenMax AL interface |
3 messages has been excluded from this view by a project administrator.
