[Bf-committers] Re: Audio/Video update (Ton Roosendaal)

Roine Gustafsson roine at users.sourceforge.net
Wed Sep 1 15:13:48 CEST 2004

IMO, ffmpeg is not the best solution. ffmpegs strength is in it's 
libavcodec, which is able to decode many of the popular video formats, 
and encode some of them. The libavformat part, which parses the 
container and demuxes, is much weaker and quite buggy. Most projects 
who use ffmpeg only use libavcodec, like MPlayer, and use their own 
demuxing code.

I suggest you look at GStreamer instead, 
http://gstreamer.freedesktop.org . It can read/write many formats using 
plugins. There's a plugin for libavcodec too.

Also, neither of these are a replacement for real Quicktime, when 
available, so you should definitely not replace that code.
There's a project for reading and writing Quicktime movie files, 
http://libquicktime.sf.net which can be used on systems lacking the 
Quicktime library. It has a completely different API though. There's 
also Quicktime4Linux from http://heroinewarrior.com , which even has 
basic AVI container support.

Most people who use Blender will want production quality output meaning 
uncompressed or lossless compressed video. You should look for a 
library which has industrial-strength container support, not fancy 


On Wednesday, Sep 1, 2004, at 12:11 Europe/Stockholm, Bob Holcomb wrote:

> Ton,
> Just wanted to answer some of your questions about ffmpeg.  It's a 
> multi-platform/architecture library that can be linked statically or 
> dynamically.  It also has no hardware dependancies.  I don't know if 
> ffmpeg is the best library to use to do this, but it's the best one 
> I've found and does seem to be feasible.  However, I'm open to 
> suggestions for other libraries.
> platforms supported:
> Windows, Linux, OS X, SunOS, BeOS, *BSD, QNX
> Dependencies:
> mp3lame, oggvorbis, faad/faac
> It supports quite a few audio/video codecs and containers.  The 
> biggies being MP3, Vorbis, AC3, ADPCM, MPEG(1,2,4), H263, DV, Sorenson 
> 1, Real Video, Quicktime, and AVI.  It would add some size to blender 
> if it's compiled in, but I can't be sure how much bigger.  It will 
> depend on which codecs are supported and which are not.  Also, the 
> current AVI and Quicktime codecs in blender could be removed helping 
> offset the size increase (and cleaning the code a bit). Like the 
> python library, it could be slimmed down for the essential codecs and 
> included as a dynamic library.
> As far as how it will incorperate into the audio system, I think it 
> will be minimal impact.  The current sequencer audio system looks like 
> it will work well for mixing and sending the audio data to the > encoder.
> On the UI side of things, I've created an audio tab and a video tab on 
> the render format panel where you can select the encoder to use (ie. 
> MP3, OGG, ADPCM, RAW, WAV) and the general properites to set for each 
> (Bitrate, Samplerate, FPS).  These values are kept in the G->scene.r 
> data structure.
> I hope I answered your questions.  I'm still wading through the 
> blender code for where the AVI and Quicktime libraries are called to 
> see where changes would need to be made.  If I'm off in left field for 
> any of this, please let me know.
> Cheers,
> Bob
> _________________________________________________________________
> Don’t just search. Find. Check out the new MSN Search! 
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list