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
