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?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to