[Mesa-dev] [PATCHv2 1/3] omx: query driver encode capatibility earlier

[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.

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.

-Emil