[FFmpeg-devel] [PATCH] to support newer neAAC for libfaadbin
Fri Jan 25 12:23:32 CET 2008
2008/1/25, M?ns Rullg?rd <mans at mansr.com>:
> "Zdenek Kabelac" <zdenek.kabelac at gmail.com> writes:
> > 2008/1/25, M?ns Rullg?rd <mans at mansr.com>:
> >> "Zdenek Kabelac" <zdenek.kabelac at gmail.com> writes:
> >> > 2008/1/24, M?ns Rullg?rd <mans at mansr.com>:
> >> >> "Zdenek Kabelac" <zdenek.kabelac at gmail.com> writes:
> >> >>
> >> >> > 2008/1/24, M?ns Rullg?rd <mans at mansr.com>:
> >> I'd be surprised if this resulted in any difference at all in the
> >> compiled code. Rather than micro-optimising things like that, feel
> > Really around 100 bytes - just check the compilation size - It also
> > might safe relocation on the startup I think.
> OK, I'll have a look.
I should add that this is on 64bit - maybe on 32bit its a bit less - not sure..,
> >> free to clean it up a bit instead. It's a total mess as is. Oh wait,
> >> it was you who wrote it to begin with...
> > Yep - but I don't see it as total mess - IMHO its quite reasonable
> > and efficient - but if you see a solution which would be cleaner and
> > would have the same functionality and would be without compiler
> > warnings - I'd love to see it (I did not created dlsym API and C
> > casting rules...)
> It has more bugs than I care to count. We obviously have very
> differing ideas of what makes a mess.
Well I could image to split the initialization outside into some header file
(so it would clean the mess in the main C file - which I believe is
the most stressing thing for you)
I guess you mainly dislike the idea of runtime linking?
But if you want to support this style of linking for libraries which
are mostly prohibited to be regularly legally distributed and you want
to avoid releasing multiple different binaries - I don't see any other
easy way :(
More information about the ffmpeg-devel