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

[Gwenole Beauchesne]

Le 18 f?vr. 09 ? 20:54, Michael Niedermayer a ?crit :

> On Wed, Feb 18, 2009 at 08:28:20PM +0100, Gwenole Beauchesne wrote:
>> Le 18 f?vr. 09 ? 19:12, Michael Niedermayer a ?crit :
>>
>>>>>> I really want start_frame() to be at a location
>>>>>> where we are assured that frame info is parsed.
>>>>>
>>>>> should not be a problem ...
>>>>
>>>> It is for e.g. h264.c, reasons kept below.
>>>
>>> you can always pass NULL/0 as buf/size if there is no single
>>> buffer ...
>>
>> Then we could have cases where codecs would emit valid buf/size
>> information and others don't.
>
> yes, if there is a whole frame in a single buf it can be passed to  
> the hw
> accel if not then not

This further means that even within a particular codec implementation,  
this could mean NULL or valid data? I don't find it very useful, or  
what/how the user should do any good with that?

However, I would do find very useful some way to specify the _maximum_  
size of the bitstream parts we will be sending through all  
decode_slice() calls. eg. for the mpeg12.c case, that would combine  
both input_size+extradata_size. This is for optimization purposes only  
so that we can map memory from the HW accelerator space in  
start_frame() and then copy the slice data, instead of first  
accumulating the data (to temporary buf) we receive and then copy that  
to the HW accelerator.

That approach could work by hijacking bitstream_buffer* variables from  
divx parts of MpegEncContext for this purpose. e.g. have  
decode_frame() store extradata_size+buf_size in bitstream_buffer_size  
and let decode_chunks() use that to call start_frame(avctx,  
bitstream_buffer_size); [or use other variables]

Of course, the "maximum frame data size" idea will only care about the  
original bitstream data, not unescaped buffers.