Hi, On Thu, Dec 29, 2011 at 9:03 AM, Ronald S. Bultje <[email protected]> wrote: > On Thu, Dec 29, 2011 at 9:02 AM, Kostya Shishkov > <[email protected]> wrote: >> On Thu, Dec 29, 2011 at 08:56:09AM -0800, Ronald S. Bultje wrote: >>> On Thu, Dec 29, 2011 at 8:01 AM, Kostya Shishkov >>> <[email protected]> wrote: >>> > On Thu, Dec 29, 2011 at 07:40:30AM -0800, Ronald S. Bultje wrote: >>> >> $attached. Makes it use get/release_buffer. >>> >> >>> >> It's kind of hacky, perhaps I could force edge emulation so that the % >>> >> and / mess isn't necessary, but I don't think performance matters all >>> >> that much for a game codec. If it does, someone else wanna finish >>> >> this? >>> > >>> > I don't think you should do all that stuff. >>> > >>> > This codec uses LZ77-style compression algorithm on the whole buffer and >>> > IMO >>> > it's better to let it uncompress the buffer as it likes and copy it to >>> > output. >>> >>> I can force CODEC_FLAG_EMU_EDGE to make that easier, perhaps. >> >> The question is why? It will effectively result in nearly the same code >> except >> that picture buffer will be allocated properly. IMO codecs with such design >> can suffer from additional memcpy from internal buffer with stride=width*bpp >> to frame with whatever stride it has. > > For one, with Anton's changes, it'll cause buf->pix_fmt/w/h to be initialized.
See attached. I have a file + Oana's fate patch locally so we can then add a kgv1 fate test that has no valgrind warnings. Ronald
0001-kgv1-use-avctx-get-release_buffer.patch
Description: Binary data
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
