[FFmpeg-devel] [PATCH] H.264 data tables cleanup

[Diego Biurrun]

On Fri, Nov 21, 2008 at 02:17:50AM +0100, Michael Niedermayer wrote:
> On Fri, Nov 21, 2008 at 12:19:46AM +0100, Diego Biurrun wrote:
> > On Thu, Nov 20, 2008 at 10:10:11AM +0100, Michael Niedermayer wrote:
> > > On Thu, Nov 20, 2008 at 09:46:29AM +0100, Diego Biurrun wrote:
> > > > On Thu, Nov 20, 2008 at 09:08:17AM +0100, Michael Niedermayer wrote:
> > > > > On Thu, Nov 20, 2008 at 12:49:03AM +0100, Diego Biurrun wrote:
> > > > > > So I've (re)started working on splitting off svq3.c from h264.c.
> > > > > > 
> > > > > > Here are some simple first steps:
> > > > > > 
> > > > > > - Remove unused tables from h264data.h.
> > > > > 
> > > > > these tables are unused because we dont have an encoder ...
> > > > > putting them under appropriate ifdef or in a seperate encoder
> > > > > specific (not compiled) header seems better than removing them
> > > > > even if there are no plans for an encoder ...
> > > > 
> > > > I don't think it's a good idea to keep cruft around forever.  Also, we
> > > > are just talking about a handful lines of code.  Nobody will waste a
> > > > huge amount of time reimplementing them.
> > > 
> > > its not cruft, it very well could be usefull for a simple h264 bitstream
> > > generator for regression tests. I mean something that maybe just generates
> > > a random bitstream with random coefficients and motion vectors.
> > 
> > OK, move to h264enc.c like in $attached then?
> 
> perfect, now iam happy :)

Committed.

> also thanks for trying to cleanup h264.c, this is definitly appreciated
> and even though h264.c might not be the worst, it is likely one of the
> more important areas we should cleanup and split.

:)

Yes, it does look like an entangled mess, let's see how far I get...

Diego