BD Rebuilder Beta - Bug Reports Only

[MrVideo]

@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
You still got to get the paste correct.

[BuddTX]

You still got to get the paste correct.

Check out this IC Graphite Pad, supposed to work just as good as the best thermal pastes, but with no drying out or installation errors:
https://youtu.be/YpphKzmDiJM
https://www.amazon.com/dp/B07CKVW18G

[SquallMX]

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

Yes I did:

[08/03/20] BD Rebuilder v0.61.09
[21:37:28] 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: Better (Faster), CRF
- Decoding/Frame serving: FFMPEG
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[21:37:32] PHASE ONE, Encoding
- [21:37:32] Processing: VID_00165 (1 of 4)
- [21:37:32] Extracting A/V streams [VID_00165]
- [21:37:37] Reencoding video [VID_00165]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 576 frames
- [21:37:37] Performing CRF Prediction...
- Analyzing 15.80 15.30 14.95 [14.95]
- [21:37:53] Encoding using constant rate factor.
- [21:38:40] Video Encode complete
- [21:38:40] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:38:40] Multiplexing M2TS
- [21:38:44] Blanking: VID_00252 (2 of 4)
- [21:38:44] Blanking: VID_00253 (3 of 4)
- [21:38:44] Processing: VID_00294 (4 of 4)
- [21:38:44] Extracting A/V streams [VID_00294]
- [21:48:00] Reencoding video [VID_00294]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23.976fps, 153,721 frames
- [21:48:00] Performing CRF Prediction...
- Analyzing 15.90 8.45 4.72 2.86 1.93 1.46 1.23 1.11 1.06 1.03 1.02 1.01 [1.01]
- [21:49:38] Encoding using constant rate factor.
- Performing size-correcting second pass...
- [09:34:24] Video Encode complete
- [09:34:24] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4354 (spa): Keeping original audio
- Track 4357 (eng): Keeping original audio
- [09:34:24] Multiplexing M2TS
[09:35:24]PHASE ONE complete
[09:35:24]PHASE TWO - Rebuild Started
- [09:35:24] Rebuilding BD file Structure
[09:35:44] - Encode and Rebuild complete

[Status]
LABEL=THE_FAST_AND_THE_FURIOUS_2001
VERSION=v0.61.09
SOURCE_SIZE=62073708041
SOURCE_VIDEO_SIZE=60550053888
TARGET_SIZE=26214400000
REDUCTION=.407774134977166
RESIZE_1080=0
RESIZE_1440=0
AUDIO_TO_KEEP=all
KEEP_HD_AUDIO=-1
SUBS_TO_KEEP=all
BACKUP_MODE=0
MOVIEONLY_TYPE=0
USE_LAVF=0
INSTANCES=1
DGDECNV=0
DGDECIM=0
FRIMSOURCE=0
FFMS2=0
SSIF_MODE=0
UHD_V3_MODE=0
QUICK=0
ENCODE_STEP=0
COMPLETED=4
REBUILD_COMPLETE=1
[00165]
AUDIO=1
PGS=
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=78560708
NSTART=27000000
NEND=28081079
NSIZE=80283648
FLINK=0
MLINK=0
[00294]
AUDIO=101001
PGS=1111111111111
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=24612185139
NSTART=27000000
NEND=315515101
NSIZE=23796996096
FLINK=0
MLINK=0


After creating an enormous 40+ GBs .hevc file, BD-RB did a 2-pass which resulted in a properly fit 23 GB output but pretty much regates the point of a CRF mode, which is getting similar quality than 2 pass mode on 1 pass, in fact, because 2-pass mode uses a "fast" 1 pass the encoding time was longer (8 Hours [Normal 2-Pass mode] vs 12 Hours [CRF mode + size-correcting second pass]).

So software encoding CRF prediction is definitely buggy, at least in version 61.09. Looks like its using FFMPEG for getting the sample data but the results are static images (crazy DTS/PTS values?) so the prediction calculates a very low CRF value:

"D:\Archivos de Programa\BD Rebuilder UHD\tools\ffmpeg.exe" -ss 5998.7456 -i
"L:\BLU-RAYS\4K\THE FAST AND THE FURIOUS 2001\BDMV\STREAM\00294.m2ts"
-frames 48 -an -sn -codec copy -f mpegts - >> "C:\TEMP\WORKFILES\00294.AVS.SMPL.m2ts"

[MrVideo]

Please code wrap, do not quote wrap output text.

[MrVideo]

Check out this IC Graphite Pad, supposed to work just as good as the best thermal pastes, but with no drying out or installation errors:
https://www.amazon.com/dp/B07CKVW18G
Neat stuff. Thanks for the tip. I ordered one from ebay. 50 cents more, but free shipping.

[jdobbs]

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.Yes. That would be the problem. If you create the source manually (using TSMUXER) then BD-RB has no way of knowing the AR is noncompliant and noting it for adjustment. TSMUXER will set the CLPI's flags to the nearest compliant resolution. Since there is no PSEUDO.INI file, BD-RB thinks it's a standard BD and assumes the CLPI is correct.

[jdobbs]

After creating an enormous 40+ GBs .hevc file, BD-RB did a 2-pass which resulted in a properly fit 23 GB output but pretty much regates the point of a CRF mode, which is getting similar quality than 2 pass mode on 1 pass, in fact, because 2-pass mode uses a "fast" 1 pass the encoding time was longer (8 Hours [Normal 2-Pass mode] vs 12 Hours [CRF mode + size-correcting second pass]).

So software encoding CRF prediction is definitely buggy, at least in version 61.09. Looks like its using FFMPEG for getting the sample data but the results are static images (crazy DTS/PTS values?) so the prediction calculates a very low CRF value:Yes. It needs work -- that's the purpose of releasing a test version, so I can get feedback. But as I said before -- the "static images" you mention AREN'T a problem when encoding for prediction... that is an issue with whatever you are using in playback.

The reason I think it is important to get CQM & CRF working well ISN'T just speed. My testing shows that you get BETTER QUALITY at the same size using CQM/CRF than you do with one-pass VBR bitrate encoding. NVENCC has no true two-pass option and X265 is so slow on UHD that you want to try and avoid two-pass. So the time comparison shouldn't be between one-pass and CQM/CRF -- but between CQM/CRF and a two pass encode (averaging across multiple discs -- not just one). A second pass in CQM/CRF mode only occurs when the final target size is exceeded to a point where it won't fit on the target disc.

It's also important to point out that the reason BD-RB has to create an alternate prediction method for HEVC is because AVISYNTH doesn't handle HEVC well. The problems stem from the fact that when trying to seek (SelectRangeEvery) with AVISYNTH on an HEVC source you don't seem to land on (or adjust from) i-frames and you get garbage output -- making the method used for AVC prediction (upon which I spent a considerable amount of time) is a non-starter. Part of the purpose of the "test" releases is to figure out a good way to predict without using AVISYNTH. So the new method (for HEVC) uses FFMPEG to pull out sections of the source M2TS and combines them into an M2TS to use as the prediction source.

With all that said... I'm working on trying to make the initial CQM/CRF value more accurate. But it ain't easy... and that's why you don't see CQM/CRF prediction algorithms laying around waiting for someone to pick one up to use.

[jdobbs]

Unless I've missed something in testing, I think the latest version is very close to release for public consumption. Please download and do some testing on this release:

BD Rebuilder v0.61.10 (https://jammernhilftnichts.de/jdobbs/BD-RBV06110.zip)

Summary of changes:- Added support for NVIDIA NVENC encoding.
- Corrected an error that could cause BD-RB
to exit in failure when attempting a size-
correcting second pass in CRF mode while
doing a UHD backup.
- Added code that will update the HDR flags
in the MPLS file for sources in which HDR
was not established until after reencoding
on full backups.
- Fixed an error in which MPEG2 sources may
not make video adjustments detected during
import when reencoding. This could result
in stretched or compressed images.
- Created a workaround for a problem with
converting PAL to NTSC flags during import
which could confuse TSMUXER's recognition
of video resolution.
- Added code to adapt to UHD sources that are
not sized to either 3840(h) or 2160(v).
- Corrected an issue in which video sources
that are an odd size during import might
use the wrong resizing when HEVC encoding
is enabled.
- Fixed a bug in which large audio offsets
detected during import were not being
interpreted correctly.
- Fixed a bug that could cause undersizing
when an AC3 stream is kept intact because
the original is smaller than the selected
reencoder bitrate. This typically only
happens on DVD imports.
- Fixed an error that could result in wrong
aspect ratio on imported sources that are
being resized.
- Corrected an issue in which some command
line settings were not being set when a
non-UHD source is output as V3.
- Added a routine to ensure formatting of
CRF values consistent.
- Updated CQM prediction routines.
- Fixed an issue that can cause the CQM/CRF
sample file to have a zero length when
used in other-than-US regions.
- Modified NVENCC options to eliminate vbrhq
from the command line, as it is targeted
to be deprecated. Replaced by "vbr" and
manually enabling "--multipass 2pass-full"
(the newer equivalent of vbrhq).
- Rewrote the "Bitstream Exception" TSMUXER
error workaround routine so it now uses
a more efficient method -- and better
adjusts audio sync. It also now adjusts
for Dolby Vision exception errors.
- Fixed an issue in which BT709 sources were
not being encoded with proper settings.
- Increased the accepted value of the THREADS
hidden option from 16 to 128. Note: While
128 is accepted for x264 -- realistically
you should never set it that high.
- Added support for HDR10+ A JSON file is
created concurrently with video extraction.
HDR10+ streams are now identified in the
streams list by a "+" next to "HEVC". Note
that "*" indicates Dolby Vision. "*+"=both.
- Changed the ALTERNATE settings so creating
a preset that outputs HEVC to MP4 is now
allowed.
- Updated the included version of MP4BOX to
support HEVC.
- Updated the included versions of X265 to a
newer (v3.2.1) release.
- Other minor corrections and cosmetic fixes.

[SquallMX]

Yes. It needs work -- that's the purpose of releasing a test version, so I can get feedback. But as I said before -- the "static images" you mention AREN'T a problem when encoding for prediction... that is an issue with whatever you are using in playback.


I have to disagree, the prediction file generated by BD-RB is also only 48 frames, here a direct feed from LASTCMD.TXT:

C:\Windows\System32>"D:\Archivos de Programa\BD Rebuilder UHD\tools\ffmpeg.exe" -probesize 100MB -i "C:\TEMP\WORKFILES\00294.AVS.SMPL.m2ts" -frames 48 -an -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | "D:\Archivos de Programa\BD Rebuilder UHD\tools\x265-64.exe" - --preset faster --profile main10 --uhd-bd --repeat-headers --vbv-bufsize 45000 --vbv-maxrate 48000 --hdr --chromaloc 2 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" --max-cll "1000,221" --fps 23.976 --slow-firstpass --pass 1 --sar 1:1 --qpfile "C:\TEMP\WORKFILES\VID_00294.CHP" --keyint 24 --crf 2.86 --y4m --no-strong-intra-smoothing --no-sao --stats "C:\TEMP\WORKFILES\TEMP.265.stats" --output "C:\TEMP\WORKFILES\TEMP.265"
ffmpeg version 3.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Input #0, mpegts, from 'C:\TEMP\WORKFILES\00294.AVS.SMPL.m2ts':
Duration: 00:00:02.00, start: 1.525122, bitrate: 4537470 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: hevc (Main 10) ([36][0][0][0] / 0x0024), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 23.98 tbc
Stream mapping:
Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
[hevc @ 00000207dc1208e0] First slice in a frame missing.
Last message repeated 6 times
[hevc @ 00000207dcd200a0] First slice in a frame missing.
Last message repeated 6 times
[yuv4mpegpipe @ 00000207e22d2020] Warning: generating non standard YUV stream. Mjpegtools will not work.
Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Video: wrapped_avframe, yuv420p10le, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc
Metadata:
encoder : Lavc57.107.100 wrapped_avframe
y4m [info]: 3840x2160 fps 23976/1000 i420p10 sar 1:1 unknown frame count
raw [info]: output file: C:\TEMP\WORKFILES\TEMP.265
x265 [info]: HEVC encoder version 3.2.1+3-b4b2ecac21f6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: uhd-bd: Turning off open GOP
x265 [warning]: uhd-bd: keyframeMin is always 1
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 24 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(34 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 24 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 2 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-2.9 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 45000 / 48000 / 0.900
x265 [info]: tools: rd=2 psy-rd=2.00 early-skip rskip signhide tmvp fast-intra
x265 [info]: tools: lslices=8 deblock stats-write
frame= 48 fps= 13 q=-0.0 Lsize= 1166400kB time=00:00:02.00 bitrate=4772803.0kbits/s dup=1 drop=0 speed=0.532x
video:25kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 4712628.500000%
x265 [info]: frame I: 4, Avg QP:8.74 kb/s: 113388.31
x265 [info]: frame P: 10, Avg QP:8.47 kb/s: 77779.35
x265 [info]: frame B: 34, Avg QP:11.63 kb/s: 42043.62
x265 [info]: Weighted P-Frames: Y:90.0% UV:90.0%
x265 [info]: consecutive B-frames: 35.7% 0.0% 7.1% 0.0% 57.1%

encoded 48 frames in 6.38s (7.53 fps), 55433.96 kb/s, Avg QP:10.73

C:\Windows\System32>

And here the output file from that preddiction pass:

https://mega.nz/file/NXpgmSJb#LPjgIryl4uhVVoKklJ8nZFQrIjcv60bdzKUTdTOTmog

Looks like even FFMPEG is incapable of properly read the "00294.AVS.SMPL.m2ts" file created for CRF prediction, and that is the reason for the ultra low values that results in a oversized file.

With all that said... I'm working on trying to make the initial CQM/CRF value more accurate. But it ain't easy... and that's why you don't see CQM/CRF prediction algorithms laying around waiting for someone to pick one up to use.

Thanks for your hard work, is what makes a difference from lesser quality bloatware (cough, cough, DVDFa... cough, cough).

EDIT: I Think I found the culprit, "-frames 48" removing it from lastcmd.txt creates a proper output file!!!

Looks like FFMPEG is actually capable of properly decoding the prediction file, but for some reason, BD-RB is parsing a incorrect parameter for "-frames" that cut the prediction file to early.

EDIT 2: Still present in 0.61.10 (obviously).

[cartman0208]

Unless I've missed something in testing, I think the latest version is very close to release for public consumption. Please download and do some testing on this release:

BD Rebuilder v0.61.10 (https://jammernhilftnichts.de/jdobbs/BD-RBV06110.zip)


Long list of changes ... thanks a lot for the hard work ... testing ... :)

[jdobbs]

@SquallMX

The "-frames 48" is a bit confusing. I'll have a look at it. If it were taken from the command line that is creating the SAMPLE it would make more sense.

The sample file is created using groups of 48 frames (about 2 seconds each), each starting with an iframe (the start of which is pulled from the CLPI's EP_map table). FFMPEG is run multiple times outputting 48 frames with each iteration giving an approximate 1% of the entire source file (by default, it is adjustable with HIDDENOPTS and it can be a larger percentage sample on smaller files).

Why it is in the command line used to encode the sample makes me think there has to be a bug somewhere. The question is "why is it not happening to me?" I assume the source being encoded is larger than 4800 frames?

Can you send me (or post) your settings (the contents of BDREBUILDER.INI). Maybe something in the settings is triggering the glitch.

[Edit] Never mind. I found it.

It was a mistake in coding and you were absolutely right. No wonder the prediction was so far off. It appears to be left over from a test I was doing to compare encoding 48 frames at a time as opposed to extracting them with FFMPEG beforehand and then encoding the group. Since most of my recent testing has been using NVENCC (the logic flow of which was copied from the X265 routine) -- I guess I just outright failed to switch it back from the test code in the X265 routine.

Thanks for the help in identifying that bug.

I'll put in a fix, test it, and get another version up. I'm also working on improving the prediction algorithm on small streams -- so it will probably be a day or two (at the most).

[jedihyte]

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.

Thanks for the reply. Ya its something I've just had to deal with for several years, but just trying to find out if there were any new developments. BTW, It only happens if it goes through BD-Rebuilder first, as the software player (PowerDVD) plays the original 3D discs fine without artifacts. I know 3D is not a priority and is dying :(, but I'm still a huge 3D fan. Thanks for all the cool BD Rebuilder developments over the years :).

[jdobbs]

Thanks for the reply. Ya its something I've just had to deal with for several years, but just trying to find out if there were any new developments. BTW, It only happens if it goes through BD-Rebuilder first, as the software player (PowerDVD) plays the original 3D discs fine without artifacts. I know 3D is not a priority and is dying :(, but I'm still a huge 3D fan. Thanks for all the cool BD Rebuilder developments over the years :).Sorry I wasn't more help. Maybe someone else in the forum has experienced the same issue and found a solution -- anyone?

[Ch3vr0n]

@jedihyte

Sorry I wasn't more help. Maybe someone else in the forum has experienced the same issue and found a solution -- anyone?

i have asked that before and supposedly using a newer version of FRIM than the one that currently comes with BDRB fixes that issue. I have it downloaded, i just havent had the time to test it. https://www.videohelp.com/software/FRIM

[jdobbs]

@jedihyte



i have asked that before and supposedly using a newer version of FRIM than the one that currently comes with BDRB fixes that issue. I have it downloaded, i just havent had the time to test it. https://www.videohelp.com/software/FRIMI'll download it and test to see if it causes any interface issues.

[meadrocks]

It failed on making alternative output; mp4, x265, auto-aac. version is 61.10


----------------------
[08/06/20] BD Rebuilder v0.61.10
[17:10:20] Source: HOWLS_MOVING_CASTLE_00200
- Input BD size: 32.77 GB
- Approximate total content: [01:59:27.243]
- Windows Version: 6.2 [9200]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MP4 Container, HEVC 1920x1080, Auto-AAC
- Quality: High Quality (Default)
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[17:10:20] PHASE ONE, Encoding
- [17:10:20] Processing: VID_00100 (1 of 3)
- [17:10:20] Extracting A/V streams [VID_00100]
- [17:15:44] Reencoding video [VID_00100]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 17,911 frames
- [17:15:44] Reencoding: VID_00100, Pass 1 of 1
- Analyzing 21.50 23.70 [23.70]
- [17:30:53] Video Encode complete
- [17:30:53] Processing audio tracks
- Track 4352 (eng): Reencoding audio to AAC...
- [17:38:06] Processing: VID_00102 (2 of 3)
- [17:38:06] Extracting A/V streams [VID_00102]
- [17:46:32] Reencoding video [VID_00102]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 147,121 frames
- [17:46:32] Reencoding: VID_00102, Pass 1 of 1
- Analyzing 21.50 21.80 [21.85]
- [20:12:38] Video Encode complete
- [20:12:38] Processing: VID_00103 (3 of 3)
- [20:12:38] Extracting A/V streams [VID_00103]
- [20:13:01] Reencoding video [VID_00103]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 6,810 frames
- [20:13:01] Reencoding: VID_00103, Pass 1 of 1
- Analyzing 21.45 18.50 17.95 17.70 [17.70]
- [20:18:48] Video Encode complete
[20:18:48]PHASE ONE complete
[20:18:48]PHASE TWO - Rebuild Started
- [20:18:48] Building ALTERNATE OUTPUT Structure
- ERROR in attempt to mux (MP4BOX)
[20:19:10] - Failed to REBUILD
-----------------------
[20:19:10] PROCESSING BATCH FILE [2]




[00041]
caption=MP4 Container, HEVC 1920x1080, Auto-AAC
vEncoder=1
vBitrate=2000
vKeyint=Auto
aBitrate=*
aType=1
vFormat=5
cType=5

[MrVideo]

but when I changed your blocking from CODE to QUOTE (so I could get line wrapping and better read the command line) and saw what was actually happening I realized I was zigging when I should have been zagging.
Keep it code wrapped, but manually cut long lines with returns. Especially useful when the included text is really long. Long quotes are very annoying.

[BuddTX]

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. NICE! Thank you!:thanks:

[cartman0208]

More of a feature request:

Is it possible to turn quality up even more?
like:
--preset quality --multipass 2pass-full

I just tried the commandline ... encoding speed drops by another 25% but that wouldn't matter for me ... still around 20x faster than CPU

Or is that already covered by the QUALITY_ULTRA hidden switch?

:thanks:

[jdobbs]

More of a feature request:

Is it possible to turn quality up even more?
like:
--preset quality --multipass 2pass-full

I just tried the commandline ... encoding speed drops by another 25% but that wouldn't matter for me ... still around 20x faster than CPU

Or is that already covered by the QUALITY_ULTRA hidden switch?

:thanks:Funny you should ask. Yes, you can get that with a hidden switch. But I left that one off the non-hidden list purposely.

Note, however: QUALITY_ULTRA doesn't apply to NVENCC, only X264 & X265.

I ran numerous tests on numerous sources using that setting. Even though the encode slowed down significantly (making you think it does more), the SSIM results were worse than the next lower setting (quality, without multipass). All the existing settings position in the quality list were based on SSIM values first and encode speed second.

My results could be wrong... but it would have to be wrong on every source I tried.

If you want, though, you can still use that setting by editing the INI file and changing ENCODE_QUALITY to a value of 4. But I wouldn't recommend it.

Just as an aside: Have you tested the HDR10+ capability I added to v0.61.10? My player doesn't support HDR10+ so I could only do limited testing (header and value checks, etc.).

[jdobbs]

Update:

I'm currently still working on CQM/CRF encode prediction improvements. In testing, I'm finding that maybe my current prediction tables for HEVC/2160p sources using X265 may need to be adjusted. Unfortunately the means encoding multiple sources at every possible CRF value so I can calculate the relationship of each value to all the rest. It's just taking forever to do that at 4-7fps.

I'm also tuning the actual encode routine to prevent some of the anomalies that have been reported.

[jdobbs]

@meadrocks

Can you post the ALTERNATE preset you used for HEVC/MP4 output? I tested it on different sources and it worked for me.

I notice you are using a multipart source. Try it on a single part source and see if that's related to the problem. I'd do it but my system is bogged down doing prediction table encodes.

[meadrocks]

@meadrocks

Can you post the ALTERNATE preset you used for HEVC/MP4 output?


Sorry, where do I find that info?
Do you mean this?
[00041]
caption=MP4 Container, HEVC 1920x1080, Auto-AAC
vEncoder=1
vBitrate=2000
vKeyint=Auto
aBitrate=*
aType=1
vFormat=5
cType=5

[Sharc]

I ran numerous tests on numerous sources using that setting. Even though the encode slowed down significantly (making you think it does more), the SSIM results were worse than the next lower setting (quality, without multipass). All the existing settings position in the quality list were based on SSIM values first and encode speed second.

My results could be wrong... but it would have to be wrong on every source I tried.
I have some doubt whether NVIDIA's 2pass method contributes much to quality in the sense of best match with the original or highest SSIM. They write:
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.
In earlier tests I found that disabling -aq resulted in better SSIM than using it. The explanation is probably that -aq is to some extent a psychovisual optimization which conflicts with PSNR -- and possibly also with SSIM --optimization.
From NVIDIA on Spatial AQ:
Spatial AQ mode adjusts the QP values based on spatial characteristics of the frame. Since the low complexity flat regions are visually more perceptible to quality differences than high complexity detailed regions, extra bits are allocated to flat regions of the frame at the cost of the regions having high spatial detail. Although spatial AQ improves the perceptible visual quality of the encoded video, the required bit redistribution results in PSNR drop in most of the cases. Therefore, during PSNR-based evaluation, this feature should be turned off.
Perhaps we see a similar effect with the 2pass modes?

[cartman0208]

I ran numerous tests on numerous sources using that setting. Even though the encode slowed down significantly (making you think it does more), the SSIM results were worse than the next lower setting (quality, without multipass). All the existing settings position in the quality list were based on SSIM values first and encode speed second.



I have some doubt whether NVIDIA's 2pass method contributes much to quality in the sense of best match with the original or highest SSIM. They write:
Quote:
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.


Well that is surprising ... and I though 2pass gives the ultimate quality ...
Do you see the same on the other quality settings, where 2pass is involved?


Just as an aside: Have you tested the HDR10+ capability I added to v0.61.10? My player doesn't support HDR10+ so I could only do limited testing (header and value checks, etc.).

Actually my player also doesn't support HDR10+ while my TV does :o
I'm still in the process of evaluating players ... (any suggestions?)
I was hoping to get the meta information in an alternate output.

[edit]
Tried an encode of a HDR10+ disk... all fine up to the point where the source resolution (or compression) changes:
---------------------
[08.08.20] BD Rebuilder v0.61.10
[09:59:02] Source: HOBBS_AND_SHAW
- Input BD size: 87,50 GB
- Approximate total content: [04:37:04.228]
- Target BD size: 47,36 GB
- Windows Version: 6.2 [9200]
- Quality: Ultra-High (Extremely Slow), CQM
- Decoding/Frame serving: NVENCC
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[09:59:05] PHASE ONE, Encoding
- [09:59:05] Processing: VID_00165 (1 of 63)
- [09:59:05] Extracting A/V streams [VID_00165]
- [09:59:10] Reencoding video [VID_00165]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 576 frames
- [09:59:10] Performing CQM Prediction...
- Analyzing 18,40 21,55 22,00 [22,08]
- [09:59:32] Encoding using constant quality mode.
- [09:59:51] Video Encode complete
- [09:59:51] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [09:59:51] Multiplexing M2TS
- [09:59:56] Processing: VID_00294 (2 of 63)
- [09:59:56] Extracting A/V streams [VID_00294]
- [10:05:08] Reencoding video [VID_00294]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 195.520 frames
- [10:05:08] Performing CQM Prediction...
- Analyzing 18,90 21,45 21,75 [21,75]
- [10:10:56] Encoding using constant quality mode.
- [11:49:51] Video Encode complete
- [11:49:51] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4353 (deu): Keeping original audio
- [11:49:51] Multiplexing M2TS
- [11:51:52] Processing: VID_00368 (3 of 63)
- [11:51:52] Extracting A/V streams [VID_00368]
- [11:52:10] Reencoding video [VID_00368]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 14.728 frames
- [11:52:10] Performing CQM Prediction...
- Analyzing 20,15 23,20 24,60 24,90 [24,90]
- [11:52:38] Encoding using constant quality mode.
- [12:00:04] Video Encode complete
- [12:00:04] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [12:00:04] Multiplexing M2TS
- [12:00:09] Processing: VID_00369 (4 of 63)
- [12:00:09] Extracting A/V streams [VID_00369]
- [12:00:16] Reencoding video [VID_00369]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 5.241 frames
- [12:00:16] Performing CQM Prediction...
- Analyzing 16,35 [12:00:17] - Failed video encode, aborted


Also tried an alternate output that fails if autocrop is enabled. Without ... went fine, but the MKV output file flickers when played directly on my TV, like the brightness meta info is switched on and off every half a second ...

[Ch3vr0n]

I tried the new FRIM, decode worked, encode process was stuck at , FPS (yes just a comma, that's not a typo) on my 9900k, then just failed on the newer one. Encoding wouldn't even start (after enabling dual GPU in the bios and installing the proper drivers and rebooting). Could be because the newer 1.30 zip contains a whole lot more files than the default 1.27. I just copied over the same 4 files and renamed the new FRIMDecode32.exe etc to FRIMDecode.exe

Tried the default one. Only copied the audio track for some reason. 26GB down to under 3GB for the main title including HD audio, yeah that aint right

oh and that is with the 61.05 version (i'll wait for the newer one until it gets updated with a newer frim)

[jdobbs]

Also tried an alternate output that fails if autocrop is enabled. Without ... went fine, but the MKV output file flickers when played directly on my TV, like the brightness meta info is switched on and off every half a second ...Interesting. That would make sense, since the metadata is inserted into i-frames (about every half second).

[cartman0208]

In the alternate output with intact video there's no such issues ... does that mean the metadata only fits to the original P, B and I-Frame sequence (or at least I-Frame interval)?
I guess, it's pretty hard to synchronize that in a reencode :eek:

[jdobbs]

In the alternate output with intact video there's no such issues ... does that mean the metadata only fits to the original P, B and I-Frame sequence (or at least I-Frame interval)?
I guess, it's pretty hard to synchronize that in a reencode :eek:It should be by scene, and a scene should always start with an i-frame. So my belief is that the sequence within that GOP (P & B frames) shouldn't matter.

In order to make sure the metadata matches the original i-frame positioning, BD-RB grabs the frame numbers of all i-frames in the original and uses them to force i-frames at the same position in the reencode (in the .CHP file).

That takes place for sure when creating a new BD structure. It's possible that I may be losing that when doing ALTERNATE output. It may be affected by the ability to create much longer GOP sequences in ALTERNATE files. For example, in a BD there is a limit as to how long a GOP can be (typically it's every 24 frames for a film source). But in ALTERNATE output you often (very often) see it expanded to 240 frames. That might play havoc with positioning of the metadata (just speculating)

The actual placement of the metadata in the newly encoded stream is done by X265 or NVENCC using a JSON file that was created from the original source.

This is all speculation until I look at the code and do some testing. I'll take a look and see what I can find. Unfortunately I'm no expert on HDR10+ and/or exactly how JSON files are applied. BD-RB uses 3rd party software to create the JSON and X265/NVENCC to apply it.

The downside is that the reason most people use GOP lengths of 240 is for encoding efficiency. If you have to keep the original i-frame positions, that goes out the window. Generally an encoder senses scene changes and inserts an i-frame when it changes -- that makes it even more complex. I believe the .CHP file overrides that, since it explicitly forces i-frames at certain points.

[Edit] Oh, and by the way, the --multipass option does seem to give better SSIM values in all the other modes. It's just in QUALITY mode that I saw that anomaly.

[Edit - again] I just scanned a JSON file, and there seems to be an entry in the file for every frame in the source. That would seem to imply that the scene change information would be kept correctly even if I didn't use the .CHP to force i-frames. Any experts out there want to chime in?

[cartman0208]

That takes place for sure when creating a new BD structure. It's possible that I may be losing that when doing ALTERNATE output. It may be affected by the ability to create much longer GOP sequences in ALTERNATE files. For example, in a BD there is a limit as to how long a GOP can be (typically it's every 24 frames for a film source). But in ALTERNATE output you often (very often) see it expanded to 240 frames. That might play havoc with positioning of the metadata (just speculating)


So just removing vKeyint=Auto from the alternate.txt could solve the problem?
I didn't know what to set and left it on all presets to Auto, since it's usually a good choice :D

[jdobbs]

So just removing vKeyint=Auto from the alternate.txt could solve the problem?
I didn't know what to set and left it on all presets to Auto, since it's usually a good choice :DAfter my last edit comment on my post, I'm not so sure. Since the JSON file contains data on every frame, it implies that the encoder can put a keyframe anywhere it wants -- but it can force one at the point where the metadata changes (a new scene) in the JSON file and add an SEI to the i-frame [keyframe] implementing the new metadata.

So that kinda' puts the theory of the GOP length as the cause as less likely.

[cartman0208]

After my last edit comment on my post, I'm not so sure. Since the JSON file contains data on every frame, it implies that the encoder can put a keyframe anywhere it wants -- but it can force one at the point where the metadata changes (a new scene) in the JSON file and add an SEI to the i-frame [keyframe] implementing the new metadata.

So that kinda' puts the theory of the GOP length as the cause as less likely.

OK, as you said... I had a look at source and output and the Keyframes match .. so that should not be the issue ...
I'll do some more testing on other sources
If that is fruitless, maybe we could join in here (https://forum.doom9.org/showthread.php?t=175947)

[edit]
I ran several encodes with NVEnc ... all the same flickering while playing.
Then I decided to make a SW encode and despite the fact that Mediainfo is almost identical, the SW encoded file with HDR10+ Metadata looked very good on my TV

[Sharc]

[Edit] Oh, and by the way, the --multipass option does seem to give better SSIM values in all the other modes. It's just in QUALITY mode that I saw that anomaly.

I am not aware of a document which explains what the presets or modes actually do in terms of setting or tuning the encoding parameters, and whether presets overwrite possibly conflicting commandline options. Or what is at the end just double stitching.
Maybe I am just missing something.

[meadrocks]

@meadrocks

Can you post the ALTERNATE preset you used for HEVC/MP4 output? I tested it on different sources and it worked for me.

I notice you are using a multipart source. Try it on a single part source and see if that's related to the problem. I'd do it but my system is bogged down doing prediction table encodes.

Watchmen Directors Cut Bluray also has the same problem with the English subtitles, they look correct duration in the source, but come out double length in the mkv. It also fails making a mp4 file. Its a multi part source. I cant find any single part source disks that have this problem.

[jdobbs]

I am not aware of a document which explains what the presets or modes actually do in terms of setting or tuning the encoding parameters, and whether presets overwrite possibly conflicting commandline options. Or what is at the end just double stitching.
Maybe I am just missing something.Neither am I. One of the reasons it took so long to implement NVENC was all the testing I had to do to determine things like which settings actually improved SSIM values (so I could decide which settings would represent the different BD-RB quality presets).

[jdobbs]

OK, as you said... I had a look at source and output and the Keyframes match .. so that should not be the issue ...
I'll do some more testing on other sources
If that is fruitless, maybe we could join in here (https://forum.doom9.org/showthread.php?t=175947)

[edit]
I ran several encodes with NVEnc ... all the same flickering while playing.
Then I decided to make a SW encode and despite the fact that Mediainfo is almost identical, the SW encoded file with HDR10+ Metadata looked very good on my TVBy SW encode, do you mean using "--avsw" in the command line instead of "--avhw"?

Have you tried using --avhw but changing the use of the JSON file to "--dhdr10-info copy"?

[jdobbs]

Watchmen Directors Cut Bluray also has the same problem with the English subtitles, they look correct duration in the source, but come out double length in the mkv. It also fails making a mp4 file. Its a multi part source. I cant find any single part source disks that have this problem.Thanks. I'll look at the code and see how it might be impacted by multi-part sources.

[jdobbs]

Also tried an alternate output that fails if autocrop is enabled. Without ... went fine, but the MKV output file flickers when played directly on my TV, like the brightness meta info is switched on and off every half a second ...I forgot to mention on this one -- if you use AUTOCROP it would force use of an AVS, which in turn causes you to lose HDR. Of course it shouldn't fail, and I'll look at that.

[cartman0208]

By SW encode, do you mean using "--avsw" in the command line instead of "--avhw"?

No ... I switched the encoder from nvencc to x264 & x265


Have you tried using --avhw but changing the use of the JSON file to "--dhdr10-info copy"?

Tried that, no change

I forgot to mention on this one -- if you use AUTOCROP it would force use of an AVS, which in turn causes you to lose HDR. Of course it shouldn't fail, and I'll look at that.

I read in other forums, that crop or resize don't get along with HDR10+, so I'll stick with the original resolution for those cases.

The currently used autocrop version had other issues, as we found out earlier in the thread...

[jdobbs]

I read in other forums, that crop or resize don't get along with HDR10+, so I'll stick with the original resolution for those cases.

The currently used autocrop version had other issues, as we found out earlier in the thread...Yeah, that makes sense. The HDR10+ metadata adjusts for things like the average brightness of the picture, etc., and then when you crop the black portion suddenly it changes the picture dramatically and it's unlikely that the calculated values used in HDR10+ apply anymore.

So... the JSON works with X265, but fails with NVENCC. And if you remove it (replaced by "copy") it still doesn't work... that means it isn't the JSON (or the use of it). It sure sounds like the problem is within NVENCC (or at least the way BD-RB is using it).

Anybody else out there done any testing of HDR10+? Your experiences?

[cartman0208]

Ok, I went and had a look at a competitive product (Staxrip) and guess what ... there's no issues with the file ... my TV shows that HDR10+ is played
Here's the commandline used:
U:\Tools\Staxrip\Apps\Encoders\NVEnc\NVEncC64.exe --avhw --vbrhq 0 --codec h265 --preset performance --profile main10 --level 5.1 --output-depth 10 --max-bitrate 30000 --vbr-quality 0 --aq --aq-temporal --bref-mode each --strict-gop --output-buf 128 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" --dhdr10-info U:\Output\WORKFILES\VID_00685.JSON --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --colorrange auto --max-cll "1000,0" --chromaloc 2 --aud -i U:\Temp\BOHEMIAN_RHAPSODY_temp\BOHEMIAN_RHAPSODY.h265 -o U:\Temp\BOHEMIAN_RHAPSODY_temp\BOHEMIAN_RHAPSODY_temp_out.h265

(I used the JSON that was extracted by BDRB)

Now I have to figure out what causes the issues ... any clues?

[edit]
Here the BDRB Command line
"U:\BD_Rebuilder\tools\nvenc\nvencc.exe" --avhw -i "U:\FULLDISC\BOHEMIAN_RHAPSODY\BDMV\STREAM\00685.m2ts" --codec hevc --preset performance --profile main10 --output-depth 10 --repeat-headers --chromaloc 2 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50) --dhdr10-info "U:\OUTPUT\WORKFILES\VID_00685.JSON" --qp-min 0 --vbr 0 --vbr-quality 25 --aq-temporal --keyfile "U:\OUTPUT\WORKFILES\VID_00685.CHP" --aud --pic-struct --vbv-bufsize 45000 --max-bitrate 48000 --gop-len 48 -o "U:\OUTPUT\WORKFILES\VID_00685.AVS.hevc"

[gonca]

@cartman0208
Can you compare the two command lines to see if there are any differences?

[cartman0208]

@cartman0208
Can you compare the two command lines to see if there are any differences?

Posted above ... some quality differences ... could --strict-gop be the culprit ?

[gonca]

Had some issues getting back on Doom9
Here are the differences between the two command lines, all common switches removed
Don't have HDR10+ capability so you gonna have to test

Staxrip
--vbrhq 0 --level 5.1 --max-bitrate 30000 --vbr-quality 0 --aq --bref-mode each --strict-gop --output-buf 128
--colorrange auto --max-cll "1000,0"

BDRB
--repeat-headers --qp-min 0 --vbr 0 --vbr-quality 25 --keyfile "U:\OUTPUT\WORKFILES\VID_00685.CHP" --pic-struct
--vbv-bufsize 45000 --max-bitrate 48000 --gop-len 48

Use the command line , I would try removing the --keyfile entry and changing --gop-len to 24 on the BDRB line

[jdobbs]

Working on a recent bug report by cartman0208, and guess what... I found a bug that apparently has been there since at least 2012 (see this post (https://forum.doom9.org/showthread.php?p=1596646#post1596646)). That has to be a record for time-from-report-to-fix.

[Edit] Nope. It wasn't a record. I found a reference to that error dating back to 2009! It was a really obscure error that can only happen under very rare certain circumstances and only then if there is secondary video.

[jdobbs]

Ok, I went and had a look at a competitive product (Staxrip) and guess what ... there's no issues with the file ... my TV shows that HDR10+ is played
Here's the commandline used:

(I used the JSON that was extracted by BDRB)

Now I have to figure out what causes the issues ... any clues?

[edit]
Here the BDRB Command line
Posted above ... some quality differences ... could --strict-gop be the culprit ?Had some issues getting back on Doom9
Here are the differences between the two command lines, all common switches removed
Don't have HDR10+ capability so you gonna have to test

Staxrip
--vbrhq 0 --level 5.1 --max-bitrate 30000 --vbr-quality 0 --aq --bref-mode each --strict-gop --output-buf 128
--colorrange auto --max-cll "1000,0"

BDRB
--repeat-headers --qp-min 0 --vbr 0 --vbr-quality 25 --keyfile "U:\OUTPUT\WORKFILES\VID_00685.CHP" --pic-struct
--vbv-bufsize 45000 --max-bitrate 48000 --gop-len 48

Use the command line , I would try removing the --keyfile entry and changing --gop-len to 24 on the BDRB lineInteresting. Please let me know what you find.

[jdobbs]

Its a multi part source. I cant find any single part source disks that have this problem.This turned out to be a TSMUXER issue. I'd updated the version used for 4k adjustments to try and keep up with the improvements. The new one uses a new naming convention when concatenating files.

I hope there aren't more surprises like that.

[meadrocks]

This turned out to be a TSMUXER issue. I'd updated the version used for 4k adjustments to try and keep up with the improvements. The new one uses a new naming convention when concatenating files.

I hope there aren't more surprises like that.

I'll rerun Howls & Watchmen with the next release & give you feedback.

Thanks!

[cartman0208]

Interesting. Please let me know what you find.

OK, after 2 days of testing, gradually removing paramters from the stax-string and then adding the parameters from the BDRB string (which I should have done the other way around, because I found it on the second-to-last parameter :mad:) the cause for the flickering is found ...
If the --pic-struct is removed from the command line string, the file plays fine.

But I also noticed, some scenes are WAY to dark on my TV.
A file with intact video (vFormat=8 in the alternate.txt) on the other hand is bright in the same scenes.
I'll do some more testing to find the cause for that...

[Michi]

Bug on HEVC/V3 BluRays and x264/LAVF frameserving:

[08.12.20] BD Rebuilder v0.61.10
[20:38:07] Source: SONNTAG_IN_NEW_YORK_1963_1080P
- Input BD size: 29,48 GB
- Approximate total content: [01:48:22.412]
- Target BD size: 4,41 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- HEVC/V3 mode for BD disc enabled
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
- Resuming from previously started job.
[20:38:09] PHASE ONE, Encoding
- [20:38:09] Processing: VID_00001 (2 of 4)
- [20:38:09] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00001.meta
- Can't open file: Q:\4K\WORKFILES\VID_00001.AVS.hevc
[20:38:13] - Failed to build structure, aborted
----------------------
[08.12.20] BD Rebuilder v0.61.10
[20:39:11] Source: SONNTAG_IN_NEW_YORK_1963_1080P
- Input BD size: 29,48 GB
- Approximate total content: [01:48:22.412]
- Target BD size: 4,41 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- HEVC/V3 mode for BD disc enabled
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
- Resuming from previously started job.
[20:39:12] PHASE ONE, Encoding
- [20:39:12] Processing: VID_00001 (2 of 4)
- [20:39:12] Multiplexing M2TS
- [20:39:17] Processing: VID_00002 (3 of 4)
- [20:39:17] Extracting A/V streams [VID_00002]
- [20:39:21] Reencoding video [VID_00002]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 557 frames
- Bitrate: 1.424 Kbs
- [20:39:21] Reencoding: VID_00002, Pass 1 of 2
- [20:40:12] Reencoding: VID_00002, Pass 2 of 2
- [20:40:49] Video Encode complete
- [20:40:49] PredictAndEncode() 00053 2809
[20:40:56] - Aborted by user request
----------------------
[08.12.20] BD Rebuilder v0.61.10
[20:40:59] Source: SONNTAG_IN_NEW_YORK_1963_1080P
- Input BD size: 29,48 GB
- Approximate total content: [01:48:22.412]
- Target BD size: 4,41 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- HEVC/V3 mode for BD disc enabled
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
- Resuming from previously started job.
[20:41:01] PHASE ONE, Encoding
- [20:41:01] Processing: VID_00002 (3 of 4)
- [20:41:01] Processing audio tracks
- [20:41:01] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00002.meta
- Can't open file: Q:\4K\WORKFILES\VID_00002.AVS.hevc
[20:41:05] - Failed to build structure, aborted
----------------------
[08.12.20] BD Rebuilder v0.61.10
[20:41:22] Source: SONNTAG_IN_NEW_YORK_1963_1080P
- Input BD size: 29,48 GB
- Approximate total content: [01:48:22.412]
- Target BD size: 4,41 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- HEVC/V3 mode for BD disc enabled
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
- Resuming from previously started job.
[20:41:23] PHASE ONE, Encoding
- [20:41:23] Processing: VID_00002 (3 of 4)
- [20:41:23] Multiplexing M2TS
- [20:41:27] Processing: VID_00003 (4 of 4)
- [20:41:27] Extracting A/V streams [VID_00003]
- [20:41:31] Reencoding video [VID_00003]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23,976fps, 279 frames
- Bitrate: 2.160 Kbs
- [20:41:31] Reencoding: VID_00003, Pass 1 of 2
- [20:42:27] Reencoding: VID_00003, Pass 2 of 2
- [20:43:18] Video Encode complete
- [20:43:18] PredictAndEncode() 00053 2809
[20:43:21] - Aborted by user request
----------------------
[08.12.20] BD Rebuilder v0.61.10
[20:43:30] Source: SONNTAG_IN_NEW_YORK_1963_1080P
- Input BD size: 29,48 GB
- Approximate total content: [01:48:22.412]
- Target BD size: 4,41 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- HEVC/V3 mode for BD disc enabled
- Decoding/Frame serving: X264/LAVF
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=448
- Resuming from previously started job.
[20:43:31] PHASE ONE, Encoding
- [20:43:31] Processing: VID_00003 (4 of 4)
- [20:43:31] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [20:43:32] Multiplexing M2TS
[20:43:35]PHASE ONE complete
[20:43:35]PHASE TWO - Rebuild Started
- [20:43:35] Rebuilding BD file Structure
[20:43:36] - Encode and Rebuild complete
[20:43:36] Writing BD structure to ISO file
- ImgBurn completed successfully
- SONNTAG_IN_NEW_YORK_1963_1080P folder removed.
- WORKFILES folder removed.
[20:43:47] JOB: SONNTAG_IN_NEW_YORK_1963_1080P finished.

The name of the encoded file is false. When I rename the file manually, BDRB works correct.

With directshow no problems.