BD Rebuilder Beta - Bug Reports Only

[Sharc]

Originally Posted by jdobbs

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]

Originally Posted by Sharc

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]

Originally Posted by 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 !

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]

Originally Posted by Mike-uk

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]

Originally Posted by jdobbs

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]

Originally Posted by jdobbs

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]

Originally Posted by Sharc

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?

Originally Posted by BuddTX

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 ?

[Sharc]

Originally Posted by jdobbs

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.

Another thought: Did your clips for the PSNR and SSIM tests include black letterbox borders? I am asking because black borders will bias the results in favour of the poorer encoder. For a fair encoder comparison any borders should be cropped off I think, as even a poor encoder can encode these perfectly.

[mikeq]

Originally Posted by 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 ?

Seems like it is - I've opened a bug on the tsmuxer site.
If I extract the streams and rebuild the BluRay - I get a similar problem.

[jdobbs]

Originally Posted by Sharc

Another thought: Did your clips for the PSNR and SSIM tests include black letterbox borders? I am asking because black borders will bias the results in favour of the poorer encoder. For a fair encoder comparison any borders should be cropped off I think, as even a poor encoder can encode these perfectly.

I don't believe that is true. The black borders might increase the overall scores, yes. But I it would do so equally for both encoders. For example, in a completely black screen (at the beginning of the movie) both encoders get a perfect SSIM of 1.00 for those frames and a deviation of 0.0000 and a score of 113.0590 dB in PSNR. The same would hold true for the black border areas -- equally for both encoders.

I would also add that an accurate evaluation would compare the two encoders as they would be used. You wouldn't trim the borders in a BD backup (if you did the output would be non-compliant) or in a true 1:1 encode of an original.

[Sharc]

Originally Posted by jdobbs

I don't believe that is true. The black borders might increase the overall scores, yes. But I it would do so equally for both encoders. For example, in a completely black screen (at the beginning of the movie) both encoders get a perfect SSIM of 1.00 for those frames and a deviation of 0.0000 and a score of 113.0590 dB in PSNR. The same would hold true for the black border areas -- equally for both encoders.

Hmmm .... let me expand my thoughts with an (overly) simple model:

Assume a picture with 50% black and 50% active picture area.
Now take 2 encoders ('Good' vs 'Poor'). Both encode the static black part perfectly, say with quality score 100.
The 'Good' encodes the active picture with quality 80, while the 'Poor' encodes the active picture with quality 60.

Case 1: with borders
Good (average) = (100+80)/2 = 90
Poor (average) = (100+60)/2 = 80
Difference Good - Poor = 10

Case 2: borders cropped
Good (average) = 80
Poor (average) = 60
Difference Good - Poor = 20

Hence for case 2 the quality differeence between the 2 encoders is more prominent.
In case 1 the black borders mask the deficiency of the poor encoder.

Am I totally mislead?

[jdobbs]

Originally Posted by Sharc

Hmmm .... let me expand my thoughts with an (overly) simple model:

Assume a picture with 50% black and 50% active picture area.
Now take 2 encoders ('Good' vs 'Poor'). Both encode the static black part perfectly, say with quality score 100.
The 'Good' encodes the active picture with quality 80, while the 'Poor' encodes the active picture with quality 60.

Case 1: with borders
Good (average) = (100+80)/2 = 90
Poor (average) = (100+60)/2 = 80
Difference Good - Poor = 10

Case 2: borders cropped
Good (average) = 80
Poor (average) = 60
Difference Good - Poor = 20

Hence for case 2 the quality differeence between the 2 encoders is more prominent.
In case 1 the black borders mask the deficiency of the poor encoder.

Am I totally mislead?

But... if you go back to my tests -- you'll see that I chose a NVENC CQM value in which the SSIM and/or PSNR values are equal to or greater than that of X264. That would mean that at that value and size NVENC represented in the table would have to be achieving a BETTER score (using the logic of your post). If the borders were equal -- then that means the encoded picture portion would have to be a higher quality (via the metric). The output sizes don't show significant differences, so that would indicate roughly equal encoder quality.

See what I mean?

[Sharc]

Originally Posted by jdobbs

But... if you go back to my tests -- you'll see that I chose a NVENC CQM value in which the SSIM and/or PSNR values are equal to or greater than that of X264. That would mean that at that value and size NVENC represented in the table would have to be achieving a BETTER score (using the logic of your post). If the borders were equal -- then that means the encoded picture portion would have to be a higher quality (via the metric). The output sizes don't show significant differences, so that would indicate roughly equal encoder quality.

See what I mean?

Yes, I think I see what you mean. You basically encoded for equal ("equal" within practical limits) PSNR (or SSIM) by adjusting CRF or CQM of encoders A and B respectively, means same objective final quality for A and B according to the metrics. You kept the borders -- as one would do in real BD-RB backup scenarios. I don't doubt the test method and the results at all, so don't get me wrong.
Eventually we may now want to compare the resulting file size and find that encoder A produced a file size which is say few % less than B (at 'same' PSNR or SSIM). Hence we conclude that encoder A is more efficient than B. I just wrapped my head around the question whether the conclusion would have been the same with the black borders cropped off because the borders would bias the result unequally for A and B. Confusing myself ... ;-)
Many thanks for the enlightening and useful tests.

[jdobbs]

Originally Posted by Sharc

Yes, I think I see what you mean. You basically encoded for equal ("equal" within practical limits) PSNR (or SSIM) by adjusting CRF or CQM of encoders A and B respectively, means same objective final quality for A and B according to the metrics. You kept the borders -- as one would do in real BD-RB backup scenarios. I don't doubt the test method and the results at all, so don't get me wrong.
Eventually we may now want to compare the resulting file size and find that encoder A produced a file size which is say few % less than B (at 'same' PSNR or SSIM). Hence we conclude that encoder A is more efficient than B. I just wrapped my head around the question whether the conclusion would have been the same with the black borders cropped off because the borders would bias the result unequally for A and B. Confusing myself ... ;-)
Many thanks for the enlightening and useful tests.

There is a point (CRF=27.5 and CQM=32.5) where the NVENC output was 10% bigger. But, conversely, there was also a point (CRF=16 and CQM=16) where is was 12% smaller.

Just for S&G, maybe I'll go back and strip the borders to see what happens.

[Sharc]

Originally Posted by jdobbs

There is a point (CRF=27.5 and CQM=32.5) where the NVENC output was 10% bigger. But, conversely, there was also a point (CRF=16 and CQM=16) where is was 12% smaller.

Just for S&G, maybe I'll go back and strip the borders to see what happens.

I made a test with my 1050ti. The result is not nearly as good as what you got with your 1660.
I aligned for same PSNR as a reference, using the commandline from BD-RB.

x264:
CRF=22 PSNR=44.81dB SSIM=83.00824601 filesize=3'307'459k 1.000

NVEncC:
CQM=25 PSNR=44.82dB SSIM=82.53126698 filesize=4'561'774k 1.379


For same PSNR the video filesize for NVEnc was 38% higher than for x264. For same SSIM it would be even more.
No borders in my test movie, but I don't think that this matters much. The big difference seems to be the HW.

[Mike-uk]

Originally Posted by Sharc

I made a test with my 1050ti. The result is not nearly as good as what you got with your 1660.
I aligned for same PSNR as a reference, using the commandline from BD-RB.

x264:
CRF=22 PSNR=44.81dB SSIM=83.00824601 filesize=3'307'459k 1.000

NVEncC:
CQM=25 PSNR=44.82dB SSIM=82.53126698 filesize=4'561'774k 1.379


For same PSNR the video filesize for NVEnc was 38% higher than for x264. For same SSIM it would be even more.
No borders in my test movie, but I don't think that this matters much. The big difference seems to be the HW.

1050ti does not support B-fame where as the 1060 does

[Sharc]

Originally Posted by Mike-uk

1050ti does not support B-fame where as the 1060 does

1050ti supports B frames for h.264 (AVC) very well. I am using it all the time.
It does however not support B frames for h.265 (HEVC).