[Gstreamer-openmax] Support for hardware codecs

[Felipe Contreras]

On Wed, Feb 24, 2010 at 12:16 AM, Stephen M. Webb <stephenw at xandros.com> wrote:
> On 23/02/10 15:09, Felipe Contreras wrote:
>> On Tue, Feb 23, 2010 at 4:45 PM, Stephen M. Webb <stephenw at xandros.com>
> wrote:
>> >
>> > What I would want is some way to expose more properties via gst-openmax,
>> > at runtime.  I use gst-openmax to integrate various hardware codecs from
>> > different vendors, each one with a different set of properties that may
>> > need to be tweaked.  The more I can keep generic and as a single binary,
>> > the happier I am.  And the easier it will be to push everything upstream.
>>
>> I'm not sure exactly what properties you might need. The only one I'm
>> aware of is TI's "OMX.TI.VideoDecode.Param.WMVFileType" which is
>> needed because the spec is missing something similar. And this one
>> cannot be properly set with a configuration file, it has to be set
>> programatically based on the fourcc/fomat caps.
>
> I have one hardware vendor who does the same thing with WVC1 vs. WMV3 formats,
> only uses a different parameter name.  They also have a parameter to enable
> the use of hardware buffering -- effectively tunnelling, only tunnelled from
> their video decoder to the gstreamer-based video renderer.  Evidently there
> are other parameters but their documentation is, ah, terse.

I'm not sure how we can fix this WVC1 vs WMV3 issue since the property
names and the values are going to be different no matter what. The
best we can do is try to align on a non-vendor-specific extension. I
will also try to fill a bug report in Khronos's bugzilla.

I'm not sure about that tunneling stuff... it's not integrated on
gst-omx yet and it looks like it might require quite big changes.

> I think what I would really like to be able to do is to be able to set OpenMAX
> parameters via GStreamer properties, not through a config file.  As long as
> the gst-openmax layer is configured to load the right component
> (introspection or configuration), if I can query and set OpenMAX parameters
> via GStreamer properties I could move most of the hardware-specific settings
> into my player software.

We could add some functions to access omx parameters directly through
a gst-omx interface. That shouldn't be that difficult.

But ideally we want all applications to be able to use the omx stuff
transparently, not just the ones that know how to use the gst-omx
interface smartly.

>> Yeah, that's definitely not ideal but it would be nice to know exactly
>> what are the differences each platform needs so that we know how to
>> build a binary that works on all those platforms with a proper
>> configuration file.
>
> Among the things I have to configure are the OMX_ALLOCATE_ON settings and the
> fourcc caps supported by the video decoders.

We could also specify the caps that each element supports, and yeah,
allocate/use would make sense, along with the share_*_buffer hacks.

Cheers.

-- 
Felipe Contreras