BD Rebuilder Beta - Bug Reports Only

[CraigWally]

Game driver Version 457.30 dated 11/09/2020

I also noted that one could switch to a "studio" driver from within the Geforce experience.. anyone have tried that driver?

//LD

Just tried it, no difference :(

[jdobbs]

@jdobbs

thank you very much for your software, it´s amazing, but I have a question...
is it possible to disable the --uhd-bd option in 4k encoding to gain a bit more speed?I assume you mean when you are outputting to ALTERNATE format? It has to be on for a 4k disc.

I'll take a look at it.

It's actually measurably faster? That surprises me.

[Sharc]

Just tried it, no difference :(
A new NVEncC version 5.20 is out - if this should matter.

[Eriz0]

I assume you mean when you are outputting to ALTERNATE format? It has to be on for a 4k disc.

I'll take a look at it.

It's actually measurably faster? That surprises me.

NO, movie-only backup. Yes, add --uhd-bd slow down the encode a bit. I have externally encoded movies with x265 and I don't add --uhd-bd to command.
I create the structure with tsmuxer and record to disk. I reproduce them perfectly on xbox series x.
if you could add the option to disable it in hidden options it would be perfect.


thanks for answering

[gonca]

You can always try DGTonemap, DGHDRtoSDR and DGPQtoHLG
http://rationalqm.us/mine.html
I believe they can run in software mode

AVS 2.6 can't handle the higher bit depth, and it has no internal filters equivalent to ConvertBits()

Quick test, but it seems that BD_RB can work with avs+ 32 bit
At least the encode started.

[jdobbs]

NO, movie-only backup. Yes, add --uhd-bd slow down the encode a bit. I have externally encoded movies with x265 and I don't add --uhd-bd to command.
I create the structure with tsmuxer and record to disk. I reproduce them perfectly on xbox series x.
if you could add the option to disable it in hidden options it would be perfect.


thanks for answeringSorry. But just because it happens to work on your system doesn't mean it is ok. That setting needs to be there or you are creating a non-compliant disc. I'd rather not make a change that could create bad discs.

[jdobbs]

Quick test, but it seems that BD_RB can work with avs+ 32 bit
At least the encode started.I tested it before. If I remember correctly, the issue wasn't that it wouldn't work -- it was that some of the filters that BD-RB uses wouldn't work in AVISYNTH+. It's been a long time since I tried it, though.

[CraigWally]

So... if that could be the issue:
Is 'field encoding' support set in hardware or software? Meaning my 'old' driver might still support that feature?

@LowDead: What's your graphics driver version?

I've just downgraded to driver 451
no change with regards to pixelation

[cartman0208]

I've just downgraded to driver 451
no change with regards to pixelation

I did the other way around and updated the driver to 457.30 and still got no issues ...

[LowDead]

Have someone else tried North American UHD release of Midway (2019) with 0.61.18? It´s having DV and I´m getting the tsmuxer error - Reading buffer overflow. Possible container streams are not syncronized...

//LD

[AmigaFuture]

@ JD

Since 0.61.18 doesn't support MULTIPROCESS still... I noticed something very interesting.. I imported an MKV (1080p) that BD-RB (0.61.13) made for me a bit ago. I wanted to rerender it from 23GB to 10GB or so..check some Screen Sharing with my Android and my HDTV.

Using 0.61.13 because MULTIPROCESS functions with it, I had BD-RB import the MKV..went well.. It created:

Movie name (Root)
BDMV
CERTIFICATE
PSEUDO

If I leave PSEUDO there, the split won't happen for the rerendering process. It just goes into single rerendering process. If I delete it or rename it it will MP. I don't have to reload anything, just rename in some way then click Backup and click No on resume, Delete All Old Files.

Heh, I tried this with latest version and this doesn't work. Figured I'd give it a try.

[jdobbs]

According to Table 1 NVIDIA dropped 'H.264 field encoding' for Turing and Ampere GPUs.
https://docs.nvidia.com/video-technologies/video-codec-sdk/nvenc-application-note/index.html#nvenc-performance

Blu-ray compliance requests 'interlaced' for 25 and 29.97 fps for any resolution. Fake-interlaced is not always possible.
Confused ........ :confused:I ran some tests on field based content on my Turing GPU. If you identify the source as interlaced (e.g. --interlace tff) the encoder will fail. If you add "--vpp-deinterlace" to or leave off the "--interlace" from the command line it reencodes it ok. The same holds true for H.264 and H.265. By default BD-RB deinterlaces field-based sources when using NVENCC.

[Sharc]

I ran some tests on field based content on my Turing GPU. If you identify the source as interlaced (e.g. --interlace tff) the encoder will fail. If you add "--vpp-deinterlace" to or leave off the "--interlace" from the command line it reencodes it ok. The same holds true for H.264 and H.265. By default BD-RB deinterlaces field-based sources when using NVENCC.
It seems to be much the same with my Pascal GPU. I can't encode as interlaced, but deinterlacing of interlaced sources works.
It is possibly an NVEncC limitation or a bug, because I can produce interlaced encodes (TFF, BFF) with ffmpeg using NVEnc (h264_nvenc).

Edit:
Now it seems to work with NVEncC for my 'ancient' Pascal 1050ti GPU, after removing the '--multipass 2pass-full' and '--bref-mode middle' from my commandline.
Current commandline for interlaced encoding (probably still much overkill for the new presets):
NVEncC64.exe --avsw -i "%~1" --codec h264 --profile high --level 4.1 --lookahead 32 --vbr 0 --vbr-quality 22 --aq --aq-temporal --aq-strength 4 --gop-len 24 --ref 4 --nonrefp --bframes 3 --mv-precision Q-pel --preset quality --bluray --interlace tff --max-bitrate 40000 --vbv-bufsize 30000 --output "%~1_NVEncC.m2ts"

[gamete]

By default it will do two pass at high quality. You may be waiting a while.

If you want to do it faster, change the settings to "One Pass (ABR)" and "Good (Fast)". If you that isn't fast enough, you can edit the INI and set ENCODE_QUALITY=5. That will run X265 at it's highest speed. No UHD encode is going to go very fast compared to HD -- but it will be faster that HQ mode. Honestly, if you are outputting to BD-25 or BD-50, you are unlikely see a noticeable quality difference when compared to HQ.

Sorry about the version thing, I forgot to update the internal version number to v0.61.01... it won't hurt anything.

if i set 5 and not 1 ,i lost video picture quality ?

[jdobbs]

Here's an interesting aside that I found while doing a little testing.

As you might expect, CQM (NVENCC) and CRF (X264) are not exactly the same -- but they use similar concepts. What I've found, by performing SSIM tests, is that a CRF of 23 is not equivalent in quality to a CQM of 23. In fact, in order to get approximately the same SSIM (perceived quality) output of a CRF=23 encode you would use a CQM value of 25.5.

By adjusting this it also brings the sizing a little closer. So to get a similar quality output an NVENCC encode (CQM=25.5) the size of the output is only 1.338 times larger than that of X264 with CRF=23. That's really not bad considering the enormous speed advantage.

This testing was done on a Turing based NVIDIA card (GTX1660). Cards that don't support B frames would probably see different results.

Tomorrow I may set up some tests to find the equivalent CQM quality values for each of the whole number CRFs.

[Weirdo]

Blank one or more items, enter Setup and change one or more settings (a resizing one, for example). Blanked items are reset back to non-blanked.

Also, blanked items are not remembered when closing/opening BD-RB. It'd be nice to have this remembered even without saving the project.

[jdobbs]

Blank one or more items, enter Setup and change one or more settings (a resizing one, for example). Blanked items are reset back to non-blanked.

Also, blanked items are not remembered when closing/opening BD-RB. It'd be nice to have this remembered even without saving the project.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.

[gamete]

if i set 5 and not 1 ,i lost video quality ?

Sorry jdobbs can you help me ?
Thanks

[jdobbs]

Sorry jdobbs can you help me ?
ThanksYes. 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".

[FilipeAmadeuO]

@jdobbs
Is there any hidden option to demux all files then stop ?
(Instead of demux file 1 -> rebuild file 1 -> demux file 2 -> rebuild file 2->...)
I would like to have this option in order to replace some subtitles.

[gamete]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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 ac3Thanks.

[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]

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]

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.So I ran another set of tests against the files created in this post (https://forum.doom9.org/showthread.php?p=1929974#post1929974) -- 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.976Once 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 !

[Sharc]

Once again, I was impressed with the performance of NVENCC on the NVIDIA GTX-1660.
Interesting and surprising findings, indeed.
So for blu-ray compliant encoder settings and GTX-1660 there seems to be no reason any more to fall back to x264 for quality vs file size reasons, based on PSNR and SSIM tests. That's something.
I assume your reference sources were AVC 1080p YV12 8bit, right?

[jdobbs]

Interesting and surprising findings, indeed.
So for blu-ray compliant encoder settings and GTX-1660 there seems to be no reason any more to fall back to x264 for quality vs file size reasons, based on PSNR and SSIM tests. That's something.
I assume your reference sources were AVC 1080p YV12 8bit, right?Yes. The originals were directly from ripped BDs. The comparison was done within AVISYNTH, they were AVC, 1080p, YV12, 8 bit. The encode settings were the command lines generated by BD-RB for output to BD (which puts compliance requirements on GOP size, maximum bitrate, etc).

Now I wonder how NVENC's standard bitrate encoding compares to X264. I suspect it will fall behind since it doesn't have a true two-pass option. But that will have to be something for a different day.

[jdobbs]

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 !48dB... that's pretty near perfect. Most of my encoding these days (other than disc backups) is for my SERVIIO media server -- so I'm a little less picky.

[Mike-uk]

do we have a setting in bdrebuilder for nvidia that produces the absolute best quality thats physically possible with nvencc ??

[jdobbs]

do we have a setting in bdrebuilder for nvidia that produces the absolute best quality thats physically possible with nvencc ??It's hard to answer. That's a relative term. Highest quality for output that will fit on a BD-25? BD-50? Highest quality output to an ALTERNATE format (with no regard for size)? Highest quality at a given bitrate?

[Mike-uk]

It's hard to answer. That's a relative term. Highest quality for output that will fit on a BD-25? BD-50? Highest quality output to an ALTERNATE format (with no regard for size)? Highest quality at a given bitrate?

ah ok yeh bd-25

[mikeq]

Not sure what the ramification of this are:
I'm using the latest makemkv to create the new Dolby Video mkv file that nvidia shield will play. When doing this on a BD_Rebuilder bluray
I get these issues. They don't happen on the original bluray (This is obviously a 4K UHD Dolby Vision Bluray - I used Rampage as my test).
I've spent a day now trying to figure out how to "fix" it. Seems kind of wierd because if the I-frames are fixed and it's a constant frame rate, how do the 2 streams get out of sync, and why do the timecode differences change. Anyway, if you have thoughts, I'd love to hear them - otherwise, just info for you.... (happens with both x265 and nvenc, btw)

AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -208.544ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -291.966ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -333.666ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -250.255ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -125.133ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -166.833ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by -83.422ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by +250.244ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by +125.122ms
AV sync issue in stream 0 at 0:00:02.711 : secondary stream video frame timecode differs by +41.7ms
AV sync issue in stream 0 at 0:00:02.794 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:02.836 : secondary stream video frame timecode differs by +83.408ms
AV sync issue in stream 0 at 0:00:02.961 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:02.961 : secondary stream video frame timecode differs by +41.705ms
AV sync issue in stream 0 at 0:00:03.044 : secondary stream video frame timecode differs by +291.955ms
AV sync issue in stream 0 at 0:00:03.044 : secondary stream video frame timecode differs by +125.122ms
AV sync issue in stream 0 at 0:00:03.044 : secondary stream video frame timecode differs by +41.7ms
AV sync issue in stream 0 at 0:00:03.128 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:03.169 : secondary stream video frame timecode differs by +83.408ms
AV sync issue in stream 0 at 0:00:03.294 : secondary stream video frame timecode differs by -83.416ms
AV sync issue in stream 0 at 0:00:03.336 : secondary stream video frame timecode differs by +333.663ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -208.544ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -291.966ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -333.666ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -250.255ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -125.133ms
AV sync issue in stream 0 at 0:00:03.712 : secondary stream video frame timecode differs by -166.833ms

[BuddTX]

It's hard to answer. That's a relative term. Highest quality for output that will fit on a BD-25? BD-50? Highest quality output to an ALTERNATE format (with no regard for size)? Highest quality at a given bitrate?
I would be interested in the answer for ALTERNATE format.

[jdobbs]

Interesting and surprising findings, indeed.
So for blu-ray compliant encoder settings and GTX-1660 there seems to be no reason any more to fall back to x264 for quality vs file size reasons, based on PSNR and SSIM tests. That's something.
I assume your reference sources were AVC 1080p YV12 8bit, right?I would be interested in the answer for ALTERNATE format.Make sure that under SETTING/ENCODER SETTINGS the quality is set to "High Quality (Default)" or "Highest (Very Slow)". In theory "Highest" should give the best results -- but in my experience that isn't necessarily true.

For BD-25/50, I would also set the encoding method to "CQM". I've found this to be the best quality at a given size. BD-RB will encode samples of the source and predict the lowest CQM value (highest quality) that will fit on the target disc. But size prediction can never be perfect, and there is a (slight) chance that the output might be oversized. Luckily NVENCC is fast -- so you can always reencode it to make it a little smaller using the FIXED_CRF hidden option and slightly higher value than was selected. (But don't forget to remove FIXED_CRF after you are done -- or all your BD encodes will use it until you do, resulting is no size control by BD-RB)

For ALTERNATE output, you can select a CQM value from the alternate dialog. The lower the number, the higher the quality and the bigger the output file -- but honestly anything below 18 or so (for NVENC) will only make it bigger without any noticable difference in quality. For reasonable quality (equivalent to X264's default) a value of 28 is a good place to start.

[Emulgator]

mikeq: could be a tsMuxeR muxing issue.
The reported offsets seem to match multiples of 23.976fps frame durations.
What has BDInfo to say about the source disc ?