[FFmpeg-devel] [RFC] Releases

Reinhard Tartler siretart
Mon May 31 20:07:25 CEST 2010

On Mo, Mai 31, 2010 at 19:19:38 (CEST), Ronald S. Bultje wrote:

> On Mon, May 31, 2010 at 11:34 AM, Reinhard Tartler <siretart at tauware.de> wrote:
>> On Mo, Mai 31, 2010 at 17:10:18 (CEST), Ronald S. Bultje wrote:
>>> Back to FFmpeg. Michael (and many others) would like releases out,
>>> and hate the classical caricature of releases, because we want
>>> features for end users (that's anyone that uses an application that
>>> uses FFmpeg). Now, for example, we'd like users to have vp8 decoding
>>> support (let's leave the licensing issue aside for a second). In the
>>> past, that might've been any other codec. That is the veyr point of
>>> our existence. Running out the next 0.5.x doesn't help achieve this
>>> purpose, which is why we care less about it.
>>> We'd like a release system that achieves the purpose of getting the
>>> next big-format decoder to as many end users as possible in the
>>> least amount of time. Can we think of a release system that achieves
>>> this?
>> I see no problem in backporting features like libvpx support to
>> ffmpeg-0.5, since it has little potential for regressions.
> What about (AAC/)SBR? (AAC/)PS? I'm not sure what else is missing but
> I think WMAVoice, Sipro are also not part of 0.5.x. MMS-TCP?
> More generally, I'm trying to ask how much you're willing to backport
> (assuming you do releases, which I'm very much in favour of).

I have always considered any backport nominations by the corresponding
and responsible maintainer.

For more introsive backports however I have to ask for a) a proposed
patch and b) a sufficient risk analysis wrt potential regressions.

For 0.5, we had an WMAPro backport proposed, but the maintainer had
serious concerns with that, so we rejected that backport. As for
AAC/SBR, if that is backportable easily with acceptable risk of
regressions, sure, why not?

Reinhard Tartler, KeyID 945348A4

More information about the ffmpeg-devel mailing list