[FFmpeg-devel] [PATCH] Support > 8 bit input in yuv2rgb.

[Reimar Döffinger]

Hello Ronald,

Sorry if I bore everyone, but it's kind of an interesting subject to
me..

On Thu, Nov 07, 2013 at 10:54:37AM -0500, Ronald S. Bultje wrote:
> Well (3) is the most important one. Typically when people use ffmpeg on a
> cellphone, it's for a custom application that has a custom video input that
> the application maker has full end-to-end control over. As such, they can
> (2).

For a cellphone I'd kind of hope that you are not using FFmpeg but the
decode hardware! Or at the very least not convert it manually to RGB
but use the support for yuv surfaces.
But wrong assumption here is that I am talking about mobile usage.
However for me this is about ARM desktop running Linux, something
I can give to people like my parents who always complain that their
computer is too large, too expensive, and are afraid of getting viruses.
Or for myself a "desktop" I can carry around just as easily as my phone,
but I can actually plug in a proper keyboard, screen, harddisk and run
a full OS with proper development tools on.
Not to mention something to run demos on at events like LinuxTag (and
carrying the monitors around is bad enough, no way I'd take a desktop,
and laptops are still too expensive for my taste).

> So that leaves (1). Quality loss b/c of intermediate rounding is indeed
> lower, so overall quality is higher. The question is whether you can see
> this on a crappy cell phone screen,

My (possibly wrong) understanding is that this quality advantage exists
across almost the whole range of the bandwidth/PSNR graph.
So the question is not about "higher quality" but "lower
bandwidth/smaller file size". Which counts on a cellphone as much if
not more than on a desktop.

> and whether that improvement in quality
> is worth it re: the higher CPU use that you will have

I have never measured it, but I don't think the CPU usage is a lot
higher for decoding 10 bit (unless you talk about hardware vs. software
decode) - and lower bitrate will reduce CPU usage in e.g. the CABAC part.
I'd expect it is mostly memory bandwidth that about doubles, which of
course can still make all the difference.

> regardless of whether
> you use these slightly more optimal C functions in colorspace conversion or
> not.

Note that the fallback libswscale code is to use the scaling (bicubic by
default!) conversion function.
This is not "slightly more optimal", the non-optimized code
needs more CPU power than the (non-optimized, pure C) 10-bit IDCT of the
decoder!
None of this changes that the number of affected users is probably fairly
minimal, no argument there from my side.

Regards,
Reimar