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

[Michael Niedermayer]

On Wed, Jun 25, 2008 at 01:53:50PM +0200, Stefan Gehrer wrote:
> 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.

indeed, ive missed that possibility, so iam fine with either patch, apply
what you prefer

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080625/f3ebc888/attachment.pgp>