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 <dalecur...@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.lepp...@gmail.com>
>> wrote:
>>
>>> On Fri, Oct 26, 2018 at 10:46 PM Thierry Foucu <tfo...@gmail.com> wrote:
>>>>
>>>> On Wed, Oct 24, 2018 at 4:02 AM Rostislav Pehlivanov <
>>> atomnu...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Sat, 20 Oct 2018 at 00:50, James Almer <jamr...@gmail.com> wrote:
>>>>>
>>>>>> Originally written by Ronald S. Bultje, with fixes, optimizations
>>> and
>>>>>> improvements by James Almer.
>>>>>>
>>>>>> Signed-off-by: James Almer <jamr...@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@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
