On Thu, Dec 29, 2011 at 10:00:12AM -0800, Ronald S. Bultje wrote: > Hi, > > On Thu, Dec 29, 2011 at 9:57 AM, Kostya Shishkov > <[email protected]> wrote: > > On Thu, Dec 29, 2011 at 09:12:05AM -0800, Ronald S. Bultje wrote: > >> Hi, > >> > >> On Thu, Dec 29, 2011 at 9:10 AM, Kostya Shishkov > >> <[email protected]> wrote: > >> > On Thu, Dec 29, 2011 at 09:03:44AM -0800, Ronald S. Bultje 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: > >> >> >> 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 > >> > >> Well, 3 is slower by thousands of millicycles. > > > > Does it matter here? > > Since I wrote the patch already...
...writing second and third patch will be easier for you :P I'd like to hear from other people which approach is the best. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
