[Bf-committers] Re: Audio/Video update
doug at oakstreetsoftware.com
Wed Sep 1 15:34:02 CEST 2004
There are also the issues of performance and quality. Personally, I like
to keep my encoding tools separate from my authoring tools. New codecs
are common, and Quicktime is updated often. Blender shouldn't try to do
everything. That approach will surely result in a bloated and sluggish
If it's really necessary to do on-the-fly MPEG encoding, due to storage
limitations or something, I'd vote for a command line option that would
pipe the render output as YUV (or something standard), so it can be piped
into an external encoder. A pipeline keeps the tools and processes
separate, allows them to be spread across processors for better
performance on multiprocessor boxes, and eliminates the need to store the
uncompressed output stream.
I'd vote for writing a simple GUI front-end to command line rendering,
that allowed the user to select a blend file and other command line
options, then launch the background render with the click of a button.
The tool could be revised to setup a pipeline to process the output, if
Blender had such an option. This also leaves you free to go on Blending
while your render is running in the background.
On Wed, 1 Sep 2004, Matt Ebb wrote:
> On 1 Sep 2004, at 8:11 PM, Bob Holcomb wrote:
> > Also, the current AVI and Quicktime codecs in blender could be removed
> > helping offset the size increase (and cleaning the code a bit).
> Erm, unless FFMPEG can support every codec that QuickTime can here on
> my Mac (MPEG2, Pixlet, Animation, ...), that would make me rather
> unhappy ;)
More information about the Bf-committers