[FFmpeg-devel] MPEG-2 Acceleration Refactor

Greg Hulands ghulands
Sun Jun 17 04:37:02 CEST 2007


Hi Michael,

On 16/06/2007, at 6:52 PM, Michael Niedermayer wrote:

> Hi
>
> On Sat, Jun 16, 2007 at 06:44:21PM -0700, Greg Hulands wrote:
>> Based on the START/STOP_TIMER stuff showing the patch is actually
>> faster I have tidied the patch a little more and removed the function
>> prototypes to the _fast functions at the top of the file.
>>
>> If there are any other problems from stopping this getting committed,
>> please let me know.
>
> yes, why is it faster now and was slower before?

I really don't know. I am out of my depth with all this. I am just  
trying to do what was originally asked when Nigels patch was  
rejected. I thought you would have more of an idea as to why.  I put  
the START_TIMER at the start of the function and STOP_TIMER("function  
name()") at the end. In the trunk with out the patch, I did this in  
the methods listed below and with the patch, the same methods minus  
the _fast ones as they have been refactored.

mpeg_decode_mb
mpeg1_fast_decode_block_inter
mpeg2_decode_block_non_intra
mpeg2_fast_decode_block_non_intra
mpeg2_decode_block_intra
mpeg2_fast_decode_block_intra

  But in any case the numbers don't lie.

> [...]
>> Index: mpeg12.c
>> ===================================================================
>> --- mpeg12.c	(revision 9339)
>> +++ mpeg12.c	(working copy)
>> @@ -47,25 +47,25 @@
>> #ifdef CONFIG_ENCODERS
>> static void mpeg1_encode_block(MpegEncContext *s,
>> -                         DCTELEM *block,
>> -                         int component);
>> +                               DCTELEM *block,
>> +                               int component);
>
> cosmetic
>
> note a single cosmetic (whitespace only) change in a patch which  
> contains
> functional changes leads to rejection of the patch
> such changes belong into a seperate patch

I'm confused. The first patch I submitted today, you rejected because  
I had used tabs - fair enough. How was the original non-cosmetic code  
allowed in the repository if one of the first rules of rejection is  
cosmetics?

I am using spaces now so I don't know why in the email it looks like  
the cosmetic problems are still there. Maybe mailmail is doing  
something. I will attach the file next time round instead of pasting  
it in.

So just to clarify for this patch, you don't want me to fix the  
cosmetic problems with the function prototypes, but all code that I  
touch, you do?

Cheers,
Greg





More information about the ffmpeg-devel mailing list