Thu May 24 15:02:04 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Robert Swain wrote:
> On 24 May 2007, at 07:43, Panagiotis Issaris wrote:
>> As Victor noted, that was the exact purpose of these patches:
>> The idea was that people could then maintain their own website with
>> different profiles for different devices.
>> The reason I did not repost the patch yet, is that -if I recall
>> correctly- for it to work, the AVOptions conversion stuff should be
>> completed first.
> That's what you stated in the thread. What exactly needs to be done
> to 'complete the AVOptions conversion'?
At first sight it appears the following would have to be converted to
AVOptions to be able to get rid of the currently hardcoded VCD, SVCD,
DVD and DV targets (and their PAL, NTSC and film variants):
* audio_sample_rate ("ar")
* audio_channels ("ac")
* mux_preload ("muxpreload")
At least that was my intention when I submitted the profile patch. The
idea was that you could then get the code out of ffmpeg and using one
multiple profile-configuration files to specify the constraints of the
above mentioned formats|targets.
> I'm eager to have such
> profiles available
Me too. I'd hoped people on f.e. Doom9 and other websites and forums
would then tune the profiles and add new ones for other devices.
Basically, I wanted to avoid that to add support for new devices, people
would have to recompile ffmpeg. Both, to attract people who are not
developers but are multimedia enthusiasts and second to allow easier
tuning by faster testing cycles (for the modified profile settings).
> such that essentially good speed/quality defaults
> can be set for various targets, be they defined by hardware (VCD,
> SVCD, DVD, [I know those are implemented] iPod, PSP, AppleTV, PS3,
> some other portable media player, some other home theatre PC, some
> other standalone device...) or to make encoding for general use
> easier which would mainly entail speed/quality settings.
> Rather than 'profiles' (which may overlap with some future option to
> do with MPEG profiles maybe...?), I would be inclined to call them
Fine for me.
> Would it be reasonable to consider the order of the
> specification of a preset as to whether it overwrites other options
> or other options overwrite it? For example, for a device that
> supports iPod 640x480 H.264 but only up to 1000kbps:
> ffmpeg -i infile -preset ipod_h264_640 -b 1M -maxrate 1M outfile.mp4
> Or, if there were quality presets for h.264 that had some overlap
> with the iPod specifications (a h.264 high quality preset could
> specify 5 reference frames while the iPod H.264 640x480 preset would
> only allow 1 reference frame for example) then:
> ffmpeg -i infile -preset h264_hq -preset ipod_h264_640 outfile.mp4
> Would result in the latter preset options overwriting the former.
I thought that was already the case with my patch or now with the
> Any comments?
With friendly regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the ffmpeg-devel