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

[Michael Niedermayer]

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? 

yes


> 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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090219/29c85520/attachment.pgp>