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: Tim-Philipp M. <t....@ze...> - 2011-02-11 01:18:59
|
This mailing list has moved to: gst...@li... Your subscription should have been transferred automatically (unless you had the "hidden" flag set) and you should already have received a welcome e-mail from the new list. If you haven't, please check your SPAM filters and other mail filters and sign up again on http://lists.freedesktop.org/mailman/listinfo/gstreamer-openmax if needed. The old mailing list will be disabled for posting. Thanks for reading, see you on the other side! Cheers -Tim |
From: Tim-Philipp M. <t....@ze...> - 2011-02-11 00:42:57
|
This mailing list has moved to: gst...@li... Your subscription should have been transferred automatically (unless you had the "hidden" flag set) and you should already have received a welcome e-mail from the new list. If you haven't, please check your SPAM filters and other mail filters and sign up again on http://lists.freedesktop.org/mailman/listinfo/gstreamer-openmax if needed. The old mailing list will be disabled for posting. Thanks for reading, see you on the other side! Cheers -Tim |
From: giulio u. <giu...@gm...> - 2011-01-27 07:43:48
|
Hi Felipe, your suggestions for code readability improvement are interesting, and I'll take into account a rework of the framework in this direction. Some complications have a reason, like the use of DERIVEDCLASS that is useful using doxygen, but I see your point here. The support for interoperability is meant to be between OpenMAX components of different vendors, and different loaders. So it implies the possibility of the coexistence between components produced by different companies. I must be pragmatic in this case, and I have to admit that in the real world I don't see examples of interoperant products, so the support for it is not a high priority. I have to investigate the actual problems of interaction between gst-omx and Bellagio, because there are no obvious reasons because it does not work any more. I'll keep you updated on this list. Best Regards, Giulio On Wed, Jan 26, 2011 at 18:47, Felipe Contreras <fel...@gm...> wrote: > Hi Giulio, > > On Wed, Jan 26, 2011 at 5:40 PM, giulio urlini <giu...@gm...> wrote: >> my two cents from Bellagio, with an opinion of pros and cons of >> Bellagio framework. >> >> The Bellagio framework has been build so complicated in order to cover >> all the definition and use cases of the standard, trying to reflect >> the general opinion of the OpenMAX Khronos group about the behavior of >> core and components in any use case. It covers also all the spec, with >> a full interoperability support. > > Sure, but you can achieve the same goals with simpler code. > > For example: > > DERIVEDCLASS(omx_base_filter_PrivateType, omx_base_component_PrivateType) > #define omx_base_filter_PrivateType_FIELDS > omx_base_component_PrivateType_FIELDS \ > /** @param pPendingOutputBuffer pending Output Buffer pointer */ \ > OMX_BUFFERHEADERTYPE* pPendingOutputBuffer; \ > /** @param BufferMgmtCallback function pointer for algorithm callback */ \ > void (*BufferMgmtCallback)(OMX_COMPONENTTYPE* openmaxStandComp, > OMX_BUFFERHEADERTYPE* inputbuffer, OMX_BUFFERHEADERTYPE* > outputbuffer); > ENDCLASS(omx_base_filter_PrivateType) > > This could be simplified a lot by doing something like: > > struct omx_base_filter { > struct omx_base_component parent; > OMX_BUFFERHEADERTYPE *pending_buffer; > ... > }; > > In fact, rather than having these base classes, it would probably be > more useful if the functionality of these bases classes was provided > to the components as utilities, that they might decide to use or not. > > Not to mention that the code is overly verbose: > omx_base_component_PrivateType* omx_base_component_Private; > omx_base_component_Private = > (omx_base_component_PrivateType*)openmaxStandComp->pComponentPrivate; > > Could be easily simplified to: > omx_base_component_PrivateType *base; > base = standard->pComponentPrivate; > > Or here: > omx_base_component_Private->state = OMX_StateLoaded; > omx_base_component_Private->transientState = OMX_TransStateMax; > omx_base_component_Private->callbacks = NULL; > omx_base_component_Private->callbackData = NULL; > omx_base_component_Private->nGroupPriority = 100; > omx_base_component_Private->nGroupID = 0; > omx_base_component_Private->pMark.hMarkTargetComponent = NULL; > > s/omx_base_component_Private/base/ > > Theres many many ways in which the code can be simplified, made easier > to read, and more maintainable. > > Also, I'm not sure about the "full interoperability" support. I'm > pretty sure if an implementation is compliant, it should work with > gst-openmax without changes. Bellagio did at some point, and then it > suddenly stopped. It might be the the API remains compatible, but the > data streams are not, to me that's a break all the same. > >> Finally it has a support for multiple loaders mechanism, necessary to >> allow the necessary flexibility since this part is not covered >> intentionally by the standard. > > Well, I don't think it's necessary. If you need another loader, you > use another omx implementation. What is there in an omx core other > than the loader anyway? > > I have experimented with this, it's possible to load TI components > (which don't use bellagio base clases) with bellagio loader. And it's > also possible to load bellagio components into TI's omx core. At the > end of the day the only difference of these implementations are the > loaders. > >> For sure I'll take a look at your implementation, but my opinion is >> that the spec itself, if considered entirely is complicated, and a >> "reference" implementation would be complicated as well. > > Sure, if your objective is to implement as most as the standard as possible. > > I would prefer to have a trampoline implementation, which people can > use to develop their own components. And for that purpose simplicity > is key. > >> Actually in Linaro Bellagio has been recognized as the reference for >> standard OpenMAX support, so probably concentrating the efforts on it >> and on the improvement of the interaction with gst-omx can be useful >> for everyone. >> >> https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/StandardizeBellagioOmxCore >> >> We are totally open to it, and we are increasing the effort spent on >> this project. > > Maybe. It would certainly be nice to get bellagio working on > gst-openmax again, but I'm not going to do that any more. I think it's > a better use of my time to implement ffmpeg wrappers for libomxil-g, > and make it more extensible. > > Cheers. > > -- > Felipe Contreras > |
From: Clark, R. <ro...@ti...> - 2011-01-26 22:37:49
|
On Wed, Jan 26, 2011 at 8:51 AM, Felipe Contreras < fel...@gm...> wrote: > > 3) Your solution doesn't conform with GStreamer API > > You can't just pad_buffer_alloc() and unref a buffer. If this buffer > comes from a sink that has a ring-buffer, like pulsesink, the sequence > would be screwed up. > > note: this is generally a problem with OpenMAX, if you want to allow reverse caps negotiation to influence the output port params. You need to allocate a buffer to trigger caps negotiation.. although that isn't yet a convenient point to use the buffer. I guess you could stuff the buffer in some member field in GOmxPort or somewhere like that, and then use it later. Not very elegant... At least it isn't a problem with the video sinks I've seen. But it is a valid point if you want to use OMX based audio decoders. BR, -R |
From: Felipe C. <fel...@gm...> - 2011-01-26 22:37:36
|
Hi Giulio, On Wed, Jan 26, 2011 at 5:40 PM, giulio urlini <giu...@gm...> wrote: > my two cents from Bellagio, with an opinion of pros and cons of > Bellagio framework. > > The Bellagio framework has been build so complicated in order to cover > all the definition and use cases of the standard, trying to reflect > the general opinion of the OpenMAX Khronos group about the behavior of > core and components in any use case. It covers also all the spec, with > a full interoperability support. Sure, but you can achieve the same goals with simpler code. For example: DERIVEDCLASS(omx_base_filter_PrivateType, omx_base_component_PrivateType) #define omx_base_filter_PrivateType_FIELDS omx_base_component_PrivateType_FIELDS \ /** @param pPendingOutputBuffer pending Output Buffer pointer */ \ OMX_BUFFERHEADERTYPE* pPendingOutputBuffer; \ /** @param BufferMgmtCallback function pointer for algorithm callback */ \ void (*BufferMgmtCallback)(OMX_COMPONENTTYPE* openmaxStandComp, OMX_BUFFERHEADERTYPE* inputbuffer, OMX_BUFFERHEADERTYPE* outputbuffer); ENDCLASS(omx_base_filter_PrivateType) This could be simplified a lot by doing something like: struct omx_base_filter { struct omx_base_component parent; OMX_BUFFERHEADERTYPE *pending_buffer; ... }; In fact, rather than having these base classes, it would probably be more useful if the functionality of these bases classes was provided to the components as utilities, that they might decide to use or not. Not to mention that the code is overly verbose: omx_base_component_PrivateType* omx_base_component_Private; omx_base_component_Private = (omx_base_component_PrivateType*)openmaxStandComp->pComponentPrivate; Could be easily simplified to: omx_base_component_PrivateType *base; base = standard->pComponentPrivate; Or here: omx_base_component_Private->state = OMX_StateLoaded; omx_base_component_Private->transientState = OMX_TransStateMax; omx_base_component_Private->callbacks = NULL; omx_base_component_Private->callbackData = NULL; omx_base_component_Private->nGroupPriority = 100; omx_base_component_Private->nGroupID = 0; omx_base_component_Private->pMark.hMarkTargetComponent = NULL; s/omx_base_component_Private/base/ Theres many many ways in which the code can be simplified, made easier to read, and more maintainable. Also, I'm not sure about the "full interoperability" support. I'm pretty sure if an implementation is compliant, it should work with gst-openmax without changes. Bellagio did at some point, and then it suddenly stopped. It might be the the API remains compatible, but the data streams are not, to me that's a break all the same. > Finally it has a support for multiple loaders mechanism, necessary to > allow the necessary flexibility since this part is not covered > intentionally by the standard. Well, I don't think it's necessary. If you need another loader, you use another omx implementation. What is there in an omx core other than the loader anyway? I have experimented with this, it's possible to load TI components (which don't use bellagio base clases) with bellagio loader. And it's also possible to load bellagio components into TI's omx core. At the end of the day the only difference of these implementations are the loaders. > For sure I'll take a look at your implementation, but my opinion is > that the spec itself, if considered entirely is complicated, and a > "reference" implementation would be complicated as well. Sure, if your objective is to implement as most as the standard as possible. I would prefer to have a trampoline implementation, which people can use to develop their own components. And for that purpose simplicity is key. > Actually in Linaro Bellagio has been recognized as the reference for > standard OpenMAX support, so probably concentrating the efforts on it > and on the improvement of the interaction with gst-omx can be useful > for everyone. > > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/StandardizeBellagioOmxCore > > We are totally open to it, and we are increasing the effort spent on > this project. Maybe. It would certainly be nice to get bellagio working on gst-openmax again, but I'm not going to do that any more. I think it's a better use of my time to implement ffmpeg wrappers for libomxil-g, and make it more extensible. Cheers. -- Felipe Contreras |
From: giulio u. <giu...@gm...> - 2011-01-26 15:46:19
|
Hi Felipe, my two cents from Bellagio, with an opinion of pros and cons of Bellagio framework. The Bellagio framework has been build so complicated in order to cover all the definition and use cases of the standard, trying to reflect the general opinion of the OpenMAX Khronos group about the behavior of core and components in any use case. It covers also all the spec, with a full interoperability support. Finally it has a support for multiple loaders mechanism, necessary to allow the necessary flexibility since this part is not covered intentionally by the standard. For sure I'll take a look at your implementation, but my opinion is that the spec itself, if considered entirely is complicated, and a "reference" implementation would be complicated as well. Actually in Linaro Bellagio has been recognized as the reference for standard OpenMAX support, so probably concentrating the efforts on it and on the improvement of the interaction with gst-omx can be useful for everyone. https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/StandardizeBellagioOmxCore We are totally open to it, and we are increasing the effort spent on this project. Best Regards, Giulio On Wed, Jan 26, 2011 at 16:05, Benjamin Gaignard <ben...@li...> wrote: > Hi, > > 1) I use bellagio only for the first tests on my desktop before going on > "real" world (I mean on the ARM device from TI, STE or Freescale or > anyother with openmax components). > > 2) Most of the ARM devices don't have hw decoder/encoder with MMU > capabilities (and yes it is a shame) so we have to take of that, and the > "share buffer" hack doesn't in this case. > > 3) about gst_pad_alloc_buffer: you are right is it a problem with ring > buffer, and Rob comments also suggest that isn't a good idea... > > Benjamin > 2011/1/26 Felipe Contreras <fel...@gm...> >> >> Hi, >> >> On Mon, Jan 24, 2011 at 3:16 PM, Benjamin Gaignard >> <ben...@li...> wrote: >> > For Linaro project I working on a new implementation of gst-openmax to >> > allow >> > zero copy between OMX element in gstreamer. >> > >> > On this page: >> > >> > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor >> > I have put sequence diagrams of what we want to achieve. >> > >> > We are looking for feedbacks about this proposal and all comment are >> > welcome. >> >> Here are my comments: >> >> 1) Why bellagio? >> >> Bellagio is largely unmaintained and too complicated IMO. I have >> contributed to the bellagio project, and although I think it has >> contributed greatly to the OpenMAX ecosystem, I think I can write >> something simpler that does the same in a short period of time. In >> fact, I kind of did already: >> >> https://github.com/felipec/libomxil-g >> >> This is a good example of how simple an OpenMAX IL implementation can be. >> >> Also, recently bellagio stopped working at all for me. >> >> 2) gst-openmax already has zero-copy support >> >> Through the "share buffer" hacks, which is not ideal, but it works on >> the implementations that support this. Any hardware that has an MMU >> (all decent hw should) should have no trouble with it. >> >> Your solution on the other hand would _not_ provide zero-copy support >> for non-omx elements. >> >> 3) Your solution doesn't conform with GStreamer API >> >> You can't just pad_buffer_alloc() and unref a buffer. If this buffer >> comes from a sink that has a ring-buffer, like pulsesink, the sequence >> would be screwed up. >> >> This could be easily fixed by checking of the next element implements >> the gst-openmax interface, and add some kind of query. >> >> Cheers. >> >> -- >> Felipe Contreras > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Gstreamer-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > |
From: Felipe C. <fel...@gm...> - 2011-01-26 15:44:37
|
On Wed, Jan 26, 2011 at 5:05 PM, Benjamin Gaignard <ben...@li...> wrote: > Hi, > > 1) I use bellagio only for the first tests on my desktop before going on > "real" world (I mean on the ARM device from TI, STE or Freescale or > anyother with openmax components). Oh, ok. This sentence might need reworking then: All vendors use OMX bellagio core and have OMX audio/video decoder/encoder. > 2) Most of the ARM devices don't have hw decoder/encoder with MMU > capabilities (and yes it is a shame) so we have to take of that, and the > "share buffer" hack doesn't in this case. All the ARM devices I've seen do. What would you do for the big buffers needed for 12mpx or 1080p then? Reserve 40M of RAM out of the system memory? > 3) about gst_pad_alloc_buffer: you are right is it a problem with ring > buffer, and Rob comments also suggest that isn't a good idea... Ok, fortunately that's the easiest to fix. Cheers. -- Felipe Contreras |
From: Benjamin G. <ben...@li...> - 2011-01-26 15:05:25
|
Hi, 1) I use bellagio only for the first tests on my desktop before going on "real" world (I mean on the ARM device from TI, STE or Freescale or anyother with openmax components). 2) Most of the ARM devices don't have hw decoder/encoder with MMU capabilities (and yes it is a shame) so we have to take of that, and the "share buffer" hack doesn't in this case. 3) about gst_pad_alloc_buffer: you are right is it a problem with ring buffer, and Rob comments also suggest that isn't a good idea... Benjamin 2011/1/26 Felipe Contreras <fel...@gm...> > Hi, > > On Mon, Jan 24, 2011 at 3:16 PM, Benjamin Gaignard > <ben...@li...> wrote: > > For Linaro project I working on a new implementation of gst-openmax to > allow > > zero copy between OMX element in gstreamer. > > > > On this page: > > > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor > > I have put sequence diagrams of what we want to achieve. > > > > We are looking for feedbacks about this proposal and all comment are > > welcome. > > Here are my comments: > > 1) Why bellagio? > > Bellagio is largely unmaintained and too complicated IMO. I have > contributed to the bellagio project, and although I think it has > contributed greatly to the OpenMAX ecosystem, I think I can write > something simpler that does the same in a short period of time. In > fact, I kind of did already: > > https://github.com/felipec/libomxil-g > > This is a good example of how simple an OpenMAX IL implementation can be. > > Also, recently bellagio stopped working at all for me. > > 2) gst-openmax already has zero-copy support > > Through the "share buffer" hacks, which is not ideal, but it works on > the implementations that support this. Any hardware that has an MMU > (all decent hw should) should have no trouble with it. > > Your solution on the other hand would _not_ provide zero-copy support > for non-omx elements. > > 3) Your solution doesn't conform with GStreamer API > > You can't just pad_buffer_alloc() and unref a buffer. If this buffer > comes from a sink that has a ring-buffer, like pulsesink, the sequence > would be screwed up. > > This could be easily fixed by checking of the next element implements > the gst-openmax interface, and add some kind of query. > > Cheers. > > -- > Felipe Contreras > |
From: Felipe C. <fel...@gm...> - 2011-01-26 14:56:52
|
Hi, On Mon, Jan 24, 2011 at 3:16 PM, Benjamin Gaignard <ben...@li...> wrote: > For Linaro project I working on a new implementation of gst-openmax to allow > zero copy between OMX element in gstreamer. > > On this page: > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor > I have put sequence diagrams of what we want to achieve. > > We are looking for feedbacks about this proposal and all comment are > welcome. Here are my comments: 1) Why bellagio? Bellagio is largely unmaintained and too complicated IMO. I have contributed to the bellagio project, and although I think it has contributed greatly to the OpenMAX ecosystem, I think I can write something simpler that does the same in a short period of time. In fact, I kind of did already: https://github.com/felipec/libomxil-g This is a good example of how simple an OpenMAX IL implementation can be. Also, recently bellagio stopped working at all for me. 2) gst-openmax already has zero-copy support Through the "share buffer" hacks, which is not ideal, but it works on the implementations that support this. Any hardware that has an MMU (all decent hw should) should have no trouble with it. Your solution on the other hand would _not_ provide zero-copy support for non-omx elements. 3) Your solution doesn't conform with GStreamer API You can't just pad_buffer_alloc() and unref a buffer. If this buffer comes from a sink that has a ring-buffer, like pulsesink, the sequence would be screwed up. This could be easily fixed by checking of the next element implements the gst-openmax interface, and add some kind of query. Cheers. -- Felipe Contreras |
From: Felipe C. <fel...@gm...> - 2011-01-26 13:59:49
|
2011/1/25 Clark, Rob <ro...@ti...>: > 2011/1/25 Victor Manuel Jáquez Leal <ce...@gm...>: >> 2011/1/25 Benjamin Gaignard <ben...@li...>: >>> you are right, the operation flow are very similar but we create an >>> overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph >> >> Aha, the same strategy used in gst-goo [1]. There was a reason why >> Felipec didn't use it, but I don't recalled it right know :s >> >> 1. https://github.com/mrchapp/gst-goo/blob/master/src/gstgoobuffer.c > > it is similar.. but not really intended for "ghost buffers" (tunneling).. > > I guess for most common scenario's Felipec was not using an omx based > sink element.. and also didn't have the same constraints about > physically contiguous buffers in the decoder/encoder elements. And > also not the same complications of reference counting when sharing > buffers with the decoder. Huh? Physically contiguous buffers? Are we talking about linux here? -- Felipe Contreras |
From: Felipe C. <fel...@gm...> - 2011-01-26 13:41:54
|
2011/1/25 Benjamin Gaignard <ben...@li...>: > you are right, the operation flow are very similar but we create an > overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph Note that gst-openmax already offers zero-copy support through the "share hacks". > With gstomxbuffer the sequence is no more: > emptybufferdone -> memcpy in gst buffer -> fillthisbuffer -> pad push > gstbuffer > it becomes: > emptybufferdone -> pad push gstomxbuffer -> gstomxbuffer unref -> > fillthisbuffer I did implement this GstOmxBuffer at some point (maybe I already have the branch somewhere), however, I did not notice any advantage, it just made the code more complicated. I have been planning to reorganize the buffer handling code, as right now it's buggy, and I would like to isolate the "share hack" implementation so it's ugliness doesn't affect the rest of the code. Similarly, this GstOmxBuffer strategy could be isolated the same way. If I truly had something against GstOmxBuffer, I don't remember anymore what that was. Cheers. -- Felipe Contreras |
From: Clark, R. <ro...@ti...> - 2011-01-25 14:15:43
|
2011/1/25 Victor Manuel Jáquez Leal <ce...@gm...>: > 2011/1/25 Benjamin Gaignard <ben...@li...>: >> you are right, the operation flow are very similar but we create an >> overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph > > Aha, the same strategy used in gst-goo [1]. There was a reason why > Felipec didn't use it, but I don't recalled it right know :s > > 1. https://github.com/mrchapp/gst-goo/blob/master/src/gstgoobuffer.c > it is similar.. but not really intended for "ghost buffers" (tunneling).. I guess for most common scenario's Felipec was not using an omx based sink element.. and also didn't have the same constraints about physically contiguous buffers in the decoder/encoder elements. And also not the same complications of reference counting when sharing buffers with the decoder. Benjamin's proposal helps, I think.. at least when there is an omx based sink element. Although there are edge cases to think through.. pad_alloc() can fail when downstream element is still flushing, for example. Or do you want to (or can you at all) support dynamically switching sink elements in a pipeline. GStreamer is quite flexible.. making that flexibility coexist with OpenMAX is sometimes challenging ;-) BR, -R > vmjl > >> >> With gstomxbuffer the sequence is no more: >> emptybufferdone -> memcpy in gst buffer -> fillthisbuffer -> pad push >> gstbuffer >> it becomes: >> emptybufferdone -> pad push gstomxbuffer -> gstomxbuffer unref -> >> fillthisbuffer >> Benjamin >> Le 25 janvier 2011 10:58, Victor Manuel Jáquez Leal <ce...@gm...> a >> écrit : >>> >>> On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard >>> <ben...@li...> wrote: >>> > Hi, >>> > >>> > For Linaro project I working on a new implementation of gst-openmax to >>> > allow >>> > zero copy between OMX element in gstreamer. >>> >>> Glancing the diagrams, the operation flow is pretty much what >>> gst-openmax does. Am I wrong? But if so, why another implementation? >>> Forking is the only option? >>> >>> vmjl >>> >>> > >>> > On this page: >>> > >>> > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor >>> > I have put sequence diagrams of what we want to achieve. >>> > >>> > We are looking for feedbacks about this proposal and all comment are >>> > welcome. >>> > >>> > Benjamin >>> > >>> > ------------------------------------------------------------------------------ >>> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >>> > Finally, a world-class log management solution at an even better >>> > price-free! >>> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires >>> > February 28th, so secure your free ArcSight Logger TODAY! >>> > http://p.sf.net/sfu/arcsight-sfd2d >>> > _______________________________________________ >>> > Gstreamer-openmax mailing list >>> > Gst...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax >>> > >>> > >> >> > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Gstreamer-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > |
From: Victor M. J. L. <ce...@gm...> - 2011-01-25 12:17:18
|
2011/1/25 Benjamin Gaignard <ben...@li...>: > you are right, the operation flow are very similar but we create an > overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph Aha, the same strategy used in gst-goo [1]. There was a reason why Felipec didn't use it, but I don't recalled it right know :s 1. https://github.com/mrchapp/gst-goo/blob/master/src/gstgoobuffer.c vmjl > > With gstomxbuffer the sequence is no more: > emptybufferdone -> memcpy in gst buffer -> fillthisbuffer -> pad push > gstbuffer > it becomes: > emptybufferdone -> pad push gstomxbuffer -> gstomxbuffer unref -> > fillthisbuffer > Benjamin > Le 25 janvier 2011 10:58, Victor Manuel Jáquez Leal <ce...@gm...> a > écrit : >> >> On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard >> <ben...@li...> wrote: >> > Hi, >> > >> > For Linaro project I working on a new implementation of gst-openmax to >> > allow >> > zero copy between OMX element in gstreamer. >> >> Glancing the diagrams, the operation flow is pretty much what >> gst-openmax does. Am I wrong? But if so, why another implementation? >> Forking is the only option? >> >> vmjl >> >> > >> > On this page: >> > >> > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor >> > I have put sequence diagrams of what we want to achieve. >> > >> > We are looking for feedbacks about this proposal and all comment are >> > welcome. >> > >> > Benjamin >> > >> > ------------------------------------------------------------------------------ >> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> > Finally, a world-class log management solution at an even better >> > price-free! >> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> > February 28th, so secure your free ArcSight Logger TODAY! >> > http://p.sf.net/sfu/arcsight-sfd2d >> > _______________________________________________ >> > Gstreamer-openmax mailing list >> > Gst...@li... >> > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax >> > >> > > > |
From: Benjamin G. <ben...@li...> - 2011-01-25 11:32:39
|
you are right, the operation flow are very similar but we create an overloaded gst buffer (gstomxbuffer) to allow zero copy in gstreamer graph With gstomxbuffer the sequence is no more: emptybufferdone -> memcpy in gst buffer -> fillthisbuffer -> pad push gstbuffer it becomes: emptybufferdone -> pad push gstomxbuffer -> gstomxbuffer unref -> fillthisbuffer Benjamin Le 25 janvier 2011 10:58, Victor Manuel Jáquez Leal <ce...@gm...> a écrit : > On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard > <ben...@li...> wrote: > > Hi, > > > > For Linaro project I working on a new implementation of gst-openmax to > allow > > zero copy between OMX element in gstreamer. > > Glancing the diagrams, the operation flow is pretty much what > gst-openmax does. Am I wrong? But if so, why another implementation? > Forking is the only option? > > vmjl > > > > > On this page: > > > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor > > I have put sequence diagrams of what we want to achieve. > > > > We are looking for feedbacks about this proposal and all comment are > > welcome. > > > > Benjamin > > > ------------------------------------------------------------------------------ > > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > > Finally, a world-class log management solution at an even better > price-free! > > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > > February 28th, so secure your free ArcSight Logger TODAY! > > http://p.sf.net/sfu/arcsight-sfd2d > > _______________________________________________ > > Gstreamer-openmax mailing list > > Gst...@li... > > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > > > > |
From: Victor M. J. L. <ce...@gm...> - 2011-01-25 09:58:08
|
On Mon, Jan 24, 2011 at 2:16 PM, Benjamin Gaignard <ben...@li...> wrote: > Hi, > > For Linaro project I working on a new implementation of gst-openmax to allow > zero copy between OMX element in gstreamer. Glancing the diagrams, the operation flow is pretty much what gst-openmax does. Am I wrong? But if so, why another implementation? Forking is the only option? vmjl > > On this page: > https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor > I have put sequence diagrams of what we want to achieve. > > We are looking for feedbacks about this proposal and all comment are > welcome. > > Benjamin > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Gstreamer-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > > |
From: Benjamin G. <ben...@li...> - 2011-01-24 13:42:16
|
Hi, For Linaro project I working on a new implementation of gst-openmax to allow zero copy between OMX element in gstreamer. On this page: https://wiki.linaro.org/WorkingGroups/Middleware/Multimedia/Specs/1105/ConsolidateGtsOmxMultivendor I have put sequence diagrams of what we want to achieve. We are looking for feedbacks about this proposal and all comment are welcome. Benjamin |
From: Clark, R. <ro...@ti...> - 2010-12-15 20:21:02
|
On Tue, Dec 14, 2010 at 12:52 AM, Kuo. Bard (GSM) <Bar...@co...> wrote: > > Thanks for reply, Clark and Felipe, > > I was confused when I study gst-openmax at the beginning. Now I know how it operate probably. > > If there were some flowchart or documents, it may helps me get a handle on gst-openmax faster. this might help: http://omapedia.org/wiki/Gstreamer_overview BR, -R > > Regarding OpenMax components setting, if there are some specific configure needed , where should I add in ? or just before setting omx states to excuting ? > > Thanks, > Bard > -----Original Message----- > From: Felipe Contreras [mailto:fel...@no...] > Sent: Tuesday, December 14, 2010 12:50 AM > To: Kuo. Bard (GSM); gst...@li... > Subject: Re: [Gstreamer-openmax] How to port gst-openmax > > Bard_Kuo@Compalcomm.com wrote: > > How to port gst-openmax ? > > I'm not sure what you mean. In theory if your OpenMAX IL implementation is > compliant, gst-openmax should not need any changes. > > > Is there some document describing how to use gst-openmax ? > > Not really, but it should be like any other GStreamer elements. > > A typical example pipeline would be: > > gst-launch filesrc location=test.avi ! avidemux ! omx_mpeg4dec ! xvimagesink > > However, you need to configure your library-name and component-name, an example > for Bellagio is: > > omx_mpeg4dec, > type=GstOmxMpeg4Dec, > library-name=libomxil-bellagio.so.0, > component-name=OMX.st.video_decoder.mpeg4, > sink="video/mpeg, mpegversion=(int)4, systemstream=false, " VIDEO_SIZE_RATE ";" \ > "video/x-divx, divxversion=(int)[4,5], " VIDEO_SIZE_RATE ";" \ > "video/x-xvid, " VIDEO_SIZE_RATE ";" \ > "video/x-3ivx, " VIDEO_SIZE_RATE ";", > src=RAW_VIDEO_CAPS, > rank=256; > > > How the process going in this plugin like flowchart, and how does it access OpenMax ? > > I am confused between two architectures. > > I don't understand your question. gst-openmax simply maps GStreamer flow to > OpenMAX IL. You can check the code in gstomx_base_filter.c and gstomx_util.c. > > Cheers. > > -- > Felipe Contreras > This message may contain information which is private, privileged or confidential of Compal Communications, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. > > CCI 2010 > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Gstreamer-openmax mailing list > Gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-openmax > |
From: Felipe C. <fel...@no...> - 2010-12-15 16:25:50
|
Bard_Kuo@Compalcomm.com wrote: > Thanks for reply, Clark and Felipe, > > I was confused when I study gst-openmax at the beginning. Now I know how it > operate probably. Good to know :) > If there were some flowchart or documents, it may helps me get a handle on > gst-openmax faster. Not that I'm aware of. > Regarding OpenMax components setting, if there are some specific configure > needed , where should I add in ? or just before setting omx states to > excuting ? The configuration file needs to be placed in a standard XDG location [1]. For example: /etc/xdg/gstreamer-0.10/gst-openmax.conf [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Felipe Contreras |
From: Kuo. B. (GSM) <Bard_Kuo@Compalcomm.com> - 2010-12-14 06:53:49
|
Thanks for reply, Clark and Felipe, I was confused when I study gst-openmax at the beginning. Now I know how it operate probably. If there were some flowchart or documents, it may helps me get a handle on gst-openmax faster. Regarding OpenMax components setting, if there are some specific configure needed , where should I add in ? or just before setting omx states to excuting ? Thanks, Bard -----Original Message----- From: Felipe Contreras [mailto:fel...@no...] Sent: Tuesday, December 14, 2010 12:50 AM To: Kuo. Bard (GSM); gst...@li... Subject: Re: [Gstreamer-openmax] How to port gst-openmax Bard_Kuo@Compalcomm.com wrote: > How to port gst-openmax ? I'm not sure what you mean. In theory if your OpenMAX IL implementation is compliant, gst-openmax should not need any changes. > Is there some document describing how to use gst-openmax ? Not really, but it should be like any other GStreamer elements. A typical example pipeline would be: gst-launch filesrc location=test.avi ! avidemux ! omx_mpeg4dec ! xvimagesink However, you need to configure your library-name and component-name, an example for Bellagio is: omx_mpeg4dec, type=GstOmxMpeg4Dec, library-name=libomxil-bellagio.so.0, component-name=OMX.st.video_decoder.mpeg4, sink="video/mpeg, mpegversion=(int)4, systemstream=false, " VIDEO_SIZE_RATE ";" \ "video/x-divx, divxversion=(int)[4,5], " VIDEO_SIZE_RATE ";" \ "video/x-xvid, " VIDEO_SIZE_RATE ";" \ "video/x-3ivx, " VIDEO_SIZE_RATE ";", src=RAW_VIDEO_CAPS, rank=256; > How the process going in this plugin like flowchart, and how does it access OpenMax ? > I am confused between two architectures. I don't understand your question. gst-openmax simply maps GStreamer flow to OpenMAX IL. You can check the code in gstomx_base_filter.c and gstomx_util.c. Cheers. -- Felipe Contreras This message may contain information which is private, privileged or confidential of Compal Communications, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. CCI 2010 |
From: Clark, R. <ro...@ti...> - 2010-12-13 19:16:56
|
On Mon, Dec 13, 2010 at 12:38 PM, Felipe Contreras <fel...@gm...> wrote: > On Mon, Dec 13, 2010 at 7:52 PM, Tim-Philipp Müller <t....@ze...> wrote: >> On Mon, 2010-12-13 at 18:55 +0200, Felipe Contreras wrote: >> >>> and the annoying 'automatic common update' is something I definitely >>> don't want on this tree. >> >> There's no link between using the common module and getting the >> automatic updates. gst-openmax is currently not in the list of modules >> that get updated like this. Just saying ;) > > Yeah, but we are getting dangerously close to that. > > Oh, and FWIW, the common submodule also complicates Maemo and MeeGo packaging. > Is it a problem with submodules, or a problem with common? I was hoping it was only bitbake that handled git submodules badly.. Well, I don't have a super-strong opinion about it.. I just wanted to align build and commit-hook with the other gst trees. If the issue is only submodules, I could update build-aux/update-common to add the additional files that were needed. BR, -R |
From: Felipe C. <fel...@gm...> - 2010-12-13 18:39:01
|
On Mon, Dec 13, 2010 at 7:52 PM, Tim-Philipp Müller <t....@ze...> wrote: > On Mon, 2010-12-13 at 18:55 +0200, Felipe Contreras wrote: > >> and the annoying 'automatic common update' is something I definitely >> don't want on this tree. > > There's no link between using the common module and getting the > automatic updates. gst-openmax is currently not in the list of modules > that get updated like this. Just saying ;) Yeah, but we are getting dangerously close to that. Oh, and FWIW, the common submodule also complicates Maemo and MeeGo packaging. -- Felipe Contreras |
From: Tim-Philipp M. <t....@ze...> - 2010-12-13 17:52:51
|
On Mon, 2010-12-13 at 18:55 +0200, Felipe Contreras wrote: > and the annoying 'automatic common update' is something I definitely > don't want on this tree. There's no link between using the common module and getting the automatic updates. gst-openmax is currently not in the list of modules that get updated like this. Just saying ;) -Tim |
From: Felipe C. <fel...@no...> - 2010-12-13 16:57:39
|
Hi Rob, Sorry for the delay. ro...@ti... wrote: > On Wed, Nov 3, 2010 at 8:56 PM, Rob Clark <ro...@ti...> wrote: > > Use common submodule and pre-commit hook, and cosemetic gstomx.h whitespace > > change. > > > > Rob Clark (2): > >  use common submodule > >  minor formatting cleanup > > > >  .gitignore        |   3 + > >  .gitmodules        |   3 + > >  autogen.sh        |  60 ++++++++-- > >  build-aux/gst-autogen.sh |  294 ---------------------------------------------- > >  common          |   1 + > >  configure.ac       |  17 ++- > >  omx/gstomx.h       |   6 +- > >  shave-libtool.in     |  69 ----------- > >  shave.in         |  79 ------------ > >  9 files changed, 74 insertions(+), 458 deletions(-) > >  create mode 100644 .gitmodules > >  delete mode 100644 build-aux/gst-autogen.sh > >  create mode 160000 common > >  delete mode 100644 shave-libtool.in > >  delete mode 100644 shave.in > > > > > > So I take it that silence means that no one has any objections to this > patchset or the tempate caps patchset? I don't like the common subdir one, but the rest look good. Thanks. -- Felipe Contreras |
From: Felipe C. <fel...@no...> - 2010-12-13 16:55:53
|
ro...@ti... wrote: > Align autogen.sh with other gst trees, including use of the commit-hook. > Also, shave no longer seemed to be working AM_SILENT_RULES (as used by > other gst trees) does. I don't like this patch at all, that's what build-aux/update-common was for. Adding the common submodule adds no value whatsoever, and the annoying 'automatic common update' is something I definitely don't want on this tree. What do you about reverting back and use build-aux/update-common? -- Felipe Contreras |
From: Felipe C. <fel...@no...> - 2010-12-13 16:50:33
|
Bard_Kuo@Compalcomm.com wrote: > How to port gst-openmax ? I'm not sure what you mean. In theory if your OpenMAX IL implementation is compliant, gst-openmax should not need any changes. > Is there some document describing how to use gst-openmax ? Not really, but it should be like any other GStreamer elements. A typical example pipeline would be: gst-launch filesrc location=test.avi ! avidemux ! omx_mpeg4dec ! xvimagesink However, you need to configure your library-name and component-name, an example for Bellagio is: omx_mpeg4dec, type=GstOmxMpeg4Dec, library-name=libomxil-bellagio.so.0, component-name=OMX.st.video_decoder.mpeg4, sink="video/mpeg, mpegversion=(int)4, systemstream=false, " VIDEO_SIZE_RATE ";" \ "video/x-divx, divxversion=(int)[4,5], " VIDEO_SIZE_RATE ";" \ "video/x-xvid, " VIDEO_SIZE_RATE ";" \ "video/x-3ivx, " VIDEO_SIZE_RATE ";", src=RAW_VIDEO_CAPS, rank=256; > How the process going in this plugin like flowchart, and how does it access OpenMax ? > I am confused between two architectures. I don't understand your question. gst-openmax simply maps GStreamer flow to OpenMAX IL. You can check the code in gstomx_base_filter.c and gstomx_util.c. Cheers. -- Felipe Contreras |