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.fr<javascript:;>
>>> <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 and prefer to "port" their application.
> I will prefer to write a full replacement from scratch than to work
> again in their code. That's why I am not contributing to gstreamer,
> work around issue, wait for them to fix the mess and hope that a
> messiah will come one day with a better solution.
Sorry Cedric for not answering this thread before, I completely forgot
about it :)
Well, gstreamer is not particularly a simple piece of code, I agree
that it might not be the most intuitive software, specially when you
have to deal with all the different possible events/states/messages in
different threads. As Gustavo suggested before, don't add
element-dependant code in emotion, it breaks the abstraction emotion
provides as that code does not belong there.
In order to rise the rank of an element at runtime just do this:
void element_rise_rank (const gchar *element_name, gboolean enable)
{
GstRegistry *registry = NULL;
GstElementFactory *element_factory = NULL;
registry = gst_registry_get_default ();
if (G_UNLIKELY (!registry)) {
goto beach;
}
element_factory = gst_element_factory_find (element_name);
if (G_UNLIKELY (!element_factory)) {
goto beach;
}
if (enable) {
gst_plugin_feature_set_rank (GST_PLUGIN_FEATURE (element_factory),
GST_RANK_PRIMARY << 2);
}
else {
gst_plugin_feature_set_rank (GST_PLUGIN_FEATURE (element_factory),
GST_RANK_MARGINAL);
}
beach:
if (element_factory && registry) {
gst_registry_add_feature (registry,
GST_PLUGIN_FEATURE (element_factory));
}
return;
}
The real problem in your case (which should just use playbin2 or if
needed let the user define its own pipeline and pass it to emotion) is
how to make your element be picked up on the autoplug process. But
that depends on how your element defines itself on the
GstElementDetails. For example, if you know that the gstramer on the
device will always work with a specific sink, you can always create a
bin which you can have as children both, the real sink and your
"filter" element and then increment this new sink rank. The filter
element (fimcconvert) again can work as a pass through element or do
the process in case the requirements match (size of buffer, etc, etc).
Or you can even define your own pipeline and set it as a string to the
video-sink property of playbin2. You have several options :)
But dont add the hw specific code to emotion please :)
Regards
> --
> 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
------------------------------------------------------------------------------
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
