[FFmpeg-devel] new open source h.264 source

Måns Rullgård mans
Thu Feb 21 01:28:11 CET 2008


Gonzalo Garramu?o <ggarra at advancedsl.com.ar> writes:

> M?ns Rullg?rd wrote:
>> Ugh.  I guess the first task would be to de-C++ that code.  Or perhaps
>> it's a not-so-subtle clue that this package is a waste of time.  After
>> all, any sane person would have made this a C library, not C++.
>> 
>
> Why?  After a very quick glance, it is quite good C++.  While the 

Good C++ is an oxymoron.

> library is huge, the code is certainly much more readable to me than
> ffmpeg's source code (sorry for saying so).

FFmpeg has highly optimised implementations of complex algorithms.  It
is hardly surprising if it takes a little effort to understand.

> Doing the same in C would involve 3 times the code.

Yes, achieving the same level of obfuscation probably requires about 3
times the amount of code in C as in C++.

> There's some clever (and in this case justified) use of templates
> that simplify the code enormously.

Would you really trust a C++ compiler with performance-critical code?
I'll take my C macros anytime.

> Use of scons (yet still use bash scripts) and providing a copy of
> boost in their repository is certainly something I would call quite
> questionable.

Indeed.  Typical C++ manners.

>> Has anyone seen any benchmarks of this code.  
>
> Probably nothing has come out yet.  I do expect to have very good 
> performance on a lot of the stuff it provides.  The library seems like 
> it is basically SSE2 + Templates for a lot of common math, image and 
> video functions.

Vendor libraries are not always what they're cracked up to be.  Just
search this list for mentions of Sun medialib.

> It can probably still be made a little bit faster here and there.  The 
> code seems to written with readability in mind.

Readability and maximum performance are often mutually exclusive.

> The order of several loops could probably be reversed, there's not
> much use of clever bit shifting, etc.  (ie. all the low-level C type
> of coding that ffmpeg really excels at).

So in other words, this library isn't all that hot after all.

>> BTW, what reputable company chooses to host
>> something on sourceforge?
>
> At this point in time, pretty much any large company or organization 
> that is not against open source.  You'll find projects there from AMD, 
> Intel, HP, ILM, AMPAS, ICC, etc.

Most big-company projects found on sourceforge tend to be throwaway
code posted more for publicity than anything else.  Intel's real
stuff, e.g. network and graphics drivers, is hosted elsewhere.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list