BD Rebuilder Beta - Bug Reports Only

[owine]

Strange, only thing I can think of is an issue with my rip, could it be that?

Here is my log file.

[04:44:13] BD Rebuilder v0.39.03 (beta)
- Source: SPOOFS_DOCUMENTARIES
- Input BD size: 39.63 GB
- Approximate total content: [07:13:48.868]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Auto Quality: High Quality (Default), Two Pass
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[04:44:14] PHASE ONE, Encoding
- [04:44:14] Processing: VID_00321 (1 of 10)
- [04:44:14] Extracting A/V streams [VID_00321]
- [04:44:19] Reencoding video [VID_00321]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 29.970fps, 240 frames
- [04:44:20] Reencoding: VID_00321, Pass 1 of 1
- [04:44:25] Video Encode complete
- [04:44:25] Reencoding audio tracks (if req'd)
- [04:44:25] Multiplexing M2TS
- [04:44:28] Processing: VID_00320 (2 of 10)
- [04:44:28] Extracting A/V streams [VID_00320]
- [04:44:34] Reencoding video [VID_00320]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 29.970fps, 990 frames
- [04:44:34] Reencoding: VID_00320, Pass 1 of 1
- [04:44:55] Video Encode complete
- [04:44:55] Reencoding audio tracks (if req'd)
- [04:44:55] Multiplexing M2TS
- [04:44:59] Processing: VID_00314 (3 of 10)
- [04:44:59] Extracting A/V streams [VID_00314]
- [04:47:20] Reencoding video [VID_00314]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 47,275 frames
- Convert: 1920x1080, 29.970fps, 47,275 frames
- [04:47:20] Reencoding: VID_00314, Pass 1 of 1
- [05:13:38] Video Encode complete
- [05:13:38] Reencoding audio tracks (if req'd)
- [05:13:38] Multiplexing M2TS
- [05:16:13] Processing: VID_00310 (4 of 10)
- [05:16:13] Extracting A/V streams [VID_00310]
- [05:20:23] Reencoding video [VID_00310]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 88,167 frames
- Convert: 1920x1080, 29.970fps, 88,167 frames
- [05:20:23] Reencoding: VID_00310, Pass 1 of 1
- [06:21:49] Video Encode complete
- [06:21:49] Reencoding audio tracks (if req'd)
- [06:21:49] Multiplexing M2TS
- [06:29:41] Processing: VID_00312 (5 of 10)
- [06:29:41] Extracting A/V streams [VID_00312]
- [06:33:54] Reencoding video [VID_00312]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 86,485 frames
- Convert: 1920x1080, 29.970fps, 86,485 frames
- [06:33:55] Reencoding: VID_00312, Pass 1 of 1
- [07:33:30] Video Encode complete
- [07:33:30] Reencoding audio tracks (if req'd)
- [07:33:30] Multiplexing M2TS
- [07:40:34] Processing: VID_00313 (6 of 10)
- [07:40:34] Extracting A/V streams [VID_00313]
- [07:44:53] Reencoding video [VID_00313]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 86,530 frames
- Convert: 1920x1080, 29.970fps, 86,530 frames
- [07:44:53] Reencoding: VID_00313, Pass 1 of 1
- [08:42:23] Video Encode complete
- [08:42:23] Reencoding audio tracks (if req'd)
- [08:42:23] Multiplexing M2TS
- [08:48:28] Processing: VID_00315 (7 of 10)
- [08:48:28] Extracting A/V streams [VID_00315]
- [08:53:50] Reencoding video [VID_00315]
- Source Video: MPEG-2, 720x480
- Rate/Length: 29.970fps, 151,065 frames
- Convert: 1920x1080, 29.970fps, 151,065 frames
- [08:53:51] Reencoding: VID_00315, Pass 1 of 1
- [10:51:35] Video Encode complete
- [10:51:35] Reencoding audio tracks (if req'd)
- [10:51:38] Multiplexing M2TS
- [11:05:19] Processing: VID_00317 (8 of 10)
- [11:05:19] Extracting A/V streams [VID_00317]
- [11:10:38] Reencoding video [VID_00317]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 29.970fps, 45,313 frames
- [11:10:38] Reencoding: VID_00317, Pass 1 of 1
- [11:47:49] Video Encode complete
- [11:47:49] Reencoding audio tracks (if req'd)
- [11:47:49] Multiplexing M2TS
- [11:50:30] Processing: VID_00316 (9 of 10)
- [11:50:30] Extracting A/V streams [VID_00316]
- [11:59:59] Reencoding video [VID_00316]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 65,611 frames
- [11:59:59] Reencoding: VID_00316, Pass 1 of 1
- [12:50:36] Video Encode complete
- [12:50:36] Reencoding audio tracks (if req'd)
- [12:50:37] Multiplexing M2TS
- [12:55:57] Processing: VID_00319 (10 of 10)
- [12:55:57] Extracting A/V streams [VID_00319]
- [13:16:31] Reencoding video [VID_00319]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 29.970fps, 174,396 frames
- [13:16:32] Reencoding: VID_00319, Pass 1 of 1
- [15:52:43] Video Encode complete
- [15:52:43] Reencoding audio tracks (if req'd)
- [15:52:44] Multiplexing M2TS
[16:02:17]PHASE ONE complete
[16:02:17]PHASE TWO - Rebuild Started
- [16:02:17] Rebuilding BD file Structure
[16:03:13] - Encode and Rebuild complete
[16:03:13] Writing BD structure to ISO file
- ImgBurn completed successfully
- SPOOFS_DOCUMENTARIES folder removed.
- WORKFILES folder removed.
[17:10:13]JOB: SPOOFS_DOCUMENTARIES finished.

And INI file:

[Status]
LABEL=SPOOFS_DOCUMENTARIES
VERSION=v0.39.03 (beta)
SOURCE_SIZE=42548155168
SOURCE_VIDEO_SIZE=41928966144
TARGET_SIZE=24641536000
REDUCTION=.57292962801654
RESIZE_1080=0
AUDIO_TO_KEEP=eng;
KEEP_HD_AUDIO=-1
SUBS_TO_KEEP=eng;
BACKUP_MODE=0
MOVIEONLY_TYPE=0
USE_LAVF=-1
QUICK=1
ENCODE_STEP=0
COMPLETED=10
REBUILD_COMPLETE=1
[00321]
AUDIO=1
PGS=100000000000000
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=10961528
NSTART=27000000
NEND=27360000
NSIZE=331776
FLINK=0
MLINK=0
[00320]
AUDIO=1
PGS=100000000000000
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=15495391
NSTART=27000000
NEND=28486080
NSIZE=10278912
FLINK=0
MLINK=0
[00314]
AUDIO=1
PGS=100000000000000
SCAN=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=915597353
NSTART=27000000
NEND=97983360
NSIZE=1784008704
FLINK=0
MLINK=0
[00310]
AUDIO=1
PGS=100000000000000
SCAN=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=1634056167
NSTART=27000000
NEND=159382080
NSIZE=6924963840
FLINK=0
MLINK=0
[00312]
AUDIO=1
PGS=100000000000000
SCAN=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=1650157011
NSTART=27000000
NEND=156856320
NSIZE=5921243136
FLINK=0
MLINK=0
[00313]
AUDIO=1
PGS=100000000000000
SCAN=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=1667683488
NSTART=27000000
NEND=156924000
NSIZE=4731654144
FLINK=0
MLINK=0
[00315]
AUDIO=1
PGS=100000000000000
SCAN=0
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=2143802419
NSTART=27000000
NEND=253823040
NSIZE=10439804928
FLINK=0
MLINK=0
[00317]
AUDIO=1
PGS=100000000000000
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=2330285678
NSTART=27000000
NEND=95037120
NSIZE=2675668992
FLINK=0
MLINK=0
[00316]
AUDIO=1
PGS=100000000000000
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=-2666232579
NSTART=27000000
NEND=150143040
NSIZE=5156247552
FLINK=0
MLINK=0
[00319]
AUDIO=1
PGS=100000000000000
VIDEO2=0
V2MBRATE=0
M2TS_TARGET=-13621855008
NSTART=27000000
NEND=288855360
NSIZE=9655013376
FLINK=0
MLINK=0

[Capsbackup]

Strange, only thing I can think of is an issue with my rip, could it be that?

Here is my log file.


What is the problem? Based on your log, it appears to have completed successfully! :confused:

[owine]

What is the problem? Based on your log, it appears to have completed successfully! :confused:

Problem is two posts above. The resulting ISO is 45+GB.

[setarip_old]

@owine

Have you played this .ISO image file - to see if you somehow doubled it, or combined it with another set of files?

[owine]

@owine

Have you played this .ISO image file - to see if you somehow doubled it, or combined it with another set of files?

Trying it right now. This is the fourth time I have run this disc with the same result every time.

[greslogo]

Can I use BDR to create standard DVD's (not BD) from BD's.

I could swear I could do this before but can't for the life of me, remember how. Selecting BD-5 generates a file format that is BD not DVD, it seems.

[jdobbs]

Can I use BDR to create standard DVD's (not BD) from BD's.

I could swear I could do this before but can't for the life of me, remember how. Selecting BD-5 generates a file format that is BD not DVD, it seems. Yes. Look under movie-only alternate output.

[Ch3vr0n]

If you're in a region using the PAL standard, there is also the option to assume PAL in the setup dialogue

[greslogo]

Yes. Look under movie-only alternate output.

Arggg. Thanks. I knew it was somewhere just couldn't remember where.

[owine]

@owine

Have you played this .ISO image file - to see if you somehow doubled it, or combined it with another set of files?

Plays and appears normal. No double sets of files or anything.

[woodman]

I have just done a dvd 5 (film only) backup from Blu-ray to dvd using BD Rebuilder V39.03, the picture and sound are great but the aspect ratio is wrong, there should be black bars at top and bottom instead the picture is stretched to fill the screen. I have used the 720x480/576 alternate output. Can I change the settings in HCenc to remedy this or is it automatic. I can alter this in VLC player but not on my TV or standalone player. Thanks.

[17:11:49] BD Rebuilder v0.39.03 (beta)
- Source: R.O.T.P.O.T.A
- Input BD size: 10.42 GB
- Approximate total content: [01:44:56.448]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: DVD-5, 720x480/576, AC3 Audio
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[17:11:49] PHASE ONE, Encoding
- [17:11:49] Processing: VID_00000 (1 of 1)
- [17:11:49] Extracting A/V streams [VID_00000]
- [17:15:35] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 150,964 frames
- Bitrate: 5,287 Kbs
- [17:15:35] Reencoding: VID_00000
- [20:56:45] Video Encode complete
- [20:56:45] Reencoding audio tracks (if req'd)
- [20:59:40] Multiplexing M2TS
[20:59:40]PHASE ONE complete
[20:59:40]PHASE TWO - Rebuild Started
- [20:59:40] Rebuilding stream 00000 [1 of 1]
- [20:59:40] Building ALTERNATE OUTPUT Structure
- [21:02:28] Starting MPLEX.
- [21:06:14] Building DVD File Structure.
[21:12:22] - Encode and Rebuild complete
[21:12:23]JOB: R.O.T.P.O.T.A finished.

[jdobbs]

Any changes to make to HCEnc would be overwritten by BD-RB. What disc is it? I can't imagine how the aspect could be incorrectly encoded. Can you post the contents of AVS file and the encoding command (LASTCMD.TXT)? Are you positive it isn't VLC Player that is the issue?

What disc is this? Is it an original disc? The size of the input looks suspect and if it an original disc the problem is likely that the source isn't a legal BD size.

[drmih]

It looks like the new POTA film which hasn't been released yet but there are some blu-ray rips around.

[setarip_old]

@jdobbs

"R.O.T.P.O.T.A." = "Rise of the Planet of the Apes".

Per Amazon U.S., Blu-ray release date WILL BE December 13, 2011...

[colinhunt]

The Change-Up on 0.39.03 scared up a bug. The disc contains two versions of the movie, but instead of branching, they've included both movies as separate files on the disc. Shorter version of the movie is a single 19.9GB file while the unrated one is a single 21.4 GB file. Total size of the disc is 46.1GB.

I tried to create a Full Backup to BD25 while blanking out the longer version of the movie. Regardless, BD-RB began to encode the shorter version at a very low bitrate (7-something mbps), as if trying to fit both movie files in the BD25 backup.

[jdobbs]

The Change-Up on 0.39.03 scared up a bug. The disc contains two versions of the movie, but instead of branching, they've included both movies as separate files on the disc. Shorter version of the movie is a single 19.9GB file while the unrated one is a single 21.4 GB file. Total size of the disc is 46.1GB.

I tried to create a Full Backup to BD25 while blanking out the longer version of the movie. Regardless, BD-RB began to encode the shorter version at a very low bitrate (7-something mbps), as if trying to fit both movie files in the BD25 backup. I don't see a bug in what you're describing.

Turn off "Quick Encode for Extras" if that is on.

[colinhunt]

I don't see a bug in what you're describing.
Hmm. Perhaps I've misunderstood how blanking works. I thought it would replace the larger movie file with a tiny m2ts placeholder, allowing the rest of the data be backupped with only minimal compression.

Turn off "Quick Encode for Extras" it that is on.
Not enabled; never used it once.

[jdobbs]

Hmm. Perhaps I've misunderstood how blanking works. I thought it would replace the larger movie file with a tiny m2ts placeholder, allowing the rest of the data be backupped with only minimal compression.


Not enabled; never used it once. It's too large to be replaced automatically. Logically someone might want to keep both versions of the movie. But you can do it manually with the editing feature.

[colinhunt]

It's too large to be replaced automatically. Logically someone might want to keep both versions of the movie. But you can do it manually with the editing feature.
I thought putting BD-RB into Edit Mode and selecting "Blank this Item" from the pop-up menu was exactly that. If not, I've obviously missed something. Could you elaborate, please?

Oh, I see: I forgot to mention in my original post that I used the Edit Mode and blanked the larger movie manually. I don't use Auto-blanking.

[Chuckwagon]

It's too large to be replaced automatically. Logically someone might want to keep both versions of the movie. But you can do it manually with the editing feature.

I thought putting BD-RB into Edit Mode and selecting "Blank this Item" from the pop-up menu was exactly that. If not, I've obviously missed something. Could you elaborate, please?

Oh, I see: I forgot to mention in my original post that I used the Edit Mode and blanked the larger movie manually. I don't use Auto-blanking.

I wonder if perhaps the estimation of how large the input will be, and therefore how much compression will be needed, is being done when the auto blanking takes place but isn't updating as manual changes are made. Maybe this is why a few folks were having unexpectedly large or small resulting encodes. If they added titles back into an encode that auto blank had removed, the size estimate would not take that extra info into account and the encode would be too large, or if they removed titles that auto blank had left in, then there is an over-estimation of the needed compression and they end up with a smaller than expected result. Just a thought.

Colin, could you set the blank threshold time limit to be just longer than the shorter version of the film so that auto blank removes it and you don't need to do any manual edits? If that gets you a rebuild that doesn't try to compress the remaining stream, then try a rebuild again but add the auto blanked shorter movie back in and see if you get an oversized result. That might highlight if it's the manual edits that are not getting tallied for the input size.

[jdobbs]

I thought putting BD-RB into Edit Mode and selecting "Blank this Item" from the pop-up menu was exactly that. If not, I've obviously missed something. Could you elaborate, please?

Oh, I see: I forgot to mention in my original post that I used the Edit Mode and blanked the larger movie manually. I don't use Auto-blanking. What disc is it? It's a lot easier to test and comment if I'm not in the dark.

[colinhunt]

What disc is it? It's a lot easier to test and comment if I'm not in the dark.
The Change-Up (Universal).

[jdobbs]

Hah! I read that wrong in your first post. I thought you meant "the change up in v0.38.2"... :)

[ken7795]

I am having trouble encoding and burning the original Cars Blu-ray disc. Please help me if you can.

[12:56:52] BD Rebuilder v0.39.02 (beta)
- Source: CARS_USA
- Input BD size: 38.52 GB
- Approximate total content: [04:11:41.852]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7600]
- Auto Quality: Good (Very Fast), ABR
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
- Resuming from previously started job.
[12:56:57] PHASE ONE, Encoding
- [12:56:57] Processing: VID_00060 (30 of 34)
- [12:56:57] Reencoding video [VID_00060]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 167,736 frames
- Bitrate: 8,057 Kbs
- [12:56:57] Reencoding: VID_00060, Pass 1 of 1
- [13:59:06] Video Encode complete
- [13:59:06] Reencoding audio tracks (if req'd)
- [13:59:06] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00060.meta
- Pes packet len too large ( >100Mb). Bad stream or invalid codec speciffed.
[14:03:00] - Failed to build structure, aborted

[JJB]

I am having trouble encoding and burning the original Cars Blu-ray disc. Please help me if you can.

[12:56:52] BD Rebuilder v0.39.02 (beta)
- Source: CARS_USA
- Input BD size: 38.52 GB
- Approximate total content: [04:11:41.852]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7600]
- Auto Quality: Good (Very Fast), ABR
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
- Resuming from previously started job.
[12:56:57] PHASE ONE, Encoding
- [12:56:57] Processing: VID_00060 (30 of 34)
- [12:56:57] Reencoding video [VID_00060]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 167,736 frames
- Bitrate: 8,057 Kbs
- [12:56:57] Reencoding: VID_00060, Pass 1 of 1
- [13:59:06] Video Encode complete
- [13:59:06] Reencoding audio tracks (if req'd)
- [13:59:06] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00060.meta
- Pes packet len too large ( >100Mb). Bad stream or invalid codec speciffed.
[14:03:00] - Failed to build structure, aborted

I used the search tool for this forum and it universally indicates a bad rip. Re-rip and give it another go.

[ken7795]

That's the thing - this is the second time that I tried to rip the disc using AnyDVD and got the same result. Any thoughts?

Thank you sincerely in advance for your help!

[JJB]

That's the thing - this is the second time that I tried to rip the disc using AnyDVD and got the same result. Any thoughts?

Thank you sincerely in advance for your help!

Might be just a bad disc. Swap it for a new one. Cars has been riped and burned to death so I suspect it has nothing to do BDRB.

[jdobbs]

"Cars" is one of my regular test discs. The only thing really unique about it is the large multi-part LPCM audio track -- which is the reason I have it on my "test list". It looks like you're attempting to keep the HD intact -- I'll do a couple of tests to see if anything has changed --you never know --but it's probably a bad rip or corrupt source. We'll see.

[ken7795]

Thank you for your help. For what it's worth, I was now successful after having limited the audio to only 1 track for English. Nonetheless, I would like to copy the disc in it's entirety if possible including the Commentary.

[jdobbs]

Thank you for your help. For what it's worth, I was now successful after having limited the audio to only 1 track for English. Nonetheless, I would like to copy the disc in it's entirety if possible including the Commentary. It sounds as if one of the audio tracks is illegally formatted.

[Dreamweaver2000a]

I apologize if this is not the right place to post this info, but I'm sure it will be moved if necessary. The purpose of the post is to pass on info I have found on another site that has been of great help to an admitted BD rebuilder neophyte (me). I could not find this info on Doom9 by doing a search.....but now maybe the next person looking will be able to find it....Anyway, BD rebuilder kept reporting that "failed video encode, aborted" when trying to do a backup on the movie "Green Zone". Although I was able to backup other BD discs before and after these failures, no matter what I did, the encode failed on "Green Zone"....that is until I found this info....."Most likely it is caused by VC-1 being disabled in FFDSHOW. Go into ffdshow configuration and under VC-1, change from "disabled" to "libavcodec" After I reconfigured the FFDSHOW.....my problem was resolved! Hope this info will help others as it did me! Thanks jdobbs for BD rebuilder!

[jdobbs]

I apologize if this is not the right place to post this info, but I'm sure it will be moved if necessary. The purpose of the post is to pass on info I have found on another site that has been of great help to an admitted BD rebuilder neophyte (me). I could not find this info on Doom9 by doing a search.....but now maybe the next person looking will be able to find it....Anyway, BD rebuilder kept reporting that "failed video encode, aborted" when trying to do a backup on the movie "Green Zone". Although I was able to backup other BD discs before and after these failures, no matter what I did, the encode failed on "Green Zone"....that is until I found this info....."Most likely it is caused by VC-1 being disabled in FFDSHOW. Go into ffdshow configuration and under VC-1, change from "disabled" to "libavcodec" After I reconfigured the FFDSHOW.....my problem was resolved! Hope this info will help others as it did me! Thanks jdobbs for BD rebuilder! As I mentioned in the first post of this thread -- I'd highly recommend you use "wmv9" rather than "libavcodec". There are some VC-1 streams that will not decode using libavcodec.

[Carter]

On a Intel i7 1366 (X5650) Six core, 12 Thread with hyperthreading X264 only uses around 25%. I don't have a clue why. Any idea ?

[jdobbs]

On a Intel i7 1366 (X5650) Six core, 12 Thread with hyperthreading X264 only uses around 25%. I don't have a clue why. Any idea ? Pass 1 or pass 2? Sometimes on very fast processors the frame serving portion of the process (AVISYNTH & FFDSHOW) can't keep up with the processor as it is actually reencoding.

You might try using LAVF for frame serving and see how that works out (under the SETUP menu).

[bobrap]

Having a few sizing problems and didn't know whether to start a new new thread or post here. I tried doing Sorcerer's Apprentice last night and ended with a final size of 29.1 GB. Tried attaching log and inf. Are those the files you need to see? Thanks for any help.

[Chuckwagon]

On a Intel i7 1366 (X5650) Six core, 12 Thread with hyperthreading X264 only uses around 25%. I don't have a clue why. Any idea ?

-UPDATE- Ignore what I had posted here previously.

I've seen the same behavior on my X980. I just re-started an encode, and it looks as though x264 isn't even using the HT part of the cores, so only 6 of the 12 available "threads" are in use, and as a result Windows is miscalculating the total utilization. The threads that are being used bounce around 80-90%, which is pretty much fully utilized. So it seems the reported % utilized gets skewed because of the HT threads. Performance monitor doesn't properly assess the utilization. You can ignore it. :)

[Chuckwagon]

Having a few sizing problems and didn't know whether to start a hew new thread or post here. I tried doing Sorcerer's Apprentice last night and ended with a final size of 29.1 GB. Tried attaching log and inf. Are those the files you need to see? Thanks for any help.

Your attachments haven't been approved yet, so let me ask, are you using Auto Blank? Are you manually adding blanked streams back into your list?

It may be unrelated, but I have noticed that if you look at the input size reported by BD-RB when it starts an encode, you will see that it does not update as you add or remove streams from the list when you use the Auto Blank feature and then manually add/remove streams. For example, I have just tested this with a 45GB BD, that reports an input size of 25.75GB if I have the blank threshold set to 3600. (Only the main movie gets selected.) If I manually go add back in all of the streams that got blanked, BD-RB still reports an input size of 25.75GB. But if I change the threshold to 600, the input size goes to 35.64GB, and even if I then manually blank all but the main movie, the input size stays at 35.64GB.

So, I'm assuming the calculation of the input size, and therefore how much compression will be needed, is taking place when the Auto Blanking takes place, and is not being updated as streams are manually added or removed. This results in over-compression for builds where streams are manually removed, and under-compression where streams are manually added. Or at least that's my theory. :)

[Carter]

but shouldnt use x264 even HT ? the utilised threads dont use 80 as well. Even when misscalculated with HT it shouldnt be shown as 25% i guess. i tried x264 HD Benchmark 4.0 and this one utilises every single of the 12 threads 100%

[Chuckwagon]

but shouldnt use x264 even HT ? the utilised threads dont use 80 as well. Even when misscalculated with HT it shouldnt be shown as 25% i guess. i tried x264 HD Benchmark 4.0 and this one utilises every single of the 12 threads 100%

Keep in mind that the benchmark you used has the CPU priority set to high for x264, and threads set to Auto, which may change it's behavior from how JDobbs calls it. My point was that the windows reports cannot be trusted. Your system is probably running as it should for how the software is using it.

The high priority CPU setting certainly insures that not much else is likely to get done by any other programs while x264 is running, so maybe he doesn't fire it off that way to allow for other things to be going on. I don't know what CPU priority JDobbs has chosen, or if he sets the threads in some way other than auto, but I'm sure he can tell you. Maybe he has a way to alter that behavior that you could tweak.

-UPDATE-
After a little more playing around with both the x264_Benchmark_HD_v4.0 commands and the x264 command for BD-RB found in the LASTCMD.TXT file I think I may have narrowed down why x264 behaves the way it does. I removed the "--preset ultrafast" portion of the command found in LASTCMD.TXT and ran the command manually. It resulted in all 12 threads being utilized and nearly 100% utilization. So, I'm guessing there is something in that preset which causes x264 to only use 6 threads instead of 12, and not to use them at full bore 100%.

Also, you can change the preset, or remove it, which will result in more threads being used, and in them having higher utilization, but it doesn't result in faster encodes. So it would seem the answer to the problem is "x264 doesn't use more threads nor a higher CPU utilization than it does because it doesn't need to." You aren't leaving any CPU power lying on the table, so to speak. It uses what it needs to. :)

[setarip_old]

@jdobbs
Both "How to Train Your Dragon" and "Constantine" utilize PIP, but use E-AC3 audio instead of DTS Express for the PIP audiostream and both BD-RB backup discs exhibit the same wretched behavior on my SONY S360 as do all DTS Express discs thusfar.

Additionally, opening the ORIGINAL disc's movie .M2TS in tsMuxer discloses that the E-AC3 audiostream only is listed as the very last item, after all PGS streams - while the BD-RB backup lists it in the conventional last of the audiostreams, and before all PGS streams. Also, tsMuxer will not allow me to change the relative position of the E-AC3 audiostream to last place after all PGS streams.

Since tsMuxer cannot process (and doesn't display) DTS Express audiostreams, I cannot determine whether they also are ORIGINALLY placed after all PGS streams. If they are, it would be my guess that this placement is critical to the S360s processing of both types, if not all types, of PIP-related audio.
Finally (I believe I mentioned this previously about DTS Express discs), the ORIGINAL disc lists the secondary video as "Profile High 3.2", whereas the BD-RB backup lists it as "Profile High 4.1" (same as it lists for primary video for both ORIGINAL and BD-RB backup).

[worknstiff]

@ bobrap RE: Having a few sizing problems and didn't know whether to start a hew new thread or post here. I tried doing Sorcerer's Apprentice last night and ended with a final size of 29.1 GB

All you have to do is run BD_RB in "Movie and Menus" mode and use 50,000 in the setup for custom size. After you select what you want to keep or blank let it run (only takes about 20 minutes or so since it keeps all the original video intact) untill it finishes creating a bluray with menu intact. Now feed this to BD_RB and set your custom size for a "FULL MODE BACKUP" to 24,000 or 24,250 if you want to push it, and you will get a really accurately sized finished encode. goodluck, worknstiff

[jdobbs]

Keep in mind that the benchmark you used has the CPU priority set to high for x264, and threads set to Auto, which may change it's behavior from how JDobbs calls it. My point was that the windows reports cannot be trusted. Your system is probably running as it should for how the software is using it.

The high priority CPU setting certainly insures that not much else is likely to get done by any other programs while x264 is running, so maybe he doesn't fire it off that way to allow for other things to be going on. I don't know what CPU priority JDobbs has chosen, or if he sets the threads in some way other than auto, but I'm sure he can tell you. Maybe he has a way to alter that behavior that you could tweak.

-UPDATE-
After a little more playing around with both the x264_Benchmark_HD_v4.0 commands and the x264 command for BD-RB found in the LASTCMD.TXT file I think I may have narrowed down why x264 behaves the way it does. I removed the "--preset ultrafast" portion of the command found in LASTCMD.TXT and ran the command manually. It resulted in all 12 threads being utilized and nearly 100% utilization. So, I'm guessing there is something in that preset which causes x264 to only use 6 threads instead of 12, and not to use them at full bore 100%.

Also, you can change the preset, or remove it, which will result in more threads being used, and in them having higher utilization, but it doesn't result in faster encodes. So it would seem the answer to the problem is "x264 doesn't use more threads nor a higher CPU utilization than it does because it doesn't need to." You aren't leaving any CPU power lying on the table, so to speak. It uses what it needs to. :) That just means that by removing that mode you've added additional work for the processors to do --but it won't likely finish any faster, and you probably won't notice a quality difference in the output. So even though you're using more processor, I'm not sure you're really accomplishing anything. As I said before, the limiting factor is the decoding and frame serving.

A better way to do what you're doing would be to turn off "Automatic Quality" settings and select "High Quality" as a permanent setting.

Did you try the LAVF setting I suggested?

[jdobbs]

@jdobbs
Both "How to Train Your Dragon" and "Constantine" utilize PIP, but use E-AC3 audio instead of DTS Express for the PIP audiostream and both BD-RB backup discs exhibit the same wretched behavior on my SONY S360 as do all DTS Express discs thusfar.

Additionally, opening the ORIGINAL disc's movie .M2TS in tsMuxer discloses that the E-AC3 audiostream only is listed as the very last item, after all PGS streams - while the BD-RB backup lists it in the conventional last of the audiostreams, and before all PGS streams. Also, tsMuxer will not allow me to change the relative position of the E-AC3 audiostream to last place after all PGS streams.

Since tsMuxer cannot process (and doesn't display) DTS Express audiostreams, I cannot determine whether they also are ORIGINALLY placed after all PGS streams. If they are, it would be my guess that this placement is critical to the S360s processing of both types, if not all types, of PIP-related audio.
Finally (I believe I mentioned this previously about DTS Express discs), the ORIGINAL disc lists the secondary video as "Profile High 3.2", whereas the BD-RB backup lists it as "Profile High 4.1" (same as it lists for primary video for both ORIGINAL and BD-RB backup). Moving the audio doesn't make a difference. I've tried it before.

I'll have to look at the profile issue -- BD-RB is supposed to use Level 3.2 for secondary video.

[Chuckwagon]

That just means that by removing that mode you've added additional work for the processors to do --but it won't likely finish any faster, and you probably won't notice a quality difference in the output. So even though you're using more processor, I'm not sure you're really accomplishing anything. As I said before, the limiting factor is the decoding and frame serving.

A better way to do what you're doing would be to turn off "Automatic Quality" settings and select "High Quality" as a permanent setting.

Did you try the LAVF setting I suggested?

I agree, and that's what I was trying to say, though probably not clearly. :) There isn't really a problem, it just LOOKS like there might be if you are looking at the Performance Monitor because it seems you aren't using all the CPU power available. But x264 just doesn't NEED any more CPU power to accomplish what is being asked of it. For the given quality level, changing the preset WILL cause more horsepower to be needed, and you will see that in the Performance Monitor, but the end result is an encode that is essentially the same size but takes longer to create. So there is no problem with x264 not using all of the available CPU power.

What follows is the results of the test I ran. I tested this using both x264-64 with LAVF and x264-32 without LAVF, with and without --preset ultrafast. Using an input file of size 990,244 KB (one of the files from my last encode) and encoding it with the last command BD-RB issued on my last encode of a disc, only changing the use of LAVF or --preset ultrafast. The bitrate used was 15649 (which is what was last used on my most recent encode) Here is what resulted:

x264-64 with LAVF and with --preset ultrafast
Encoded 10809 frames, 58.54 fps, 15241.66 kb/s
Resulting file size - 838,785 KB

x264-64 with LAVF and no preset
Encoded 10809 frames, 22.88 fps, 15090.14 kb/s
Resulting file size - 830,447 KB

x264-32 without LAVF with --preset ultrafast
Encoded 10809 frames, 56.30 fps, 15241.82 kb/s
Resulting file size - 838,794 KB

x264-32 without LAVF and no preset
Encoded 10809 frames, 21.39 fps, 15090.21 kb/s
Resulting file size - 830,451 KB

With or without LAVF, the CPU utilization was about the same; around 25% or so and only 6 threads active when using --preset ultrafast, and all 12 threads active and maxed out when not using --preset ultrafast.

So it is possible to MAKE the x264 use more CPU power, but there isn't a NEED unless you want slower encodes for the given quality you have selected. There is no need to worry about what the Performance Monitor says about your CPU utilization while x264 is encoding, x264 is doing what it was asked and using what it needs to do so.

So there's no bug in BD-RB related to this perceived issue. :)

[jdobbs]

If it is disc bound (which is very likely), an SSD would probably really fly with your setup.

It might also be possible to modify BD Rebuilder to check on usage and do multiprocessing in addition to multithreading -- like encoding more than one video file at a time, or encoding audio concurrent with the video. More-and-more people are getting high-speed 6 and 8 core machines, and it would be nice to be able to take advantage of them.

[Ch3vr0n]

if you could pull that off and make it work on a simple quad core like my Q9550 that would be very impressive :)

[jdobbs]

if you could pull that off and make it work on a simple quad core like my Q9550 that would be very impressive :) My quad core (Phenom X4) runs at around 96% in pass 2 and sometimes hits 100%. Pass 1 rarely gets much more than 60%.

[Chuckwagon]

If it is disc bound (which is very likely), an SSD would probably really fly with your setup.

It might also be possible to modify BD Rebuilder to check on usage and do multiprocessing in addition to multithreading -- like encoding more than one video file at a time, or encoding audio concurrent with the video. More-and-more people are getting high-speed 6 and 8 core machines, and it would be nice to be able to take advantage of them.

I ran the tests from my SSD RAID 0 array, consisting of 3 Intel X25E 32GB drives. It's quite fast. :D But I haven't noticed it making much of a difference in encoding speed vs the mirrored 1GB standard HDDs I normally use. And I too think it would be great if you were able to multi-task rebuilds in some way, though I'm not unhappy with how it works now. :)

On to another issue dealing with a different problem, I just completed verifying that there does seem to be a problem with BD-RB setting the bitrate for encoding when streams are manually added or removed.

I allowed Auto Blank to remove all but the main movie from a rebuild, and BD-RB reports an input size of 25.75 GB and sets the bit rate to 19632, and the resulting ISO ends up being 22,922,240 KB. When I set the Threshold to 600 and then manually remove the rest of the streams so that only the main movie is left BD-RB reports an input size of 35.64 GB and the bitrate gets set to 12059, and the resulting ISO is 16,628,736 KB. The rebuilds are using the same streams each time, the material being encoded hasn't changed, only the way in which it was selected was changed.

So it seems that input size and bitrate are not being recalculated after manual selections are made, and as a result rebuilds are ending up either too small or too large depending on if streams were added or removed.

[Sharc]

Since a while (OS update? BD-RB update?) wavi.exe crashes at the end of its task instead of terminating properly. I can then terminate the application (wavi.exe) manually and BD-RB continues as expected, and the final result is o.k. Nothing is reported in BD-RB's logfile, so basically no problem with the exception that I have to intervene manually in order to let DB-RB to continue its task. I never had any issues with this until recently :confused:

[jdobbs]

I ran the tests from my SSD RAID 0 array, consisting of 3 Intel X25E 32GB drives. It's quite fast. :D But I haven't noticed it making much of a difference in encoding speed vs the mirrored 1GB standard HDDs I normally use. And I too think it would be great if you were able to multi-task rebuilds in some way, though I'm not unhappy with how it works now. :)

On to another issue dealing with a different problem, I just completed verifying that there does seem to be a problem with BD-RB setting the bitrate for encoding when streams are manually added or removed.

I allowed Auto Blank to remove all but the main movie from a rebuild, and BD-RB reports an input size of 25.75 GB and sets the bit rate to 19632, and the resulting ISO ends up being 22,922,240 KB. When I set the Threshold to 600 and then manually remove the rest of the streams so that only the main movie is left BD-RB reports an input size of 35.64 GB and the bitrate gets set to 12059, and the resulting ISO is 16,628,736 KB. The rebuilds are using the same streams each time, the material being encoded hasn't changed, only the way in which it was selected was changed.

So it seems that input size and bitrate are not being recalculated after manual selections are made, and as a result rebuilds are ending up either too small or too large depending on if streams were added or removed. When are you making the manual selections? If you do it after some encoding have been completed and you resume, I can see how it would be off because the size of the completed items wouldn't match the new calculations.

Any chance that's it? It sounds like it -- and if that's the case it makes perfect sense, the only thing I could do is start the entire encode over when you change your selections. You can't change the size of a file that has already been encoded...

Was the SSD the source (where the original BDMV and CERTIFICATE folders reside). If disc I/O is the limiting factor, that's where you'd have to use it to see a difference.