[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