[FFmpeg-devel] [PATCHv3] On2 VP7 decoder

[wm4]

On Sun, 30 Mar 2014 00:31:07 +0100
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Sat, Mar 29, 2014 at 05:24:03AM +0100, Vittorio Giovara wrote:
> > On Fri, Mar 28, 2014 at 3:14 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > >>
> > >> You're welcome, it would be just nice if these kind of security
> > >> reports were bi-derectional.
> > >
> > > Iam not sure i understand your suggestion (or complaint if its meant
> > > as one)
> > 
> > It was wishful thinking.
> > 
> > > Iam not keeping a secret list of security issues in libav.
> > > Actually iam not a user of libav at all, so i dont notice in general
> > > when theres an issue in libav.
> > 
> > You definitely are a Libav user, as is every ffmpeg developer and
> > user, as you merge every day whatever change Libav provides.
> > The fact that you can accept
> 
> thats a game of words where you use a different definition of user.
> also called a strawman argument
> 
> Noone disputes that people using FFmpeg also use code developed by
> libav developers but that doesnt imply that they use the
> unmodified libav.
> 
> 
> > 
> > > I did very rarely test it for sake of an argument or for some
> > > statistics only ...
> > >
> > > So really the only place i could find an issue is in ffmpeg and
> > > if i do, it goes either as bugfix patch to the ML, as bugfix commit to
> > > git master, as ticket to trac or on my todo list for doing one of the
> > > previous once i have time
> > 
> > The point is that this daily merge from Libav to ffmpeg also allows to
> > fix bugs sometimes and this is good, but the problem is that these
> > seldom bugfixes remain here while they should be reported to the
> > original author at least. This should be done in the spirit of open
> > source contribution, not in the "my project has more features and more
> > bugfixes".
> 
> Lets see
> FFmpeg merges from libav the commits as they are and we fix issues
> in them as seperate commits on top of that. Keeping the code that
> was taken from libav and each change on top of that seperate.
> 
> OTOH
> Libav takes code from FFmpeg and rebases and stashes fixes and
> improvments together so that noone can afterwards easily see what was
> changed and why.

There's some truth here. Sometimes I wonder whether the usual Libav
development pattern of reformatting a file before making major changes
to it is a way to make merging it harder. Now maybe this already goes
into the realm of conspiracy theories. But the truth is probably while
they don't intentionally do this, they don't care much about making the
merger's (MiNi's) life easier.

And that is not very nice.

It's not so much a problem with changes initiated by Libav, but it gets
a really big mess when they do this with backported changes. It's a
pain for other developers too, because it makes it harder to review
what actually got changed, what's different over the original ffmpeg
patch, etc.... Keep in mind that quite some developers contribute to
both projects and possibly looked at the original ffmpeg patch too.

Same can be said about Libav work being merged into FFmpeg before it
lands in Libav, like the HEVC decoder. So both sides have to work on
their behavior.

> Just as an example from the last 2 days you can take a look at:
> The brender pix decoder in libav:
> https://github.com/Libav/libav/commit/ae17878fb2ab100264226c84c58f5b95a703312f
> compared to the original that was in ffmpeg before:
> https://github.com/FFmpeg/FFmpeg/blob/68014c6ed98b5c90f4dc211429dd269ac727be4b/libavcodec/brender_pix.c
> 
> FFmpegs changes on top of what i merged back from libav:
> https://github.com/FFmpeg/FFmpeg/commits/bcd5fd5346be263162792be595eff9fc08e5c853/libavcodec/brenderpix.c
> 
> or you can take a look at todays commits
> my fix to the dvdsub code also was seperate and not stashed in the
> merge
> https://github.com/FFmpeg/FFmpeg/commit/8a9d0a1561470a185a3d09676fcf9b44830a4bfe
> 
> 
> so really, libav seems trying very hard to make their changes unuseable
> by ffmpeg while OTOH it seems seperate commits for each fix in ffmpeg
> arent enough for libav to use them.
> 
> its probably not very diplomatic but IMO, if you fork another project
> you should accept that if you dont merge all changes that you wont
> have all changes then and that the extra work that choice causes is
> your problem.
> 
> And yes i would suggest that all libav developers just join ffmpeg,
> end the split and noone has to do duplicate work, testing and
> reporting.
> Even more ironic, iam sure most libav developers would be happier had
> the fork never happened but it did and now people seem stuck in that
> split ...
> 
> [...]