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

[Michael Niedermayer]

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:
> > On Sat, Feb 21, 2009 at 10:34:05AM +0200, Kostya wrote:
> > > On Fri, Feb 20, 2009 at 06:52:12PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 20, 2009 at 08:17:24PM +0200, Kostya wrote:
> > > > > On Fri, Feb 20, 2009 at 01:09:08PM +0100, Michael Niedermayer wrote:
> > > > > > On Fri, Feb 20, 2009 at 11:37:40AM +0200, Kostya wrote:
> > > > > [...]
> > > > > > > 
> > > > > > > This one should be right.
> > > > > > 
> > > > > > ok
> > > > > 
> > > > > I'll apply it after code thaw then (i.e. next week).
> > > > 
> > > > you dont want to fix pb frames in the release?
> > > > well i dont care, as long as i dont have to redo the review ...
> > > 
> > > it's not fixing, it's rather new feature (i.e. not a thing for release) 
> > 
> > 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.
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 ...
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

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090221/ef0549c7/attachment.pgp>