[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 4)

[Michael Niedermayer]

On Wed, Feb 11, 2009 at 05:10:38PM +0100, Gwenole Beauchesne wrote:
> On Mon, 9 Feb 2009, Michael Niedermayer wrote:
> 
> > ehm this is close but not exactly what i had in mind
> > i more had in mind:
> >
> > typedef struct AVHWAccel {
> >    /** (copied from AVCodec)
> >     * Name of the codec implementation.
> >     * The name is globally unique among encoders and among decoders (but an
> >     * encoder and a decoder can share the same name).
> >     * This is the primary way to find a codec from the user perspective.
> >     */
> >    const char *name;
> >    enum CodecType type;
> >    enum CodecID id;
> >    int (*start_frame)(AVCodecContext *avctx);
> >    int (*start_slice)(AVCodecContext *avctx, const uint8_t *buffer, unsigned size);
> >    int (*decode_slice)(AVCodecContext *avctx);
> >    int (*end_slice)(AVCodecContext *avctx);
> >    int (*end_frame)(AVCodecContext *avctx);
> >    int capabilities;
> >    const enum PixelFormat *pix_fmts;       ///< array of supported pixel formats, or NULL if unknown, array is terminated by -1
> >    /** (copied from AVCodec)
> >     * Descriptive name for the codec, meant to be more human readable than \p name.
> >     * You \e should use the NULL_IF_CONFIG_SMALL() macro to define it.
> >     */
> >    const char *long_name;
> >
> >    struct AVHWAccel *next;
> > } AVHWAccel;
> >
> > av_register_hw_accel(struct AVHWAccel *hw_accel);
> >
> > and adding a AVHWAccel *hw_accel field to AVCodecContext
> > and adding to codecs
> > if(ctx->hw_accel)
> >    ctx->hw_accel->start_frame(ctx);
> >
> > anyway above is just a rough draft ...
> 
> I don't see fit for name and long_name.
> 
> However, an alternative is to have an AVHWAccel with init(), uninit() 
> member functions, that's the accelerator class + an AVHWAccelCodec which 
> is more consistent with existing AVCodec and that would have the 
> start_frame(), start_slice() et al. instead.

whats the point of the extra complexity?


> 
> Then, avctx could have
> 
> - hwaccel_id: the unique identifier for the accelerator, including 
> entry-point (VLD, iDCT). This is set by the user (decoder).
> 
> e.g.
> 
> enum HWAccelID {

>      HWACCEL_ID_VAAPI        = 0x56410000, /* 'VA'00 */

no


>      HWACCEL_ID_VAAPI_VLD    = (HWACCEL_ID_VAAPI|HWACCEL_ENTRY_ID_VLD),  ///< VA API acceleration (variable-length decoding)

HWACCEL_ENTRY_ID_VLD is undefined



>      HWACCEL_ID_VAAPI_IDCT   = (HWACCEL_ID_VAAPI|HWACCEL_ENTRY_ID_IDCT), ///< VA API acceleration (inverse DCT)
>      HWACCEL_ID_VAAPI_MOCO   = (HWACCEL_ID_VAAPI|HWACCEL_ENTRY_ID_MOCO), ///< VA API acceleration (motion compensation)
> };

and anyway the whole enum seems very useless
each AVHWAccel has a list of supported pix_fmts they identify what it can
produce already and are sufficient


> 
> - hwaccel: the AVHWAccel. That one can have:
> name, long_name, HWAccelID, init(), close()
> This is read-only from a user POV, i.e. only set by libavcodec
> 
> - hwaccel_codec: the proposed AVHWAccelCodec minus name, long_name.
> This is read-only from a user POV, i.e. only set by libavcodec
> 

> Then, avcodec_open() will find a matching accelerator for the specified 

avcodec_open() does not seem like a particularly good place for that as it
lacks many things that might affect the decission of which if any hw accel
should be used


> codec and hwaccel_id set beforehand, if acceleration is requested. That 

no

once the codec has determined all needed stuff mpeg1 vs mpeg2 video res, ...
it will querry registered AVHWAccels to see which could decode it and
then present a list via the AVCodecContext.get_format() callback to the
user app. The user app then just returns the pix_fmt it wants and that
implicates a AVHWAccel or none.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090211/928c7a0a/attachment.pgp>