[FFmpeg-devel] [PATCH] HWAccel infrastructure (take 3)
Thu Feb 19 13:29:46 CET 2009
On Thu, Feb 19, 2009 at 05:34:03AM +0100, Gwenole Beauchesne wrote:
> 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?
skip spliting the frame in slices in software when its available as a whole
frame and the hardware ca handle that directly.
> 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]
i see no need for any change to know the frame size, there is buf_size that
can be given to start_frame
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel