[FFmpeg-devel] release status

[Michael Niedermayer]

On Sun, Mar 01, 2009 at 07:48:04PM +0000, Robert Swain wrote:
> 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?

It wasnt working before
If you ask me if the random timestamps where by luck sometimes correct and
that by more luck they are wrong in that case now, well iam not aware of a
specific case but i did not search for one either (it was said, you dont have
to work for the release just dont be in its way ...)


[...]
> > * 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.

i can commit my fixes if you want but i make no promise about the regressions
that might cause (make test, the h264 conformance & some random files pass)
also these are all old bugs no regressions as far as i can see


[...]

> > * 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.

mpeg ts never worked but baptiste has improved it somewhat in recent times.


[...]
> > * 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.

it needs more work ...


> 
> > * 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.

you wont be a good leader because you should distribute work on others
not make long lists that noone has reason to work on nor that if someone
did where worth the effort (yes iam harsh and a little rude i know ;)

correct way: drop imgconvert, force people who care to add the 5 #ifdef GPL
and find/report any regressions, then concentrate the limited developer
power to fix the reported issues.

wrong way: do everything yourself while 50 issues in other parts of ffmpeg
arent dealt with, while 50 patches and their authors are waiting for a review
...

when it comes to imgconvert we have people who "have to" fix things if
imgconvert is droped we should use them. And keep in mind its to some
part at least people who use ffmpeg for their commercial LGPL requireing
code, i have little interrest to work for free to make non(/half free use of
ffmpeg easier.


> 
> > 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.

you preferred non functional h264? over a regression that has not been
spot by anyone in a few days?


[...]
> > ? ?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?

just throw a dice each week and when you get a 2 do a svn up and
make a tarball [except of course if something is known to be broken]
it worked fine for our users since ages to use 'svn up' from random
times ...


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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/20090301/611e68d0/attachment.pgp>