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

[James Almer]

> On Fri, Oct 26, 2018 at 4:00 PM James Almer <jamrial at gmail.com> wrote:
> 
>> 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.
>>
> 
> Sorry for being unclear, my comment was a request. This is something
> Chromium would require to use this wrapper. If it's not planned, we'd forgo
> the wrapper and use dav1d directly. Otherwise we'd need to change our
> common ffmpeg based decoder enough for this one case that we'd be better
> off writing a pure dav1d based decoder. Thanks for your consideration in
> any case.
> 
> - dale
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

I don't think the wrapper can use the get_buffer2 API if the idea is to
use it within Dav1dPicAllocator.alloc_picture_callback(). There's no way
to guarantee that the constrains required by said callback will be met
for example by a user provided implementation of get_buffer2.
Also, avctx dimensions need to be set by the time the
alloc_picture_callback() is called (as required by ff_get_buffer), and
said callback can't set them itself since we don't know at what point
during decoding it's going to be called (Things would probably go south
decoding a sample with frame changes in a frame multi-threading scenario).

If the idea is letting dav1d allocate its own buffers and then memcpy
them to get_buffer2() allocated buffers with av_image_copy(), like the
libaom wrapper is doing, then that can be done, but it's not something i
want committed since it will be slower than this zero copy implementation.
You could keep a local patch to implement it that way if you need to. It
should be trivial.