[FFmpeg-devel] [PATCH] Interleaved memset/memcpy.
Thu Aug 27 03:55:44 CEST 2009
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.
>> 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,
> if you find a way that is clean+simple+portable+doesnt depend on swscale :)
More information about the ffmpeg-devel