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

[Gwenole Beauchesne]

Hi,

Le 20 f?vr. 09 ? 17:23, Stephen Warren a ?crit :

>> That's what was done initially with my buf+offset approach (as an
>> optimization hint if buf is the frame start) but Michael preferred
>> buf+size instead. So, you will now have to compute your offsets  
>> yourself
>> too. ;-)
>
> 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:

static int vaapi_mpeg4_decode_slice(AVCodecContext *avctx, const  
uint8_t *buffer, uint32_t size)
{
[...]
     /* Fill in VASliceParameterBufferMPEG4 */
     slice_param = vaapi_slice_params_next(rds);
     slice_param->slice_data_size        = size;
     slice_param->slice_data_offset      = rds->slice_data_size;
     slice_param->slice_data_flag        = VA_SLICE_DATA_FLAG_ALL;
[...]
     return vaapi_slice_data_append(rds, buffer, size);
}

and rds->slice_data_size is increased as the slice is sent to the  
mapped accelerator region.

Besides, I also try to keep the start code in the passed slice (as  
defined per [ buf, buf+size [). This is important to keep the start  
code for VDPAU, for other slice level accelerators, it just doesn't  
matter.

Regards,
Gwenole.