[FFmpeg-user] Reencoding from H.264 to H.265

[Peter White]

Hi,

04.09.2016 20:40, Sven C. Dack:
 > On 02/09/16 17:28, Sven C. Dack wrote:
 >
 > There are a few things I need to note first... The Nvidia hardware
 > encoder NVENC doesn't accept a "-crf" value

Why do you have to use it then for this? I get that you use it in your
day to day encoding but since this is not related to a specific
implementation, why bother?

 > which is why I had to use "-qmax" for a quality setting.

Well, I have a hard time calling it a "quality" setting. The only
thing it does is restrain the codec in its quality related decisions,
so "anti-quality" setting is more like it. ;)

 > But as per your suggestion did I now include the software encoders
 > x264 and x265. The "-crf" values have been chosen so all three
 > encoders (x264, x265 & nvenc) produce about the same file size when
 > using the simplest of algorithm, nearest neighbor.

It is not as easy as that, I am afraid. Having looked at your images
below, they differ quite significantly in bitrate between the scaling
algorithms. If one wants to compare quality, all files must have the
same bitrate, at least approximately. Otherwise, how are you going to
be able to tell if the quality difference is due to a higher/lower
bitrate or because of a better/worse scaler?
The only thing your comarison shows is that there are differences in
bitrate. The cause of those could be any of the above factors.

 > *** Please note that this is _NOT_ a comparison of encoders, but it is
 > meant to show the effect of the (down-)scaling filters on reencoding.
 > ***

But what effects? That is the question that cannot be answered with
your method. Again, there is a size/bitrate difference, yes. Your
original conclusion seemed to be that the higher the bitrate the less
the scaler used is suited for transcoding. That assumption is not
correct.
A higher bitrate may or may not be due to details preserved. It may
also be due to scaling artefacts which the codec mistakes for details.
See, how nearest neighbor, arguably one of the worst scalers, produces
the highest bitrate, presumably because of all the nice sharp edges of
the staircases I am seeing there.
Also see gauss producing the lowest bitrate due to it washing out
details by blurring the image. I maintain that those suggestions for
scalers, you waved away as not suited for transcoding, remain the
scalers of choice. Mine being natural bicubic spline, or spline for
short in ffmpeg's own S/W scaling filter.

Also, I cannot help but notice how bad the quality of the Nvidia H/W
scaler is compared to S/W ffmpeg scalers. I see aliasing (staircasing)
all over the place in your samples, except for supersampling. That
looks rather broken to me. Even supersampling shows some aliasing.

 > https://i.imgur.com/SNuHzma.png

Just compare lanczos done in H/W and in S/W. S/W wins hands not only
down but in the pockets. And that at only 75% the bitrate, but that
might be due to codec. Or there really is something broken in the
chain.

 > Suggestions are welcome!

One more thing sprung to mind. Are you certain you used a keyframe?
For such comparisons the frame should be of that type and of course
the exact same frame from all the samples must satisfy that condition
otherwise you are comparing apples to oranges.

 > To the bug... When the CUDA H/W scaler is run as follows:
 >
 > ... -pix_fmt:v +nv12 -filter:v 
"hwupload_cuda,scale_npp=w=1024:h=720:format=nv12:interp_algo=cubic,hwdownload" 
...
 >
 > then it will apply the cubic filter correctly. If however 1280 is
 > given as width and so the aspect ratio stays the same will it fail
 > to select the cubic filter.

Fail how? Is there a message, a crash or is it just plain obvious by
the image that it cannot be the selected filter?
I am not a developer, so do note that I cannot fix this, but some more
information will be needed, I reckon. Full uncut command and console
output is a good start. I also would recommend to open a new thread
for that, since it is, first, not really related to this topic,
second, it might not get the attention it needs in this one.


Peter