[FFmpeg-devel] [PATCH] refactor H.264 decoder/parser common code

[Michael Niedermayer]

On Tue, Jun 16, 2009 at 11:00:01PM +0200, Diego Biurrun wrote:
> On Tue, Jun 16, 2009 at 10:48:26PM +0200, Michael Niedermayer wrote:
> > On Fri, Jun 12, 2009 at 10:50:43PM +0200, Diego Biurrun wrote:
> > > On Fri, Jun 12, 2009 at 10:49:32PM +0200, Diego Biurrun wrote:
> > > > This splits off the code shared between parser and decoder into a
> > > > separate file, similar to what I did for VC-1.  It shrinks h264.c, even
> > > > if just by about 10%.  It's so huge, every bit counts ;)
> > > > 
> > > > There was only one function that I needed to make non-static:
> > > > free_tables.  I declared it in h264.h as
> > > > 'void ff_h264_free_tables(H264Context *h);'.
> > > > 
> > > > OK to apply?
> > > 
> > > Applied.
> > 
> > you meant attached :)
> 
> No, I applied the empty patch :)

:)


> 
> > > OK, and now for the non-empty patch...
> > 
> > i think iam not really in favor of this patch, the split is not semantically
> > sensible IMHO
> > What i would love to see is to cleanly split parts out and fully document the
> > API between them
> > this split does just one thing and that is make it harder to find where
> > a function is, these are all decoder functions, guessing which is currently
> > also used by the parser (a thing that likely wil change) is not easy
> 
> Well, this patch at least reduces the dependencies of the H.264 parser.
> If in the future the functions used by the parser change, it will fail
> to compile or link, so this will be caught eventually.
> 
> In any case h264.c is badly in need of splitting.  The file is
> monstrously huge and takes ages to compile.  Why don't you go ahead and
> split it into more sensible pieces?  What I fear is that this will be

because ive a heap of patches, mails and bugs i should deal with ...
my feeling is more people are able to split h264 cleanly than review patches
and fix bugs but i dont mind doing the spliting and leaving the bugs and
patches to others, iam way behind wit dealing with bugs anyway  ... mainly
because theres always a patch to review or mail to awnser ...


> one more thing that gets added to an ever-growing todo list and never
> actually done...

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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20090616/70e5de5d/attachment.pgp>