[FFmpeg-devel] Google Summer of Code participation
Thilo Borgmann
thilo.borgmann
Thu Apr 9 09:19:00 CEST 2009
Michael Niedermayer schrieb:
>>>> + int offset = 0;
>>>> + uint8_t *pd = s->image_buf;
>>>> + uint8_t *pd_last = s->last_image_buf;
>>>> +
>>>> + for(j=0; j < s->height; j++) {
>>>>
>>>>
>>>
>>>
>>>> + for(i=0; i < s->image_linesize; i++) {
>>>>
>>>>
>>> width
>>>
>>>
>>>
>> No. image_linesize != width. Linesize is needed here as the copy is done
>> byte-wise. But there are s->height of these long lines.
>>
>
> we want to just change width pixels not linesize samples.
>
>
>
From that point of view, yes of course. But as we have a uint8_t
pointer, which increments by 8-bit and a picture buffer with 24 bits per
pixel in that case...
I've used width in revision 1 but this is worse as there are 12 new
multiplications per iteration instead of 3 times as many iterations.
And this way even works only with 3 bytes a pixel, what about 8 and 16
or 32?
The linesize version is independent...
What do I not understand?
>>
>> Hmm to avoid this call I think about double buffering via a second AVFrame
>> in the PNGContext instead of a uint8_t buffer? If you agree I will do this
>> tomorrow.
>>
>
> yes, that was my thought as well
>
>
Done.
Revision 1 attached, just for reviewing the double buffering... there is
still the width<->linesize issue...
TB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tb.CorePNG.rev1.patch
Type: text/x-patch
Size: 2796 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090409/bdff6f92/attachment.bin>
More information about the ffmpeg-devel
mailing list