[FFmpeg-devel] [PATCH] Interleaved memset/memcpy.

Michael Niedermayer michaelni
Thu Aug 27 05:27:48 CEST 2009

On Wed, Aug 26, 2009 at 07:55:44PM -0600, Nathan Caldwell wrote:
> On Wed, Aug 26, 2009 at 4:40 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
> > On Tue, Aug 25, 2009 at 11:43:00PM -0600, Nathan Caldwell wrote:
> >> On Mon, Aug 24, 2009 at 11:01 AM, Michael Niedermayer<michaelni at gmx.at> wrote:
> >> > On Sun, Aug 23, 2009 at 09:29:09PM -0600, Nathan Caldwell wrote:
> >> >> This patch adds an interleaved memset (useful for setting rows of
> >> >> pixels in eg: packed RGB). And an interleaved memcpy (useful for
> >> >> planar -> packed RGB).
> >> >
> >> > for what would any of that be usefull, even more so, in libavutil?
> >>
> >> Well, for memset, setting only one channel of a packed pixel format
> >> (like setting alpha to fully opaque in RGBA). Is your opinion that the
> >> memcpy would be more useful if it were passed an unknown number of
> >> planar buffers and interleave them all at once?
> >
> > My question is _what_ will use this code, that is which file will call
> > this function. ATM its unused and does nt look usefull besides i could
> > make a log list why its interface and implementation are poor but first
> > id like to know the use case for this
> Oops, guess I misunderstood. I thought you were asking for clarification,
> I was using it in lagarith because it stores RGB(A) as seperate planes
> instead of packed, and there are not any planar RGB(A) pix_fmt in
> avutil. Mans suggested it might be useful to more than just lagarith,
> so I figured it couldn't hurt to move the functions around a bit. If
> you are really against them I have no problem keeping them restricted
> to lagarith. The memset can probably be done away with, I don't see
> _too_ many others using it, but the memcpy would be useful to pretty
> much any planar RGB codec.

why is lagarith not interleaving the bytes as it decodes them?

> >> As for why libavutil,
> >> this seemed the most logical place. That's where the other memory
> >> functions are. It really doesn't matter to me. If you have a better
> >> suggestion I would move it.
> >
> > swscale possibly does already what you want and probably better
> > but i dont know what you want to use this for so maybe sws is not
> > the correct thing ...
> I don't doubt it can, in fact I'm fairly sure it can. For me I need
> something that can be used inside avcodec. swscale does have
> interleaveBytes(), but when I asked if I could use this in avcodec,
> you said:
> > if you find a way that is clean+simple+portable+doesnt depend on swscale :)

btw, this can be done by adding a planar rgb format ... not that iam
suggesting that, it probably is overkill for a single codec

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090827/dae557cb/attachment.pgp>

More information about the ffmpeg-devel mailing list