BD Rebuilder Beta - Bug Reports Only

[gamete]

Originally Posted by jdobbs

Yes. Using 5 is a lower quality setting than 1 (5 uses x264's "ultrafast" preset while 1 uses "faster") -- but, the question is whether you can even tell a difference on a 25GB disc. There's also a setting between the two (0) that will use "superfast".

So the presets are

1 more quality but slower
2
3
0 middle ?
4
5 less quality but faster

Is it correct ?

[jdobbs]

Originally Posted by gamete

So the presets are

1 more quality but slower
2
3
0 middle ?
4
5 less quality but faster

Is it correct ?

No. The 5 was added later after everything else was established, just as a way to use the fastest setting when you are in a hurry -- so it is out of sequence. It also isn't on the menu under "Encoder Settings". The only way you can set it is to manually do so by editing the INI file. Here are the values for each of the "Encoder Settings" selections:

0=Good
1=Very Good
2=Better
3=High Quality (Default)
4=Highest (Very Slow)

5=Fastest, but lowest quality at a given bitrate (not on the menu)

The actual X264/X265 command line option used when you select 4/Highest can can also be adjusted via the QUALITY_ULTRA hidden option. But it's probably best to leave at the default unless you are very familiar with X264/X265. QUALITY_ULTRA has no effect on NVENC encodes.

[AmigaFuture]

Originally Posted by jdobbs

Yeah. That was done purposefully. I can't remember why I did it that way, but I do remember it was a good reason. Blanking should be the last thing you do before encoding.

What!?!?!?! (*LOUD Gurgling sounds from a bong*), Oh, sorry...I was distracted by Lathe in the background somewhere. You're right, a good idea before encoding.

[gamete]

Originally Posted by jdobbs

No. The 5 was added later after everything else was established, just as a way to use the fastest setting when you are in a hurry -- so it is out of sequence. It also isn't on the menu under "Encoder Settings". The only way you can set it is to manually do so by editing the INI file. Here are the values for each of the "Encoder Settings" selections:

0=Good
1=Very Good
2=Better
3=High Quality (Default)
4=Highest (Very Slow)

5=Fastest, but lowest quality at a given bitrate (not on the menu)

The actual X264/X265 command line option used when you select 4/Highest can can also be adjusted via the QUALITY_ULTRA hidden option. But it's probably best to leave at the default unless you are very familiar with X264/X265. QUALITY_ULTRA has no effect on NVENC encodes.

Thanks jdobbs perfect

[gamete]

sometimes the program does not respect the target set as final output .... often the file is larger or smaller, why?

[Ch3vr0n]

Originally Posted by gamete

sometimes the program does not respect the target set as final output .... often the file is larger or smaller, why?

Nobody here has a crystal ball. Post your conversion log and bdrb.ini settings

Sent from my Pixel 3 XL using Tapatalk

[jdobbs]

So... I am pleased to say that the NVIDIA encoder is a lot better than I had originally thought. As I mentioned in another post -- the CRF (x264) and CQM (NVENC) are similar in their methodology -- but the values used with the setting don't align (a CRF of 23 is NOT equal to a CQM of 23). So I decided to do some extensive testing to find out what NVENC CQM values to use to get the equivalent of X264's CRF.

Here's what I did:

1. Selected a series of movies that differed in action content and the type of cinematography.

2. Encoded them all using X264 with CRF values ranging from 16 to 30 in steps of .5 (a reasonable range from near-perfect [16] to not-so-great [30]). I used the same method used in BD-RB's prediction mechanism to gather samples across the entire film.

3. I then used AVISYNTH with the SSIM module to gather the overall SSIM values for each movie at each CRF value (comparing them against the original). SSIM is the best way I've found to measure output quality without introducing subjective methods. I used AVISYNTH rather than the encoders' internal SSIM calcs just to be sure they are 100% equivalent.

4. I then encoded the same movies with NVENC using values ranging from 16 to 40 in steps of .5, since my earlier tests showed that NVENC needs a higher value to be equivalent to x264's.

5. I, again, used AVISYNTH with the SSIM module to gather the overall SSIM values for each movie at each CQM value.

6. I then aligned the CRF/CQM values based upon the SSIM values so I could create a table that shows the equivalent value to use to get the same quality (within a .5 CRF/CQM differential).

7. I also used the output sizes of all the encodes to predict how much larger/smaller an equivalent encode would be (from NVENC) when it is compared to x265 with equal quality.

Below is a table of the equivalent values. I hope you find it useful. The thing I find most exciting is that NVENC (using CQM) is very competitive with x264 -- even though on my system it is in the neighborhood of 10+ times faster. In higher quality (e.g. CRF 16) encodes it meets x264's quality -- and is actually smaller. I never expected that! In mid and lower quality ranges it is still very competitive in terms of sizing at a given quality.

CRF	CQM	SIZE
----	----	-----
16	18.5	0.883
16.5	19.5	0.847
17	20	0.879
17.5	21	0.853
18	21.5	0.890
18.5	22.5	0.857
19	23.5	0.823
19.5	24	0.854
20	24.5	0.819
20.5	25.5	0.853
21	26	0.889
21.5	26.5	0.929
22	27	0.950
22.5	27.5	0.989
23	28	1.007
23.5	28.5	1.038
24	29	1.059
24.5	29.5	1.077
25	30	1.089
25.5	30.5	1.098
26	31	1.095
26.5	31.5	1.097
27	32	1.099
27.5	32.5	1.101
28	33	1.099
28.5	33.5	1.075
29	34	1.064
29.5	34.5	1.042
30	35	1.035

So, for example... if you encode at a CRF value of 23 (x264's default), you could use a CQM value of 28 and get equivalent quality in a file size that is 1.007 times the size of the x264 encode. Not bad -- you'd gain less than 1% in terms of output sizing for an equivalent quality -- while encoding at 10x the speed.

Please note that the NVENC encodes were done on a Turing based GPU (Nvidia GTX 1660) with B-Frames enabled -- GPU encoders that don't have B-Frames may not match the results I've shown here. I suspect they may be close though (except possibly output sizing) since they are using the same CQM algorithms.

The command line options used for encoding were the same ones that would be generated by BD Rebuilder when the "High Quality (Default)" option is selected for NVENCC and for X264 with options asserted for output to a blu-ray. The sources were all 1080p HD as they were encoded on original blu-rays.

Of course these tests are never perfect, so take this for what it is worth. But I think it is pretty close. It took me a whole lot of hours of encoding to come to these conclusions. I think I may do the same testing for a comparison of x265 and NVENC, but I'm first going to take a little break.

Try them out. I'd be interested to see what you find and if your experience matches what I found with this testing.

[spotswood]

Hello everyone... using the current v0.61.18. Not sure if this is by design or a bug but, when importing an MKV/MP4 with an EAC3/DD+ or TrueHD/Atmos track, BDRB reencodes the track to AC3. When importing an MKV/MP4 with a DTS-MA or DTS:X track it is left intact. I have "Keep HD Audio" checked in Settings, but not sure if that has anything to do with it. Any help/ideas/suggestions appreciated. Thanks!

[gamete]

Originally Posted by Ch3vr0n

Nobody here has a crystal ball. Post your conversion log and bdrb.ini settings

Sent from my Pixel 3 XL using Tapatalk

It was happened with severals film
After i post bdrebuilder.ini

[Sharc]

Originally Posted by jdobbs

Try them out. I'd be interested to see what you find and if your experience matches what I found with this testing.

Your exhaustive SSIM-based tests are very interesting.
My past experience in 'blind tests' with family members confirm that similar quality is obtained for CQM > CRF at about same file size. No complaints about quality from uneducated viewers. All subjective of course rather than metric based comparisons.

The difference which I found is with respect to preserving 'details' in the sense of replicating the source as closely as possible. SSIM - as a quality metric adapted to human perception - seems to be pretty forgiving in this respect.
Inspecting individual frames, the NVEnc encodes looked like pre-filtered (de-noised) x264 encodes in my experience. Fine details like textures of clothes are partially smoothed away (mainly in B-frames), and low contrast areas (e.g. dust or gravel in shady areas) look mashed. One will however hardly notice this when watching the movie real-time (what a movie is supposed to be used for), and some viewers may subjectively even prefer the 'denoised' NVEnc version. Hence SSIM seems to not penalize these losses unduly.

Also, when lowering the CQM more and more I found that the details don't get fully recovered as you might expect from x264 experience. Perhaps this explains why you got an even smaller filesize (surprise!) in your tests for low CQM compared to same SSIM quality using x264 with CRF?

I did my basic tests some time ago with my Pascal 1050ti which supports B-frames for h264. The results may be better for Turing though.

Bottom line: For backups and streaming to TV I prefer the speed of NVEnc with little compromise on file size and/or 'technical quality' in the sense of most exact replication, for 'archiving' (e.g. my VHS) I stick to x264. I hardly ever use x265.

Your SSIM-based table is a useful guideline, thanks.

[jdobbs]

Originally Posted by spotswood

Hello everyone... using the current v0.61.18. Not sure if this is by design or a bug but, when importing an MKV/MP4 with an EAC3/DD+ or TrueHD/Atmos track, BDRB reencodes the track to AC3. When importing an MKV/MP4 with a DTS-MA or DTS:X track it is left intact. I have "Keep HD Audio" checked in Settings, but not sure if that has anything to do with it. Any help/ideas/suggestions appreciated. Thanks!

It would violate the BD standard if left intact -- that is why it is reencoded. Do a search of this thread, this subject has been discussed before. DD+ is a part of the standard, but player support for DD+ isn't required. DD, on the other hand, must be supported. That means that a BD compliant DD+ stream has to include both DD and DD+ together.

[spotswood]

Originally Posted by jdobbs

It would violate the BD standard if left intact -- that is why it is reencoded. Do a search of this thread, this subject has been discussed before. DD+ is a part of the standard, but player support for DD+ isn't required. DD, on the other hand, must be supported. That means that a BD compliant DD+ stream has to include both DD and DD+ together.

Thanks for your reply and suggestion. I went back and looked at a few posts regarding my question. But don't TrueHD/Atmos tracks include the AC3 core? Why are they being reencoded if the core is included? Does this not follow the standard? I just created an MKV of my disc ANNA which has a 7.1 TrueHD track and AC3 core (leaving both video and audio intact). Imported MKV back into BDRB and it still wants to reencode the track to AC3. Would this scenario not be compliant? Very confused...

[jdobbs]

Originally Posted by spotswood

Thanks for your reply and suggestion. I went back and looked at a few posts regarding my question. But don't TrueHD/Atmos tracks include the AC3 core? Why are they being reencoded if the core is included? Does this not follow the standard? I just created an MKV of my disc ANNA which has a 7.1 TrueHD track and AC3 core (leaving both video and audio intact). Imported MKV back into BDRB and it still wants to reencode the track to AC3. Would this scenario not be compliant? Very confused...

I don't think you can import into an MKV without the core being removed or at least separated. Even if the AC3 is kept during import (as a second stream), it wouldn't be compliant because the two audios aren't muxed into a single stream for BD. That's if I remember it correctly.

[gonca]

Originally Posted by jdobbs

I don't think you can import into an MKV without the core being removed or at least separated. Even if the AC3 is kept during import (as a second stream), it wouldn't be compliant because the two audios aren't muxed into a single stream for BD. That's if I remember it correctly.

You remember correctly.
MKV cannot hold an "interleaved" track (if the term is correct)
Mux a thd+ac3 track into a MKV container and the result is two distinct tracks thd and ac3

[jdobbs]

Originally Posted by gonca

You remember correctly.
MKV cannot hold an "interleaved" track (if the term is correct)
Mux a thd+ac3 track into a MKV container and the result is two distinct tracks thd and ac3

Thanks.

[Emulgator]

The difference which I found is with respect to preserving 'details' in the sense of replicating the source as closely as possible.
SSIM - as a quality metric adapted to human perception - seems to be pretty forgiving in this respect.
Inspecting individual frames, the NVEnc encodes looked like pre-filtered (de-noised) x264 encodes in my experience.
Fine details like textures of clothes are partially smoothed away (mainly in B-frames), and low contrast areas (e.g. dust or gravel in shady areas) look mashed.
One will however hardly notice this when watching the movie real-time (what a movie is supposed to be used for), and some viewers may subjectively even prefer the 'denoised' NVEnc version.
Hence SSIM seems to not penalize these losses unduly.

See the same, Sharc. I am still asking PSNR for that reason, SSIM being called in by codec makers to soothe away codec's imperfections.
Many thanks for the continued development, jdobbs !

[jdobbs]

Originally Posted by Emulgator

See the same, Sharc. I am still asking PSNR for that reason, SSIM being called in by codec makers to soothe away codec's imperfections.[/SIZE]
Many thanks for the continued development, jdobbs !

I don't really trust PSNR, because it only records differences without any consideration for the actual viewing experience (human perception).

But, just out of curiosity, I may run tests to see what the equivalent CRF/CQM values would be for a matching PSNR value. It would be interesting to see if there is a significant difference when compared against SSIM.

I'm pretty sure I still have the output from the original encodes, so all I should have to do is do the AVISYNTH portion, but using a PSNR module rather than SSIM.

[Sharc]

If this should be of interest: VMAF v2.0 is out
https://github.com/Netflix/vmaf/releases/tag/v2.0.0

[jdobbs]

Originally Posted by Emulgator

See the same, Sharc. I am still asking PSNR for that reason, SSIM being called in by codec makers to soothe away codec's imperfections.[/SIZE]
Many thanks for the continued development, jdobbs !

Originally Posted by jdobbs

I don't really trust PSNR, because it only records differences without any consideration for the actual viewing experience (human perception).

But, just out of curiosity, I may run tests to see what the equivalent CRF/CQM values would be for a matching PSNR value. It would be interesting to see if there is a significant difference when compared against SSIM.

I'm pretty sure I still have the output from the original encodes, so all I should have to do is do the AVISYNTH portion, but using a PSNR module rather than SSIM.

So I ran another set of tests against the files created in this post -- but this time the I used PSNR as the metric. Interestingly, it didn't change a whole lot. In fact, the PSNR numbers leaned even (a little) more toward NVIDIA/CQM. Below is the table of results showing equivalent CRF/CQM numbers based upon PSNR values. In order to make a point, I chose only NVENC CQM values that resulted in a higher PSNR value (rather than the closest)

							NV FILE SIZE
X264_CRF	X264_PSNR	NV_CQM	NV_PSNR		RATIO
16		48.309		18.5	48.480		0.883
16.5		48.009		19.5	48.102		0.847
17		47.719		20.5	47.754		0.816
17.5		47.448		21	47.601		0.853
18		47.188		22	47.265		0.820
18.5		46.941		23	46.946		0.785
19		46.708		23.5	46.796		0.823
19.5		46.495		24	46.632		0.854
20		46.295		25	46.333		0.819
20.5		46.108		25.5	46.185		0.853
21		45.928		26	46.040		0.889
21.5		45.754		26.5	45.893		0.929
22		45.584		27	45.715		0.950
22.5		45.419		27.5	45.574		0.989
23		45.256		28.5	45.264		0.936
23.5		45.094		29	45.106		0.960
24		44.928		29.5	44.950		0.983
24.5		44.757		30	44.784		1.000
25		44.583		30.5	44.628		1.014
25.5		44.401		31	44.427		1.015
26		44.218		31.5	44.258		1.022
26.5		44.032		32	44.057		1.027
27		43.840		32.5	43.881		1.031
27.5		43.643		33	43.676		1.032
28		43.445		33.5	43.468		1.010
28.5		43.243		34	43.258		1.001
29		43.038		34.5	43.040		0.982
29.5		42.829		35	42.824		0.977
30		42.620		35.5	42.629		0.976

Once again, I was impressed with the performance of NVENCC on the NVIDIA GTX-1660. The PSNR numbers were created by the AVISYNTH "COMPARE" output and represent the "Overall PSNR" value in the statistics file.

[Emulgator]

Now thats remarkably well for that speed of NVEnc.
-48dB (~1/250) deviation from source is all I could ask for if giving good bitrates and targetting 8bit.
Many thanks, jdobbs !