Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Fri, Jul 6, 2012 at 2:47 PM, Vincent Torri vincent.to...@gmail.com wrote: On Fri, Jul 6, 2012 at 7:37 AM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 11:28 PM, Jorge Luis Zapata Muga jorgeluis.zap...@gmail.com wrote: On Thu, Jul 5, 2012 at 3:42 PM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.comjavascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.comjavascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained Yes, I did think about that solution. Just to painfull for me. If you do it, then go ahead and will always plug it in emotion. But I am not going to have anything to do inside gstreamer code again. And I think I am not the only one to feel the same pain as nobody from any application did try to do that
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thu, Jul 5, 2012 at 10:42 AM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained Yes, I did think about that solution. Just to painfull for me. If you do it, then go ahead and will always plug it in emotion. But I am not going to have anything to do inside gstreamer code again. And I think I am not the
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thu, Jul 5, 2012 at 3:42 PM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained Yes, I did think about that solution. Just to painfull for me. If you do it, then go ahead and will always plug it in emotion. But I am not going to have anything to do inside gstreamer code again. And I think I am not the
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Thu, Jul 5, 2012 at 11:28 PM, Jorge Luis Zapata Muga jorgeluis.zap...@gmail.com wrote: On Thu, Jul 5, 2012 at 3:42 PM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained Yes, I did think about that solution. Just to painfull for me. If you do it, then go ahead and will always plug it in emotion. But I am
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Fri, Jul 6, 2012 at 7:37 AM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 11:28 PM, Jorge Luis Zapata Muga jorgeluis.zap...@gmail.com wrote: On Thu, Jul 5, 2012 at 3:42 PM, Cedric BAIL cedric.b...@free.fr wrote: On Thu, Jul 5, 2012 at 10:30 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Thu, Jul 5, 2012 at 10:07 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; wrote: On Thursday, July 5, 2012, Cedric BAIL wrote: On Wed, Jun 6, 2012 at 11:17 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.frjavascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:; javascript:; wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com javascript:;javascript:; wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. I agree with you on the theory, but the fact is that all embedded hardware that I have access to have really a bad implementation of gstreamer on it (The cubox seems to be the worth one and will require a big custom pipeline). So this left us with only a limited choice. We are not going to fix proprietary code on this platform. If we do not provide an infra to work around all this crappy implementation then emotion is basically useless. The situation of Video library on Linux is actually really poor. As long as their is no serious solution to this issue we are stuck with hack. On this, the next step is clearly to move gstreamer to use the generic pipeline also, as it is a big source of crash... So I am going to commit this patch as the first step toward an infra for working around embedded device limitation. Isn't this a Samsung hw with Samsung sw? Also, if this is specific to some HW, why have it in svn? It should be in the SDK patchset. I really don't get it in svn :-/ I am refering to this device : http://www.solid-run.com/products/cubox/ . And in my past experience, gstreamer wasn't that good and needed some workaround (Look how many times XBMC need to be ported). I want to be able to use Emotion on this hardware. Currently it's not going to happen with a patch that I need to put somewhere in my own distribution. And that need to be repeated for almost all embedded device (We don't have yet the equivalent of OpenGL ES for video). By moving this stuff in Emotion, I hope to come up with a generic approach and share code among this hardware. Did u think about a gst plugin that use the others and have higher priority? Then for emotion it would be transparent. As bonus it can be shared with non EFL users and co maintained Yes, I did think about that solution. Just to
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Wed, Jun 6, 2012 at 12:14 AM, Cedric BAIL cedric.b...@free.fr wrote: On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. so either make the plugins to be used a compile/runtime configured list (much like the playbin/decodebin uses) or keep it as a separate patch. as is this really does not belong to emotion. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com wrote: Hi all. I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] emotion-gstreamer : add fimcconvert element on device
On Tue, Jun 5, 2012 at 4:39 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Jun 5, 2012 at 4:22 AM, Sohyun Kim anna1014@samsung.com wrote: I've made a patch for emotion-gstreamer. When I tested video playing using emotion on the device, the frame rate was no good enough. So I added a filter using fimc to resize and convert color on the device. When the size of image object in the emotion object is smaller than 80% of video size, I added a fimcconvert element to the pipeline. The fimcconvert element is distributed in Samsung to use internally, so if the element exists, it is added to the pipeline. is this opensource or generic? The gstreamer plugin code is proprietary I think (need ot check that), but the driver is open source and already mainline in linux kernel since a few year. So it's just the user space glue (the gstreamer plugins) that is not public. If it's restricted to samsung hw, then please keep this a patchset for your platforms. If it's public, then could you share a timeline to get his accepted in Gstreamer's plugin base or at least good set? It would be nice if the decodebin would use it automatically, improving all the users of such helper, including emotion. Problem is gstreamer playbin doesn't handle this kind of plugins at the moment. There is some work to do on gstreamer side before it can get this kind of plugins in correctly (not in a hackish way). In some way this patch is a work around gstreamer limitation and the fact that it lack some feature. The thing is we need this feature and maybe more than for just Samsung hardware (colorspace convertion and scaledown in an optimized way). This patch gave the infra to work around a limitation in a hackish way, I agree, but the time needed to fix gstreamer is much higher than if we do it on our side. I see that as a temporary mesure until gstreamer 1.0 is out, device maker start to adopt it and we can start to fix it correctly. -- Cedric BAIL -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
