> On Fri, Oct 26, 2018 at 4:00 PM James Almer <jamr...@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@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
