[FFmpeg-devel] [PATCH] refactor H.264 decoder/parser common code
Tue Jun 16 23:05:11 CEST 2009
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel