[Bf-committers] FFMPEG properties from Blender presets overridden by defaults?

Peter Schlaile peter at schlaile.de
Sun Nov 21 20:51:54 CET 2010


Hi Randall,

please file a bug report, since ffmpeg custom properties were working 
in Blender 2.49 .

I have to take a deeper look into the code to see, how they should 
reappear in Blender 2.5 (the UI in 2.49 was aehm somewhat strange :) ) 
and filing a bug report, is a way to make sure, I don't forget :)

Cheers,
Peter

> My goal is to encode H264 Quicktime files that are compatible with
> Apple's Quicktime Player (should not be too much to ask, right?). Before
> 2.5, I could do this by tweaking the individual ffmpeg options that were
> exposed in the UI after selecting the H264 preset. That preset was
> clearly designed for making H264 AVI files, but it would work for
> Quicktime after changing the container format and tweaking ffmpeg
> options, especially getting rid of "flags:loop".
>
> 2.5 doesn't expose those options in the UI. They seem to be hardcoded in
> source/blender/blenkernel/intern/writeffmpeg.c under case
> FFMPEG_PRESET_H264. They mirror the options in libx264-default.preset
> that is distributed with ffmpeg. So I'm editing the settings in
> writeffmpeg.c to see if I can get Blender to write a QT
> Player-compatible Quicktime movie. No matter what I do to those
> settings, Blender's stderr stream shows that it is still using the
> defaults, not the settings I modified.
>
> The settings seem to be stored in a RenderData->ffcodecdata.properties,
> but I get lost (I'm not a programmer) as I try to figure out where they
> come from, since they obviously don't come from the FFMPEG_PRESET_H264
> settings I edited. Any help?
>
> Thanks,
> Randall
>
> p.s.: Please don't suggest rendering an image sequence, then encoding
> from the command line! That's what I do for 3D renders, but I want to
> encode output from the VSE. It seems stupid to render an image sequence
> from the VSE, because it would just duplicate the same frames I already
> have on disk but with different frame numbers, wasting a lot of disk
> space.
>
>


More information about the Bf-committers mailing list