[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 22:19:13 EET 2017

Hello Karl,

I appreciate your interest and comments.

Keeping on topic, to the patch decision makers:

 I actually complied with all real suggestions heard during
 the discussion, even with those I find being misdirected,
 i.e. virtually everything except dropping the patch as a whole.

 Now I am unsure, will anybody look at the patch
 or is it so that some policy (which everyone here but me knows)
 does clearly specify that such a patch shall be rejected no matter what?

Possibly the dialogue below will be ok ontopic, as a background.

On Mon, Mar 06, 2017 at 05:42:31PM +0100, Karl Blomster wrote:
> >Nor is there any apparent reasonable way to "get rid" of those getenv()s.
> I would say that as usual when determining what is "right" in software
> architecture, the answer is "it depends". As far as I am aware, most of the

Thank you. I fully agree.

> things libav* touches environment variables for is related to interactions
> with things external to ffmpeg, such as the network (HTTP_PROXY), the
> terminal, the locations of certain types of plugins, etc. Modifying internal
> behavior based on environment variables is ugly in my opinion, and I can't
> think of any other case in ffmpeg where this is done. In general, if you
> want to interact with library functionality, do it through the API. In this
> case there's even a mechanism in place explicitly for this purpose
> (negotiating output pixelformat via the get_format callback), although I'll
> note that the ordinary use case for that is quite different from what you
> want to do here.

Exactly, the possibility to choose the pixel format is present but it
is not meant to be controlled otherwise than via a competent application.

I agree that an added envvar is by nature an intrusive change,
that's why I try to reduce the tention by omitting this
(I have to patch my own ffmpeg builds in any case).

> As far as SDL goes, I'll just note that the documentation states that
> "[u]sing these variables isn't recommended and the names and presence of
> these variables aren't guaranteed from one release to the next." They seem
> intended for debugging only.

I guess they _were_ thought for debugging while one did not realize
that some things are impossible or hard to put under the applications'
responsibility. They have since then in practice become an integral part
of the product. My opinion corresponds to the fact that the variables
always are present in the usual non-debug SDL builds, do you have a
different experience? Of course I can not talk for the usage od SDL
everywhere, my use of the SDL-bound applications would be hardly
meaningful without the variables.

> >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.
> And here's one of the biggest issues in this debate and where I think you
> and wm4 et al keep talking past each other. The cost in lines of code is
> relatively unimportant. The cost in "number of different behaviors" is
> different.

Ah. I see your point. Each extra degree of freedom makes it harder
to support all the possible cases and combinations.

> In practice this isn't a huge deal for cinepak in particular
> since it already does this bit of ugliness, but surely you can see why there
> is a reluctance to add more of it?

Thanks. Pity no one else did say this. Fortunately the last version
of the patch definitely does not make the situation worse, rather
quite more regular - pal8 was handled as a special case (a very rare one,
which makes maintenance even harder, also one which made the output depend
on the format of input), rgb565 is fast, fully regular and always available
(and also well defined what it shall look like, no uncertainty like yuv).

0rgb or argb are full quality and faster than rgb24 on usual hardware
but replacing the default rgb24 format would introduce a surprise.

> Then there's also the fact that, to be blunt to the point of rudeness,
> nobody *cares* about cinepak. I'm sure that *you* do, and as you've
> repeatedly pointed out we do not have your point of view, but from the
> "mainstream" perspective or whatever you want to call it this is definitely
> a fringe codec that has very few users today. Hence the reluctance to accept

I agree, it is not so well visible as the newest heavy codecs. It is not
profitable to the CPU/GPU manufacturers nor suits the contents providers,
they _choose_ to copy every byte again and again as many times as it is
being played. That's why the compression ratio becomes so important,
because the user not the provider pays for the heavy decoding while the
provider can not avoid paying for the (accumulated) traffic, nor accepts
to optimize the transmission by decoupling the user from the service
(say, like bittorrent).

The applications using cinepak do still exist but it is seldom advertised.

OTOH mainstream is not the whole world.
It is possible to even make one's living by doing unusual things,
even though it is hard to every time have to explain the sense present
in your choices.

I appreciated ffmpeg since long ago because it was created to be efficient
(with Fast as the first word). Now it is the hardware which takes over
instead, for the good and for the bad.

> an "ugly" patch, I believe. A cursory search of the mailing list archives
> makes it seem like nobody's really contributed meaningful functionality to
> the decoder other than you yourself (although your tendency to change email

This is not entirely true, other people were involved, but thank you!

> addresses makes it a bit hard to tell for certain) and almost no users have
> ever asked about it.

I was not good at looking at the Cinepak-related issues, my fault. Found
out recently some unattended ones like the closed as WONTFIX
"make the encoder faster". (Now it would be uncontroversial to implement the
formerly patented Cinepak encoder algo. It is not as good as our elbg but an
order of magnitude faster at encoding.)

Also Cinepak is not marketed at all. There are certainly people and
situations which would benefit from it but they do not know this.
Thus, hardly anybody asks.

> One also has to wonder *how* slow a system needs to be, exactly, to require
> this kind of change. Again, I don't have all the details on your use case,
> but just out of curiosity, how many systems were you intending to deploy
> this to, correct to an order of magnitude? Forgive me for presuming things,

Feel free to assume anything from 1 to the whole IoT.
It is neither of those of course. The main point is to make video
playback extremely lightweight so that you can use hardware one or two
classes lower than whoever takes a "modern" codec for the same purpose.
This is about not needing a GPU and using the memory bandwidth in the
best way. If you have got an energy-efficient display technology,
you spare quite a lot in the needed power (a slow low-gate-count CPU,
no GPU), this is a nice thing too.

This is no magic bullet, you pay quite a lot when you are
compressing, but every time you play back you offset the cost.

> but users who have not until now had video playback on their early 1990's
> vintage systems (dumb terminals?) for performance reasons must surely have
> gotten used to the situation by now. Or implemented their own decoder.
> Or...?

Do you mean possibly the "8088 corruption"? :) It is a very impressive
and nice illustration of what is possible when you have got suitable
algorithms and are ready to take unusual steps.


More information about the ffmpeg-devel mailing list