[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 3)
Thu Feb 19 05:34:03 CET 2009
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.
More information about the ffmpeg-devel