[FFmpeg-devel] DCA Decoder

[Derek Buitenhuis]

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.

>> From what I understand, neither of them implements fixed point yet in
>> the core DCA decoder, which means neither is actually lossless or
>> bit-exact.
> 
> ok, but do they implement something testable ?
> and if so, how can this be tested ?
> knowing this will be usefull to anyone working on the code

I do not think DCA extensions are independently testable from the core,
but I may be misunderstanding.

- Derek