[FFmpeg-devel] [PATCHv3] On2 VP7 decoder

[Michael Niedermayer]

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.

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

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140330/b2b956db/attachment.asc>