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: 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-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: 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: 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: 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: 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 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: 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: 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 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: 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 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-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 > |