[FFmpeg-devel] release status

[Robert Swain]

2009/3/1 Michael Niedermayer <michaelni at gmx.at>:
> On Sun, Mar 01, 2009 at 07:10:59PM +0100, Diego Biurrun wrote:
>> There has been a flurry of activity during the past days. ?I must admit
>> I have lost track of current issues. ?So, are there any regression fixes
>> pending or any regressions or nasty new bugs that need to be addressed?
>>
>> Does HEAD compile and pass regression tests on all OSes and CPU
>> architectures? ?FATE looks reasonably green right now but I would
>> like to hear more explicit OKs from you as well.
>
> The sooner we release the sooner we are back to normal development
>
> if you ask about outstanding issues, well
> * h264 timestamps still have a heap of issues but less than 2 weeks ago, i
> ?suspect they could be fixed in 1-2 weeks if ivan works hard on them but it
> ?could take longer

But are there any regressions versus before all this timestamp stuff kicked off?

> * swscale alpha (not the cpu) support is incomplete, theres a large patch that
> ?needs review and another patche iam waiting for to be fixed

OK, this is a new feature so it can wait.

> * ive found some bugs in the parser but my fix does not yet pass regresions
> ?ivans work depends on this fix i suspect as it will make handling pos
> ?easier

See my first comment.

> * searching for keyframes in seeking is missing, maybe ivan will work on this

If this is not a regression and it will take some time to fix, it can wait.

> * mpeg ts is broken, and i dont expect this to change in the short future,
> ?but ill happily be proofen wrong.

Is this a regression in recent times? If not, it's irrelevant for this release.

> * libavfilter needs more people working on it and pushing patches to
> ?ffmpeg-dev

libavfi is a new feature, not a regression and so it can wait. As an
aside, I agree.

> * AVHWaccel & VAAPI (patch que empty, iam waiting for gwenole to post
> ?something) but this will also ake a week at best assuming gwenole works
> ?hard

Is it functional? It would be cool to have this in the release, but if
it's not done, it can wait.

> * imgconvert is still there, i ve lost track if there are any issues left
> ?anyone is whining about (i guess noone knows and they have to search first
> ?for some corner cases to troll about) but i like imgconvert droped

As we are not sure, I would suggest an audit of sorts after the
release to make sure swscale is now completely functional in LGPL
'mode' and then some effort should be made to clean up the
organisation of the LGPL C code versus GPL asm code. The former is
mandatory for dropping imgconvert so that we are certain that there
will not be license disruption. The latter is just a good thing to
have.

> also all the timestamping stuff is moderately risky and can uncover other
> bugs

I think these alterations should have waited until after the release
unless it was clear they would be both completed and not introduce
regressions. But it's done now. So in terms of things being held back,
I actually think we could have (and possibly should have - we'll see
how it turns out) been much more conservative.

> PS: It might make sense to do another release soon in case the above issue
> ? ?end up being fixed. But i think delaying this one more is not good.

I totally agree with this as it is clear we have a few significant
issues/features which are almost resolved/completed. And we may get
some feedback about things like the new metadata API that will produce
some bug fixes that we want in a release.

> ? ?And i like to see the next done without a freeze of HEAD.

Hmm, so what do you propose? A tag and branch, backporting fixes to
the branch up until we make the release?

Regards,
Rob