[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 3)

Gwenole Beauchesne gbeauchesne
Fri Feb 20 17:43:01 CET 2009

Le 20 f?vr. 09 ? 17:36, Gwenole Beauchesne a ?crit :

>> Just so I'm clear (because I'm ill and possibly not thinking
>> straight), the
>> API will be presented with one buf+size per slice that the ffmpeg
>> parser
>> found, so all the "compute" is is adding up the sizes of previous
>> slices?
>> That's no big deal. Just so long as the ffmpeg->VDPAU-specific
>> structure
>> conversion doesn't have to rescan the entire bitstream looking for
>> start
>> codes.
> Yes, e.g. I currently have that in the new VA API tree:

And the most "complicated" VDPAU case would be for H.264 but reduces  
to only:

static int vdpau_h264_decode_slice(AVCodecContext *avctx, const  
uint8_t *buffer, uint32_t size)
     MpegEncContext * const s = avctx->priv_data;
     struct vdpau_render_state *rds;
     static const uint8_t start_code_prefix_one_3byte[3] = { 0x00,  
0x00, 0x01 };

     rds = ff_get_vdpau_render_state(s->current_picture_ptr);

     if (vdpau_ensure_bitstream_buffers(rds) < 0)
         return -1;

 >bitstream_buffers_used].struct_version  =  
 >bitstream_buffers_used].bitstream       = start_code_prefix_one_3byte;
 >bitstream_buffers_used].bitstream_bytes =  

     if (vdpau_common_decode_slice(avctx, buffer, size) < 0)
         return -1;

     return 0;

and vdpau_common_decode_slice() reduces to an add_data_chunk but it  
could be converted very easily to your new approach if you implement it.

More information about the ffmpeg-devel mailing list