[FFmpeg-devel] [PATCH]: Video Decoder Acceleration (VDA) HWAccel module for Mac OS X

[Michael Niedermayer]

On Wed, Nov 02, 2011 at 01:50:17AM +0100, Sebastien Zwickert wrote:
> 
> On Nov 1, 2011, at 8:15 PM, Michael Niedermayer wrote:
> 
> > On Tue, Nov 01, 2011 at 05:39:30PM +0100, Sebastien Zwickert wrote:
> >> 
> >> On Nov 1, 2011, at 4:43 PM, Carl Eugen Hoyos wrote:
> >> 
> >>> Sebastien Zwickert <dilaroga <at> gmail.com> writes:

[...]


> > [...]
> >> +static int decode_slice(AVCodecContext *avctx,
> >> +                        const uint8_t *buffer,
> >> +                        uint32_t size)
> >> +{
> >> +    H264Context *h = avctx->priv_data;
> >> +    struct vda_context *vda_ctx = avctx->hwaccel_context;
> >> +    struct vda_picture_context *pic_ctx = h->s.current_picture_ptr->f.hwaccel_picture_private;
> >> +    void *tmp;
> >> +
> >> +    if (!vda_ctx->decoder)
> >> +        return -1;
> >> +
> > 
> >> +    tmp = NULL;
> >> +    tmp = av_realloc(pic_ctx->bitstream, pic_ctx->bitstream_size+size+4);
> > 
> > the tmp = NULL is unneeded
> > also please consider using *av_fast_realloc() if its possible in this
> > case here as its faster (*alloc is actually slow, so never downsizing
> > and instead reusing buffers is faster)
> 
> It would be possible if i can get the bitstream total size.
> This couldn't be done in start_frame ? buffer and size parameters sounds good candidates to get this info.

this wont work when CODEC_FLAG2_CHUNKS is set.

But what could work is not freeing in end_frame() but reusing the
buffer for the next frame and only reallocating when adding a slice
requires it.


> 
[...]
> > 
> > 
> > [...]
> > 
> > also, if you want to maintain this code in ffmpeg,
> > please add yourself to the MAINTAINERS file
> 
> Of course. Done.

great :)

now you just need a public git repository containing a clone of ffmpeg,
github is the most popular place for that.
You can then make changes to VDA there as you see fit, apply patches
that you reviewed or revert changes that you consider wrong.
Once you are happy with whats in your repository you
just tell me to pull it and ill pull it into main ffmpeg.


also patch applied & thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111102/b5500f14/attachment.asc>