[FFmpeg-devel] [PATCH] reduce global data in lavc

[Stefan Gehrer]

Michael Niedermayer wrote:
> On Wed, Jun 25, 2008 at 01:13:19PM +0200, Stefan Gehrer wrote:
>> Michael Niedermayer wrote:
>>> On Wed, Jun 25, 2008 at 09:17:44AM +0200, Stefan Gehrer wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Tue, Jun 24, 2008 at 10:52:34PM +0200, Stefan Gehrer wrote:
>>>>>> Stefan Gehrer wrote:
>>>>>>> Hi,
>>>>>>> After this patch, there are still global variables around
>>>>>>> which I would categorize as the following:
>>>>>>> 1. run-length tables that I think can be avoided by using
>>>>>>>   INIT_VLC_STATIC, but I haven't looked closely.
>>>>>>>   These can be found in the following files:
>>>>>>>   msmpeg4data.o (rl_table, mv_tables, wmv2_inter_table)
>>>>>>>   mpeg12data.o  (ff_rl_mpeg1, ff_rl_mpeg2)
>>>>>>>   h263.o        (rl_inter, rl_intra_aic, rl_intra,
>>>>>>>                  rvlc_rl_inter, rvlc_rl_intra)
>>>>>>>   h261dec.o     (h261_rl_tcoeff)
>>>>>>> 2. temporary space for compound literals in many files
>>>>>>> 3. ModeAlphabet in vp3.c, which is written to and thus
>>>>>>>   should be moved to the context
>>>>>> attached patch fixes point 3.
>>>>> does that really need to be in the context, isnt the stack enough?
>>>> That depends on whether the custom mode alphabet stays
>>>> valid only for one frame.
>>>>
>>>> http://multimedia.cx/vp3-format.txt says:
>>>>
>>>> " The MB coding mode information is encoded using one of 8 alphabets.
>>>> The first 3 bits of the MB coding mode stream indicate which of the
>>>> 8 alphabets, 0..7, to use to decode the MB coding information in this
>>>> frame."
>>>>
>>>> The "this frame" sounds like so, but the safe method would be to put
>>>> in a test for reusing the custom alphabet in following frames and
>>>> run it over the samples we have. Do you think this is necessary, or
>>>> can maybe some VP3-pro confirm that the custom alphabet stays valid
>>>> only for one frame?
>>> RTFS and tell me how on earth the custom modes of a previous frame could
>>> ever be used.
>>          if (scheme == 0) {
>>              debug_modes("    custom mode alphabet ahead:\n");
>>              for (i = 0; i < 8; i++)
>>                  s->custom_mode_alphabet[get_bits(gb, 3)] = i;
>>          }
>>
>> It depends on the bitstream which values of the alphabet are
>> overwritten and which are not, or am I missing something?
> 
> yes, that the only place using it will only if scheme == 0
> and nothing writes to scheme between

I know that, but

for (i = 0; i < 8; i++)
     s->custom_mode_alphabet[get_bits(gb, 3)] = i;

could for example write only to s->custom_mode_alphabet[0] eight times
if there are 24 zero-bits in a row and then

coding_mode = s->custom_mode_alphabet[get_vlc2(gb, 
s->mode_code_vlc.table, 3, 3)];

could read from an index different to zero.

Anyway, this is maybe far-fetched and a patch to place the custom
mode alphabet on the stack is attached.

Stefan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: vp3global.diff
Type: text/x-diff
Size: 2288 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080625/42faada4/attachment.diff>