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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
