On 29/12/11 19:00, 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...
If it works already AND could be used as example/template for further
serious work...
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
