Am 16.02.2014 21:55, schrieb Emil Velikov:
On 16/02/14 15:52, Christian König wrote:
Am 16.02.2014 13:53, schrieb Emil Velikov:
On 16/02/14 10:20, Christian König wrote:
Am 15.02.2014 20:35, schrieb Emil Velikov:
Query of the driver support AVC_HIGH encode before reporting
the total number of supported components.
v2: drop if (name_specific_length) check
I considered this as well, but as far as I understand it that's not
necessary correct.
Hi Christian
I'm not sure I see your concern.
If you consider this an individual project one will not implement nor
advertise an encoder (second component) if they know it is not going to
work (would that be missing hardware capability or other reason). Same
thing here - there is no point in saying "we have two components" only
to die later after realising that is not the case.
As far as I understood it the number of components and the name of them
should be statically and never change without rebulding the component
registry. Actually that we concatenate the component name and have
dynamically specific names/roles is already quite questionable
See for example the ".omxregister" file that the bellagio loader builds
up while loading the library. Not sure if it was bellagios caching or
that of gstreamer, but while working on the code I had to clear and
rebuild them a couple of times to make it work.
I suspect that this may even help with the following bug
https://bugs.freedesktop.org/show_bug.cgi?id=74944
Actually to fix this bug we shouldn't check at all while being queried
for available components, but rather fail while creating them. To be
honest I don't have much experience with applications using this
interface (except for gstreamer), so I can't really judge what's the
right approach here.
Anyway, the proper fix for this bug is probably to use the pipe loader
instead.
Have you checked the spec on how exactly we should do it?
I have skimmed through the openmax IL 1.1.2 spec and it does not seem to
cover this topic. Or perhaps I should be looking at the
libomxil-bellagio documentation ?
I couldn't find anything clear on this topic either.
So to put things mildly - it's rather messy.
We have do to either one of the following two
- Shout "I can do everything" and fail a handful of times. Then hope
that everyone can pick up the pieces.
- Have to constantly redo the cache(re-register). And scratch our heads
how do we control this, considering mesa changes, user switching between
two codecs.
Actually it's not so unorthodox what the bellagio loader does here. It
needs to know which component can be found in which library (independent
of weather or not the component is available), cause otherwise it would
need to load every library and check what's support at the moment when
an application request a component. Thinking this thought to the end it
suddenly looks like option 1 makes allot of sense.
BTW: I took a look at the loader implementation.
omx_component_library_Setup is supposed to never fail! So we should
never return OMX_ErrorInsufficientResources from it (the bellagio sample
source code is probably not up to date any more).
We could also cleanup/drop all the caching mess in bellagio ... I'd
rather not.
I will go with option 1 (+ pipe-fication of omx) some time this week and
add some comments along the way about the (imho) unorthodox behaviour.
Thx allot for this. I'm currently working on hammering out all the
remaining bugs and missing features in the H264 decoder, so when you
could do the cleanup and pipe-fication that would be great.
Christian.
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
