[FFmpeg-devel] [PATCH] reduce global data in lavc
Michael Niedermayer
michaelni
Wed Jun 25 12:54:01 CEST 2008
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.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
-------------- 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/3221bdd1/attachment.pgp>
More information about the ffmpeg-devel
mailing list