BD Rebuilder Beta - Bug Reports Only

[jdobbs]

I also reinstalled 4002 to verify.

4002=Works perfectly splitting
4004=Fail to split. Errors out directly. Works when using MULTIPROCESS=0

//LD I can't figure out why it is doing it on your encode but there are no other reports... I've done several more encodes since your post -- and still no problem.

[NightHawkGuy]

I had to update the MKVMERGE version so I can add .SUP subtitle support.

Is there a hidden option to include the subtitles in the output mkv file?

[Farscape1]

I'm guessing the Header stripping listed under Muxing mode in MediaInfo is the problem. It is a quick fix with MkvMerge.

Instructions at this link

http://www.noblemd.info/index.php?option=com_content&view=article&id=21&Itemid=24


you can have header stripping turned off permanently:

1. file>options
2. under "mmg" tab, make sure "disable header removal compression for audio and video tracks by default" is checked (v5.3.0 but also was an option in 4.8....not sure about earlier versions)

[jdobbs]

Is there a hidden option to include the subtitles in the output mkv file? Not yet. That is just a little forward planning.

[LowDead]

I can't figure out why it is doing it on your encode but there are no other reports... I've done several more encodes since your post -- and still no problem.

I don't understand it either.. with no other reports it has to be something with my system, but what? O_o

/LD

[jdobbs]

I don't understand it either.. with no other reports it has to be something with my system, but what? O_o

/LD I don't think so... it has to be BD-RB's splitting -- but I can't figure what is different in this case. I'd like to figure it out and put in a fix (as well as the issue reported by The_Unknown) before I post another interim release.

[LowDead]

I don't think so... it has to be BD-RB's splitting -- but I can't figure what is different in this case. I'd like to figure it out and put in a fix (as well as the issue reported by The_Unknown) before I post another interim release.

Please let me now if you need some more testing from me.

//LD

[AmigaFuture]

I'm not sure what's up with MULTIPROCESS, as I'm noticing it's not working well with 40.04. I've noticed as LowDead that something isn't functional as it was. I was going to post to please reactive MULTIPROCESS as 0, 1, 2 or 3 aren't working with my machine anymore.

I also noticed something else, I went back to...40.01 for testing, and when I had reported the video glitch (The Matrix - Revolutions), I didn't notice that BD-RB reported it as VC-1 before or not. So I ripped it again, and tried it with 40.01, and this time I saw VC-1 and MULTIPROCESS=1 showed BD-RB was indeed splitting it. Which could be why the glitch was there...as in your website says it shouldn't work with VC-1. Now, with 40.04 even AVC's, here, with MUTLTIPROCESS 0, 1, 2, or 3 set aren't functioning. I am noticing 1st pass starts with HIGH (98) FPS and slowly it drops to 40 something FPS or lower. I haven't let it go to 2nd pass yet.

The changes were made using View/Edit Config and NOT exiting the program for the info above.

[19:37:57] BD Rebuilder v0.40.01 (beta)
- Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=640
[19:37:58] PHASE ONE, Encoding
- [19:37:58] Processing: VID_00020 (1 of 1)
- [19:37:58] Extracting A/V streams [VID_00020]
- [19:43:04] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 11,261 Kbs
- [19:43:04] Reencoding: VID_00020, Pass 1 of 2
[20:00:37]PHASE ONE aborted by user request
-----------------------
[20:00:49] BD Rebuilder v0.40.01 (beta)
- Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=640
[20:00:52] PHASE ONE, Encoding
- [20:00:52] Processing: VID_00020 (1 of 1)
- [20:00:52] Extracting A/V streams [VID_00020]
- [20:06:02] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 11,261 Kbs
- [20:06:02] Reencoding: VID_00020, Pass 1 of 2
- [21:11:05] Reencoding: VID_00020, Pass 2 of 2
- [23:42:52] Video Encode complete
- [23:42:52] Processing audio tracks
- [23:42:52] Multiplexing M2TS
[23:42:52]PHASE ONE complete
[23:42:52]PHASE TWO - Rebuild Started
- [23:42:52] Rebuilding stream 00020 [1 of 1]
- [23:42:52] Building ALTERNATE OUTPUT Structure
[23:50:34] - Encode and Rebuild complete
[23:50:34] JOB: ASSAULTONPRECINCT13 finished.
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[10:45:42] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[10:45:43] PHASE ONE, Encoding
- [10:45:43] Processing: VID_00020 (1 of 1)
- [10:45:43] Extracting A/V streams [VID_00020]
- [10:50:41] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [10:50:41] Reencoding: VID_00020, Pass 1 of 2
- [11:47:59] Reencoding: VID_00020, Pass 2 of 2
[12:16:07]PHASE ONE aborted by user request
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[12:16:35] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[12:16:37] PHASE ONE, Encoding
- [12:16:37] Processing: VID_00020 (1 of 1)
- [12:16:37] Extracting A/V streams [VID_00020]
- [12:21:32] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [12:21:32] Reencoding: VID_00020, Pass 1 of 2
[12:22:24]PHASE ONE aborted by user request
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[12:22:44] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [2-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[12:22:46] PHASE ONE, Encoding
- [12:22:46] Processing: VID_00020 (1 of 1)
- [12:22:46] Extracting A/V streams [VID_00020]
- [12:27:48] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [12:27:48] Reencoding: VID_00020, Pass 1 of 2
[12:28:00]PHASE ONE aborted by user request
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[12:28:13] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[12:28:14] PHASE ONE, Encoding
- [12:28:14] Processing: VID_00020 (1 of 1)
- [12:28:14] Extracting A/V streams [VID_00020]
- [12:33:18] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [12:33:18] Reencoding: VID_00020, Pass 1 of 2
[12:35:37]PHASE ONE aborted by user request
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[12:36:16] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[12:36:19] PHASE ONE, Encoding
- [12:36:19] Processing: VID_00020 (1 of 1)
- [12:36:19] Extracting A/V streams [VID_00020]
- Extracting A/V to M2TS [VID_00020]
- Extracting A/V from M2TS [VID_00020]
- Error in attempt to extract audio/subs.
-
- Error in attempt to extract audio/subs.
-
[12:48:00] - Failed to retrieve audio, aborted

The previous log is because of disk space as to why it failed.

Now most recent test logs..

In this instance MP is set to 1. 3-way is set, looks like, and 1st pass atarts at 95 FPS and slowly drops to 40's but before doing so it climbs to 99. x264 is 1 instance and using 1GB of RAM.
[02/10/12] BD Rebuilder v0.40.04 (beta)
[13:05:53] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[13:05:53] PHASE ONE, Encoding
- [13:05:53] Processing: VID_00020 (1 of 1)
- [13:05:53] Extracting A/V streams [VID_00020]
- [13:10:52] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [13:10:52] Reencoding: VID_00020, Pass 1 of 2

I've now changed MP to 2. Exited, and re-run the program. Clicked to delete old files. x264 same stuff.
[02/10/12] BD Rebuilder v0.40.04 (beta)
[13:18:40] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [2-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[13:18:42] PHASE ONE, Encoding
- [13:18:42] Processing: VID_00020 (1 of 1)
- [13:18:42] Extracting A/V streams [VID_00020]
- [13:23:50] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [13:23:50] Reencoding: VID_00020, Pass 1 of 2
[13:25:15]PHASE ONE aborted by user request

I changed MP to 0. Exited, re-ran program. Clicked to delete old files. Same RAM usage, and 1 instance of x264. Same scene as above except without DirectShow, as should be.
[02/10/12] BD Rebuilder v0.40.04 (beta)
[13:29:05] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[13:29:07] PHASE ONE, Encoding
- [13:29:07] Processing: VID_00020 (1 of 1)
- [13:29:07] Extracting A/V streams [VID_00020]
- [13:34:07] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [13:34:07] Reencoding: VID_00020, Pass 1 of 2
[13:37:02]PHASE ONE aborted by user request

MP is now removed from the config. Exited program, and re-run.
----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[13:39:36] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[13:39:38] PHASE ONE, Encoding
- [13:39:38] Processing: VID_00020 (1 of 1)
- [13:39:38] Extracting A/V streams [VID_00020]
- [13:44:38] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [13:44:38] Reencoding: VID_00020, Pass 1 of 2
[13:45:55]PHASE ONE aborted by user request

Now using MP=1 with 40.02. 3-was split is active. 3 processes of x264 are active. About 50MB RAM per x264. From the splitting process to seeing FPS was about 14 minutes. Holding around 53.xx FPS. After maybe 15 to 20 minutes I'm seeing 55-66.xx FPS. Finished at 51 minutes. This is all within the 1st pass.

2nd pass started. 3 processes of x264 using about 50MB+/- each for 14 minutes of processing before it shows FPS. Now ranges from 400 to 700MB each. It started at 40.xx FPS and has slowly dropped to 18.xx at 36% done. The process isn't done and I'll Watch the final result tonight.
-----------------------
[13:47:52] BD Rebuilder v0.40.02 (beta)
- Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=640
[13:47:53] PHASE ONE, Encoding
- [13:47:53] Processing: VID_00020 (1 of 1)
- [13:47:53] Extracting A/V streams [VID_00020]
- [13:52:52] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 10,185 Kbs
- [13:52:52] Reencoding: VID_00020, Pass 1 of 2
- [14:51:14] Reencoding: VID_00020, Pass 2 of 2

[NightHawkGuy]

Didn't the x264 version change between BD Rebuilder v0.40.01 thru v0.40.04?
Could that cause the difference in speed and amounts of RAM used by x264, noted above?

[jdobbs]

as in your website says it shouldn't work with VC-1. Where did you get that? The only time it would not split VC-1 is if it is interlaced, which is very rare (virtually non-existent) for a feature -- and that wouldn't even matter with DGDecNV.

I'm telling you -- except for fixing the 00006 error, which isn't related to that, the code when using DirectshowSource is identical. I'll go back an check -- but I'm pretty sure that's true.

Maybe I'm dense, but as for your post... I read it about 5 times and I can't for the life of me figure out what you're trying to say. I also don't get the connection between what you are saying and LowDead's report. He's reporting an straight-forward error... and that doesn't sound anything like what you're posting.

Sticking with only the current version... please tell me what it is (or isn't) doing that you think it should (or should not) be doing???

[jdobbs]

@LowDead

When you get your error is it with a clean start (not an attempt to resume)? Is it possible you may have killed the job from task manager rather than with the "Abort" buttong. The reason I ask is that I've been experimenting and if that happens during the spit it could confuse BD-RB into thinking the split was already done and cause the failure to encode...

Also... does it fail on other discs or just the one you reported?

[jdobbs]

Didn't the x264 version change between BD Rebuilder v0.40.01 thru v0.40.04?
Could that cause the difference in speed and amounts of RAM used by x264, noted above? Yes it did. According to the X264 changelog the newer version should be slightly faster.

[NightHawkGuy]

Using multiprocess mode I noticed after encoding is complete there appears to be a separate concatenation of the split video segments prior to final muxing.
Is it possible that it could that be done during the mux process instead to eliminate the extra time and temp disk space used?
Both Tsmuxer and mkvmerge appear to support joining input segments that could help optimize that process a bit.

[jdobbs]

Using multiprocess mode I noticed after encoding is complete there appears to be a separate concatenation of the split video segments prior to final muxing.
Is it possible that it could that be done during the mux process instead to eliminate the extra time and temp disk space used?
Both Tsmuxer and mkvmerge appear to support joining input segments that could help optimize that process a bit.

Yes, it could... I did it that way so I could get it debugged without spreading the risk over too many modules of code. I'll probably eventually just do it in the mux -- on most jobs it'll save 5-10 minutes of so.

[AmigaFuture]

Jdobbs,

I was referencing post #14351 from LowDead, he typed about the differences with 40.01 and 40.04 with MP which I've notied.

I thought the VC-1 comment I remembered was at http://www.jdobbs.net/freeware/multiprocessing.html, nope. Then going back further..in this thread..

"Reasons that could happen:

1. LAVF is set.
2. Resizing. (ALTERNATE resizing or selecting one of the resize options in SETUP)
3. VC-1 Interlaced source."

I remembered that incorrectly. Pardon.


So...with 40.04, is x264 also now doing multiprocessing itself and is the reason only 1 instance of x264.exe (with ffdshow and Haali Media Splitter)? I didn't see anything in the x264 change log to indicate its own multiprocessing.

I have internal x264 LAVF unchecked. Also DGDecNV unchecked since I use an ATI board. I'm not seeing the speeds, or the processing (around 10 to 15 minutes) before and after pass 1 even though 3-way is showing.
I was before which is why I was checking with 40.01 and 40.02....and shared the logs.

Is this a bit more clear? Let me know, if not. :-)

Using 40.04 ONLY...first pass had no preprocessing that I saw.
I am seeing a pretty steady 37.72 FPS and a speed of 1.57x. CPU between 34 and 41%. RAM (6GB) is at 3.41GB.

Pass 2..FPS shot up to 100, and is slowly going down. CPU is at MAX, and RAM 3.22GB. Single instance of x264 is almost using 840MB.
This is at 3.40% complete, pass 2.

Pass 2..4.10% done...FPS is at 35 and dropping. x264 around 840MB.

Pass 2..53% done, FPS very steady at 20.63. CPU 95 - 100%. Single instance of x264 using 842MB.

Different results compared to 40.01 or 40.02 which had multiple instances depending on MP value. I'm not suggesting multiple instances are required, only noticing differences.

Also, Cool about .SUP files.


----------------------
[02/10/12] BD Rebuilder v0.40.04 (beta)
[19:23:24] Source: ASSAULTONPRECINCT13
- Input BD size: 19.03 GB
- Approximate total content: [01:30:49.444]
- Windows Version: 6.1 [7601]
- MOVIE-ONLY/ALTERNATE OUTPUT mode enabled
- Mode: MKV Container, 1920x1080, Intact Audio
- Automatic cropping of borders enabled
- Decoding/Frame serving: DirectShow [3-way]
- Audio Settings: AC3=0 DTS=1 HD=0 Kbs=448
[19:23:38] PHASE ONE, Encoding
- [19:23:38] Processing: VID_00020 (1 of 1)
- [19:23:38] Extracting A/V streams [VID_00020]
- [19:28:37] Reencoding video [VID_00020]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 130,656 frames
- Bitrate: 5,675 Kbs
- [19:28:37] Reencoding: VID_00020, Pass 1 of 2
- [20:26:02] Reencoding: VID_00020, Pass 2 of 2
- [22:10:50] Video Encode complete
- [22:10:50] Processing audio tracks
- [22:10:50] Multiplexing M2TS
[22:10:50]PHASE ONE complete
[22:10:50]PHASE TWO - Rebuild Started
- [22:10:50] Rebuilding stream 00020 [1 of 1]
- [22:10:50] Building ALTERNATE OUTPUT Structure
[22:14:22] - Encode and Rebuild complete
[22:14:22] JOB: ASSAULTONPRECINCT13 finished.

[AmigaFuture]

I'm now trying INDEX_WITH_EXTRACT.

[Harlem Carmello]

A CERTIFICATE folder is a part of the Blu-Ray standard and is not required in AVCHD.

Originally Posted by Harlem View Post Carmello
good afternoon
I just do the conversion of a Blu-ray to AVCHD BD Rebuilder will take longer than 18 hours in the end did not come all the BDMV folder without the CERTIFICATE folder so I did a test from this folder create a BDMV ISO does not work as expected does anyone know the solution as a folder is missing!

Thank you!
The certificate folder is a part of the Blu-Ray and AVCHD is not necessary.

This has been resolved. It was only to create the folder (CERTIFICATE / BACKUP) and burn with imgburn that road legally without problems.

Thank you!

[jdobbs]

@AmigaFuture

X264 has always done it's own internal multiprocessing. You'll see that by watching Task Manager and noticing that it uses all of your processors. But... the frame-serving portion of the process (feeding frames for X264 to encode) doesn't and that's (probably) why you don't see all the processors maxed to 100%. On faster processors X264 spends at least some of its time waiting for something to encode. BD-RB's multiprocessing function runs multiple instances of X264 so that the other (support) software can feed more frames to X264 and use that extra processing time.

So... if you are already using something close to 100% of your processor time, there isn't room for improvement and you likely wouldn't see additional speed with BD-RB's multiprocessing. In fact, in some instances the additional overhead might even slow it down a little -- especially if an excessive number of instances is being used.

The FPS figure isn't particulary useful when starting/stopping jobs like in your first post. There are other factors that can wildly affect it. For example, if you keep starting over and doing small sections of code you'll see super-high figures (at least at the beginning) because the frames are always in the disc cache and you never have to actually read from the hard drive. So unless you are doing an entire encode (that is at least as large as the cache) you may never actually see any benefit of multiprocessing -- because your cache keeps your processor up-front loaded with frames. The bottom line is that you need to complete whole jobs and compare the overall time -- otherwise the information is skewed terribly and becomes meaningless.

I'd suggest you, instead, look at processor utilization. So, for example, if you are using 90% of your processor with one instance of X264, the most you could reasonably expect to gain by implementing more instances would be 10%. On the other hand, if you are only using 50% -- you could theoretically get up to double your speed.

Currently INDEX_WITH_EXTRACT applies to DGDecNV only. There is no indexing for DirectshowSource().

[colinhunt]

Dark Star has a 116-minute long making of which is originally MPEG-2 720x480p@23.976fps. BD-RB v0.40.04 processes it into AVC 720x480p@29.97fps and audio is very much out of sync. Is there a box to tick in settings which might solve this?

[jdobbs]

Dark Star has a 116-minute long making of which is originally MPEG-2 720x480p@23.976fps. BD-RB v0.40.04 processes it into AVC 720x480p@29.97fps and audio is very much out of sync. Is there a box to tick in settings which might solve this? I'll need to look at it... is DGDecNV enabled? Also, make sure Directshow is using the FFDSHOW MPEG-2 CODEC. Other programs have a tendency to intercept that one often because it is so commonly used (for DVD). It also commonly uses pulldown and different CODECs have a tendency to react to pulldown in different ways. Uninstall/reinstall FFDSHOW and immediately encode and see if that corrects it.

[colinhunt]

I'll need to look at it... is DGDecNV enabled?
Yes, it's enabled.

Also, make sure Directshow is using the FFDSHOW MPEG-2 CODEC. Other programs have a tendency to intercept that one often because it is so commonly used for DVD. Reinstall FFDSHOW and immediately encode and see if that corrects it.
Is this relevant when DGDecNV is enabled?

[jdobbs]

Yes, it's enabled.


Is this relevant when DGDecNV is enabled? No. It wouldn't be relevant for DGDecNV. I'll dig up some MPEG-2 sources and do some testing.

[jdobbs]

@colinhunt

Can you look at the stream list in BD-RB and see if it has a "*" or a "**" next to the fps number? That way I can tell whether it is interlaced, uses pulldown, or is hybrid MPEG-2.

[colinhunt]

Can you look at the stream list in BD-RB and see if it has a "*" or a "**" next to the fps number? That way I can tell whether it is interlaced, uses pulldown, or is hybrid MPEG-2.
Stream list reads:

VID_00007 MPEG-2, 480i, 29.97fps*, 4 607,04 MB

Huh? How come Mediainfo says it's 480p@23.976fps?

[jdobbs]

Stream list reads:

VID_00007 MPEG-2, 480i, 29.97fps*, 4 607,04 MB

Huh? How come Mediainfo says it's 480p@23.976fps? Apparently because Mediainfo isn't giving you all the information. The "*" means that there are pulldown flags in the source. The pulldown flags bring the 23.976 progressive source up to 29.97fps interlaced upon playback.

23.976/480p isn't even a legal rate/frame-size combination in Blu-ray standard except as a secondary. But... if your DVD or Blu-ray player sees this combination it can sometimes ignore the pulldown flags a play it back as progressive (which usually delivers better perceived quality).

Trust what BD-RB says, if anything else disagrees -- it is wrong.

[colinhunt]

Apparently because MediaInfo isn't giving you all the information. The "*" means that there are pulldown flags in the source. The pulldown flags bring the 23.976 progressive source up to 29.97fps interlaced upon playback. 23.976/480p isn't even a legal rate/frame-size combination in Blu-ray except as a secondary.
OK. I guess MediaInfo isn't quite as trustworthy as I had imagined. Anyhoo, doesn't change the fact that the file comes out of BD-RB quite wonky. I did not have "IVTC sources with 3:2 pulldown" box ticked; I'll try another run with IVTC enabled.

Trust what BD-RB says, if anything else disagrees -- it is wrong.
:)

[jdobbs]

OK. I guess MediaInfo isn't quite as trustworthy as I had imagined. Anyhoo, doesn't change the fact that the file comes out of BD-RB quite wonky. I did not have "IVTC sources with 3:2 pulldown" box ticked; I'll try another run with IVTC enabled.


:) Mediainfo isn't necessarily "wrong" at a fundamental level -- it's just appears to be leaving out some important information.

I'm building a souce that is similar and will run some tests on it. There are three ways I can treat these sources in DGDecNV, I used the one that is most similar to the way DirectshowSource() delivers them in order to prevent the need for exceptions in the following processing. I'll see what I can find.

Wonky, eh? Sounds sinister.

[jdobbs]

By the way, as a recommendation, you should leave IVTC enabled (the default). Otherwise you aren't maintaining the original format of the source and it will become "hard-telecined".

[colinhunt]

Wonky, eh? Sounds sinister.
Heh, only meant the audio is very much out of sync. It's running with IVTC enabled now.

[rendez2k]

Just running a test disc with DGDecNV installed. I ran the same disc without DGDecNV last night and encode went fine. What I'm now getting is an error saying "Timed out looking for I/P frame". Whats causing that? The actual encode has stopped completely as its waiting for me to press OK to continue.

[jdobbs]

Heh, only meant the audio is very much out of sync. It's running with IVTC enabled now. You should be ok with IVTC enabled. I didn't test it with it disabled -- so of course there had to be an issue there. I found it and fixed it for the next release.

[jdobbs]

Just running a test disc with DGDecNV installed. I ran the same disc without DGDecNV last night and encode went fine. What I'm now getting is an error saying "Timed out looking for I/P frame". Whats causing that? The actual encode has stopped completely as its waiting for me to press OK to continue. Hmm... that has to be from DGDecNV -- as I've never seen it. It sure sounds like a corrupt source, though. The only cause for pause would be "why didn't Directshow have an issue with it?"

Where did the source originate? It isn't one of those video streams that was preprocessed/reencoded at some point in its history with a huge (illegal for Blu-ray) GOP was it? That's sounds like it might cause something like that (since there may be 10 seconds or more between the I frames).

I'm guessing this is a question for Neuron2.

[LowDead]

@LowDead

When you get your error is it with a clean start (not an attempt to resume)? Is it possible you may have killed the job from task manager rather than with the "Abort" buttong. The reason I ask is that I've been experimenting and if that happens during the spit it could confuse BD-RB into thinking the split was already done and cause the failure to encode...

Also... does it fail on other discs or just the one you reported?

I have tried both with clean start and and start again after abort and change settings. I have never killed the job via task manager or tried to resume (always choosed to delete temporary files so it would begin from start.)

It fails on every disk I try. Always the same error when begin to split.

//LD

[jdobbs]

I have tried both with clean start and and start again after abort and change settings. I have never killed the job via task manager or tried to resume (always choosed to delete temporary files so it would begin from start.)

It fails on every disk I try. Always the same error when begin to split.

//LD Every disc? Then I have to believe the problem is specific to just your system... now we have to figure out why that is possible.

Is there anything unique about your system?

[LowDead]

Every disc? Then I have to believe the problem is specific to just your system... now we have to figure out why that is possible.

Is there anything unique about your system?

Yes, 4002=Every disk works.. 4004=Every disk fails..

Intel 980X, 24GB RAM, Nvidia GTX580, Revodrive X2 240GB, Win7 Ultimate 64bit

I was wondering about if the split module needs to be run as administrator(as BD-RB) as I was having the work folder on C:/temp but I tried switching to D:/work instead but it was still a no go.. :(

/LD

[jdobbs]

Yes, 4002=Every disk works.. 4004=Every disk fails..

Intel 980X, 24GB RAM, Nvidia GTX580, Revodrive X2 240GB, Win7 Ultimate 64bit

I was wondering about if the split module needs to be run as administrator(as BD-RB) as I was having the work folder on C:/temp but I tried switching to D:/work instead but it was still a no go.. :(

/LD That is a difference between the two versions. in 0.40.02 the split code was a function within BD-RB. In 0.40.04 I compiled it as a separate exe (with the intent of making it at some point run concurrently to save time) and it is called from within BD-RB. I can't see how that could affect it this way, though, as there are already other programs being spawned by BD-RB (like X264, TSMUXER, WAVI, AFTEN, and DGIndexNV).

The odd thing is that the nature of the way it exits give the impression that the failure is occurring during the encode as opposed to the split. What I might do is add a little debugging code to the next release just to see where specifically it is bombing for you. I want to make sure we clear this up.

[jdobbs]

@LowDead

I PM'd you with a "debugging" version of SPLIT.EXE -- try it and let me know if you get any useful feedback from it.

[rendez2k]

Hmm... that has to be from DGDecNV -- as I've never seen it. It sure sounds like a corrupt source, though. The only cause for pause would be "why didn't Directshow have an issue with it?"

Where did the source originate? It isn't one of those video streams that was preprocessed/reencoded at some point in its history with a huge (illegal for Blu-ray) GOP was it? That's sounds like it might cause something like that (since there may be 10 seconds or more between the I frames).

I'm guessing this is a question for Neuron2.

The source is my own rip done with AnyDVD. No idea if thats the best way to rip it but will be happy to test any alternative methods. I think the main movie has encoded fine and its the extras that its had issues with. Exactly the same rip source as last nights test.

[jdobbs]

The source is my own rip done with AnyDVD. No idea if thats the best way to rip it but will be happy to test any alternative methods. I think the main movie has encoded fine and its the extras that its had issues with. Exactly the same rip source as last nights test. An AnyDVD rip is fine and is the preferred method. I was referring to something that may have been reencoded previously using non-BD acceptable parameters. A lot of the third-party software out there (MKV converters, etc.) will use GOP sizes that are illegal in blu-ray.

Does BD-RB's log say how many frames are in that stream?

[d62ks821]

- Added a new option to the ALTERNATE output dialog
that allows removal of black borders (automatic
cropping). ...[/code]

Processed much of my library with this feature and it seemed to worked great. However it didnt work for star wars blurays. It appears avisythn autocrop plugin crops way too much from all side of frame. To debug this, I edited VID_82*.AVS file and changed to Autocrop(mode=1) and it shows actual cropping as:
Left 312 Top 152
Right 315 Bottom 303
Width 4 Height 152
Crop(312,152,4,152)

Autocrop by default is looking at 5 samples starting at frame 0 and in this video the first 120 frames are blank! If I add samplestartframe=150 param to autocrop, then it works much better, but it still crops too much off the top (maybe this is happening with my other videos also, I'll have to check). Then added threshold=20 to autocrop, then it finally got it right.

The autocrop plugin is going to need some tending for it to consistently get the desired results. Maybe BDR needs something more complicated like:

1. take multiple samples at various offsets (or from various files in multiple file stream) using autocrop mode=2 for log output

2. parse through log outputs and make intelligent guess at best crop settings.

[AmigaFuture]

@AmigaFuture

X264 has always done it's own internal multiprocessing. You'll see that by watching Task Manager and noticing that it uses all of your processors. But... the frame-serving portion of the process (feeding frames for X264 to encode) doesn't and that's (probably) why you don't see all the processors maxed to 100%. On faster processors X264 spends at least some of its time waiting for something to encode. BD-RB's multiprocessing function runs multiple instances of X264 so that the other (support) software can feed more frames to X264 and use that extra processing time.

So... if you are already using something close to 100% of your processor time, there isn't room for improvement and you likely wouldn't see additional speed with BD-RB's multiprocessing. In fact, in some instances the additional overhead might even slow it down a little -- especially if an excessive number of instances is being used.

The FPS figure isn't particulary useful when starting/stopping jobs like in your first post. There are other factors that can wildly affect it. For example, if you keep starting over and doing small sections of code you'll see super-high figures (at least at the beginning) because the frames are always in the disc cache and you never have to actually read from the hard drive. So unless you are doing an entire encode (that is at least as large as the cache) you may never actually see any benefit of multiprocessing -- because your cache keeps your processor up-front loaded with frames. The bottom line is that you need to complete whole jobs and compare the overall time -- otherwise the information is skewed terribly and becomes meaningless.

I'd suggest you, instead, look at processor utilization. So, for example, if you are using 90% of your processor with one instance of X264, the most you could reasonably expect to gain by implementing more instances would be 10%. On the other hand, if you are only using 50% -- you could theoretically get up to double your speed.

Currently INDEX_WITH_EXTRACT applies to DGDecNV only. There is no indexing for DirectshowSource().

I was sure INDEX_WITH_EXTRACT is meant but only DGDecNV, but I thought I'd try it.. I'm trying different things to get across that BD-RB 40.04 is not running more than 1 process of x264 on my system now as BD-RB 40.01 and 40.02 did. I'm trying to figure Why. In all the stuff I shared, my computer specs are what I forgot.

Intel i7-930 4 Cores, 8 Threads, Overclocked to 3.17Ghz and absolutely stable, 6GB of RAM. Multiple Hard Drives running at 5700 RPM with an ATI GFX board. I build this computer for power. :) I've exited all programs several times to keep RAM and PageFile free so BD-RB 40.04 could allow/help x264 run multiple process but it only runs 1 x264 process when 40.01 and 40.02 ran 2 to 3 depending on how I set MULTIPROCESS. With my specs, should I only be seeing in TaskManagaer/Processes only 1 process of x264? That is all I see when using 40.04.

Seeing DirectShow (2-way) or (3-way) or even sometimes I see (4-way) indicates to me I should see x264.exe show that many processes in TaskManger/Processes respectively. Correct? Because I am not seeing more than 1 at all with 40.04.

When I run DB-RB 40.04, I ONLY run it. I don't play games. Only...Maybe..Firefox is running...and perhaps Notepad. I keep RAM and CPU available for DB-RB and x264.


I hope this helps. :-D

[rendez2k]

An AnyDVD rip is fine and is the preferred method. I was referring to something that may have been reencoded previously using non-BD acceptable parameters. A lot of the third-party software out there (MKV converters, etc.) will use GOP sizes that are illegal in blu-ray.

Does BD-RB's log say how many frames are in that stream?

----------------------
[02/11/12] BD Rebuilder v0.40.04 (beta)
[13:34:50] Source: ADJUSTMENT_BUREAU
- Input BD size: 33.44 GB
- Approximate total content: [03:12:09.499]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- MOVIE and MENUS mode enabled
- Auto Quality: Good (Very Fast), ABR
- Decoding/Frame serving: DGDecNV
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
[13:34:50] PHASE ONE, Encoding
- [13:34:50] Blanking: VID_00061 (1 of 187)
- [13:34:50] Blanking: VID_00062 (2 of 187)
- [13:34:50] Blanking: VID_00084 (3 of 187)
- [13:34:50] Blanking: VID_00085 (4 of 187)
- [13:34:50] Blanking: VID_00300 (5 of 187)
- [13:34:50] Blanking: VID_00301 (6 of 187)
- [13:34:50] Blanking: VID_00302 (7 of 187)
- [13:34:50] Blanking: VID_00304 (8 of 187)
- [13:34:50] Blanking: VID_00305 (9 of 187)
- [13:34:50] Blanking: VID_00306 (10 of 187)
- [13:34:50] Blanking: VID_00307 (11 of 187)
- [13:34:50] Blanking: VID_00308 (12 of 187)
- [13:34:50] Blanking: VID_00309 (13 of 187)
- [13:34:50] Blanking: VID_00310 (14 of 187)
- [13:34:50] Blanking: VID_00311 (15 of 187)
- [13:34:50] Blanking: VID_00312 (16 of 187)
- [13:34:50] Blanking: VID_00313 (17 of 187)
- [13:34:50] Blanking: VID_00314 (18 of 187)
- [13:34:50] Blanking: VID_00315 (19 of 187)
- [13:34:50] Blanking: VID_00316 (20 of 187)
- [13:34:50] Blanking: VID_00320 (21 of 187)
- [13:34:50] Blanking: VID_00321 (22 of 187)
- [13:34:50] Blanking: VID_00322 (23 of 187)
- [13:34:50] Blanking: VID_00323 (24 of 187)
- [13:34:50] Blanking: VID_00324 (25 of 187)
- [13:34:50] Blanking: VID_00325 (26 of 187)
- [13:34:50] Blanking: VID_00326 (27 of 187)
- [13:34:50] Blanking: VID_00327 (28 of 187)
- [13:34:50] Blanking: VID_00328 (29 of 187)
- [13:34:50] Blanking: VID_00329 (30 of 187)
- [13:34:50] Blanking: VID_00330 (31 of 187)
- [13:34:50] Blanking: VID_00331 (32 of 187)
- [13:34:50] Blanking: VID_00332 (33 of 187)
- [13:34:50] Blanking: VID_00333 (34 of 187)
- [13:34:50] Blanking: VID_00334 (35 of 187)
- [13:34:50] Blanking: VID_00335 (36 of 187)
- [13:34:50] Blanking: VID_00336 (37 of 187)
- [13:34:50] Blanking: VID_00337 (38 of 187)
- [13:34:50] Processing: VID_00800 (39 of 187)
- [13:34:50] Extracting A/V streams [VID_00800]
- [13:41:44] Reencoding video [VID_00800]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 152,256 frames
- Bitrate: 19,686 Kbs
- [13:41:44] Reencoding: VID_00800, Pass 1 of 1
- [14:14:46] Video Encode complete
- [14:14:46] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- Track 4355 (eng): Keeping original audio
- Track 4356 (eng): Keeping original audio
- [14:14:46] Multiplexing M2TS
- [14:24:05] Blanking: VID_50055 (40 of 187)
- [14:24:05] Blanking: VID_50056 (41 of 187)
- [14:24:05] Blanking: VID_50057 (42 of 187)
- [14:24:05] Blanking: VID_50058 (43 of 187)
- [14:24:05] Blanking: VID_50059 (44 of 187)
- [14:24:05] Blanking: VID_50060 (45 of 187)
- [14:24:05] Blanking: VID_50100 (46 of 187)
- [14:24:05] Blanking: VID_50101 (47 of 187)
- [14:24:05] Blanking: VID_50102 (48 of 187)
- [14:24:05] Blanking: VID_50103 (49 of 187)
- [14:24:05] Blanking: VID_50104 (50 of 187)
- [14:24:05] Blanking: VID_50105 (51 of 187)
- [14:24:05] Blanking: VID_50106 (52 of 187)
- [14:24:05] Blanking: VID_50126 (53 of 187)
- [14:24:05] Blanking: VID_50205 (54 of 187)
- [14:24:06] Blanking: VID_50206 (55 of 187)
- [14:24:06] Blanking: VID_50207 (56 of 187)
- [14:24:06] Blanking: VID_50208 (57 of 187)
- [14:24:06] Blanking: VID_50210 (58 of 187)
- [14:24:06] Blanking: VID_50211 (59 of 187)
- [14:24:06] Blanking: VID_50212 (60 of 187)
- [14:24:06] Blanking: VID_50262 (61 of 187)
- [14:24:06] Blanking: VID_50263 (62 of 187)
- [14:24:06] Blanking: VID_50267 (63 of 187)
- [14:24:06] Blanking: VID_50269 (64 of 187)
- [14:24:06] Blanking: VID_50270 (65 of 187)
- [14:24:06] Blanking: VID_50271 (66 of 187)
- [14:24:06] Blanking: VID_50272 (67 of 187)
- [14:24:06] Blanking: VID_50273 (68 of 187)
- [14:24:06] Blanking: VID_50274 (69 of 187)
- [14:24:06] Blanking: VID_50275 (70 of 187)
- [14:24:06] Blanking: VID_50276 (71 of 187)
- [14:24:06] Blanking: VID_50278 (72 of 187)
- [14:24:06] Blanking: VID_50283 (73 of 187)
- [14:24:06] Blanking: VID_50284 (74 of 187)
- [14:24:06] Blanking: VID_50285 (75 of 187)
- [14:24:06] Processing: VID_50286 (76 of 187)
- [14:24:06] Extracting A/V streams [VID_50286]
- [14:24:11] Reencoding video [VID_50286]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 444 frames
- Bitrate: 10,127 Kbs
- [14:24:11] Reencoding: VID_50286, Pass 1 of 1
- [14:24:18] Video Encode complete
- [14:24:18] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [14:24:18] Multiplexing M2TS
- [14:24:22] Processing: VID_50287 (77 of 187)
- [14:24:22] Extracting A/V streams [VID_50287]
- [14:34:49] Reencoding video [VID_50287]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1 frames
- Bitrate: 10,875 Kbs
- [14:34:49] Reencoding: VID_50287, Pass 1 of 1
- [14:34:50] Video Encode complete
- [14:34:50] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [14:34:50] Multiplexing M2TS
- [14:34:53] Processing: VID_50288 (78 of 187)
- [14:34:53] Extracting A/V streams [VID_50288]
- [14:35:00] Reencoding video [VID_50288]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1,385 frames
- Bitrate: 10,132 Kbs
- [14:35:00] Reencoding: VID_50288, Pass 1 of 1
- [14:35:20] Video Encode complete
- [14:35:20] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [14:35:20] Multiplexing M2TS
- [14:35:25] Processing: VID_50289 (79 of 187)
- [14:35:25] Extracting A/V streams [VID_50289]
- [19:01:48] Reencoding video [VID_50289]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1 frames
- Bitrate: 10,875 Kbs
- [19:01:48] Reencoding: VID_50289, Pass 1 of 1
- [19:01:48] Video Encode complete
- [19:01:48] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:01:48] Multiplexing M2TS
- [19:01:52] Processing: VID_50290 (80 of 187)
- [19:01:52] Extracting A/V streams [VID_50290]
- [19:01:57] Reencoding video [VID_50290]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 445 frames
- Bitrate: 10,122 Kbs
- [19:01:57] Reencoding: VID_50290, Pass 1 of 1
- [19:02:03] Video Encode complete
- [19:02:03] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:02:03] Multiplexing M2TS
- [19:02:07] Processing: VID_50292 (81 of 187)
- [19:02:07] Extracting A/V streams [VID_50292]
- [19:02:16] Reencoding video [VID_50292]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1 frames
- Bitrate: 10,875 Kbs
- [19:02:16] Reencoding: VID_50292, Pass 1 of 1
- [19:02:16] Video Encode complete
- [19:02:16] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:02:16] Multiplexing M2TS
- [19:02:20] Processing: VID_50294 (82 of 187)
- [19:02:20] Extracting A/V streams [VID_50294]
- [19:02:25] Reencoding video [VID_50294]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 95 frames
- Bitrate: 10,132 Kbs
- [19:02:25] Reencoding: VID_50294, Pass 1 of 1
- [19:02:26] Video Encode complete
- [19:02:26] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:02:26] Multiplexing M2TS
- [19:02:30] Processing: VID_50295 (83 of 187)
- [19:02:30] Extracting A/V streams [VID_50295]

[NightHawkGuy]

You should be ok with IVTC enabled. I didn't test it with it disabled -- so of course there had to be an issue there. I found it and fixed it for the next release.

Was this an issue using DGDecNV with a bluray that had some MPG2 480i extras titles that used soft pulldown getting audio sync issues?
I believe I got that as well in one of my test runs on a blu-ray that had a bunch of MPG2 480i extras (like deleted scenes) that had pulldown flags.
I had the default setting of ivtc off.

The main source HD title was AVC 1080p 23.976fps and that played back fine with good audio sync. Only the 480i extras with pulldown (originally in MPEG2) played back with audio out of sync after they were encoded into AVC 480i.

I just confirmed this doing a quick run with movie only build with other movie-only playlist of just a 41min 480i with pulldown extras title (deleted scenes).
With ivtc off, deinterlacing off, and using DGDecNV decoding the resulting output was way out of audio sync.
Running the build using regular ffdshow decoding however produced the output with good audio sync.
In both cases I just did a quick run with target size BD-5 and good(veryfast) with ABR 1-pass, no multiprocess.

[jdobbs]

Was this an issue using DGDecNV with a bluray that had some MPG2 480i extras titles that used soft pulldown getting audio sync issues?
I believe I got that as well in one of my test runs on a blu-ray that had a bunch of MPG2 480i extras (like deleted scenes) that had pulldown flags.
I had the default setting of ivtc off.

The main source HD title was AVC 1080p 23.976fps and that played back fine with good audio sync. Only the 480i extras with pulldown (originally in MPEG2) played back with audio out of sync after they were encoded into AVC 480i.

I just confirmed this doing a quick run with movie only build with other movie-only playlist of just a 41min 480i with pulldown extras title (deleted scenes).
With ivtc off, deinterlacing off, and using DGDecNV decoding the resulting output was way out of audio sync.
Running the build using regular ffdshow decoding however produced the output with good audio sync.
In both cases I just did a quick run with target size BD-5 and good(veryfast) with ABR 1-pass, no multiprocess. If you had IVTC turned off and used DGDecNV on a telecined source -- yes, you would likely have sync issues. It is was a true 29.97 interlaced or hard telecined the sync wouldn't be an issue. If you had the default set (IVTC enabled) it should always be in sync.

It is extremely rare that anything is telecined on a blu-ray other than 480i sources (that are usually copes of what was developed for DVD extras) -- so they are pretty much the only ones that would be affected.

[jdobbs]

I was sure INDEX_WITH_EXTRACT is meant but only DGDecNV, but I thought I'd try it.. I'm trying different things to get across that BD-RB 40.04 is not running more than 1 process of x264 on my system now as BD-RB 40.01 and 40.02 did. I'm trying to figure Why. In all the stuff I shared, my computer specs are what I forgot.

Intel i7-930 4 Cores, 8 Threads, Overclocked to 3.17Ghz and absolutely stable, 6GB of RAM. Multiple Hard Drives running at 5700 RPM with an ATI GFX board. I build this computer for power. :) I've exited all programs several times to keep RAM and PageFile free so BD-RB 40.04 could allow/help x264 run multiple process but it only runs 1 x264 process when 40.01 and 40.02 ran 2 to 3 depending on how I set MULTIPROCESS. With my specs, should I only be seeing in TaskManagaer/Processes only 1 process of x264? That is all I see when using 40.04.

Seeing DirectShow (2-way) or (3-way) or even sometimes I see (4-way) indicates to me I should see x264.exe show that many processes in TaskManger/Processes respectively. Correct? Because I am not seeing more than 1 at all with 40.04.

When I run DB-RB 40.04, I ONLY run it. I don't play games. Only...Maybe..Firefox is running...and perhaps Notepad. I keep RAM and CPU available for DB-RB and x264.


I hope this helps. :-D There are several conditions that will make the encode use only one instance -- even when MULTIPROCESS is set to more than one. This includes but isn't limited to:

1. There are less than 5000 frames per segment.
2. There isn't an EP table in the CLPI for collecting SPNs
3. MKV_INTERMEDIATE is enabled.
4. Autocropping is enabled.

[jdobbs]

I have updated the first page of this thread with links to a new version of BD-RB (v0.40.05). Changes for this release:- Corrected an issue with MKV file output. By
default the new MKVMERGE used header compression
that may not be supported by some players. BD-RB
now forces compression to "none" for maximum
player compatibility.
- Corrected a issue in which BD-RB may configure
DGDecNV incorrectly for MPEG-2 pulldown video
that is not being IVTC'd. This could in some
cases result in out-of-sync audio/video.
- Removed the hidden option FIX_CLPI as well as
the associated code. It was only useful for
old outdated versions of TSMUXER that are no
longer used.
- Put a limit of 4 into the automatic multiprocess
value. This is to help prevent too many instances
caused by hyperthreading "pretending" to be more
processors than it really is.
- Corrected an error in which multiprocess splitting
would fail in regions that do not use the same
decimal notation (".") as is used in North America.
- Other minor corrections and cosmetic fixes.

[LowDead]

I have updated the first page of this thread with links to a new version of BD-RB (v0.40.05). Changes for this release:- Corrected an issue with MKV file output. By
default the new MKVMERGE used header compression
that may not be supported by some players. BD-RB
now forces compression to "none" for maximum
player compatibility.
- Corrected a issue in which BD-RB may configure
DGDecNV incorrectly for MPEG-2 pulldown video
that is not being IVTC'd. This could in some
cases result in out-of-sync audio/video.
- Removed the hidden option FIX_CLPI as well as
the associated code. It was only useful for
old outdated versions of TSMUXER that are no
longer used.
- Put a limit of 4 into the automatic multiprocess
value. This is to help prevent too many instances
caused by hyperthreading "pretending" to be more
processors than it really is.
- Corrected an error in which multiprocess splitting
would fail in regions that do not use the same
decimal notation (".") as is used in North America.
- Other minor corrections and cosmetic fixes.

Thank you for the quick fix and taking your time to find it. The split works perfectly now on all rates. Donation for you, kind sir :)

[colinhunt]

Not sure if this is a genuine bug or something else... tested Alternate movie-only output to "MKV Container 720x480/576, 128Kbs AC3", constant rate factor 21. Source was Warner's Malcolm X and specifically its playlist 00204 which contains deleted scenes. The playlist consists of 9 AVC 480i/29.97fps files.

BD-RB version 0.40.04, DGDecNV enabled, multiprocessing disabled, "IVTC Sources with 3:2 pulldown" enabled.

The problem has to do with audio sync. At the start of output audio sync is OK but as the 20min 54sec file playback proceeds, audio begins to go out-of-sync more and more. By the end of the file audio plays ~1 second late.

** update
Re-running the backup with 0.40.05 and noticed that each source file has 5 identical AC3 tracks. BD-RB re-encodes each and every one. I'm guessing the audio sync issue is caused by this (unnecessary AC3 2.0 to AC3 2.0) re-encoding.

** update
Re-ran the backup with 0.40.05 with one difference compared to previous run with 0.40.04: switched from DGDecNV to LAVF. Everything went fine until the "Building ALTERNATE OUTPUT Structure" phase which threw up a "Failed to REBUILD" error.

[NightHawkGuy]

Not sure if this is a genuine bug or something else... tested Alternate movie-only output to "MKV Container 720x480/576, 128Kbs AC3", constant rate factor 21. Source was Warner's Malcolm X and specifically its playlist 00204 which contains deleted scenes. The playlist consists of 9 AVC 480i/29.97fps files.

BD-RB version 0.40.04, DGDecNV enabled, multiprocessing disabled, "IVTC Sources with 3:2 pulldown" enabled.

I had audio sync issues as well as noted before with DGDecNV decoding and 480i pulldown sources (extras, deleted scenes).
I had no audio sync issue when I used regular ffdshow decoding instead with the ivtc option disabled with the 480i pulldown sources, so you might try that in your case.

Also the just released new version of BD Rebuilder may also resolve this using DGDecNV and with ivtc disabled. I'm going to try that new version now with my 480i pulldown deleted scenes again.

[colinhunt]

I had audio sync issues as well as noted before with DGDecNV decoding and 480i pulldown sources (extras, deleted scenes).
I had no audio sync issue when I used regular ffdshow decoding instead with the ivtc option disabled with the 480i pulldown sources, so you might try that in your case.

This is different. If this was caused by pulldown, audio sync would be off by a *lot*. Since the error is only about a second, this is caused by something else. I'm fairly certain the culprit is audio re-encoding in this case.