[packman] ffmpeg not in monolithic repository

[Carl Eugen Hoyos]

Neil Darlow <neil at ...> writes:

> On Sunday 03 Apr 2011 23:13:23 Carl Eugen Hoyos wrote:
> > But it contained a regression before it was merged into FFmpeg.
> 
> So libav introduced features that were less than perfect while the ffmpeg 
> project chose to wait until they were?

That is how FFmpeg development is done, yes.
(Note that the main criticism about the project maintainer was that he paid too
much attention on reviews and not enough on development. He has now switched to
a more active development style that implies less reviews, but the most obvious
exploitable issues and regressions that are part of the fork are still refused
in FFmpeg.)

> > Fortunately, you do not have to believe me to know that this is not
> > correct, you just have to read the explanation from the ffmpeg-mt
> > developer:
> > http://article.gmane.org/gmane.comp.video.ffmpeg.devel/124245
> 
> My information was taken from the libav website's explanation for their 
> existence. Maybe I should have consulted the ffmpeg project for their 
> perspective on why libav came about. I'm sure there are reasons, both good
> and bad, on both sides.

I am looking forward desperately for the bad reasons on the FFmpeg side ;-)
(Although, on a more theoretical basis, I don't know how FFmpeg's reasons for
people to fork after they unsuccessfully tried to take over the project can a)
exist and b) be bad.)

> > Note that FFmpeg contains several features missing in the fork, video
> > filters among them. (No features from the fork are missing in FFmpeg, the
> > fork just contains less fixes for user-reported bugs.)
> 
> I don't know how to interpret that. libav removed features from ffmpeg.

Do you claim that or is this something that you interpreted from my mail?
While the fork actually has removed "features" by breaking API/ABI, I do not
know of features (things the application can do) that were removed, I just know
that the fork currently has less features than FFmpeg because they prefer not to
pull new features (and bug fixes) from FFmpeg.

> Is 
> there an inference that libav removed troublesome features or it is that
> their development model provides less manpower or time for bug fixes.

I fear I am not capable of answering the question why the fork misses most
bug-fixes from FFmpeg development - both security and usability-wise.

> Correctness of my statement apart, I am sure that Manfred switched from
> ffmpeg to libav for good reasons.

The reason I posted here is that I would like to hear those reasons (after all,
I may miss something that happens - or is planned or promised - in the fork but
not in FFmpeg - this knowledge could be used to improve development in FFmpeg).

> I also expect he was aware of any defiencies 
> introduced by making the switch before he committed to doing so.

Given how you believed what the people who forked claim on their homepage were
true, how should he?

Carl Eugen