[FFmpeg-devel] DCA Decoder
michaelni at gmx.at
Thu Mar 12 13:34:40 CET 2015
On Thu, Mar 12, 2015 at 11:47:55AM +0000, Derek Buitenhuis wrote:
> On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
> > you continue to talk about something completely unrelated to what i
> > said/meant.
> > you: take best code
> > I: for code to be ever in FFmpeg it must either be developed on top
> > of FFmpeg or it must be rebased/ merged/integrated at some point. Its
> > better if its developed and tested on top of FFmpeg in the first place
> > as this is less work and has a lower chance of bugs.
> FUD as usual, and utter nonsense - see below.
> > The difference here is the "question" that is awnsered
> > like in "there are 2 X implementations, which should we use" vs.
> > "I want to write a X implementation, on top of what codebase should
> > i do the work"
> Except it's already written. "I want to" is not a part of the question,
> for either implementations.
> >> Yeah, merge one patchset in FFmpeg, and if it turns out the other functions
> >> better, the resulting mess is best summed up as "a clusterf*ck"...
> > you really are missunderstanding what i meant
> > I did not mean to suggest to push
> > something to main FFmpeg master, i suggested or intended to suggest,
> > that code be developeed on top of FFmpeg, code generally is developed
> > by a devloper locally on his box or in his own public repo.
> Writing in full English sentences certainly would help my comprehension.
> My point above was that both are already 'developed' to a usable point,
> as far as I can tell. It's irrelevant which codebase they're on top of.
> They both exist. They can both be merged in different ways.. Being developed
> on top of one codebase or the other does not give an advantage, and does
> not make it in any way special in any sense.
> I am looking at what is the best end result for the *user*. The answer to that
> is a *single* decoder, which works the best - regardless of the "effort" it. Yes,
> I don't buy that merging one from Libav causes "more bugs" than independently
> reviewing and pushing a different one.
> I am sad to see that so many years later, these sorts of stupid tropes are still
> being thrown around by everyone on both sides. Scaremongering and FUD, whether or
> not you truly believe it to be the case or not. The users are the ones suffering
> in the end.
> >> This is a strawman argument (or perhaps just FUD).
> > From your point of view its indeed a strawman, and from my point of
> > view your arguments are a strawman because we just talk about 2
> > completely different things from the begin.
> Yes, from my point of view. The view of someone who is associated with
> neither project, and is a downstream user. Someone who doesn't care
> about the past, or people being butthurt by someone else which I did
> not witness. Someone who cares about how the end result will look.
> Perhaps you should lay off the kool-aid. Even Jim Jones seems sane
> in comparison to these two projects. Y'all are insane.
Its interresting what kind of bizare replies one gets by stating on
the main FFmpeg development list that work should be based on FFmpeg
and should be tested. And then repeating a few times that this is
really what was meant and none of the implications others jumped to
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel