To everyone:
I am really sorry for having to react to this kind of irrational
arguments. OTOH keeping silence could be interpreted as accepting them.
As far as my common sense goes, I can not count these as "pending comments".
TL;DR:
trying to reason,
given the arbitrary statements and careless behaviour of the opponent
On Mon, Mar 06, 2017 at 10:31:42AM +0100, wm4 wrote:
> I think we've repeatedly made clear that:
> - we don't really want the decoder to output multiple pixfmts by choice
It is clear that you personally do not want the Cinepak decoder to be able
to output multiple pixel formats, for unspecified reasons ("by choice").
You make it look like it is your discretion who decides whether something
is deemed to be good or not for FFmpeg. I do not believe this.
> - but if it's limited to a very small number of formats (say, 2) it
> might be ok
You are again referring to nothing but your discretion.
Anyway, if you take your time to look at the current version of the patch,
it _happens_ to do exactly this.
So this point is moot.
> - but ideally the decoder should output the "native" pixfmt/colorspace
> of the codec, which apparently is YCgCo (which would also require
> libswscale modifications)
What makes it "ideal", by which criteria? Be technical please.
(BTW "which apparently is" is a wrong assumption.
You still did not use the references I offered you for some background
information on the matter. Please learn, before posting next time.)
> - we're not even interested in a faster cinepak decoder, because we see
> no need for it (even you haven't demonstrated any need for it - I'm
> pretty sure everyone would be all over a fast intermediate codec, but
> people don't use cinepak for that)
Are you saying no need for everyone?
Nor have they ever tasted a 3 times faster decoder but you already know
they will not like it?
Sorry, seriously I have no reason to assume that you have prerequisites
to know for everyone and especially in advance.
You are talking about what is inside the horizon of yourself.
> - trying to trick us into applying this patch by playing policy lawyer
> won't work
You make it again sound like you decide for the project.
Frankly, such behaviour makes the project look bad.
Also you are accusing me of "tricking" and "playing".
Please be specific about what I am doing wrong
or apologize otherwise.
While at it, I am still expecting your apology
for the use of abusive language when you were commenting
on my proposal last time.
> - whether or not having these multiple code paths would be so horrible
> is not even the main question - by now we're just annoyed by this
> topic and how much attention it seems to drain, so we'd rather ignore
> this (don't blame us - people tend to ignore unimportant things to
> get important work done, and not applying your patches seems to be
> the safer option)
You did not have to pay attention to the patch, given your limited
understanding of the matter (which _you_ stated repeatedly) and the
limited capacity to participate, which you demonstrated by relying on
wrong assumptions and neglecting to correct your mistakes in this discussion.
> - again, nobody understands your needs, and some we find extremely
You are assuming that everyone has the same level of understanding
as you do. This is not necessarily true.
> absurd and out of place, like using getenv() in a decoder (we'd
> probably suggest a better alternative if we did, maybe)
Regrettably, the proposed alternatives were either to put the
corresponding functionality into every application or to avoid ffmpeg
and start a separate project. Neither of those alternatives would be
practically useful. Never mind, this is not part of the current patch.
Thanks for reading this long!
Regards,
Rune
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
