[FFmpeg-devel] release status

[Robert Swain]

2009/3/1 Michael Niedermayer <michaelni at gmx.at>:
> 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 ...)

OK, so these changes have been improvements, good. I wasn't aware
things were significantly broken before and just had the impression
that you were trying to clean things up/generalise the implementation.
Admittedly I didn't follow the threads about timestamp issues too
closely.

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

Hmm, I suspect if you had enough confidence in it to make the change
before the release, you would have committed it already.

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

OK, good.

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

OK.

>>
>> > * 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 ;)

I've never claimed to be a leader, I don't aspire to be one though my
discussion and actions may seem to suggest I do.

I'm trying to clarify situations so that people can see what needs
doing. I think if people are unaware of the status of various issues
and unaware of what needs addressing immediately then any progress is
just a disorganised snow ball of random enthusiasm.

For example, your responses above clarify that there are very few
issues pertaining to making the release. And the responses to the FATE
messages suggests that we just need to clarify the state of Linux
x86_32 before going ahead with the release.

How can one organise and delegate work to people if one does not know
what work needs to be done?

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

Some of our commercial users sponsor some of us to develop FFmpeg. I
think being supportive of them is a good thing. I don't think FFmpeg
being GPL for a couple of weeks would really hurt anything practically
in the grand scheme of things, but it may hurt things politically. I
don't really care for such myself but I think it would be ignorant to
suggest it would have no adverse impact on FFmpeg to take such a
course of action.

Anyway, on to productive discussion. I started to look at what needed
to be done to make sure swscale is available in LGPL earlier this week
but I have been side-tracked since. I will return to it ASAP.

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

I can understand you feeling the weight of your position and I will
try to help reduce your load. Maybe you also need to delegate work
better through encouraging people to work on things rather than taking
negative action such as forcing GPL upon people and ripping things out
so that things _have_ to be done. It seems like going to war before
exhausting diplomacy.

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

See above comments about commercial entities and their relationship
with FFmpeg. I do think we should be receiving more sponsorship from
various commercial users of FFmpeg though, only as long as these users
do not try to steer the course of our development in a negative way.
It is clear that FFmpeg's good parts are such high quality because of
the pedantism and attention to every last detail of the code. That
must persist.

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

Of course not. Like I said above, I was unaware that there was a
problem and thought the effort was to clean things up and generalise.

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

I think the tag and branch approach may be better. ;p

Regards,
Rob