BD Rebuilder Beta - Bug Reports Only

[Ch3vr0n]

Quick question as I'll be testing shortly, if I'm just editing /deleting various previews, etc but keeping menus and streams intact without any re-encoding, will the remuxing retain all the Dolby Vision and other original streams?

Dolby vision support is highly experimental at this time

[lithiumus]

Dolby vision support is highly experimental at this time

Let me ask the question differently... if my goal is to only blank previews and warnings and keep all menus and streams untouched (using FORCE_NOENCODE ) could the Backup process avoid Extracting the streams, deciding there is no encoding, and then Multiplexing? If possible, it would save a lot of processing time.

- [00:54:57] Processing: VID_00006 (6 of 78)
- [00:54:57] Extracting A/V streams [VID_00006]
- Extracting video streams [VID_00006]
- Extracting audio/subtitle streams [VID_00006]
- [01:20:14] Reencoding video [VID_00006]
- [01:20:14] Keeping original video (no reencode)
- [01:20:14] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4353 (eng): Keeping original audio
- Track 4354 (spa): Keeping original audio
- Track 4355 (fra): Keeping original audio
- [01:20:14] Multiplexing M2TS
- [02:31:52] Blanking: VID_00007 (7 of 78)

25 mins to Extract all the streams... no reencode 1hr 10 mins to Multiplex them back together. Also reduces the possibility to introduce issues into the steam as Tsmuxer did before.

[cartman0208]

Hey @jdobbs, their may be hope for your software and any other wanting to implement dolby vision etc

https://www.audioholics.com/audio-technologies/dolby-widthdraws-from-restricting-non-native-upmixing-a-win-for-consumers

literally fresh of the press today!

Not sure, what the article in the link has to do with Dolby Vision ... There's only Audio content mentioned... :confused:

[lithiumus]

Was trying to test A Space Odyssey 2001 UHD where I was only blanking some videos and used FORCE_NOENCODE. It errored out with

- [11:01:27] Processing: VID_00058 (11 of 11)
- [11:01:27] Extracting A/V streams [VID_00058]
- [11:28:33] Reencoding video [VID_00058]
- [11:28:33] Keeping original video (no reencode)
- [11:28:33] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4353 (eng): Keeping original audio
- Track 4354 (fra): Keeping original audio
- Track 4355 (deu): Keeping original audio
- Track 4356 (ita): Keeping original audio
- Track 4357 (spa): Keeping original audio
- Track 4358 (spa): Keeping original audio
- Track 4359 (por): Keeping original audio
- Track 4360 (pol): Keeping original audio
- Track 4361 (jpn): Keeping original audio
- Track 4362 (eng): Keeping original audio
- Track 4363 (eng): Keeping original audio
- [11:28:33] Multiplexing M2TS
- [11:56:04] UHD_Correct_M2TS() 00005 8100
[12:02:38]PHASE ONE aborted by user request

A Popup with

"BD Rebuilder experienced an error 8100 [11:56:04]
UHD_Correct_M2TS() 00005 8100"

Showed up. This UHD had Dolby Vision so I wanted to test it out. I tested Assassin's Creed UHD and it had no issues with just blanking but keeping the main movie with no reencode.

[Lowpro]

@lowpro
BDRB has the possibility to add avisynth scripts. Assuming your source is 1920x1080, try
crop(0,120,-0,-120) #1.78 to 2.40
addborders(0,120,0,120) #letterbox (mask) for for blu-ray compliance

(It works in avisynth, I didn't try to include it in BDRB)Thanks. I'll give that a try and yes, I own several movies on Blu-ray (1920x1080) that contain multiple aspect ratios. I'd like to create versions of each where the aspect ratio doesn't change. For example, if the main aspect ratio is 2.39:1 I'd like to mask everything above and below that visible area of the frame during times when the aspect ratio has changed. I don't care what content I lose as a result.

[musiclover]

found a bug in Version 0.60.23 and 0.60.19. In 0.60.04 it works! It is an old BD with VC1, Secondary Video + Audio Source. Here is the log:

[08.29.19] BD Rebuilder v0.60.23
[21:19:55] Source: LAND_OF_THE_DEAD_G51
- Input BD size: 24,34 GB
- Approximate total content: [02:59:01.963]
- Target BD size: 23,63 GB
- Windows Version: 6.2 [9200]
- Auto Quality: Very Good (Very Fast), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[21:19:57] PHASE ONE, Encoding
- [21:19:57] Processing: VID_00009 (1 of 13)
- [21:19:57] Extracting A/V streams [VID_00009]
- [21:24:39] ExtractAudioSubs() 00009 2904
[21:25:27] - Failed to retrieve audio, aborted
----------------------
[08.29.19] BD Rebuilder v0.60.19
[21:28:35] Source: LAND_OF_THE_DEAD_G51
- Input BD size: 24,34 GB
- Approximate total content: [02:59:01.963]
- Target BD size: 23,63 GB
- Windows Version: 6.2 [9200]
- Auto Quality: Very Good (Very Fast), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[21:28:39] PHASE ONE, Encoding
- [21:28:39] Processing: VID_00009 (1 of 13)
- [21:28:39] Extracting A/V streams [VID_00009]
- [21:32:09] ExtractAudioSubs() 00009 2904
[21:32:24] - Failed to retrieve audio, aborted
----------------------
[08.29.19] BD Rebuilder v0.60.04
[21:33:24] Source: LAND_OF_THE_DEAD_G51
- Input BD size: 24,34 GB
- Approximate total content: [02:59:01.963]
- Target BD size: 23,63 GB
- Windows Version: 6.2 [9200]
- Auto Quality: Good (Very Fast), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[21:33:26] PHASE ONE, Encoding
- [21:33:26] Processing: VID_00009 (1 of 13)
- [21:33:26] Extracting A/V streams [VID_00009]
- [21:36:58] Reencoding video [VID_00009]
- [21:36:58] Reencoding secondary video [TRK_02]
- [21:44:20] Keeping original video (no reencode)
- [21:44:20] Processing audio tracks
- Track 4353 (eng): Keeping original audio
- Track 4355 (deu): Keeping original audio
- Track 4357 (eng): Keeping original audio
- Track 6656 (eng): Keeping original audio
- [21:44:20] Multiplexing M2TS
- [21:50:38] Processing: VID_00010 (2 of 13)
- [21:50:38] Extracting A/V streams [VID_00010]
- [21:50:48] Reencoding video [VID_00010]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 23.255 frames
- Bitrate: 4.734 Kbs
- [21:50:48] Reencoding: VID_00010, Pass 1 of 1
- [21:52:35] Video Encode complete
- [21:52:35] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:52:35] Multiplexing M2TS
- [21:52:42] Processing: VID_00057 (3 of 13)
- [21:52:42] Extracting A/V streams [VID_00057]
- [21:52:49] Reencoding video [VID_00057]
- [21:52:49] Keeping original video (no reencode)
- [21:52:49] Processing audio tracks
- [21:52:49] Multiplexing M2TS
- [21:52:55] Processing: VID_00080 (4 of 13)
- [21:52:55] Extracting A/V streams [VID_00080]
- [21:53:01] Reencoding video [VID_00080]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 1.465 frames
- Bitrate: 9.225 Kbs
- [21:53:01] Reencoding: VID_00080, Pass 1 of 1
- [21:53:35] Video Encode complete
- [21:53:35] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:53:35] Multiplexing M2TS
- [21:53:42] Processing: VID_00081 (5 of 13)
- [21:53:42] Extracting A/V streams [VID_00081]
- [21:53:48] Reencoding video [VID_00081]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 1.560 frames
- Bitrate: 11.707 Kbs
- [21:53:48] Reencoding: VID_00081, Pass 1 of 1
- [21:54:27] Video Encode complete
- [21:54:27] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:54:27] Multiplexing M2TS
- [21:54:33] Processing: VID_00082 (6 of 13)
- [21:54:33] Extracting A/V streams [VID_00082]
- [21:54:39] Reencoding video [VID_00082]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 1.296 frames
- Bitrate: 8.387 Kbs
- [21:54:39] Reencoding: VID_00082, Pass 1 of 1
- [21:55:09] Video Encode complete
- [21:55:09] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:55:09] Multiplexing M2TS
- [21:55:15] Processing: VID_00084 (7 of 13)
- [21:55:15] Extracting A/V streams [VID_00084]
- [21:55:21] Reencoding video [VID_00084]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23,976fps, 1.978 frames
- Bitrate: 9.566 Kbs
- [21:55:21] Reencoding: VID_00084, Pass 1 of 1
- [21:56:11] Video Encode complete
- [21:56:11] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:56:11] Multiplexing M2TS
- [21:56:18] Processing: VID_00113 (8 of 13)
- [21:56:18] Extracting A/V streams [VID_00113]
- [21:56:28] Reencoding video [VID_00113]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 13.615 frames
- Bitrate: 4.784 Kbs
- [21:56:28] Reencoding: VID_00113, Pass 1 of 1
- [21:57:38] Video Encode complete
- [21:57:38] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:57:38] Multiplexing M2TS
- [21:57:44] Processing: VID_00114 (9 of 13)
- [21:57:44] Extracting A/V streams [VID_00114]
- [21:57:53] Reencoding video [VID_00114]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 17.114 frames
- Bitrate: 4.726 Kbs
- [21:57:53] Reencoding: VID_00114, Pass 1 of 1
- [21:59:13] Video Encode complete
- [21:59:13] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [21:59:13] Multiplexing M2TS
- [21:59:22] Processing: VID_00115 (10 of 13)
- [21:59:22] Extracting A/V streams [VID_00115]
- [21:59:34] Reencoding video [VID_00115]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 23.373 frames
- Bitrate: 4.736 Kbs
- [21:59:34] Reencoding: VID_00115, Pass 1 of 1
- [22:01:52] Video Encode complete
- [22:01:52] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [22:01:52] Multiplexing M2TS
- [22:02:02] Processing: VID_00116 (11 of 13)
- [22:02:02] Extracting A/V streams [VID_00116]
- [22:02:15] Reencoding video [VID_00116]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 5.280 frames
- Bitrate: 4.802 Kbs
- [22:02:15] Reencoding: VID_00116, Pass 1 of 1
- [22:02:42] Video Encode complete
- [22:02:42] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [22:02:42] Multiplexing M2TS
- [22:02:47] Processing: VID_00117 (12 of 13)
- [22:02:47] Extracting A/V streams [VID_00117]
- [22:02:55] Reencoding video [VID_00117]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29,970fps, 14.250 frames
- Bitrate: 4.804 Kbs
- [22:02:55] Reencoding: VID_00117, Pass 1 of 1
- [22:04:05] Video Encode complete
- [22:04:05] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [22:04:05] Multiplexing M2TS
- [22:04:11] Processing: VID_00120 (13 of 13)
- [22:04:11] Extracting A/V streams [VID_00120]
- [22:04:23] Reencoding video [VID_00120]
- Source Video: MPEG-2, 720x480, Hybrid
- Rate/Length: 29,970fps, 5.940 frames
- Bitrate: 4.837 Kbs
- [22:04:23] Reencoding: VID_00120, Pass 1 of 1
- [22:04:51] Video Encode complete
- [22:04:51] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [22:04:51] Multiplexing M2TS
[22:04:56]PHASE ONE complete
[22:04:56]PHASE TWO - Rebuild Started
- [22:04:56] Rebuilding BD file Structure
[22:05:07] - Encode and Rebuild complete
[22:05:07] JOB: LAND_OF_THE_DEAD_G51 finished.

I can confirm this report. Had the same issue with Paul McCartney's "The Space Within US". Also a bluray with VC1.
BDRB v0.60.04 handled it perfectly where newer versions (v0.60.17 - v0.60.19 - v0.60.22 - v0.60.23) did not.
I noticed that as soon as the message "Converting field-based or secondary stream" is shown v0.60.04 goes on to do its work and the newer versions stop working with the error 'ExtractAudioSubs() 00009 2904'.

[Mike-uk]

ok so after reading a post about how DGDecNV is better ( is this the case still ?? ) was using lav 0.74 fine ( i know i know but it seems to work :p ), so decided to give DGDecNV a try, but it fails straight away with failed video encode on all vids that i successfully did with lav ??

[09/05/19] BD Rebuilder v0.60.23
[11:14:57] Source: A day out
- Input BD size: 44.52 GB
- Approximate total content: [04:35:52.073]
- Target BD size: 22.95 GB
- Windows Version: 6.2 [9200]
- Quality: Highest (Very Slow), Two Pass
- Decoding/Frame serving: DGDecNV
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[11:14:58] PHASE ONE, Encoding
- [11:14:58] Processing: VID_00102 (1 of 72)
- [11:14:58] Extracting A/V streams [VID_00102]
- [11:15:08] Reencoding video [VID_00102]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 6,887 frames
- Bitrate: 4,265 Kbs
- [11:15:08] Reencoding: VID_00102, Pass 1 of 2
- Encode failed. Aborting.
- BD-Rebuilder v0.60.23
- Windows Version: 6.2 [9200]
- Working Path Free Space: 637.09GB
- AVISYNTH Version: 2.6.0.6, Ok
- LAVFILTERS: Ok
- X264: Ok
- X265: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[11:15:10] - Failed video encode, aborted


OK SOLVED

AHHHH you need to buy a licence :( to use it

so is DGDecNV better than LAV ??

[zamengo]

I got this error with John Wick Chapter 3, this is a Lionsgate disc.

[09/05/19] BD Rebuilder v0.60.23
[05:42:48] Source: JOHN_WICK_CHAPTER_3_PARABELLUM
- Input BD size: 87,40 GB
- Approximate total content: [03:45:16.669]
- Target BD size: 22,95 GB
- Windows Version: 6.2 [9200]
- Auto Quality: Very Good (Very Fast), ABR
- Decoding/Frame serving: FFMPEG
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[05:42:48] PHASE ONE, Encoding
- [05:42:48] Processing: VID_00008 (1 of 16)
- [05:42:48] Extracting A/V streams [VID_00008]
- [05:42:52] Reencoding video [VID_00008]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 529 frames
- Bitrate: 9.553 Kbs
- [05:42:52] Reencoding: VID_00008, Pass 1 of 1
- [05:44:36] Video Encode complete
- [05:44:36] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [05:44:36] Multiplexing M2TS
- [05:44:41] Processing: VID_00278 (2 of 16)
- [05:44:41] Extracting A/V streams [VID_00278]
- [05:48:19] Reencoding video [VID_00278]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 188.123 frames
- Bitrate: 9.429 Kbs
- [05:48:19] Reencoding: VID_00278, Pass 1 of 1
- [17:35:29] Video Encode complete
- [17:35:29] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4353 (eng): Keeping original audio
- Track 4354 (eng): Keeping original audio
- Track 4355 (spa): Keeping original audio
- Track 4356 (fra): Keeping original audio
- [17:35:29] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00278.meta
- Bitstream exception Unknown exception. It does not have to be! Please contact application support team for more information.
[17:35:38] - Failed to build structure, aborted

[MrVideo]

ok so after reading a post about how DGDecNV is better ( is this the case still ?? ).
AHHHH you need to buy a licence :( to use it
First off, it doesn't encode. DGDecNV, along with your compatible nVidia graphics card, is a frame server. The decoded frames are passed to your encoder (x264 by default). Normally the frames are passed via AVISynth, which BDRB uses.

DGDecNV doesn't decode, the nVidia graphics card does that. DGDecNV provides information about each frame to the encoder.

[Lathe]

Just a quickie... (the only kind I know) Is the newer version of BDRB running the very latest x264 version? I remember there were speed/CPU utilization issues where JD was using older x264 versions listed as L-264. Is that still the case or does BDRB run the newest version right 'out of the box', so to speak, and are there still continuing speed issues? Seems like it has been quite a while since we have undressed that issue :)

[Mike-uk]

First off, it doesn't encode. DGDecNV, along with your compatible nVidia graphics card, is a frame server. The decoded frames are passed to your encoder (x264 by default). Normally the frames are passed via AVISynth, which BDRB uses.

DGDecNV doesn't decode, the Nvidia graphics card does that. DGDecNV provides information about each frame to the encoder.

Hi MrVideo thanks for the reply, im sort of aware its a frame server and doesn't play a part in the quality of the encoding, but read its very accurate?

question is, is it better than lav, DirectShow or frim, does it better serve at not getting out of sync audio ?? why would someone pay to use DGDecNV ? ( other than the person who coded it is charging ) i use madvr so tend to have lav updated

[Ch3vr0n]

because last time i checked (and i could be wrong) DS doesn't support hw acc decoding dgdecnv does. Frim only comes into play (for me at least) when doing 3D backups and the current version included with bdrb does support hw acc decoding and encoding, but it results in severe glitching. Havent tried 1.30 yet that supposedly doesn't have that problem.

[sneaker_ger]

You can use hardware decoding via DirectShow as well (e.g. LAV Video DXVA2 copy-back). DGDecNV has the reputation of being more reliabe, mainly in regard to being "frame accurate (https://forum.doom9.org/showthread.php?t=176231)".

[gonca]

First off, it doesn't encode. DGDecNV, along with your compatible nVidia graphics card, is a frame server. The decoded frames are passed to your encoder (x264 by default). Normally the frames are passed via AVISynth, which BDRB uses.

DGDecNV doesn't decode, the nVidia graphics card does that. DGDecNV provides information about each frame to the encoder.
From
http://rationalqm.us/dgdecnv/dgdecnv.html
DGDecNV is a decoder/frameserver

[videoh]

so is DGDecNV better than LAV ?? Usually. And maybe sometimes LAV is better. There is no silver bullet. Your use cases rule.

MrVideo is quite right. DGDecNV has always used CUVID/NVDec for decoding. That is not a secret. It's a strength.

And just think, for a small donation you enter the inner circle!

[MrVideo]

From
http://rationalqm.us/dgdecnv/dgdecnv.html
DGDecNV is a decoder/frameserver
It is only a decoder in that it works with your nVidia card to do the actual decoding. It physically does not decode video. If it did, it wouldn't need you to have a nVidia card. It outputs a file that contains information about each frame of the video (DGdecodeNV.dll) and puts that info into a *.dgi file. Then the dgsource portion of the suite uses that file to frameserve each frame of the nVideo decoded video thru whatever program you are using to handle the encoding. In my case, it is AVISynth in conjunction with x264. BDRB also uses AVISynth/x264.

[gonca]

If it didn't use the video card then it it wouldn't be a GPU accelerated frame server
Yes it relies on the raw data from NVDec, but try using that as is
It takes the "frame information" and decodes it so your avisynth can use it
According to you then, the actual decoders are Intel, AMD, and NVidia.
Yet, Avisynth/x264/x265 can't use that decoded video without something else decoding it
Please respond with your usual word games, because I'm out

[MrVideo]

If it didn't use the video card then it it wouldn't be a GPU accelerated frame server
Yes it relies on the raw data from NVDec, but try using that as is
It takes the "frame information" and decodes it so your avisynth can use it
No. Only the nVidia card does the decoding. The DG program looks at each decoded (raw) video frame to provide details about that video frame.

[videoh]

No. Only the nVidia card does the decoding. The DG program looks at each decoded (raw) video frame to provide details about that video frame. Every HW accelerated application uses the GPU for video decoding (leaving aside QuickSync stuff), and so does DGDecNV. Hair splitting over terminology is for losers. And DGDecNV (DGIndexNV + DGDecodeNV) does a heck of a lot more than your incoherent "provide details about that video frame", not to mention the other DG CUDA filters working with DGDecNV. That's why over 15000 users have donated! Not one of them has complained that I call the application a decoder/frame server, until now. ;)

[MrVideo]

Hair splitting over terminology is for losers.
I guess I'm a loser. I've been called worse. :D

[busch42]

I keep getting and error with the new version 06023, ExtractAudioSubs() 00009 2904
[08:19:11] - Failed to retrieve audio, aborted

[musiclover]

I keep getting and error with the new version 06023, ExtractAudioSubs() 00009 2904
[08:19:11] - Failed to retrieve audio, aborted

And your source file is probably VC1. That issue is rapported before. See #28749 and #28757
You need to go back to BDRB v0.60.04

[jdobbs]

And your source file is probably VC1. That issue is rapported before. See #28749 and #28757
You need to go back to BDRB v0.60.04I'm glad he brought it up again, though. I somehow passed right over that issue (even though I edited one of those posts to put in CODE blocks!)

Now I need to dig thought discs and find a VC1 example to debug it...

[jdobbs]

found a bug in Version 0.60.23 and 0.60.19. In 0.60.04 it works! It is an old BD with VC1, Secondary Video + Audio Source.I keep getting and error with the new version 06023, ExtractAudioSubs() 00009 2904
[08:19:11] - Failed to retrieve audio, abortedAnd your source file is probably VC1. That issue is rapported before. See #28749 and #28757
You need to go back to BDRB v0.60.04Ok, I fixed it. It was a stupid mistake I made with some new code I'd added for UHD support. Used the wrong variable as an array index. Doh!!! The fix will be included in the next release.

[busch42]

Thanks, I'm doing Game of Thrones season 7 disk 1 and now it's working with version 0.60.04 and I should have known that since I had to use this version on the other seasons.

[cartman0208]

I try to do my UHD encodes with 50GB target size. To fit on a 50GB media, the result should be around 45 GB.
But only one of my encodes so far matches that size, all the others are way smaller ...
Source -> encoded
79GB -> 45GB
59GB -> 38GB
74GB -> 43GB this one should be fine
55GB -> 34GB
59GB -> 34GB
88GB -> 37GB
55GB -> 31GB

I keep 2 non-reencoded audio tracks.
I never noticed that much spread on my FHD encodes with 25GB target size.
Did I mess up my settings?

[84lion]

I try to do my UHD encodes with 50GB target size. To fit on a 50GB media, the result should be around 45 GB.
But only one of my encodes so far matches that size, all the others are way smaller ...
Source -> encoded
79GB -> 45GB
59GB -> 38GB
74GB -> 43GB this one should be fine
55GB -> 34GB
59GB -> 34GB
88GB -> 37GB
55GB -> 31GB

I keep 2 non-reencoded audio tracks.
I never noticed that much spread on my FHD encodes with 25GB target size.
Did I mess up my settings?

I have noticed this as well. Are you using the "very good" setting or the "high quality" (default) setting? I have done most UHD encodes on "very good" but the few I've done on "high quality" seem to be closer in size to the 50 GB number.

[cartman0208]

... I have done most UHD encodes on "very good" but the few I've done on "high quality" seem to be closer in size to the 50 GB number.

I did all my encodes with the "high quality (default)" setting.

[AmigaFuture]

[11:15:10] - Failed video encode, aborted

OK, SOLVED!

AHHHH, you need to buy a licence :( to use it.

Is DGDecNV better than LAV ??

If you're editing and not rerendering use LAV. If you're reencoding I think DGDecNV is faster. Haha, yeah, a license is helpful. HA! You didn't read the Docs.

[zamengo]

Ok, I fixed it. It was a stupid mistake I made with some new code I'd added for UHD support. Used the wrong variable as an array index. Doh!!! The fix will be included in the next release.

I found another bug / mistake.

When import MKV HEVC 2160p, BD Rebuilder recognize as a HEVC 1080p.

After encode and UHD Adjust has done, this keep HEVC 1080p, but the file is 2160p, only the disc structure has this info.

[jdobbs]

I found another bug / mistake.

When import MKV HEVC 2160p, BD Rebuilder recognize as a HEVC 1080p.

After encode and UHD Adjust has done, this keep HEVC 1080p, but the file is 2160p, only the disc structure has this info.I've imported multiple 2160p sources and haven't experienced what you describe. Are you sure you are letting it complete? When TSMUXER creates the structure it marks it as 1080p (because it doesn't support 2160p directly) -- but BD-RB corrects that after the TSMUXER session is completed.

[zamengo]

I've imported multiple 2160p sources and haven't experienced what you describe. Are you sure you are letting it complete? When TSMUXER creates the structure it marks it as 1080p (because it doesn't support 2160p directly) -- but BD-RB corrects that after the TSMUXER session is completed.

yep, after encode this keep with 1080p info, when open the encoded disc in bdrebuilder.

Another stranger things that happened, but with a legit 1080p, the CPU use is around 20%, this is a bug ?

I already see this low cpu use in the past, but i don't know how I fix this :(

[jdobbs]

yep, after encode this keep with 1080p info, when open the encoded disc in bdrebuilder.

Another stranger things that happened, but with a legit 1080p, the CPU use is around 20%, this is a bug ?

I already see this low cpu use in the past, but i don't know how I fix this :(That's very unusual with newer versions of X264... but trying looking up MULTIPROCESS in HIDDENOPTS.txt.

[Mike-uk]

hi, anyone know how i can run avisynth+ and avisynth260 at the same time, i use avs2dvd with avisynth+ for its MT capabilities but when i install avisynth260 avs2dvd only sees 260 and not the MT version,

thanks
Mike

[MrVideo]

I'm not sure you can because of the same-named DLL file that is installed.

[LowDead]

hi, anyone know how i can run avisynth+ and avisynth260 at the same time, i use avs2dvd with avisynth+ for its MT capabilities but when i install avisynth260 avs2dvd only sees 260 and not the MT version,

thanks
Mike

Not really the right thread for this, but check out Universal Avisynth Installer (https://forum.doom9.org/showthread.php?p=1720988#post1720988)

I think its very useful.

//LD

[jdobbs]

I have updated the first post of this thread with a link to the most recent version of BD-RB (v0.60.25). Changes for this release:- Corrected an error in which BD-RB was using
X264 (incorrectly) to reencode UHD sources
when CRF mode was selected, causing rebuild
to fail.
- Added code to better adjust predicted sizing
for sources that use audio bitrates that are
poorly sized due to muxing overhead. This
helps prevent oversizing that causes output
to exceed targets and not fit on media.
- Fixed a bug in which some odd imports may
not reflect necessary resizing in the MPLS
file of the pseudo-BD structure.
- Fixed an error in which FORCE_STEREO_RATE
hidden option was used in prediction calcs
even in multichannel output, causing over-
sizing and target miss.
- Fixed a bug that causes "ExtractAudioSubs()
00009 2904" error when working with VC1
sources.
- Added code to adjust for non-standard frame
rates on imported files.
- Corrected "UHD_Correct_M2TS() 00005 8100"
error that could occur during muxing of
UHD sources.
- Fixed an issue in which imported UHD video
could be flagged incorrectly as 1080p in
the CLPI file.
- Other minor corrections and cosmetic fixes.

[Sharc]

- Added code to adjust for non-standard frame
rates on imported files.

This seems to have solved the problem which I reported here (https://forum.doom9.org/showpost.php?p=1859500&postcount=28205). Thank you :)

Would the (automatic) rotation of .mp4 sources shot in portrait orientation be something for a future release?

[jdobbs]

This seems to have solved the problem which I reported here (https://forum.doom9.org/showpost.php?p=1859500&postcount=28205). Thank you :)

Would the (automatic) rotation of .mp4 sources shot in portrait orientation be something for a future release?I'll look at it and see how hard it would be to do. Since most portrait videos are meant to stay that way, though, wouldn't it make more sense to frame them into a landscape backdrop but keep them displayed as portrait?

[Sharc]

Since most portrait videos are meant to stay that way, though, wouldn't it make more sense to frame them into a landscape backdrop but keep them displayed as portrait?
Exactly.
Currently the encoded picture is displayed as 1920x1080 landscape, 90 degrees rotated. MediaInfo reports the rotation of the original .mp4 source as 90 degrees. As I understand it, the 1920x1080 picture should be rotated back by 90 degrees (1080x1920), then resized to 608x1080 and finally pillarboxed to 1920x1080 for blu-ray compliance.
Perhaps there is a simpler method?

[zamengo]

I got a new error on Spider Man


[09/23/19] BD Rebuilder v0.60.23
[06:25:23] Source: SPIDER_MAN_FAR_FROM_HOME
- Input BD size: 71,98 GB
- Approximate total content: [02:34:25.963]
- Target BD size: 22,95 GB
- Windows Version: 6.2 [9200]
- Auto Quality: Very Good (Very Fast), ABR
- Decoding/Frame serving: FFMPEG
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[06:25:23] PHASE ONE, Encoding
- [06:25:23] Processing: VID_00001 (1 of 4)
- [06:25:23] Extracting A/V streams [VID_00001]
- [06:28:47] Reencoding video [VID_00001]
- Source Video: HEVC, 3840x2160
- Rate/Length: 23,976fps, 186.144 frames
- Bitrate: 15.931 Kbs
- [06:28:47] Reencoding: VID_00001, Pass 1 of 1
- [20:10:33] Video Encode complete
- [20:10:33] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4353 (eng): Keeping original audio
- Track 4360 (por): Keeping original audio
- [20:10:33] Multiplexing M2TS
- [20:11:45] UHD_Correct_M2TS() 00005 8100
[21:22:24]PHASE ONE aborted by user request

[lithiumus]

I got a new error on Spider Man

Try the new version... this error should be fixed. I'm also testing with another release.

[prologic]

I use bdrebuilder these days , to take out unwanted streams , I have been testing the new UHD versions , in its beta stages ..the latest one BD Rebuilder v0.60.23 worked fine on my test , were others failed ..
I picked a movie at random ..Pirates of the carribean - dead mans tales .. took all the unwanted audios, and subtitles out , and it worked fine .. my next test will be blancing out extras .Good work !!!
I also use it very regulary on normal bluray ..

[Michi]

The UHD mpls Bug isn't fixed with the new version. All reauthored UHD discs are some minute shorter than the original disc.

[jdobbs]

The UHD mpls Bug isn't fixed with the new version. All reauthored UHD discs are some minute shorter than the original disc.Can you give me a better explanation of what you are reporting? It isn't making sense to me.

Is is a full backup? Movie-Only? I haven't seen anything like what you are describing in my backups.

[Michi]

Can you give me a better explanation of what you are reporting? It isn't making sense to me.

Is is a full backup? Movie-Only? I haven't seen anything like what you are describing in my backups.

The bug is on all full backups. The m2ts file has the regular length, but the mpls-file is shorter.


https://forum.doom9.org/showthread.php?p=1882347#post1882347

This bug is on all full backups. Since I found this bug, I stopped all testing.

[jdobbs]

The bug is on all full backups. The m2ts file has the regular length, but the mpls-file is shorter.


https://forum.doom9.org/showthread.php?p=1882347#post1882347

This bug is on all full backups. Since I found this bug, I stopped all testing.That's the part that throws me. The original MPLS is used in a full backup. The only MPLS changes would be if the encode involved resolution change or if it was reencoded to a different format (like VC-1 to AVC). The chapter information, etc, is never changed. I'll go back through the code to make sure... but I'm pretty confident that's the case.

Also, no one else is reporting this issue. I think if the end of the movie was missing people would notice/report it???

A movie-only backup would be different. BD-RB generates the MPLS from scratch in that case.

Are you doing any external editing or modifications?

[Michi]

I made over twenty UHD full backups and all backups have this bug.

[jdobbs]

I made over twenty UHD full backups and all backups have this bug.You never answered my question.

Are you doing any external editing or modifications? Are you involving any software at all beyond BD Rebuilder?

Have you looked at the original discs in the same way (by looking at the MPLS time and the M2TS time)?

[Edit] I'm also not sure you should trust what TSMUXER reports when it opens an MPLS. I tried a disc with a 2 (or so) hour movie that are reported as 16 hours long -- and has a filename glitch in the reporting. I looked at another where there is a discrepancy of a minute between the time of the M2TS and the MPLS. Both of those are original discs, not processed ones! That's on the first two discs I opened... it wouldn't surprise me if they all show different times.

[Edit again] Yeah. It has to be the reporting. I just tried a third disc and the M2TS report says it is a minute longer than the MPLS also. Again this was an original disc, not one processed by BD-RB. My guess is TSMUXER is just guessing at the times or giving an estimate when it reports.

[Edit] ...and a fourth. So far the MPLS and M2TS lengths haven't matched on a single disc I've tried.

[Michi]

I'm not doing any external editing or modifications.

Here the mpls-file from the main film. The first is the reauthored BD-Rebuilder and the second is the original file.

My Sony Player stops the film at the end of the reauthored mpls-file.