[FFmpeg-devel] Bounties?

[Panagiotis Issaris]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Robert,

Robert Swain wrote:
> On 24 May 2007, at 13:39, Luca Barbato 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'? I'm eager to have such
>>> profiles available 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'. 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.
>>>
>> what about having a nice plain text file with
>>
>> ipods:
>>
>> line1
>> line2
>>
>> psp:
>>
>> line...
> 
> That wasn't the point of my discussion above. If you look at the  
> suggested layout of presets from Takis (I'm intrigued, is Takis a  
> short version of Panagiotis? :) ), 
Yes :)

"Panagiotakis" is the diminutive of my name "Panagiotis". But, as it is
quite lengthy -especially for kids who are often supposed to be using
it-, it is quite common to use "Takis" as a shorthand for it.

> they use a layout very similar to  
> what you suggest.
> 
> The point I was making was that I think options preceeding a preset  
> (including specification of another preset) should be overwritten by  
> said preset and similarly options proceeding a preset should  
> overwrite the options specified in a preset.
> 
>> or just a script that calls ffmpeg accordingly?
> 
> Well this could be and has been done, but the point is to make using  
> FFmpeg easier so people don't have to look for third party scripts  
> and frontends to be able to use the program. We get a large number of  
> requests in the IRC channel for help encoding files that will be  
> compatible with various devices and also for options to improve the  
> quality of video output because the defaults aren't good enough.

I fully agree.

With friendly regards,
Takis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVY4x9kOxLuzz4CkRAuZzAJ9I3QcivqG7WqUohS6docNgc6aDsgCdEUl2
+nW36Qx4OMkyr+6HysK4Vrc=
=VBzy
-----END PGP SIGNATURE-----