[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