BD Rebuilder Beta - Bug Reports Only

[Lathe]

Wow. When was that posted... I must have missed it completely.

[Edit] Ok, I see. It was part of the "3 frigg'n MONTHS behind" post. I guess I just missed that part.

Sorry Boss... http://lathe-of-heaven.com/rolleyes2.gif

[Lathe]

but frankly I am skeptical of all of these "extensions" to HDR10 as I think they are getting ridiculous and may in the same category as "HD Audio" (which is nothing beyond a marketing gimmick that has been proven scientifically as nonsense). Of course that comment will likely result in responses from people with "magic ears" who will say how they can tell the difference (even though what they actually hear is increased baseline volume that the marketeers have implemented in HD audio to try and make it appear as if there is an actual difference). Double blind tests show that (other than the additional channels available available in HD formats) Dolby Digital 5.1 at 640Kbs is indistinguishable from an lossless original audio source. Okay, time to step down off my soapbox.

Poor JD... All those tours in 'Nam around those big guns... http://lathe-of-heaven.com/no.gif

[meadrocks]

That is a really weird one. The only explanation I can see is that somehow either: 1) The PGS files have something off within them (either in the original or created by TSMUXER during demux). or 2) MKVMERGE is somehow misreading the timestamps in the PGS file when it is creating the MKV.

What can I do to help you with this?

[Lathe]

Normal is in the eye of the beholder. :D



You got that right, just ask @gonca...




http://lathe-of-heaven.com/Groucho eyeroll1.gif

[cartman0208]

FOUND IT!

There is a similar problem here (https://forum.doom9.org/showthread.php?t=163825) which put me to the right direction.
The commandline states "--threads auto" ... that might do for 99% of the systems. But I build that machine mainly for encoding, with 2 Xeon 2699v3, that sum up (with hyperthreading) to 72 threads total.
Every thread of x264 uses a certain amount of RAM, which breaks the memory limitation of 32bit apps

I guess disabling hyperthreading ("--threads 36" is working with 2.8 GB RAM used) will solve the problem for me, but if someone builds a similar system or uses one of the mean AMD Threadrippers, they will also run into that Problem.
[edit] Read a little more: "--threads auto" creates 1.5 times CPU cores threads for encoding... So even with Hyperthreading switched off the encode would fail on my machine

[Lathe]

Uh, I kinda feel bad asking this amongst the more serious cutting edge stuff that you've been working on here (which I've just been catching up on and is truly amazing guys!) But, it's been a while since I used BDRB and I THOUGHT that I remembered that if you input a file that was not BR compliant, say an MKV file with the dimensions of 1920x800, that BDRB would automatically see that and using AVS would add borders to bring it up to compliance. BUT... maybe once you take that MKV file and put it through TSMuxer to put it into a BDMV folder format and THEN input that into BDRB, apparently it does not seem to do that but even setting the output size slightly smaller (to force re-encoding) the dimensions of the resulting m2ts file are unchanged...???

So, is that the deal then, whatever is INSIDE the BDMV folder is left untouched when inputted into BDRB, and borders are not automatically added?

I'm doing it over now and I simply added the AVS script to add borders, and of course in checking the processing .264 file it is now going to be compliant when it is done. I guess I had always thought that BDRB did that automatically with anything out of specification.

[BuddTX]

What preset(s) do you use?
And are your sources UHDs or *normal* BDs?

I cant recall if any DVD's imported into BD-RBD ever failed the "auto crop black borders", I think, from memory, maybe there were a few.

However, I mainly do 1080P Blu-ray sources, using X265 to process the encode.

I rough guess would be about 1 in 10 Blu-ray sources fail when "auto crop black borders" is selected.

Again, "from memory" I think I tested one encode with X264 when one encode failed using X265, and I believe it also failed, so both X265 and X264 failed with "auto crop black borders" selected for that encode.

Next encode that fails, I will try both x264 and x265.

[jdobbs]

FOUND IT!

There is a similar problem here (https://forum.doom9.org/showthread.php?t=163825) which put me to the right direction.
The commandline states "--threads auto" ... that might do for 99% of the systems. But I build that machine mainly for encoding, with 2 Xeon 2699v3, that sum up (with hyperthreading) to 72 threads total.
Every thread of x264 uses a certain amount of RAM, which breaks the memory limitation of 32bit apps

I guess disabling hyperthreading ("--threads 36" is working with 2.8 GB RAM used) will solve the problem for me, but if someone builds a similar system or uses one of the mean AMD Threadrippers, they will also run into that Problem.
[edit] Read a little more: "--threads auto" creates 1.5 times CPU cores threads for encoding... So even with Hyperthreading switched off the encode would fail on my machineI'll recheck and see if that option is actually necessary. If not I'll remove it, otherwise I'll create a hidden option to remove it.

[Edit] Actually that won't work because the default value is "auto". But... there is a HIDDEN option in BD-RB that will set the number of threads you want to use:

THREADS=n

n is the number of threads to use. The limit is 16. I may have to look at increasing that limit. X264 has a limit of 128, but they say "realistically you should never set it this high".

[jdobbs]

Uh, I kinda feel bad asking this amongst the more serious cutting edge stuff that you've been working on here (which I've just been catching up on and is truly amazing guys!) But, it's been a while since I used BDRB and I THOUGHT that I remembered that if you input a file that was not BR compliant, say an MKV file with the dimensions of 1920x800, that BDRB would automatically see that and using AVS would add borders to bring it up to compliance. BUT... maybe once you take that MKV file and put it through TSMuxer to put it into a BDMV folder format and THEN input that into BDRB, apparently it does not seem to do that but even setting the output size slightly smaller (to force re-encoding) the dimensions of the resulting m2ts file are unchanged...???

So, is that the deal then, whatever is INSIDE the BDMV folder is left untouched when inputted into BDRB, and borders are not automatically added?

I'm doing it over now and I simply added the AVS script to add borders, and of course in checking the processing .264 file it is now going to be compliant when it is done. I guess I had always thought that BDRB did that automatically with anything out of specification.It is not automatically resized or padded during import. So you can have a pseudo-BD structure (thus the name) that contains a video stream that is not resized to be compliant.

But... when you run a job against that structure, the resizing occurs during reencoding and the output is compliant.

[jedihyte]

There is no '3D MVC mkv' option AFAIK. However, the Alternate Movie-only output includes a few options for SBS 3D mkv.

Ok thanks for the info.

Does anyone know how to get around the issue when making BD-25 Full backups of 3D movies without the pixelization/artifacts that show up every second of the playback using software players? (I have not seen the issue using a hardware player). But searching the forum I can see it happens to others, but not sure if there ever was a workaround found?

[gonca]

@AmigaFuture It is really a no-brainer :))
It is about your speed

[gonca]

You got that right, just ask @gonca...

This from a guy that plays with dolls

[jdobbs]

Ok thanks for the info.

Does anyone know how to get around the issue when making BD-25 Full backups of 3D movies without the pixelization/artifacts that show up every second of the playback using software players? (I have not seen the issue using a hardware player). But searching the forum I can see it happens to others, but not sure if there ever was a workaround found?If it only happens on a software player and never on a hardware player, it would lead to to believe that the software player is at fault, not the encode.

[meadrocks]

What can I do to help you with this?

I also have the same issue with Porco Rosso, Princess Mononoke, and The Iron Giant.


$ mediainfo IRON_GIANT.mkv
General
Unique ID : 249929721907896038595676073595108680533 (0xBC06B6AAA7854E4A9BA9125D1FA56355)
Complete name : IRON_GIANT.mkv
Format : Matroska
Format version : Version 2
File size : 1.76 GiB
Duration : 2 h 55 min
Overall bit rate : 1 438 kb/s
Encoded date : UTC 2019-08-01 09:29:38
Writing application : mkvmerge v9.7.1 ('Pandemonium') 32bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 26 min
Bit rate : 2 608 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Original frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.052
Stream size : 1.58 GiB (90%)
Writing library : x265 2.8+69-856f056d392e:[Windows][GCC 8.2.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=3 / numa-pools=8 /
wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 /
total-frames=0 / level-idc=0 /
high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd /
info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=240 / gop-lookahead=0 / bframes=4 /
b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / radl=0 /
no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 /
imit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 /
no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 /
merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock /
rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 /
psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 /
stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 /
no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 /
transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 /
vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / n
o-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 /
scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / c
opy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : A_AAC-2
Duration : 1 h 26 min
Bit rate : 288 kb/s
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 176 MiB (10%)
Language : English
Default : Yes
Forced : No

Text
ID : 3
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 2 h 54 min
Bit rate : 5 781 b/s
Count of elements : 2448
Stream size : 7.22 MiB (0%)
Language : English
Default : No
Forced : No

Menu
00:00:00.000 : en:00:00:00.000
00:02:26.896 : en:00:02:26.896
00:06:11.537 : en:00:06:11.537
00:08:58.454 : en:00:08:58.454
00:10:31.339 : en:00:10:31.339
00:12:47.558 : en:00:12:47.558
00:14:53.934 : en:00:14:53.934
00:16:23.899 : en:00:16:23.899
00:18:17.054 : en:00:18:17.054
00:20:36.401 : en:00:20:36.401
00:23:53.682 : en:00:23:53.682
00:25:47.504 : en:00:25:47.504
00:27:55.465 : en:00:27:55.465
00:29:57.045 : en:00:29:57.045
00:32:19.979 : en:00:32:19.979
00:33:42.395 : en:00:33:42.395
00:36:11.711 : en:00:36:11.711
00:37:54.188 : en:00:37:54.188
00:40:22.711 : en:00:40:22.711
00:44:04.808 : en:00:44:04.808
00:45:51.415 : en:00:45:51.415
00:48:07.968 : en:00:48:07.968
00:50:33.405 : en:00:50:33.405
00:52:33.108 : en:00:52:33.108
00:54:04.366 : en:00:54:04.366
00:58:31.132 : en:00:58:31.132
01:01:27.517 : en:01:01:27.517
01:03:42.443 : en:01:03:42.443
01:05:36.140 : en:01:05:36.140
01:09:03.347 : en:01:09:03.347
01:10:19.256 : en:01:10:19.256
01:14:00.394 : en:01:14:00.394
01:16:40.762 : en:01:16:40.762
01:19:28.513 : en:01:19:28.513
01:26:38.818 : en:01:26:38.818

[gonca]

Can you retry without the subtitles
and if possible post a before and after subtitle file

[cartman0208]

I'll recheck and see if that option is actually necessary. If not I'll remove it, otherwise I'll create a hidden option to remove it.

[Edit] Actually that won't work because the default value is "auto". But... there is a HIDDEN option in BD-RB that will set the number of threads you want to use:

THREADS=n

n is the number of threads to use. The limit is 16. I may have to look at increasing that limit. X264 has a limit of 128, but they say "realistically you should never set it this high".

I set it to 16, but the CPU utilization is now around 20% at the most.
Changing values of MULTIPROCESS doesn't make it faster.
Even 36 threads don't use more CPU

Guess I'll have to go with that

[BuddTX]

I cant recall if any DVD's imported into BD-RBD ever failed the "auto crop black borders", I think, from memory, maybe there were a few.

However, I mainly do 1080P Blu-ray sources, using X265 to process the encode.

I rough guess would be about 1 in 10 Blu-ray sources fail when "auto crop black borders" is selected.

Again, "from memory" I think I tested one encode with X264 when one encode failed using X265, and I believe it also failed, so both X265 and X264 failed with "auto crop black borders" selected for that encode.

Next encode that fails, I will try both x264 and x265.

Forgot to add, that I create, almost exclusively, MKV Files.

[Lathe]

It is not automatically resized or padded during import. So you can have a pseudo-BD structure (thus the name) that contains a video stream that is not resized to be compliant.

But... when you run a job against that structure, the resizing occurs during reencoding and the output is compliant.

Thanks kindly for the answer JD, but I must not be understanding you correctly because I THOUGHT that is exactly what I just did. I used the non-compliant BDMV folder (containing the TSMuxer muxed MKV file still at 1920x800) and BDRB did re-encode it, but the resulting BDMV folder and thus the m2ts file inside it STILL was the non-compliant AR of 1920x800, nothing changed.

What am I missing here...?

[Lathe]

This from a guy that plays with dolls

Well, at least I am procreating within my species... :D

[Lathe]

Just in addition...

So, what I ended up doing was re-running the exact same job with BDRB, but this time adding the AVS code for 'add borders', so yes this time the borders were added to the re-encode just fine. BUT... I had thought that BDRB detected that automatically and that you didn't need to add the AVS code.

[meadrocks]

What can I do to help you with this?

In alternate.txt I copied my MKV entry to the end, 00041, changed ctype from 1 to 5,
ran it, but it still created a mkv file and mediainfo reports the General->Format to be Matroska. I was curious to see if the mp4 container fixed the Duration problems that the mkv seems to have.

[cartman0208]

In alternate.txt I copied my MKV entry to the end, 00041, changed ctype from 1 to 5,
ran it, but it still created a mkv file and mediainfo reports the General->Format to be Matroska. I was curious to see if the mp4 container fixed the Duration problems that the mkv seems to have.

Did you try Subtitle Edit (https://github.com/SubtitleEdit/subtitleedit/releases) to check out the Subtitles?

I can confirm that x265 only results in MKVs, even if MP4 is requested as container.
x264 seems to output the correct container.

[meadrocks]

Did you try Subtitle Edit (https://github.com/SubtitleEdit/subtitleedit/releases) to check out the Subtitles?

I can confirm that x265 only results in MKVs, even if MP4 is requested as container.
x264 seems to output the correct container.

I'll check it out Sunday, as Im out of town.

[AmigaFuture]

You got that right, just ask @gonca...

Just ask at-gonca?? That's like saying "I want to use the ATM machine." since ATM is an acronym for Automatic Teller Machine.

"Ur funny."

More fun poking.."But, it's been a while since I used BDRB..." "It is been a while..", are you sure it IS been a while? Though MrVideo and I aren't related, it's fun to catch stuff.

Well, at least I am procreating within my species... :D

Yet, you speak...and type. Are you "Possessed"??

FOUND IT!

There is a similar problem here (https://forum.doom9.org/showthread.php?t=163825) which put me to the right direction.
The commandline states "--threads auto" ... that might do for 99% of the systems. But I build that machine mainly for encoding, with 2 Xeon 2699v3, that sum up (with hyperthreading) to 72 threads total.
Every thread of x264 uses a certain amount of RAM, which breaks the memory limitation of 32bit apps

I guess disabling hyperthreading ("--threads 36" is working with 2.8 GB RAM used) will solve the problem for me, but if someone builds a similar system or uses one of the mean AMD Threadrippers, they will also run into that Problem.
[edit] Read a little more: "--threads auto" creates 1.5 times CPU cores threads for encoding... So even with Hyperthreading switched off the encode would fail on my machine

Thhhhhhat is interesting!! I'll check that with my new budget Ryzen build. Still using Windows 7, ahhhhhhhhh...it's sweet.

[Lathe]

Just ask at-gonca?? That's like saying "I want to use the ATM machine." since ATM is an acronym for Automatic Teller Machine.

"Ur funny."

More fun poking.."But, it's been a while since I used BDRB..." "It is been a while..", are you sure it IS been a while? Though MrVideo and I aren't related, it's fun to catch stuff.



Yet, you speak...and type. Are you "Possessed"??



I think BOTH you and Mr. Video should be severely beaten...

And, BTW... "it's" is also a proper contraction for "it has" Mr. WeeWeeHead...



http://lathe-of-heaven.com/Suspicious Cat.gif

[jdobbs]

I set it to 16, but the CPU utilization is now around 20% at the most.
Changing values of MULTIPROCESS doesn't make it faster.
Even 36 threads don't use more CPU

Guess I'll have to go with thatI've changed the limits on THREADS=n for the next release. It can be set up to 128 (the limit for X264).

[jdobbs]

I can confirm that x265 only results in MKVs, even if MP4 is requested as container.
x264 seems to output the correct container. Actually I'd forgotten about that. Earlier versions of MP4BOX (like the 2012 one included with BD-RB) didn't support HEVC -- so BD-RB only allowed MKV for writing an HEVC stream.

I'm testing a version with HEVC support that is a good balance of size/capability to include with BD-RB in the next release.

[Edit] Completed. You will be able to output HEVC to an MP4 in the next release.

[jdobbs]

Thanks kindly for the answer JD, but I must not be understanding you correctly because I THOUGHT that is exactly what I just did. I used the non-compliant BDMV folder (containing the TSMuxer muxed MKV file still at 1920x800) and BDRB did re-encode it, but the resulting BDMV folder and thus the m2ts file inside it STILL was the non-compliant AR of 1920x800, nothing changed.

What am I missing here...?One thing that might cause that: Did you import the file before NVENCC was implemented in BD-RB and then use NVENCC for the encode? If so, the NVENCC adjustments wouldn't be found in the PSEUDO.INF file (created during import) and the resizing and/or padding wouldn't occur.

Just throwing out possibilities.

[cartman0208]

I've changed the limits on THREADS=n for the next release. It can be set up to 128 (the limit for X264).

:thanks:

and

Completed. You will be able to output HEVC to an MP4 in the next release.

:thanks:

Was anyone able to do a successful Autocrop with HEVC (UHD) content?
The AVS file is running, there is just no cropping done.

[jdobbs]

Was anyone able to do a successful Autocrop with HEVC (UHD) content?
The AVS file is running, there is just no cropping done.I'll do some testing.

Were you using NVENCC or X265 for your output?

[jdobbs]

Was anyone able to do a successful Autocrop with HEVC (UHD) content?
The AVS file is running, there is just no cropping done.I'll do some testing.

Were you using NVENCC or X265 for your output?I just tried it with an HEVC 2160p source... and it didn't work. The AVS file looks okay, but when I play it back (even directly with no reencoding) it isn't cropping. It's almost as if the AutoCrop() call isn't even there -- but it is.


[Edit] Just tried it with RoboCrop (another auto cropping plugin) as suggested by BuddTX (https://forum.doom9.org/showthread.php?p=1919471#post1919471) and got the same results.

[gonca]

Quick question
Do AutoCrop or RoboCrop work with 10 bit video?

[jdobbs]

Quick question
Do AutoCrop or RoboCrop work with 10 bit video?That could be an issue, yes. AVISYNTH only works in 8 bit. But I would have assumed that the conversion takes place during decoding, otherwise AVISYNTH shouldn't work at all with the source.

[cartman0208]

I just tried it with an HEVC 2160p source... and it didn't work. The AVS file looks okay, but when I play it back (even directly with no reencoding) it isn't cropping. It's almost as if the AutoCrop() call isn't even there -- but it is.


Can confirm that ... I did a conversion with x265, but also just played the AVS file in MPC-HC.
I'm afraid, in 2005, when AutoCrop was last updated, 10bit and 4K was far away :(

[Mike-uk]

@jdobbs are you using multipass ??

Multi pass frame encoding
When determining the QP to use for encoding a frame, it is beneficial if NVENC knows the overall complexity of the frame to distribute the available bit budget in the most optimal manner. In some situations, multi-pass encoding may also help catch larger motion between frames. For this purpose, NVENC supports the following types of multi-pass frame encoding modes:

1-pass per frame encoding (NV_ENC_MULTI_PASS_DISABLED)
2-passes per frame, with first pass in quarter resolution and second pass in full resolution (NV_ENC_TWO_PASS_QUARTER_RESOLUTION)
2-passes per frame, with both passes in full resolution (NV_ENC_TWO_PASS_FULL_RESOLUION).
In 1-pass rate control modes, NVENC estimates the required QP for the macroblock and immediately encodes the macroblock. In 2-pass rate control modes, NVENC estimates the complexity of the frame to be encoded and determines bit distribution across the frame in the first pass. In the second pass, NVENC encodes macroblocks in the frame using the distribution determined in the first pass. As a result, with 2-pass rate control modes, NVENC can distribute the bits more optimally within the frame and can reach closer to the target bitrate, especially for CBR encoding. Note, however, that everything else being the same, performance of 2-pass rate control mode is lower than that of 1-pass rate control mode. The client application should choose an appropriate multi-pass rate control mode after evaluating various modes, as each of the modes has its own advantages and disadvantages. NV_ENC_TWO_PASS_FULL_RESOLUION generates better statistics for the second pass, whereas NV_ENC_TWO_PASS_QUARTER_RESOLUTION results in larger motion vectors being caught and fed as hints to second pass.

and from nvencc

--multipass <string>
Multi pass mode. Available only for --vbr and --cbr. [API v10.0]

none
2pass-quarter
2pass-full

[Sharc]

History repeats ..... ;)

https://forum.doom9.org/showpost.php?p=1918354&postcount=29626

From rigaya's release notes of Release 5.10:
Options below will be mapped to each other depending on the NVENC API version used.

SDK API 9.0, 9.1: --vbrhq
SDK API 10.0: --vbr --multipass 2pass-full

The 2 are currently equivalent.
He also wrote that in future the --vbrhq of API 9.0, 9.1 may be dropped and and only the syntax of API 10.0 will be supported.

[Mike-uk]

History repeats ..... ;)

https://forum.doom9.org/showpost.php?p=1918354&postcount=29626

lol didnt see your post :P

[Sharc]

No problem. Double-stitching has its benefits :D

[SquallMX]

CRF Prediction is broken for x265.

----------------------
[08/02/20] BD Rebuilder v0.61.09
[14:41:06] Source: THE_FAST_AND_THE_FURIOUS_2001
- Input BD size: 57.81 GB
- Approximate total content: [02:36:40.348]
- Target BD size: 24.41 GB
- Windows Version: 6.2 [9200]
- Quality: High Quality (Default), CRF
- Decoding/Frame serving: FFMPEG
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[14:41:08] PHASE ONE, Encoding
- [14:41:08] Processing: VID_00165 (1 of 4)
- [14:41:08] Extracting A/V streams [VID_00165]
- [14:41:14] Reencoding video [VID_00165]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 576 frames
- [14:41:14] Performing CRF Prediction...
- Analyzing 16.00 14.40 15.45 14.70 15.25 14.85 15.15 [15.15]
- [14:42:22] Encoding using constant rate factor.
- Performing size-correcting second pass...
- [14:45:07] Video Encode complete
- [14:45:07] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [14:45:07] Multiplexing M2TS
- [14:45:11] Blanking: VID_00252 (2 of 4)
- [14:45:11] Blanking: VID_00253 (3 of 4)
- [14:45:11] Processing: VID_00294 (4 of 4)
- [14:45:11] Extracting A/V streams [VID_00294]
- [14:54:27] Reencoding video [VID_00294]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 153,721 frames
- [14:54:27] Performing CRF Prediction...
- Analyzing 16.30 2.00 [2.00]
- [14:55:03] Encoding using constant rate factor.
[14:56:53] - Aborted by user request

CRF 2 is insanely low, I loaded the prediction AVS script / M2TS on VDub, seems to be broken at I frames, so its mainly static frames, which explains the low CRF value.

This is the sample file:
https://mega.nz/file/ATpg3Q6J#XK09Bq7i5cyL5eE1nU24ddgXb2Q7UKhTTZVPpz4w9Es

[cartman0208]

CRF Prediction is broken for x265.



CRF 2 is insanely low, I loaded the prediction AVS script / M2TS on VDub, seems to be broken at I frames, so its mainly static frames, which explains the low CRF value.

This is the sample file:
https://mega.nz/file/ATpg3Q6J#XK09Bq7i5cyL5eE1nU24ddgXb2Q7UKhTTZVPpz4w9Es

Did you try a complete encode?
I had CRF Values of 1.00 but the output was not oversized ...

[SquallMX]

Did you try a complete encode?
I had CRF Values of 1.00 but the output was not oversized ...

It's almost impossible for a 35mm live action film to get those CRF values for a 4K BD-25, for reference when using nVidia HW Accelerated encoding I got a value of 22.15.

[meadrocks]

Actually I'd forgotten about that. Earlier versions of MP4BOX (like the 2012 one included with BD-RB) didn't support HEVC -- so BD-RB only allowed MKV for writing an HEVC stream.

I'm testing a version with HEVC support that is a good balance of size/capability to include with BD-RB in the next release.

[Edit] Completed. You will be able to output HEVC to an MP4 in the next release.

I'll wait for the next release & try both container types.

[Lathe]

One thing that might cause that: Did you import the file before NVENCC was implemented in BD-RB and then use NVENCC for the encode? If so, the NVENCC adjustments wouldn't be found in the PSEUDO.INF file (created during import) and the resizing and/or padding wouldn't occur.

Just throwing out possibilities.

Hmmm, thanks for the thought, but no... I just simply took the MKV file, used TSMuxer to convert it to a BDMV/CERT format, then used that as the source like I would any ripped Blu-ray for BDRB. I then set the size output slightly smaller so that it would force a re-encode (the original size of the BDMV folder was around 18 Gigs. I used the LAV internal encoder as usual. I didn't change anything that I normally would do.

No biggie really, as long as I know now that BDRB will not automatically detect the improper AR within the BDMV folder, I will just add the AVS script from now on if I have to do that. I don't do that very often, only when I have a pretty high resolution file that has the lossless audio (I know, I know... :)) but I want to convert the video to a playable Blu-ray format.

It just occurred to me too that maybe if I just simply imported the original MKV file into BDRB and let IT created the pseudo BDMV folder, then perhaps it would detect the non-compliant AR in the MKV file. I guess I was just trying to skip having BDRB do that step.

[cartman0208]

It's almost impossible for a 35mm live action film to get those CRF values for a 4K BD-25, for reference when using nVidia HW Accelerated encoding I got a value of 22.15.

Sure, but did you actually complete the encode (in your log it was aborted)?
Might be a display issue and an other value is used ... just see, what output size you get...

[jdobbs]

Status update: Got pretty much everything reported in bug reports fixed. Currently working on HDR10+ support. I'll probably be releasing the next version in a day or two.

[jdobbs]

CRF Prediction is broken for x265.



CRF 2 is insanely low, I loaded the prediction AVS script / M2TS on VDub, seems to be broken at I frames, so its mainly static frames, which explains the low CRF value.

This is the sample file:
https://mega.nz/file/ATpg3Q6J#XK09Bq7i5cyL5eE1nU24ddgXb2Q7UKhTTZVPpz4w9EsThe AVS isn't used for HEVC prediction because the SelectRangeEvery() filter just doesn't seem to be able to find keyframes on HEVC. You also can't look at the M2TS used as input because a player (but not an encoder) will have trouble with the crazy DTS/PTS values.

You pretty much have to look at the output of the prediction to actually see how it went.

[Lathe]

Status update: Got pretty much everything reported in bug reports fixed. Currently working on HDR10+ support. I'll probably be releasing the next version in a day or two.

Thanks Boss! http://lathe-of-heaven.com/tiphat.gif

[Lathe]

On a side note, with my new build everything works really well, except when I try to utilize more of the CPU. I wonder if the Ryzen 5's are known easily to over heat? It's ONLY when I try to do an encode which of course tries to utilize most of the CPU. If it is running full out at 90%+ it gradually gets hotter and hotter until it reaches about 90 degrees and shuts the computer off. The case I got has FIVE bloody fans in it too for Goodness sake! With a huge one on the side to draw in cooler air. I'm taking it back in to where they built it, and as an added help I bought an after market CPU cooler. But, it really shouldn't be doing that anyway.

The only work around I could come up with is when I did an encode using x264 either with or without BDRB, the only way I can keep the CPU from overheating is to deselect the cores/threads in the 'Affinity' setting when you right-click the x264 process in TM. So, if I only use 1/4 of the 'cores' or whatever they are and the CPU is only running at 25%, I can just BARELY keep it under the redline temperature. Sure is frustrating. Still is a lot faster than my old one, but it would be kind of nice to be able to use the entire potential of the CPU.

I'm HOPING that he will find what exactly is causing that (hopefully NOT a bad CPU!) because just adding the after market cooler alone will not fix that. I guess I'll just hafta see what happens...

[cartman0208]

On a side note, with my new build everything works really well, except when I try to utilize more of the CPU. I wonder if the Ryzen 5's are known easily to over heat? It's ONLY when I try to do an encode which of course tries to utilize most of the CPU. If it is running full out at 90%+ it gradually gets hotter and hotter until it reaches about 90 degrees and shuts the computer off. The case I got has FIVE bloody fans in it too for Goodness sake! With a huge one on the side to draw in cooler air. I'm taking it back in to where they built it, and as an added help I bought an after market CPU cooler. But, it really shouldn't be doing that anyway.


It's like cars with a lot of power and crappy tires ... can't get the power on the street ;)
One hint I can give: thermal conductive paste, not too little, not too much...
If the heat from the CPU cant get to the heat spreader you can have the best cooling solution ever but it won't cool.

I, personally, use AIO watercoolers ... easy setup, lots of space left in the case, way cooler than all the aircoolers I had and not even that expensive...

[gonca]

@Lathe
The coolers supplied by Intel and AMD with their CPUs are not the greatest, to be kind.
Like cartman0208 said, get an AIO watercooler
I like Corsair, and don't get one with a small radiator