[FFmpeg-devel] [PATCH] Move cavs dsp functions to their own struct

Måns Rullgård mans
Tue Aug 3 22:53:43 CEST 2010


Stefan Gehrer <stefan.gehrer at gmx.de> writes:

> On 08/03/2010 01:13 AM, Mans Rullgard wrote:
>
>> diff --git a/libavcodec/cavs.h b/libavcodec/cavs.h
>> index 729c83e..c80fd32 100644
>> --- a/libavcodec/cavs.h
>> +++ b/libavcodec/cavs.h
>> @@ -24,6 +24,7 @@
>>
>>   #include "dsputil.h"
>>   #include "mpegvideo.h"
>> +#include "cavsdsp.h"
>>
>>   #define SLICE_MAX_START_CODE    0x000001af
>>   #define EXT_START_CODE          0x000001b5
>> @@ -153,6 +154,7 @@ struct dec_2dvlc {
>>
>>   typedef struct {
>>       MpegEncContext s;
>> +    CAVSDSPContext dsp;
>
> Since there are still references to the DSPContext left
> (e.g. clear_block and h264 chroma MC) I agree with Michael that it
> is a bit confusing, renaming to e.g. "cdsp" would be sufficient to
> avoid it.

OK, will do.

>> diff --git a/libavcodec/cavsdsp.c b/libavcodec/cavsdsp.c
>> index 808f62b..3593cfa 100644
>> --- a/libavcodec/cavsdsp.c
>> +++ b/libavcodec/cavsdsp.c
>> @@ -24,6 +24,7 @@
>>
>>   #include<stdio.h>
>>   #include "dsputil.h"
>> +#include "cavsdsp.h"
>>
>>   /*****************************************************************************
>>    *
>> @@ -510,7 +511,7 @@ CAVS_MC(put_, 16)
>>   CAVS_MC(avg_, 8)
>>   CAVS_MC(avg_, 16)
>>
>> -av_cold void ff_cavsdsp_init(DSPContext* c, AVCodecContext *avctx) {
>> +av_cold void ff_cavsdsp_init(CAVSDSPContext* c, AVCodecContext *avctx) {
>>   #define dspfunc(PFX, IDX, NUM) \
>>       c->PFX ## _pixels_tab[IDX][ 0] = ff_ ## PFX ## NUM ## _mc00_c; \
>>       c->PFX ## _pixels_tab[IDX][ 1] = ff_ ## PFX ## NUM ## _mc10_c; \
>> @@ -537,4 +538,6 @@ av_cold void ff_cavsdsp_init(DSPContext* c, AVCodecContext *avctx) {
>>       c->cavs_filter_cv = cavs_filter_cv_c;
>>       c->cavs_filter_ch = cavs_filter_ch_c;
>>       c->cavs_idct8_add = cavs_idct8_add_c;
>> +
>> +    if (HAVE_MMX) ff_cavsdsp_init_mmx(c, avctx);
>
> Can you just remind me: If we rely on the behavior that compiling
> if(0) foo();
> does not leave unresolved references to foo in the object file,
> is that by some specification or just by experience from the
> compilers we support?

It works with every compiler we've ever encountered.  That's good
enough for me.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list