On 24/03/14 21:02, wm4 wrote:
> On Mon, 24 Mar 2014 03:01:53 +0100
> Luca Barbato <[email protected]> wrote:
> 
>> From: Anton Khirnov <[email protected]>
>>
>> It leverages the new hwaccel 1.2 features:
>>
>> - get_buffer2 is never called
>> - the internal context is automatically initialized/deinitialized
>>
>> Signed-off-by: Luca Barbato <[email protected]>
>> ---
>>  libavcodec/Makefile       |   1 +
>>  libavcodec/allcodecs.c    |   1 +
>>  libavcodec/h264_slice.c   |  23 ++++-
>>  libavcodec/vda.c          |  64 ++++++++++++
>>  libavcodec/vda.h          |  53 ++++++++++
>>  libavcodec/vda_h264.c     | 248 
>> ++++++++++++++++++++++++++++++++++++++++++++--
>>  libavcodec/vda_internal.h |  33 ++++++
>>  7 files changed, 412 insertions(+), 11 deletions(-)
>>  create mode 100644 libavcodec/vda.c
>>  create mode 100644 libavcodec/vda_internal.h
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index 1b5a044..5908011 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -67,6 +67,7 @@ OBJS-$(CONFIG_RDFT)                    += rdft.o 
>> $(RDFT-OBJS-yes)
>>  OBJS-$(CONFIG_SINEWIN)                 += sinewin.o
>>  OBJS-$(CONFIG_TPELDSP)                 += tpeldsp.o
>>  OBJS-$(CONFIG_VAAPI)                   += vaapi.o
>> +OBJS-$(CONFIG_VDA)                     += vda.o
>>  OBJS-$(CONFIG_VDPAU)                   += vdpau.o
>>  OBJS-$(CONFIG_VIDEODSP)                += videodsp.o
>>  OBJS-$(CONFIG_VP3DSP)                  += vp3dsp.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index ed6d7ff..7b061e6 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -79,6 +79,7 @@ void avcodec_register_all(void)
>>      REGISTER_HWACCEL(H264_DXVA2,        h264_dxva2);
>>      REGISTER_HWACCEL(H264_VAAPI,        h264_vaapi);
>>      REGISTER_HWACCEL(H264_VDA,          h264_vda);
>> +    REGISTER_HWACCEL(H264_VDA_OLD,      h264_vda_old);
>>      REGISTER_HWACCEL(H264_VDPAU,        h264_vdpau);
>>      REGISTER_HWACCEL(MPEG1_VDPAU,       mpeg1_vdpau);
>>      REGISTER_HWACCEL(MPEG2_DXVA2,       mpeg2_dxva2);
>> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> index 73c0740..eb4adde 100644
>> --- a/libavcodec/h264_slice.c
>> +++ b/libavcodec/h264_slice.c
>> @@ -153,6 +153,7 @@ static const enum AVPixelFormat 
>> h264_hwaccel_pixfmt_list_420[] = {
>>  #endif
>>  #if CONFIG_H264_VDA_HWACCEL
>>      AV_PIX_FMT_VDA_VLD,
>> +    AV_PIX_FMT_VDA,
>>  #endif
>>  #if CONFIG_H264_VDPAU_HWACCEL
>>      AV_PIX_FMT_VDPAU,
>> @@ -170,6 +171,7 @@ static const enum AVPixelFormat 
>> h264_hwaccel_pixfmt_list_jpeg_420[] = {
>>  #endif
>>  #if CONFIG_H264_VDA_HWACCEL
>>      AV_PIX_FMT_VDA_VLD,
>> +    AV_PIX_FMT_VDA,
>>  #endif
>>  #if CONFIG_H264_VDPAU_HWACCEL
>>      AV_PIX_FMT_VDPAU,
>> @@ -247,10 +249,23 @@ static int alloc_picture(H264Context *h, H264Picture 
>> *pic)
>>      av_assert0(!pic->f.data[0]);
>>  
>>      pic->tf.f = &pic->f;
>> -    ret = ff_thread_get_buffer(h->avctx, &pic->tf, pic->reference ?
>> -                                                   AV_GET_BUFFER_FLAG_REF : 
>> 0);
>> -    if (ret < 0)
>> -        goto fail;
>> +
>> +    if (h->avctx->pix_fmt == AV_PIX_FMT_VDA) {
>> +        /* the VDA framework handles its surfaces internally, so we
>> +         * do not call get_buffer at all;
>> +         * create a dummy buffer here until we get the real one later */
>> +        pic->f.buf[0] = av_buffer_alloc(1);
>> +        pic->f.width  = h->avctx->width;
>> +        pic->f.height = h->avctx->height;
>> +        pic->f.format = h->avctx->pix_fmt;
>> +        if (!pic->f.buf[0])
>> +            goto fail;
>> +    } else {
>> +        ret = ff_thread_get_buffer(h->avctx, &pic->tf, pic->reference ?
>> +                                   AV_GET_BUFFER_FLAG_REF : 0);
>> +        if (ret < 0)
>> +            goto fail;
>> +    }
> 
> Maybe this could be made a bit nicer by adding a new callback to
> AVHWAccel? If that callback is NULL, the code would fall back to 
> ff_thread_get_buffer.
> 

Surely we can and we should IMHO.

lu


_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to