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

u-9iep at aetey.se u-9iep at aetey.se
Mon Mar 6 16:12:23 EET 2017


I wish to thank you for the effort to make the "opposite" parties
to better understand each other.

As you say, indeed the patch makes a move which looks in line with
ffmpeg's former traditions but which at least formally collides with
the currently percepted "best practices".

On Mon, Mar 06, 2017 at 12:47:26PM +0100, Karl Blomster wrote:
> 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

I am pretty sure the definition of yuv420p in ffmpeg and the constants
agree to each other. Yes I am aware of the mess around the variety of
YUVs, that's why I referred to the source of the numbers. (IIRC they
come actually from Microsoft but I felt Wikipedia looked more neutral)

> I really don't think that link was appreciated at all.

Interesting that nobody but you could articulate what was wrong with
it. Anyway, this detail is now a matter of the past. I never needed
it in practice myself (hardware scalers via yuv420p were slower than
Cinepak-on-the-CPU), implemented it just for generality.

Undesired - removed.

> 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

My problem with the commenters is that they take their percepted best
practice rules as something which is not to be exposed to scrutiny.

An attempt to say that the rules are not necessary applicable or useful
is not heard at all or otherwise amounts to heresy.

> 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

Correct, no GPU. (GPU costs among others a lot more lines of code to
take care of than Cinepak patches :)

> cannot modify the playback software, necessitating the rather remarkable
> hack where a ubiquitous system library modifies its behavior based on an

Do you believe that libraries are not supposed to react on environment
variables? The most ubiquitous system one (libc) does by design.

Ffmpeg itself contains over twenty getenv() in the libav* libraries and
also via ffplay depends on SDL which for very natural reasons (similar
to my motivation with Cinepak) relies on environment variables.
Nor is there any apparent reasonable way to "get rid" of those getenv()s.

> 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.

The cost in the code is in fact not that "big", about 68 LOC per output
pixel format, in the latest revision. Compared to the several times (!)
speed loss when going through swscale it looks to me like an
exceptionally low hanging fruit.

> 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.

Nobody cared to define their view on what maintainability means
even when I explicitly asked how to measure it.

> 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.

That's what I was doing and apparently will have to, given that the
vitally useful things like out-of-band control are percepted as "evil" here.

It still feels inadequate to keep this functionality for myself, or
otherwise to maintain the patches so that they would suit someone else
(I made this now for the submission but would not do continuously).

> 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.

Indeed it is not the speed of Cinepak, nor the speed of any module
which is a problem, but I would say the atmosphere in the project.

> Best regards
> Karl Blomster

Thanks again.


More information about the ffmpeg-devel mailing list