[FFmpeg-devel] [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.
u-9iep at aetey.se
u-9iep at aetey.se
Wed Feb 8 10:30:19 EET 2017
Dear Henrik,
On Tue, Feb 07, 2017 at 07:21:39PM +0100, Hendrik Leppkes wrote:
> > Why not, if there will be a data consumer with this hypothetical format
> > and we will need speed? Why not? This _is_ efficient at the decoder,
> > it is just many of the developers ignored this fact until now.
>
> If you don't understand why this is bad, then trying to explain it
> again is just wasted time.
Unfortunately this is my very impression, hard to explain "evident"
things because the other party is blinded by his/her own perspective.
> I'll give you a hint: What if every codec would do this? Surely that
> would be faster, but noone in their right mind would ever want to work
> on such an abonimation.
Let me return another hint :)
not every codec (but a small minority) is actually suited for such
optimizations, so your imagined hellish world would not be much faster.
Abomination or not is also a matter of personal taste. I do not feel that
Cinepak code (current one, which since long ago does format conversions :)
is more repulsive than the code of *264 :) but this is irrelevant!
What is relevant is how well they work in the long run.
> >> not a decoders job to convert from RGB to YUV.
> >
> > What is the criteria to choose where the job is to be done?
> > My point is efficiency. What is yours?
>
> If you want effieciency above everything else, maybe you should write
> a very specific application tailored for your one specific use-case,
This is an example of being "blinded" by one's perspective.
You are positively/constructively trying to put yourself in my situation
and suggest a good solution, but this is highly unreliable. In this
particular case: I do not generally have the power over the applications.
Ther is also the plural "s" in applications.
> and not use a generic multimedia frame work like ffmpeg.
This would not help me a tiny bit. Ffmpeg is a very useful tool,
not being able to use it would be devastating! :) You should be proud.
> Anyway, you don't seem to be understanding our points at all, so the
> chances of this ever being commited are reaching zero.
Doing my best. :)
Unfortunately your position looks like "I know what is a right
solution. If somebody does not agree, s/he is not understanding".
This is because people (you and me included) tend to underestimate:
the invisible but huge limitations which our environment and perspective
put on our capacity to see each other's situation, needs, constraints
and criteria.
You assume a lot about why I am doing thing a certain way.
Many of your assumptions are unfounded.
I assume a lot about what are the developer's motivations and priorities.
Certainly many of these guesses are wrong.
Let's calm down and stop assuming at least one thing,
that the other party is stupid.
Regards,
Rune
More information about the ffmpeg-devel
mailing list