[FFmpeg-devel] [PATCH] PB-frames support for i263

Diego Biurrun diego
Sat Feb 21 18:51:05 CET 2009

On Sat, Feb 21, 2009 at 11:41:37AM +0100, Michael Niedermayer wrote:
> code that is under if(not true in current working cases) is not going to break
> the release and thus there is
> no sense to delay it also code that handles cases that just returned -1
> before is also not going to break the release.
> Compared to this many bug fixes which are needed have a very high potential
> to break the release.

I never said such code should not be committed, I just said that people
should be extra confident that they will not cause regressions.

That said, even the seemingly harmless openjpeg wrapper support had
subtle bugs regarding the wrong #include path...

> also iam considering to forbid any future freeze of head if development is
> stoped like that. If the release manager considers a freeze needed that can
> be done after forking and limited to the fork.
> Its enough that development of core parts is stoped, stopping addition of
> new features that cannot break existing feaures is just lame.

No development is stopped.  It is just being refocussed.  We have indeed
seen many bug fixes during the past two weeks, more than usual.  And
people do appear to be exceptionally active.  This is a good thing that
benefits FFmpeg as a whole.

Kostya is still working on other things, it's not a setback if he
commits the new table generator in a week.  Two weeks of freeze after
more than 200 weeks of open trunk will not hurt anybody or cause big
amounts of delay.

Also, as I said, let's collect some experience first and argue about
results and possible improvements after the fact.  Right now it's just a

And now I'm returning to bug fixing and patch application instead of
flaming :)


More information about the ffmpeg-devel mailing list