[Gstreamer-openmax] Support for hardware codecs

[Rob Clark]

On Feb 23, 2010, at 4:16 PM, Stephen M. Webb 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 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.
> 
> Hmm, I will think about this.  It doesn't sound too hard....
> 
>> 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.
> 


buffer mode per port (use vs allocate, and whether buffer sharing is enabled) would be nice..

For supported color formats, I did experiment with a trick of trying a SetParam with each different color format and seeing for which ones it returned an error code. Of course an introspection API for OMX would be more ideal.  But assuming your OMX implementation wasn't *too* horrible, that could be an option..



BR,
-R