[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);
     assert(rds);

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

     rds->bitstream_buffers[rds- 
 >bitstream_buffers_used].struct_version  =  
VDP_BITSTREAM_BUFFER_VERSION;
     rds->bitstream_buffers[rds- 
 >bitstream_buffers_used].bitstream       = start_code_prefix_one_3byte;
     rds->bitstream_buffers[rds- 
 >bitstream_buffers_used].bitstream_bytes =  
sizeof(start_code_prefix_one_3byte);
     rds->bitstream_buffers_used++;

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

     ++rds->info.h264.slice_count;
     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