[FFmpeg-devel] [PATCH] HWAccel infrastructure

[Michael Niedermayer]

On Wed, Feb 18, 2009 at 05:42:29AM +0100, Gwenole Beauchesne wrote:
> Hi,
> 
> Le 17 f?vr. 09 ? 20:33, Michael Niedermayer a ?crit :
[...]
> >>>> +                if (avctx->hwaccel_codec) {
> >>>> +                    const uint8_t *curr_slice = buf_ptr - 4;
> >>>> +                    const uint8_t *next_slice;
> >>>> +                    start_code = -1;
> >>>
> >>>> +                    next_slice = ff_find_start_code(buf_ptr + 2,
> >>>> buf_end, &start_code);
> >>>
> >>> are you doing another pass over the bitstream? if so this is
> >>> unacceptable
> >>
> >> I am just trying to reuse existing code to know where the current
> >> slice ends. How could I achieve this purpose otherwise?
> >
> > how does vdpau do it? a quick look shows no ff_find_start_code() but
> > i may have missed it
> 
> VDPAU can offload the whole picture data. VA API specifies this as a  
> per-slice process, i.e. emit all individual slice, one control block  
> at a time (VASliceParameterBufferMPEG2). However, in practise and  
> IIRC, the current Intel implementation does support the once control  
> block at a time approach (akin to NVIDIA's VDPAU implementation) but  
> it's just not specified to work that way. So, I need a way to advance  
> to the next slice, thus determining the actual size of the slice.

that belongs inside the VA API wraper then, not in mpeg12.c, we wouldnt
want to slow VDPAU down because of limitations on intels side


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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/20090218/50889956/attachment.pgp>