[FFmpeg-devel] [PATCH v3] avcodec: libdav1d AV1 decoder wrapper.

[James Almer]

On 10/26/2018 7:50 PM, Dale Curtis wrote:
> One more piece of feedback, this is not obeying the
> AVCodecContext.get_buffer2 API.

It's not using it on purpose, wrapping the buffers dav1d allocated
itself instead. Hence the lack of AV_CODEC_CAP_DR1 flag.

> 
> - dale
> 
> On Fri, Oct 26, 2018 at 3:31 PM Dale Curtis <dalecurtis at chromium.org> wrote:
> 
>> The following warnings show up when compiling with clang:
>> ../../third_party/ffmpeg/libavcodec/libdav1d.c:92:24: error: suggest
>> braces around initialization of subobject [-Werror,-Wmissing-braces]
>>     Dav1dPicture p = { 0 };
>>                        ^
>>                        {}
>> ../../third_party/ffmpeg/libavcodec/libdav1d.c:119:24: error: suggest
>> braces around initialization of subobject [-Werror,-Wmissing-braces]
>>     Dav1dPicture p = { 0 };
>>                        ^
>>                        {}
>> ../../third_party/ffmpeg/libavcodec/libdav1d.c:194:45: error: implicit
>> conversion from enumeration type 'enum Dav1dMatrixCoefficients' to
>> different enumeration type 'enum AVColorSpace' [-Werror,-Wenum-conversion]
>>     frame->colorspace = c->colorspace = p.p.mtrx;
>>                                       ~ ~~~~^~~~
>> ../../third_party/ffmpeg/libavcodec/libdav1d.c:195:55: error: implicit
>> conversion from enumeration type 'enum Dav1dColorPrimaries' to different
>> enumeration type 'enum AVColorPrimaries' [-Werror,-Wenum-conversion]
>>     frame->color_primaries = c->color_primaries = p.p.pri;
>>                                                 ~ ~~~~^~~
>> ../../third_party/ffmpeg/libavcodec/libdav1d.c:196:43: error: implicit
>> conversion from enumeration type 'enum Dav1dTransferCharacteristics' to
>> different enumeration type 'enum AVColorTransferCharacteristic'
>> [-Werror,-Wenum-conversion]
>>     frame->color_trc = c->color_trc = p.p.trc;
>>                                     ~ ~~~~^~~
>> 5 errors generated.
>>
>>
>>
>> On Fri, Oct 26, 2018 at 2:59 PM Hendrik Leppkes <h.leppkes at gmail.com>
>> wrote:
>>
>>> On Fri, Oct 26, 2018 at 10:46 PM Thierry Foucu <tfoucu at gmail.com> wrote:
>>>>
>>>> On Wed, Oct 24, 2018 at 4:02 AM Rostislav Pehlivanov <
>>> atomnuker at gmail.com>
>>>> wrote:
>>>>
>>>>> On Sat, 20 Oct 2018 at 00:50, James Almer <jamrial at gmail.com> wrote:
>>>>>
>>>>>> Originally written by Ronald S. Bultje, with fixes, optimizations
>>> and
>>>>>> improvements by James Almer.
>>>>>>
>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>> ---
>>>>>> Updated to work with libdav1d git head.
>>>>>>
>>>>>>  configure              |   4 +
>>>>>>  libavcodec/Makefile    |   1 +
>>>>>>  libavcodec/allcodecs.c |   1 +
>>>>>>  libavcodec/libdav1d.c  | 271
>>> +++++++++++++++++++++++++++++++++++++++++
>>>>>>  4 files changed, 277 insertions(+)
>>>>>>  create mode 100644 libavcodec/libdav1d.c
>>>>>>
>>>>>
>>>>> There hasn't even been a 0.1 release yet, and there won't be one that
>>> soon.
>>>>> As far as I know the promise is for that to be out by the 30th next
>>> month.
>>>>> Also I'm still against this making it into the next release.
>>>>>
>>>>
>>>> Why should we wait for a 0.1 release?
>>>> If we want to benchmark it against libaom, this is good to have in
>>> ffmpeg.
>>>> It does not have to be the default decoder...
>>>>
>>>
>>> If there is no guarantees whatsoever for API/ABI stability yet, adding
>>> a wrapper already seems a bit early.
>>>
>>> - Hendrik
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>