BD Rebuilder Beta - Bug Reports Only

[ggtop]

Originally Posted by jdobbs

I'll look at it and see how that is possible. But, I'm surprised -- as BD-RB has a preference for Directshow. There are things that force Directshow when you have "Use X264's..." selected -- but none that go the other way.

Hi jdobbs,
just tested on another machine. Same there. X264L-64.exe is called. I even started with a new ini file.
Using a playlist containing a 30 min extra (because demuxing is quicker) everything is normal. x264.exe is called and feeded with the AVS script.
Seems it only happens with the main movie playlist... Movie is Sherlock Holmes 2 by the way. The one with Robert Downey Jr.
Looking into some INF files I still had and they are all saying "USE_LAVF=0". Is that correct? (only a guess)

ggtop

[jdobbs]

Originally Posted by ggtop

Hi jdobbs,
just tested on another machine. Same there. X264L-64.exe is called. I even started with a new ini file.
Using a playlist containing a 30 min extra (because demuxing is quicker) everything is normal. x264.exe is called and feeded with the AVS script.
Seems it only happens with the main movie playlist... Movie is Sherlock Holmes 2 by the way. The one with Robert Downey Jr.
Looking into some INF files I still had and they are all saying "USE_LAVF=0". Is that correct? (only a guess)

ggtop

It must have something to do with my adding X264L to correct for the slow decoding of the newer versions. I'll see what I can find.

[ggtop]

Originally Posted by jdobbs

It must have something to do with my adding X264L to correct for the slow decoding of the newer versions. I'll see what I can find.

I see this in version 0.50.20 changelog:

December 5th, 2016 - v0.50.20
 - Updated code so that X264/LAVF can also be used for ALTERNATE encoding. In previous releases ALTERNATE encoding forced the use of DirectshowSource (for resizing).
Now X264's internal resizing filters are used when X264/LAVF is selected. This reduces BD-RB's dependence on LAVF or FFDSHOW.

From my ini file: DECODER=0

ggtop

[LoneSwan]

Quickplay has option for "finding" the original BD menu background video and using that instead of a static image. My question is: Why not let user select the correct *.m2ts file to use from the BDMV\Stream folder?

I frequently run into this issue when trying to re-author BD's, especially problem ones like Mockingjay 2(Hunger Games). This BD uses playlist obfuscation, which leads to multiple issues using BD Rebuilder. Using TSMuxer I create a new BD structure by selecting the correct playlist and de-selecting unwanted audio and subtitle streams. It is good to go at this point: under 25GB so will fit on a single disc. However, it would be really nice to add an opening "Quickplay" menu using the background video from the original disc.

Read earlier posts: there is a problem where BD Rebuilder will always re-encode. This is such a case. Would be great if BD Rebuilder had option to really _FORCE No Encode_ for testing purposes. I tried multiple tricks attempting to get BD Rebuilder to "find" that background video. I know the correct *.m2ts and the *.mpls; can make a guess on the matching *.clpi... but my knowledge on BD structure is minimal.

Is there a way to copy the necessary files to the structure(BDMV folder) to help BD Rebuilder "find" the menu background video... if implementing a direct choice under Quickplay options is too troublesome?

I have found numerous work-arounds to create nice Quickplay menus, and would like to add a "tutorial" post to this thread to share tips. The _FORCE No Encode_ option (for testing) and (somehow?) choose original background video for Quickplay menu, would be a big help.

Thanks JD for your continued efforts!!!

Walker (in Virginia's Northern Neck)

[ggtop]

Hi LoneSwan,

from Hiddenopts.txt:

This file contains descriptions of settings that can be added to the BDREBUILDER.INI file (via the Config/INI 
editor) that may change the handling of files during conversion, reencode, and rebuild.

[Options]
FORCE_NOENCODE=n	n = 0/1 - if set to 1, BD-RB will always use original video (sizing will not be checked)

You could also set your Output size to BD-50 which would prevent re-encoding as long as your output type is compliant.

BTW I had no problems with MockingJay 2. Prerequisite is of course it is decrypted properly.

ggtop

[MrVideo]

v0.50.20

Bug selecting BLANK.AC3 from BDRB install directory.

When I go down the path: C:\Program Files (x86)\BD.... to select the BLANK.AC3 file, all that shows up is: C:\Program Files

The rest of the path is missing. To get around the issue, I just copied the AC3 file into the same directory as the background menu.

Unrelated issue:

What is the darkest black that can be used for the active color? I discovered that selecting 0x000000, results in default green being used. I'm down to 0x202020. Thinking about it, you need some margin to be able to subdue it when the menu item isn't active, hence the not liking 0x000000.

[jdobbs]

Originally Posted by MrVideo

v0.50.20

Bug selecting BLANK.AC3 from BDRB install directory.

When I go down the path: C:\Program Files (x86)\BD.... to select the BLANK.AC3 file, all that shows up is: C:\Program Files

The rest of the path is missing. To get around the issue, I just copied the AC3 file into the same directory as the background menu.

Unrelated issue:

What is the darkest black that can be used for the active color? I discovered that selecting 0x000000, results in default green being used. I'm down to 0x202020. Thinking about it, you need some margin to be able to subdue it when the menu item isn't active, hence the not liking 0x000000.

I don't think I understand your first question. But, as the instructions say, I don't recommend installing in the "C:\Program Files" folder -- because of virtualization.

The MENU_ACTIVE_COLOR value can be anything greater than zero. So 0x010101 would be the darkest evenly distributed color. Of course you could use 0x000001 -- but that's not even. The reason is because 0 (which is the same as no setting) indicates the default color.

[MrVideo]

Originally Posted by jdobbs

I don't think I understand your first question. But, as the instructions say, I don't recommend installing in the "C:\Program Files" folder -- because of virtualization.

I'm on XP-64. I do not believe that virtualization exists. Even if it does, I have no issues with other programs finding things via that path.

The long path to the BLANK.AC3 file has "(x86)" as part of it. I'm guessing that your program doesn't like the part of the path containing the ( ) characters, therefore truncating the rest of the path from those characters onward. Just a WAG.

Try installing to C:\jdobbs (x86)\BDRebuilder\... and then see if you can get the program to point to the BLANK.AC3 file that is in that path.

The MENU_ACTIVE_COLOR value can be anything greater than zero. So 0x010101 would be the darkest evenly distributed color. Of course you could use 0x000001 -- but that's not even. The reason is because 0 (which is the same as no setting) indicates the default color.

Who would guess that a legal color would indicate no color.
To me, MENU_ACTIVE_COLOR="" or MENU_ACTIVE_COLOR= is equal to no setting. Blame it on my Linux scripting programming where a variable such as this is not binary True/False (1/0), so anything would be a value.

IIRC, I did try 0x010101 and the text was white.

[jdobbs]

I'm on XP-64. I do not believe that virtualization exists. Even if it does, I have no issues with other programs finding things via that path.

The problem with virtualization is that BD-RB uses an INI path in the same path as the executable. The O/S may virtualize any writes to the INI -- and programmatic changes are physically written to a different (hidden) path. So you could, for example, go into the INI file and attempt to make a change -- and it won't take effect because the real INI is somewhere else. This is one of those things Microsoft introduced starting with Vista that is nothing more than a headache. They are trying to make it more secure -- but it really doesn't.

The solution is for me to change my code to use the registry instead of an INI -- but I just don't feel like putting that much effort into it.

[MrVideo]

OK, so I do not have virtualization. Even if I did, it has nothing to do with this problem. I think you may be misunderstanding the issue.

Install BDRB into the normal M$ location on a 64-bit system, where BDRB will end up in C:\Program Files (x86). Start BDRB. Then do Settings->Import/Quick-Play Settings. Now browse (audio) to the location of the installed BLANK.AC3 audio file. Select the BLANK.AC3 file and then click on Open. The path shown will now only be C:\Program Files. All of this before anything is ever attempted to be written to any INI file. Again, I believe that BDRB doesn't like any path with ( ) characters.

I agree with not putting this stuff in the registry. Makes it very difficult to look thru the parameters.

[jdobbs]

Well... actually it does have something to do with the problem. If you'd followed the instructions you wouldn't be in that folder and you wouldn't be having that problem.

Also, I just tried browsing from within that folder while choosing the .AC3 file for the menu, and had no issues. Are you sure you have privileges?

[MrVideo]

Originally Posted by jdobbs

Well... actually it does have something to do with the problem. If you'd followed the instructions you wouldn't be in that folder and you wouldn't be having that problem.

I seriously doubt that virtualization is an issue, since XP-64 doesn't have it. IMHO, no user should be forced to not use the default M$ install path. While virtualization is an issue for M$ after my version, users do not have to directly edit the INI file, since you have full editing of the INI file in the program.

Also, I just tried browsing from within that folder while choosing the .AC3 file for the menu, and had no issues. Are you sure you have privileges?

I am the only user on my systems, having full admin rights. Never an issue installing files, or access to anything, anywhere on the system.

So, I did some more testing. I copied the blankclip directory, and its contents to the same path you searched. No problem with that path. So, I copied BLANK.AC3 to the BD_Rebuilder and Tools directories. There was no problem when searching those two locations. The path it does not like is: C:\Program Files (x86)\BD_Rebuilder\Tools\blankclip\BLANK.AC3. So, I copied BLANK.AC3 into the dvdauthor directory and that path is not liked either.

Lastly I created a C:\jdobbs\jdobbs path and copied the BD_Rebuilder directory, and its contents into it. Searching that longer path worked.

I have no clue as to why BDRB doesn't like any directory under Tools when the path is C:\Program Files (x86)\BD_Rebuilder\Tools.

[gonca]

When I was on win7 I had no problems with Program Files (x86)
Just tried on my win10 machine and I can navigate to the blank.ac3 file just fine. In fact I moved BD_RB to Program Files (x86) temporarily to test

[jdobbs]

Originally Posted by MrVideo

I seriously doubt that virtualization is an issue, since XP-64 doesn't have it. IMHO, no user should be forced to not use the default M$ install path. While virtualization is an issue for M$ after my version, users do not have to directly edit the INI file, since you have full editing of the INI file in the program.

I am the only user on my systems, having full admin rights. Never an issue installing files, or access to anything, anywhere on the system.

So, I did some more testing. I copied the blankclip directory, and its contents to the same path you searched. No problem with that path. So, I copied BLANK.AC3 to the BD_Rebuilder and Tools directories. There was no problem when searching those two locations. The path it does not like is: C:\Program Files (x86)\BD_Rebuilder\Tools\blankclip\BLANK.AC3. So, I copied BLANK.AC3 into the dvdauthor directory and that path is not liked either.

Lastly I created a C:\jdobbs\jdobbs path and copied the BD_Rebuilder directory, and its contents into it. Searching that longer path worked.

I have no clue as to why BDRB doesn't like any directory under Tools when the path is C:\Program Files (x86)\BD_Rebuilder\Tools.

Ok. I see it now. The value is actually being collected and stored correctly, but, because of it's length it is wrapping to another line that can't be seen in that text window. I'm not sure whether there is anything I can do about that, but I'll try. It's a Microsoft control that I'm just referencing. Interesting, as it has a "Wrap" attribute that I have turned off.

[MrVideo]

I was thinking that length had something to do with it, but not the length of characters. Why? Because in the menu background result box, the numbers of characters is larger than the available space and the characters to the right are just truncated. No wrapping. Then again, there are no spaces in that line in which the line can be cut to wrap.

I just did a test with the menu background in that I was able to change a "-" to a space and sure enough, it wrapped.

The bug might be with M$ if it has a no-wrap attribute and you have it enabled, but it wraps anyway. If it is still bad with Win10, it has been around for a very long time.

Can you make that dialog box user resizable so that a user can make it wider, allowing for the text to fit and not wrap?

[Lathe]

I might have mentioned this a while back, I don't remember, but is it possible to be able to use more characters in the titles of the Quick Play menu? Many times I use it to put the Xtras, and usually the titles of each of the xtras is cut off (looks like about maybe 36 characters total including spaces) Any chance of being able to have longer titles in the Quick Play menu. They currently only take up about 1/2 the length of the screen.

Thanks!

[jdobbs]

Originally Posted by Lathe

I might have mentioned this a while back, I don't remember, but is it possible to be able to use more characters in the titles of the Quick Play menu? Many times I use it to put the Xtras, and usually the titles of each of the xtras is cut off (looks like about maybe 36 characters total including spaces) Any chance of being able to have longer titles in the Quick Play menu. They currently only take up about 1/2 the length of the screen.

Thanks!

The number of allowed characters is variable. It is calculated based upon the font, the graphic width of the text to be displayed, and the size of the screen area dedicated to each title. So there really isn't a way to simply add characters. The actual space allocated to each title is a lot more complicated -- based upon the number of titles and the number of columns needed, and I'm not willing, at the moment, to go through all that again. There are a lot of variables.

What is possible is that I could add a hidden option that reduces the font size by some specified amount. For example, if you set a value of .75, the size of the font would be reduced to 3/4 of the default. It would give you more horizontal space. It may not be exact, since most fonts don't use fixed spacing. But it would make it more controllable. The downside is that when you reduce the font size, both the vertical and horizontal size is affected.

[Lathe]

Originally Posted by jdobbs

The number of allowed characters is variable. It is calculated based upon the font, the graphic width of the text to be displayed, and the size of the screen area dedicated to each title. So there really isn't a way to simply add characters. The actual space allocated to each title is a lot more complicated -- based upon the number of titles and the number of columns needed, and I'm not willing, at the moment, to go through all that again. There are a lot of variables.

What is possible is that I could add a hidden option that reduces the font size by some specified amount. For example, if you set a value of .75, the size of the font would be reduced to 3/4 of the default. It would give you more horizontal space. It may not be exact, since most fonts don't use fixed spacing. But it would make it more controllable. The downside is that when you reduce the font size, both the vertical and horizontal size is affected.

Thanks JD! No, don't sweat it; for stuff like this, I truly do not know what exactly goes into it, so it's good you explain that it is indeed more involved than one may think. If the hidden option is no big deal for you, then sure, that would be interesting to try. In the meantime (like my posts and EVERYTHING else) this will give me an opportunity to refine my 'skills' at succinctness and brevity..

Now, to expand upon this...

[MrVideo]

I have some MKV H.264 videos that I want to put on a couple of discs. First, I wasn't sure if the H.264 video would play in the Blu-ray player, untouched, so I created a test disc with a single video. When I put the disc into the player, the video was fine, but there wasn't any audio. Going back to the computer, I looked at the M2TS file, and sure enough, no audio. Then I noticed that when the BDRB job finished, it only showed the video file. No explanation as to why BDRB rejected the audio stream.

The audio is E-AC3 5.1. MediaInfo and txMuxer both claim it is 640 kbps, while VideoReDo says it is 1280 kbps. E-AC3 is a legit Blu-ray audio format, so why would BDRB reject it?

I can supply a 30 sec segment of the video for downloading from my server.

[Lathe]

Originally Posted by MrVideo

I have some MKV H.264 videos that I want to put on a couple of discs. First, I wasn't sure if the H.264 video would play in the Blu-ray player, untouched, so I created a test disc with a single video. When I put the disc into the player, the video was fine, but there wasn't any audio. Going back to the computer, I looked at the M2TS file, and sure enough, no audio. Then I noticed that when the BDRB job finished, it only showed the video file. No explanation as to why BDRB rejected the audio stream.

The audio is E-AC3 5.1. MediaInfo and txMuxer both claim it is 640 kbps, while VideoReDo says it is 1280 kbps. E-AC3 is a legit Blu-ray audio format, so why would BDRB reject it?

I can supply a 30 sec segment of the video for downloading from my server.

Yeah, my OPPO will not play MKV files with E-AC3 audio (Dolby+) I always have to use UsEac3to to covert it to either AC3 or DTS depending on the bit rate. But, I have no idea why BDRB won't process it; I don't think I've ever run a file through it with that codec...