[FFmpeg-devel] Bounties?

[Robert Swain]

On 24 May 2007, at 14:02, Panagiotis Issaris wrote:
> Robert Swain wrote:
>> On 24 May 2007, at 07:43, Panagiotis Issaris wrote:
>>> As Victor noted, that was the exact purpose of these patches:
>>>
>>> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/37220
>>> http://article.gmane.org/gmane.comp.video.ffmpeg.devel/37244
>>>
>>> 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.

OK

>
>> 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).

There are hacked firmwares for the PSP and so on and I'd be inclined  
to leave such things to the communities interested in using them. But  
generic official stuff could go into an official FFmpeg preset file.

>> 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
>> 'presets'.
>
> 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
> "-target" option.

Maybe, I didn't check. Just pointing it out. :)

Rob