[FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

[Karl Blomster]

Hi,
It is regrettable that the positions are so entrenched here, but I agree with 
the majority opinion that pushing this really isn't a good idea, nor do I 
understand the reasons it's even desirable in the first place. The core issue 
here, I think, is fundamentally different views of software architectural issues 
as well as an almost as fundamentally different understanding of what 
"maintainability" means. I will make an honest attempt at laying out the 
situation _as I see it_ and while I don't think it will actually convince 
anyone, perhaps it will clarify a few points, make the situation slightly 
clearer and/or prevent further misunderstandings. I am not a ffmpeg developer 
and do not speak for anyone else and definitely not for the project, but I've 
been following the project for a long time and I believe I have come to at least 
some understanding of its principles.
To start off with an obvious fact, ffmpeg is a huge project, and a relatively 
old one. It has quite a bit of legacy code that, while it works, does things in 
ways that are not viewed with favor today, nor fit in with the way the current 
developers think. My general impression of the project in the last few years is 
that the consensus has been to attempt to steer the project to align with the 
principle of least astonishment: less "clever" solutions, more separation of 
concerns, more consistency in code and in behavior. This patch is almost 
directly contrary to that principle, and I think that's where one of the major 
rubs are. That's not to say solutions that are seen as "ugly" cannot be 
accepted, but it has to be weighed carefully against the estimated usefulness of 
the change.
In this particular case, the cinepak decoder is already "doing it wrong", so to 
speak (of course it's not actually bugged, but hopefully you see what I mean) - 
it's outputting a colorspace that isn't its "natural" output colorspace. Adding 
more options may seem reasonable since it's already doing it, but it's in the 
opposite direction of where the project is heading. I think the original patch 
made this seem particularly unpalatable since it added a whole new "quick and 
dirty" colorspace conversion to YUV with hardcoded constants (there are several 
different YUV variants with slightly different constants), with a 
intended-as-helpful link to the Wikipedia page on YUV in an explanatory comment. 
Considering what project the patch was contributed to, I really don't think that 
link was appreciated at all.
With all of this in mind, there would need to be an extraordinarily big 
practical benefit for a large number of users for this patch to be percieved as 
a "necessary evil" (and just to be perfectly clear here, I'm not trying to say 
that there is any evil intent anywhere - it's a figure of speech). I'm sure that 
for _you_ there is such a benefit, but I don't think anyone else has even fully 
understood your use case. From your earlier correspondence, my impression 
gathered from several different hints in different emails is that you're trying 
to play back video on some extraordinarily slow system with no GPU, where the 
only decoder you could find that was fast enough (not just in terms of CPU 
cycles but also in terms of memory bandwidth) was cinepak with 16-bit RGB 
output. Furthermore, you cannot modify the playback software, necessitating the 
rather remarkable hack where a ubiquitous system library modifies its behavior 
based on an environment variable. You've done away with this modification now, 
but I think having that in there at the start kinda poisoned the well from the 
beginning. Regardless, while I don't doubt that you have a legitimate use case 
that is important to you, I really cannot see the scenario you seem to be 
painting as anything other than an extremely specific edge case. ffmpeg is a 
generalist library that tries to support a broad range of use cases on a wide 
range of platforms, but that also by necessity means it lends itself less well 
to extremely specific use cases like this one, where you're prepared to buy 
decoding performance at any cost.

In an earlier email you pointed out that historically, very few code changes 
have been needed to keep the cinepak decoder up to date with the rest of ffmpeg, 
highlighting a view of what maintainability is that I believe is substantially 
different from that of other participants in this debate. However, what it does 
imply is that the maintenance burden of having your own branch that suits your 
use case, with all the oddball solutions you could imagine, would not seem to be 
overly heavy.
Also, in another of your earlier emails you also rather passive-aggressively 
mentioned that not accepting the patch might be a "problem for the project". I 
really don't think anyone around here sees it that way, precisely because 
interest in cinepak in 2017 is not, shall we say, at an all time high.

Best regards
Karl Blomster