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

[Christian König]

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
>