On Thu, Dec 29, 2011 at 09:03:44AM -0800, Ronald S. Bultje wrote: > Hi, > > 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: > >> Hi, > >> > >> 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: > >> >> Hi, > >> >> > >> >> $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.
I agree the current way is hacky, the question is if it's really better to 1) complicate code with direct rendering to the frame with handling padding or 2) direct render into frames and forcing linesize = width * bpp or 3) use internal buffers and copy lines from it into output frame _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
