BD Rebuilder Beta - Bug Reports Only

[jdobbs]

It's been a while since I worked on that section... but if I recall correctly it is because DGDecNV (via DGSource) is used within the version of AVISYNTH required by BD-RB -- and that needs the 32 bit version. Trying to get around that is more work than I think I want to commit to this late in the game. There are too many dependencies (for example, BD-RB creates the script used, and I'm pretty sure there have been changes in format that would make them not work).

[Ch3vr0n]

If it's not too much trouble, could you just look the section when you have a moment. If it's undoable all i'd want to know then if i should use X264's or ffdshows in combo with my strix 4090 for best results. Now obviously it's a holiday period, so i'll check in again in a few days Oh and if there's any flags in my old config file here https://forum.doom9.org/showthread.p...76#post2026476 that are no longer used. As i said, it's been a while

[jdobbs]

I don't understand why it is so important to use the 64 bit version... what does it give you that you don't get in the 32 bit version?

[Emulgator]

DG announced that from 252 on he won't build DGDecNV x32 binaries anymore, so this would leave NV Decoding within BD-RB frozen at version 251.
Given the lack of x32 drivers anyway, and nVidia removing x32 build capabilities, well...
From 252 the higher CUDA processing tweaks come in, these shouldn't be necessarily needed for plain decoding.

As I am happy with pure decoding from 251 I am guessing I wouldn't need anything newer than that with BD-RB, so no biggie for me.
I love perfected and frozen tools, but others may see it differently.

Ah, and as I skim DG's forum he mentioned DGIndexNV 2053 still fitting older GPUs like GeForce 210.
Good to know for compatibility fallbacks, maybe.
Some more dug up from there:

Fri Apr 27, 2018 3:40 pm: 32-bit OS is no longer supported for any GPU in 397.31 (nVidia driver) going forward !
32-bit flow on 64-bit OS seems OK, however.

Mon Dec 04, 2023 4:46 am: DGDecNV build 251:
* Moved to CUDA 11. This drops support for pre-Maxwell cards.

Tue Dec 05, 2023 5:35 am: Our builds (DGIndexNV) are now running with CUDA 11. There is no turning back.
(meaning Maxwell minimum)(2023 11 15 should still be 250 ?)

Wed Dec 13, 2023 4:05 am: Moving to CUDA 11 pretty much also kills Win7 support, even with Maxwell+ GPUs.
The reason is that there is no compatible Win7 nVidia driver that supports CUDA 11. :salute: jpsdr.

Thu Dec 14, 2023 6:42 am: Slipstream for DGDecNV build 251:
* Reverted to CUDA 6.5 as the upgrade to 11.7 caused some Maxwell cards to fail (reason not yet understood).
:salute: jpsdr :salute: CYPHER

[Columbo]

If our 32-bit builds still build and run we could supply them. I don't know if there is any new syntax in 257 that could cause issues for BDRB, however. Would y'all like to try it?

[Emulgator]

I would like to try it.

(I was under the impression that all the DGDenoise, DGSharpen, DGHDRtoSDR, DGTweak, DGLevels, DGTelecide, DGDecimate, DGBob
run on CUDA and that these can not be built as 32-bit anymore because
* Support for Visual Studio 2015 is deprecated in release 11.1; support for Visual Studio 2017 is deprecated in release 12.5 and dropped in release 12.9.
32-bit compilation native and cross-compilation is removed from CUDA 12.0 and later Toolkit. Use the CUDA Toolkit from earlier releases for 32-bit compilation.
CUDA Driver will continue to support running 32-bit application binaries on GeForce GPUs until Ada.
Ada will be the last architecture with driver support for 32-bit applications. Hopper does not support 32-bit applications.
Support for running x86 32-bit applications on x86_64 Windows is limited to use with:
CUDA Driver
CUDA Runtime (cudart)
CUDA Math Library (math.h))

If somebody builds for earlier CUDA, then it might be feasible.

https://stackoverflow.com/questions/...pport-for-cuda

[Columbo]

DGDecNV is still built with CUDA 6.5 on vs 2019, so there's a good chance things will work. Will try a build and report back.

[Columbo]

OK DGIndexNV 32-bit built and runs fine. For DGDecodeNV the 32-bit build configurations were removed. I could recreate them with some effort. Before doing that I'd like a commitment from jdobbs that he would do the needful to ensure that the 32-bit stuff works in BDRB.

[jdobbs]

Originally Posted by Columbo

OK DGIndexNV 32-bit built and runs fine. For DGDecodeNV the 32-bit build configurations were removed. I could recreate them with some effort. Before doing that I'd like a commitment from jdobbs that he would do the needful to ensure that the 32-bit stuff works in BDRB.

Sorry, but I'm not going to commit to something when I have absolutely no idea what the impacts might be.

[Columbo]

That's fine. I won't do anything further then. There are lots of alternative source filters.

[Lathe]

Originally Posted by jdobbs

Sorry, but I'm not going to commit to something when I have absolutely no idea what the impacts might be.

What happened to the daring and adventurous JDobbs that we knew and loved...

[jdobbs]

Originally Posted by Lathe

What happened to the daring and adventurous JDobbs that we knew and loved...

There is a difference between "daring and adventurous" and "stupid".

[Lathe]

Originally Posted by jdobbs

There is a difference between "daring and adventurous" and "stupid".

Being a solid dues paying member of the latter group, I would heartily agree...

[Ch3vr0n]

My main reason is simple. I'd like to use up-to-date stuff as much as possible and didn't want to have bdrb lose support for DG entirely, although that still might happen as i have no control over how you proceed as its your software afterall. But yeah the first paragraph of Emulgator's earlier comment sums it up nicely. Updated functionality for modern gpus. But the "up-to-date" part also impacts the other things bdrb relies on. LAV filters is up to 0.80. 0.65 goes back to april 2015. According to the release notes https://github.com/Nevcairiel/LAVFilters up to then there have been lots of improvements and fixes, avisynth is up to 3.7.5 over 2.57. Obviously the saying goes "if it aint broke, don't fix it", just sort of wondering i guess why you've opted to use sub components that are now a decade old. That's all.

Bdrb itself still works perfectly as expected of course, so please don't get me wrong after being "on hiatus" for a while. Just seeking feedback on if i should stick to dgdecnv or if lav and ffdshow etc can be updated to newer versions safely and i should use that instead?

[Emulgator]

Well, I would consider DG's decoders gold standard from day 1.
If asked nicely he was and is constantly ready to improve and extend.
Running older and newer versions here and never missed a frame while other source filters relying on mother ffmpeg did.

BTW if columbo offers his help why not say thank you to the DG side ? ;-)

[Ch3vr0n]

Me too Emulgator, but in the end it's Jdobbs' decision. As shown above it can still be compiled in 32bit, but understandibly won't get done if jdobbs doesn't want too which is his right. Though to be fair, the only way to know what the consequences would be he's referring to, is to actually do it

[Lathe]

Originally Posted by Ch3vr0n

Me too Emulgator, but in the end it's Jdobbs' decision. As shown above it can still be compiled in 32bit, but understandibly won't get done if jdobbs doesn't want too which is his right. Though to be fair, the only way to know what the consequences would be he's referring to, is to actually do it

You realize of course that he can be bribed...

[meadrocks]

Can BD-RB re-encode a 4K video source? In the Alternate Output config file the highest resolution I see available is 1920x1080.

[jdobbs]

Originally Posted by meadrocks

Can BD-RB re-encode a 4K video source? In the Alternate Output config file the highest resolution I see available is 1920x1080.

If the source is 4k, just choose one of the "NO_RESIZE" options. The only time you need a specific output size is if you are resizing.

[Dudeman007]

Back here again after 2 years, with new problems. Creating 3D Blu-Ray from full-SBS 3D MKV

Problem #1
This is the same problem as before. If The source is HEVC BD Rebuilder fails to mux the files, because it keeps looking for a file named VID_xxxxx.AVS.HEVC, but the re-encoded files have a 264 extension. This was an issue back then, but one of the workarounds was to re-encode the source video to H264 prior to using BD Rebuilder. That no longer works. If it detects a 4K file (~3840 wide), it detects it as a UHD-BD source regardless of CODEC. How do you fix this? Is there a way of preventing BD Rebuilder from detecting the video as UHD?

Problem #2
After the BD Rebuilder would fail to mux the .264 and the MVC files, I used to use TSMuxer to mux the video and audio files and get a 3D Blu-Ray ISO file. My new problem is that the muxed video, while it plays in 3D it has very pronounced artifacting and breakups. The right eye image breaks up badly in blocks as if it's having a problem keeping up with the decoding. If there is very little stuff moving on the screen it's not very noticeable, but once things start moving, it's so bad it's unwatchable.

Here is an example of the left and right frames. Left is clean, right is messed up.






Why is this happening. It is the encode that went bad, the muxer,? I need some help.