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

[Kostya]

On Sat, Feb 21, 2009 at 03:28:55PM +0100, Michael Niedermayer wrote:
> On Sat, Feb 21, 2009 at 02:29:09PM +0200, Kostya wrote:
> > 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.
> > > 
> > > 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.
> > > 
> > > A freeze is NOT about only doing bug fixes (that may or may not break the
> > > whole ffmpeg) BUT
> > > its about NOT doing changes that could break the release unless they are
> > > essential bug fixes.
> > 
> > I'll wait until we have formal release rules instead of flamebait. 
> 
> you dont have to commit but please dont call a decission of the ffmpeg
> leader flamebait if you disagree with it.

I was referring to "Freeze" thread.

> Besides in the absence of written rules the decission of the ffmpeg leader
> or the maintainer of the code in question holds, iam both in this case.
> 
> and i rarely make decissions overriding others but things slowly change
> from the prommised
> "you dont have to do any work, just dont be in the way of the release"
> to
> "the release is in everyones way and especially in ffmpegs way"
> 
> there are factorization patches to yuv2rgb_template for example and your
> LGPL patch to yuv2rgb, i really would prefer not to have people spend
> time adding alpha support to yuv2rgb to then see a discussion start
> about what to do with the no longer applying lgpl yuv2rgb ...

IIRC, you can expect AVR32-specific stuff related to yuv2rgb from Mans too.

> and the whole holding up swscale even further and just on top of that
> peter already wasted time adding half functional rgb48 support to
> imgconvert, something that could have been prevented had imgconvert finally
> been droped
> so while i can live with the PB frame code being delayed for a week, it
> just harms the quality of the release if the header parsing isnt fixed and
> pb frames arent supported. Hey its just the standard in the FOSS world of
> having released being outdated before they are released ...
> i will not accept yuv2rgb to be delayed because this holds swscale/imgconvert
> up and that did already cause people to waste time

Since regressions are passed now (with a patch, of course) I can apply it.
Additional patch is required to drop --enable-swscale, GPL check for it and
dropping imgconvert - someone have to write it though.

> and your patch looks ok and for the release too if its tested with a few h263
> i263 videos and they are _binary_ identical

Will test and apply in case of success tomorrow.
The hardest thing is to find some time to perform tests (I do not want to break
anything, honestly, but I suspect I can).

> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB