BD Rebuilder Beta - Bug Reports Only

[laserfan]

I thought I'd try the Alt Output feature to make vids for our iGizmos (used lowest-common denominator "iPod MP4 640x480/360, 128Kbs AAC" profile) and while it worked w/o error, the forced subtitles are not displayed when the movie is played-back. All the WORKFILES suggest goodness, e.g. the forced .sup track was created and looks right timing-wise (I looked at it with BDSup2Sub). I also see in the .INF file that SUBS_TO_KEEP=eng; for whatever that's worth, but I can find nothing about how these files get muxed into an mp4 output file.

How does that happen? If a tool like MP4BOX is used, I see nothing in the workfiles to suggest what command might have been invoked...?

EDIT: Or maybe .sup tracks simply don't work with mp4box? I tried using it manually (cli) and it doesn't let me -add the .sup track "not valid". Do I have to make an .srt file in order to get subtitles to work? Hmmm I guess that should be easy enough, but I'd have thought that BD-RB would handle this automagically...

[jdobbs]

I thought I'd try the Alt Output feature to make vids for our iGizmos (used lowest-common denominator "iPod MP4 640x480/360, 128Kbs AAC" profile) and while it worked w/o error, the forced subtitles are not displayed when the movie is played-back. All the WORKFILES suggest goodness, e.g. the forced .sup track was created and looks right timing-wise (I looked at it with BDSup2Sub). I also see in the .INF file that SUBS_TO_KEEP=eng; for whatever that's worth, but I can find nothing about how these files get muxed into an mp4 output file.

How does that happen? If a tool like MP4BOX is used, I see nothing in the workfiles to suggest what command might have been invoked...?

EDIT: Or maybe .sup tracks simply don't work with mp4box? I tried using it manually (cli) and it doesn't let me -add the .sup track "not valid". Do I have to make an .srt file in order to get subtitles to work? Hmmm I guess that should be easy enough, but I'd have thought that BD-RB would handle this automagically...Yes, MP4BOX is used for the muxing... and no, it doesn't support SUP as a subtitle.

Trying to convert SUP to another format that the MP4 will support would require a lot of human intervention, so I side-stepped it.

I'll check around. It's been a while since I've updated MP4BOX. It's possible a newer version may support SUP files.

[wakko709]

----------------------
[08/22/14] BD Rebuilder v0.47.07 (beta)
[18:13:19] Source: WANDERLUST
- Input BD size: 25.85 GB
- Approximate total content: [02:01:41.168]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Auto Quality: Good (Very Fast), ABR
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[18:13:23] PHASE ONE, Encoding
- [18:13:23] Processing: VID_00022 (1 of 12)
- [18:13:23] Extracting A/V streams [VID_00022]
- [18:13:53] Reencoding video [VID_00022]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 9,740 frames
- Bitrate: 13,679 Kbs
- [18:13:53] Reencoding: VID_00022, Pass 1 of 1
- [18:20:57] Video Encode complete
- [18:20:57] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [18:20:57] Multiplexing M2TS
- [18:21:14] Processing: VID_00023 (2 of 12)
- [18:21:14] Extracting A/V streams [VID_00023]
- [18:36:12] Reencoding video [VID_00023]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 141,145 frames
- Bitrate: 26,043 Kbs
- [18:36:12] Reencoding: VID_00023, Pass 1 of 1
- [19:39:17] Video Encode complete
- [19:39:17] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:39:17] Multiplexing M2TS
- [19:45:27] Processing: VID_00099 (3 of 12)
- [19:45:27] Extracting A/V streams [VID_00099]
- [19:45:35] Reencoding video [VID_00099]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 1,748 frames
- Bitrate: 8,711 Kbs
- [19:45:35] Reencoding: VID_00099, Pass 1 of 1
- [19:46:54] Video Encode complete
- [19:46:54] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:46:54] Multiplexing M2TS
- [19:46:59] Processing: VID_00104 (4 of 12)
- [19:46:59] Extracting A/V streams [VID_00104]
- [19:47:07] Reencoding video [VID_00104]
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 2,247 frames
- Bitrate: 9,886 Kbs
- [19:47:07] Reencoding: VID_00104, Pass 1 of 1
- [19:48:11] Video Encode complete
- [19:48:11] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:48:11] Multiplexing M2TS
- [19:48:16] Processing: VID_00113 (5 of 12)
- [19:48:16] Extracting A/V streams [VID_00113]
- [19:48:25] Reencoding video [VID_00113]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 769 frames
- Bitrate: 13,677 Kbs
- [19:48:25] Reencoding: VID_00113, Pass 1 of 1
- [19:48:54] Video Encode complete
- [19:48:54] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:48:54] Multiplexing M2TS
- [19:48:59] Processing: VID_00114 (6 of 12)
- [19:48:59] Extracting A/V streams [VID_00114]
- [19:49:09] Reencoding video [VID_00114]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 2,328 frames
- Bitrate: 13,678 Kbs
- [19:49:09] Reencoding: VID_00114, Pass 1 of 1
- [19:50:26] Video Encode complete
- [19:50:26] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:50:26] Multiplexing M2TS
- [19:50:32] Processing: VID_00115 (7 of 12)
- [19:50:32] Extracting A/V streams [VID_00115]
- [19:50:38] Reencoding video [VID_00115]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 530 frames
- Bitrate: 13,674 Kbs
- [19:50:38] Reencoding: VID_00115, Pass 1 of 1
- [19:51:01] Video Encode complete
- [19:51:01] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:51:01] Multiplexing M2TS
- [19:51:05] Processing: VID_00116 (8 of 12)
- [19:51:05] Extracting A/V streams [VID_00116]
- [19:51:12] Reencoding video [VID_00116]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 769 frames
- Bitrate: 13,743 Kbs
- [19:51:12] Reencoding: VID_00116, Pass 1 of 1
- [19:51:28] Video Encode complete
- [19:51:28] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:51:28] Multiplexing M2TS
- [19:51:32] Processing: VID_00117 (9 of 12)
- [19:51:32] Extracting A/V streams [VID_00117]
- [19:51:39] Reencoding video [VID_00117]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 769 frames
- Bitrate: 13,683 Kbs
- [19:51:39] Reencoding: VID_00117, Pass 1 of 1
- [19:51:53] Video Encode complete
- [19:51:53] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:51:53] Multiplexing M2TS
- [19:51:57] Processing: VID_00118 (10 of 12)
- [19:51:57] Extracting A/V streams [VID_00118]
- [19:52:04] Reencoding video [VID_00118]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 792 frames
- Bitrate: 15,456 Kbs
- [19:52:04] Reencoding: VID_00118, Pass 1 of 1
- [19:52:27] Video Encode complete
- [19:52:27] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:52:27] Multiplexing M2TS
- [19:52:32] Processing: VID_00119 (11 of 12)
- [19:52:32] Extracting A/V streams [VID_00119]
- [19:52:39] Reencoding video [VID_00119]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 769 frames
- Bitrate: 13,689 Kbs
- [19:52:39] Reencoding: VID_00119, Pass 1 of 1
- [19:53:05] Video Encode complete
- [19:53:05] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [19:53:05] Multiplexing M2TS
- [19:53:09] Processing: VID_00120 (12 of 12)
- [19:53:09] Extracting A/V streams [VID_00120]
- [19:53:18] Reencoding video [VID_00120]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 1,844 frames
- Bitrate: 13,677 Kbs
- [19:53:18] Reencoding: VID_00120, Pass 1 of 1
- Encode failed. Aborting.
- BD-Rebuilder v0.47.07 (beta)
- Windows Version: 6.1 [7601]
- Working Path Free Space: 175.97GB
- AVISYNTH Version: 2.5.8.0, Ok
- HAALI Splitter: 1.9.42.1, Ok
- FFDSHOW: 4504, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- AnyDVD settings check: Ok.
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[19:53:19] - Failed video encode, aborted
any ideas what's going on?
what log files?

[Wizzu]

Hello Jdobbs,

I'm trying to backup my Game of Thrones series (european edition) to BR for convenience. These discs have subtitles.

BD-RB seems to think that there is something wrong with these subtitles and doesn't mux them into the resulting m2ts (see log at the end of the post)

The thing is, I already succeeded in converting several of these titles to BD with DVDtoBD Express 2.0, complete including the subtitles. So I guess the subtitles in themselves aren't really an issue, but something with them "irritates" BD-RB so to speak. ;)

I understand that without taking look at the source you probably can't tell what's wrong, so maybe I can send you some file (but which and how?...)

Regards,

Wizz'

LOG
----------------------
[14:35:41] Importing DVD: GAME_OF_THRONES_SAISON_1
- Processing DVD title [1 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
- Processing DVD title [2 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
[14:39:52] DVD import aborted per user request..

[laserfan]

Yes, MP4BOX is used for the muxing... and no, it doesn't support SUP as a subtitle.

Trying to convert SUP to another format that the MP4 will support would require a lot of human intervention, so I side-stepped it.

I'll check around. It's been a while since I've updated MP4BOX. It's possible a newer version may support SUP files.
Thanks for confirming--I looked at another tool that makes mp4s and it wants an .srt file and then hard-encodes it to the video (so at least I know how to do it now). And I looked at the -help for mp4box and found it mostly incomprehensible!!!

:eek:

Anyway it seems my solution is to use SupRip on the Forced.sup and then tweak the .AVS to hard-code it into the video.

Just my luck for my 1st attempt to use a movie that has some forced subs--will have to pay close attention to that if I decide to make more iGizmo movies with BD-RB. It WAS fast, and looks really good...

[Sharc]

Hello Jdobbs,

I'm trying to backup my Game of Thrones series (european edition) to BR for convenience. These discs have subtitles.

BD-RB seems to think that there is something wrong with these subtitles and doesn't mux them into the resulting m2ts (see log at the end of the post)

The thing is, I already succeeded in converting several of these titles to BD with DVDtoBD Express 2.0, complete including the subtitles. So I guess the subtitles in themselves aren't really an issue, but something with them "irritates" BD-RB so to speak. ;)

I understand that without taking look at the source you probably can't tell what's wrong, so maybe I can send you some file (but which and how?...)

Regards,

Wizz'

LOG
----------------------
[14:35:41] Importing DVD: GAME_OF_THRONES_SAISON_1
- Processing DVD title [1 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
- Processing DVD title [2 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
[14:39:52] DVD import aborted per user request..
Well, I can confirm that BD-RB seems to dislike certain subtitles on (European only?) DVDs.
Same message: Source issue, subtitle ignored.
I didn't dig deeper because I didn't care to much.

[jdobbs]

Hello Jdobbs,

I'm trying to backup my Game of Thrones series (european edition) to BR for convenience. These discs have subtitles.

BD-RB seems to think that there is something wrong with these subtitles and doesn't mux them into the resulting m2ts (see log at the end of the post)

The thing is, I already succeeded in converting several of these titles to BD with DVDtoBD Express 2.0, complete including the subtitles. So I guess the subtitles in themselves aren't really an issue, but something with them "irritates" BD-RB so to speak. ;)

I understand that without taking look at the source you probably can't tell what's wrong, so maybe I can send you some file (but which and how?...)

Regards,

Wizz'

LOG
----------------------
[14:35:41] Importing DVD: GAME_OF_THRONES_SAISON_1
- Processing DVD title [1 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
- Processing DVD title [2 of 10]
- Collecting audio/video/subtitle streams...
- Converting subtitles to BD format...
- Source issue, subtitle 1 ignored.
- Source issue, subtitle 2 ignored.
- Multiplexing audio/video/subtitles...
[14:39:52] DVD import aborted per user request..You'd have to extract the subtitle and send it to me. That's the only way I can think to try processing it short of buying the series. You'd have to grab it from the TEMPIMPORT folder (in your working folder) between the extract and rebuild phases of the IMPORT. After the build of the pseudo-BD structure, BD-RB removes that folder.

It should be small enough to e-mail.

[Wizzu]

You'd have to extract the subtitle and send it to me. That's the only way I can think to try processing it short of buying the series. You'd have to grab it from the TEMPIMPORT folder (in your working folder) between the extract and rebuild phases of the IMPORT. After the build of the pseudo-BD structure, BD-RB removes that folder.

It should be small enough to e-mail.Thanks a lot for the reply. :cool:

I've just e-mailed some of these subtitles to you.

Take care,

Wizz'

[jdobbs]

I have updated the first post in this thread with a link to the newest release of BD-RB (v0.48.01). Changes for this release:- Added FFVideoSource() as the defaut decoding
option. This means that FFDSHOW and HAALI
are no longer required for operation (except
when support for DirectshowSource is forced).
Note: When this option is selected MPEG-2
decoding is accomplished by DGDecode.
- Added a new hidden option DSHOW which will
allow BD-RB to be used with DirectShow, this
would require HAALI and FFDSHOW. It is not
recommended unless problems are encountered
as it may be discontinued in future releases.
- Corrected an error in which Quick-Play title
edits were not kept when the source was not
writable (e.g. mounted ISO or BD Drive).
- Added a checkbox under "Import/Quick-Play
Settings" that instructs BD-RB to apply the
audio/subtitle language filters defined in
the SETTINGS dialog when importing a BD or
DVD source. This allows you to remove any
unwanted audio/subtitle tracks before any
subsequent reencoding/rebuilding.
- Modified video file import routine so that
1440x1080 sources are examined and those
with 16:9 ratio do not have borders added.
- Corrected an error in which 3D M2TS streams
that are used for angles may not be properly
flagged as 3D. This could result in playback
failure when one of the alternate angles,
typically related to non-original language,
is selected.
- Added new hidden option MENU_CUSTOM_COLOR and
added "custom" as a color selection for use
with MENU_ACTIVE_COLOR in Quick-Play and
Import menus. See HIDDENOPTS.TXT.
- Added new hidden option MENU_FONT. This will
allow you to set the font used Quick-Play menus
to be customized with any legal font. Note: Any
specified unavailable font name will result in
the Arial font (the BD-RB default).
- Added an algorithm so that if none of the
audio tracks in your SETUP list is present in
the source, at least one language is kept --
and your chosen default subtitle language is
forced on.
- Added a new hidden option SHUTDOWN_REBOOT that
will reboot rather than shutdown when selected.
See HIDDENOPTS.TXT for more information
- Added the ability to perform IVTC on 720p
sources when forced via the IVTC_SELECTION
hidden operation.
- Fixed an issue in which importing certain oddly
sized video file sources with IMPORT_PAL_TO_NTSC
set can result in illegally sized output.
- Removed bicubic as a resize option. Bicubic
could cause errors and blank video during output
to ALTERNATE selections due to differences in
filter parameter format.
- Updated the included version of X264.EXE to the
latest release (r2453).
- Updated the included version of X264-64.EXE to
the latest release (r2453).
- Other minor corrections and cosmetic fixes.

The update that removes the requirement for HAALI and FFDSHOW will change the installation instructions a bit -- but I want to get this tested a little before editing the instructions. It will also make it easier for me to create an installation executable prior to taking BD-RB out of beta status.

[Ch3vr0n]

Sweet, thanks for adding my reboot option :D

[laserfan]

Yes, MP4BOX is used for the muxing... and no, it doesn't support SUP as a subtitle.

Trying to convert SUP to another format that the MP4 will support would require a lot of human intervention, so I side-stepped it.

I'll check around. It's been a while since I've updated MP4BOX. It's possible a newer version may support SUP files.
jdobbs it seems that between mp4box and yamb they can easily mux .srt files to mp4s (as something called "Timed Text" tx3g format) BUT I can't seem to find a player that plays these subs. Only tried VLC and one other obscure on on my iPad.

It seems the only way (that I have found anyway) to get subtitles to display on my iPad is to hard-code them into the video, which AFAICT means using TextSub(moviename.srt) in the avs script that invokes x264. I do not think this is a BD-RB opportunity myself (owing to the need for OCR i.e. sup-to-srt) but maybe in the future BD-RB can at least incorporate a user's srt into its encoding process.

If anyone here knows a better/different way to do this I'd be glad to hear it, though this belongs in another thread, perhaps jdobbs you can move these posts to Feature Requests.

[soneca]

Very good, thanks for the new version!!!
jdobbs, is difficult to implement this (http://forum.doom9.org/showthread.php?p=1678732#post1678732) request?:(

[jdobbs]

Very good, thanks for the new version!!!
jdobbs, is difficult to implement this (http://forum.doom9.org/showthread.php?p=1678732#post1678732) request?:(Yes. But I'll eventually get it in.

[Sharc]

I have updated the first post in this thread with a link to the newest release of BD-RB (v0.48.01). Changes for this release:
.........
- Corrected an error in which Quick-Play title
edits were not kept when the source was not
writable (e.g. mounted ISO or BD Drive).
- Modified video file import routine so that
1440x1080 sources are examined and those
with 16:9 ratio do not have borders added.
.....

:thanks:

[Ch3vr0n]

Jdobbs, what would you recommend to use with the current release on a book quick synch system, ffvideosource or dgdecnv?

Verstuurd vanaf mijn Nexus 7 met Tapatalk

[musiclover]

Am I correct in thinking that "convert 4:3 to 16:9" and "Widen 4:3 Viewing" only are working in full backup mode? Because I can't get it to work in alternate movie-only output. If I'm correct in this should it not say so in the video encoding options?

Thank you for an amazing program.

[jdobbs]

Am I correct in thinking that "convert 4:3 to 16:9" and "Widen 4:3 Viewing" only are working in full backup mode? Because I can't get it to work in alternate movie-only output. If I'm correct in this should it not say so in the video encoding options?

Thank you for an amazing program.It works for full-backup and movie-only backup modes. But, the size of the output in ALTERNATE mode is determined by the preset. So none of the SETUP resizing settings should affect it.

What I might be able to do is add a mode to the presets that does those conversions.

[musiclover]

It works for full-backup and movie-only backup modes. But, the size of the output in ALTERNATE mode is determined by the preset. So none of the SETUP resizing settings should affect it.

What I might be able to do is add a mode to the presets that does those conversions.

That would be great. Thanx

[jdobbs]

Jdobbs, what would you recommend to use with the current release on a book quick synch system, ffvideosource or dgdecnv?

Verstuurd vanaf mijn Nexus 7 met TapatalkI'd experiment, as it seems to be quite different from system to system. Generally you're better off with DGDECNV, especially if you enable multiple instances. But on a quick-sync system you may find FRIMSource to be faster.

I can't really say for sure, as I don't have a quick-sync enabled system.

[colinhunt]

Hello folks,

based on my first run with the 0.48.01 (using the new FFVideoSource default) I can say it's a lot slower than 0.47.07.

I set up an encode last night at 3:40. A similar encode, using my Super High Quality settings, on the 0.47.07 would take approx. 5-6 hours... but 0.48.01 is still running, more than 13 hours later. It's now at 91,18% and ETA is 2 hours and 6 minutes, so total processing time will be more than 15 hours.

I'll let it finish to see what the output looks like, but it certainly appears that FFVideoSource is not a good choice for my system.

[jdobbs]

Hello folks,

based on my first run with the 0.48.01 (using the new FFVideoSource default) I can say it's a lot slower than 0.47.07.

I set up an encode last night at 3:40. A similar encode, using my Super High Quality settings, on the 0.47.07 would take approx. 5-6 hours... but 0.48.01 is still running, more than 13 hours later. It's now at 91,18% and ETA is 2 hours and 6 minutes, so total processing time will be more than 15 hours.

I'll let it finish to see what the output looks like, but it certainly appears that FFVideoSource is not a good choice for my system.It shouldn't be slower. Something else is likely wrong.

Add DSHOW=1 to your INI and deselect FFVideoSource. I think you'll find the speed similar for the same source.

[colinhunt]

It shouldn't be slower. Something else is likely wrong.
I think it's partly because the mandatory indexing done by FFVS takes a long time over LAN from a NAS box, and partly because I can see that during pass 2 x264 does not use 100% of available CPU power, like it does on the 0.47.07.

[jdobbs]

I think it's partly because the mandatory indexing done by FFVS takes a long time over LAN from a NAS box, and partly because I can see that during pass 2 x264 does not use 100% of available CPU power, like it does on the 0.47.07. The LAN shouldn't make that much of a difference, unless it is slow -- and the indexing happens concurrently with the extraction. It could possibly be the fact that the implementation of FFVideoSource doesn't currently support multiple instances -- but when you're running super-high quality settings it is X264 that is the limiting factor. Any frame-server should be able to keep up.

I'll add multi-processing support for FFVideoSource in a later release -- but first I wanted to get some testing done against a lot of sources.

[colinhunt]

The LAN shouldn't make that much of a difference, unless it is slow -- and the indexing happens concurrently with the extraction. It could possibly be the fact that the implementation of FFVideoSource doesn't currently support multiple instances -- but when you're running super-high quality settings it is X264 that is the limiting factor. Any frame-server should be able to keep up.
Hmm. All I know is that CPU utilization on the 0.48.01 hovers around 60-65% at the moment, during pass 2, when on 0.47.07 the utilization during pass 2 tends to hover way above 90%. As for the indexing/extraction time, I'll have to check logs to compare. It feels like it's taking forever on the 0.48.01 but it could be the "boiling pot" phenomenon in action.

[colinhunt]

Here's some actual data from logs.

0.47.07
Show length: 102 845 frames
Extraction phase: 2 min 48 sec
Pass 1: 23 min 48 sec
Pass 2: 165 min 25 sec

0.48.01 (FFVS enabled)
Show length: 103 546 frames
Extraction phase: 9 min 39 sec
Pass 1: 45 min 08 sec
Pass 2: 169 min 14 sec

The file processed by 0.48.01 is 701 frames longer, which adds about a minute to its pass 2. Turns out the biggest differences in time are in extraction and especially in pass 1.

I'll keep an eye out for the CPU utilization during pass 2 when running the next encode with FFVS deselected. Also, I can see from the logs that the encoding job I was thinking of (disc 3 of a 3-disc box) took 8 hours on 0.47.07, not 5-6 hours, and the disc had less content on it than the disc being backupped by the 0.48.01 now. D'oh!

Taking that into account, this disc would have taken 11 hours to process on the 0.47.07. So, 0.48.01 is approx. 4 hours slower on the same system, with all things being more or less equal.

[jdobbs]

They're two different sources. You can't come to any conclusions at all!!!

Configure the settings I gave you so you can run DirectshowSource with 48.01, run it again, and tell me how it comes out.with all things being more or less equal This is a very inaccurate statement.

[colinhunt]

They're two different sources. You can't come to any conclusions at all!!!
They are very similar, even though they are not the same. Different discs of the same tv show box.

I've got 48.01 running the same disc now, with LAVF decoding/frame serving instead of FFVS.

First data point:

0.48.01 (FFVS enabled)
Show length: 103 546 frames
Extraction phase: 9 min 39 sec
Pass 1: 45 min 08 sec

0.48.01 (LAVF)
Show length: 103 546 frames
Extraction phase: 2 min 39 sec
Pass 1: 22 min 12 sec

[musiclover]

After deselecting FFVideoSource I cannot reselect it again. The message "A path to DGIndexIM.EXE is required in order to select this option" appears. How can I remedy that? DGIndexIM.EXE is not on my system.

[jdobbs]

After deselecting FFVideoSource I cannot reselect it again. The message "A path to DGIndexIM.EXE is required in order to select this option" appears. How can I remedy that? DGIndexIM.EXE is not on my system.Hmmm... that's weird. I just tested it on my system and I can select/deselect with no issues.

[jdobbs]

They are very similar, even though they are not the same. Different discs of the same tv show box.

I've got 48.01 running the same disc now, with LAVF decoding/frame serving instead of FFVS.

First data point:

0.48.01 (FFVS enabled)
Show length: 103 546 frames
Extraction phase: 9 min 39 sec
Pass 1: 45 min 08 sec

0.48.01 (LAVF)
Show length: 103 546 frames
Extraction phase: 2 min 39 sec
Pass 1: 22 min 12 secThis isn't a debating club. It's a bug reporting thread. Now you've decided to run a completely different scenario than I suggested. Do you want to fix it or not? I'm not going to keep jumping through hoops just because you don't want to follow instructions. Until you do so, you won't get any more help...

[musiclover]

Hmmm... that's weird. I just tested it on my system and I can select/deselect with no issues.

And do you have DGIndexIM.EXE and DGDecodeIM.dll on your system? Because without the path for both files I am stuck on the setting UI. As a temporary solution I have made copies of DGIndex.EXE and DGDecode.dll and renamed them so I could get out of the settings UI.

[jdobbs]

And do you have DGIndexIM.EXE and DGDecodeIM.dll on your system? Because without the path for both files i am stuck on the setting UI.Could be. I'll remove them and see what happens.

[Edit] Yep. That's it. There was some left-over code there from when I included DGDecIM. I'll fix that and get another release out today.

[colinhunt]

This isn't a debating club. It's a bug reporting thread. Now you've decided to run a completely different scenario than I suggested. Do you want to fix it or not? I'm not going to keep jumping through hoops just because you don't want to follow instructions. Until you do so, you won't get any more help...
A misunderstanding, clearly. I wasn't reporting a bug, per se, only reporting that FFVS resulted in longer processing times on my setup. I didn't consider it a bug, only a slower method of doing the same thing.

My apologies for not realizing you considered it a bug and wanted me to test something specific. I've used only LAVF for ages, and that's what I was comparing to earlier. I'll run the job again, with DSS.

[omegaman7]

A misunderstanding, clearly. I wasn't reporting a bug, per se, only reporting that FFVS resulted in longer processing times on my setup. I didn't consider it a bug, only a slower method of doing the same thing.

My apologies for not realizing you considered it a bug and wanted me to test something specific. I've used only LAVF for ages, and that's what I was comparing to earlier. I'll run the job again, with DSS.

I'm noticing some slowness myself lol. Extracting a 200Mb file, took 4+ minutes. But then later, files much larger, were significantly quicker. Audio encoding seems rather slow, but I've never really paid any attention to it. I'll compare different encodes.

Clearly, in the 'stream' tab, it's showing the video size only. It's not accounting for the audio track size. The extraction was larger than I realized. Oddly, it's still curious that something of 1700 frames, would extract slower, than a 70+ thousand frame stream.

[colinhunt]

Hmmh. Like I said, it's been ages since I last used DirectShow, and it certainly shows:

[08.24.14] BD Rebuilder v0.48.01 (beta)
[21:23:12] Source: THEWHITEQUEEN_D2
- Input BD size: 44,94 GB
- Approximate total content: [03:57:20.926]
- Target BD size: 23,73 GB
- Windows Version: 6.1 [7601]
- Quality: Ultra High Quality (Extremely Slow), Two Pass
- X264 Tweak(s) enabled (< --tune film)
- Output folder: U:\_ENCODES\
- Decoding/Frame serving: DirectShow
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
- Resuming from previously started job. (<-- extraction done on previous attempt which ended the same as this)
[21:23:14] PHASE ONE, Encoding
- [21:23:14] Processing: VID_00001 (1 of 10)
- [21:23:14] Reencoding video [VID_00001]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 29,970fps, 103*546 frames
- Bitrate: 10*334 Kbs
- [21:23:14] Reencoding: VID_00001, Pass 1 of 2
- Encode failed. Aborting.
- BD-Rebuilder v0.48.01 (beta)
- Windows Version: 6.1 [7601]
- Working Path Free Space: 391,09GB
- AVISYNTH Version: 2.5.8.0, Ok
- HAALI Splitter: 1.11.96.14, Ok
- FFDSHOW: 4504, Ok
- WIN7 preferred AVC CODEC: Ok
- WIN7 preferred VC-1 CODEC: Ok
- WIN7 preferred MPEG2 CODEC: Ok
- FFDSHOW VC-1 set to "wmv9", Ok
- FFDSHOW MPEG2 set to "libavcodec": Ok
- FFDSHOW AVC set to "libavcodec": Ok
- X264: Ok
- AFTEN: Ok
- FAAC: Ok
- MP4BOX: Ok
- WAVI: Ok
- TSMUXER: Ok
- FRIMEncode: Ok
- FRIMDecode: Ok
[21:23:15] - Failed video encode, aborted

Filters checked with Win7DSFilterTweaker. Not a 32-bit/64-bit clash (only 32-bit FFDShow installed, BD-RB tries to run 32-bit x264). Re-installed FFDShow, didn't help either.

[jdobbs]

Hmmh. If it's been ages since you used DirectshowSource -- then to what are you comparing FFVideoSource? It is meant as a replacement for DirectshowSource -- so how it compares to anything else is inconsequential.

[jdobbs]

I'm noticing some slowness myself lol. Extracting a 200Mb file, took 4+ minutes. But then later, files much larger, were significantly quicker. Audio encoding seems rather slow, but I've never really paid any attention to it. I'll compare different encodes.

Clearly, in the 'stream' tab, it's showing the video size only. It's not accounting for the audio track size. The extraction was larger than I realized. Oddly, it's still curious that something of 1700 frames, would extract slower, than a 70+ thousand frame stream.I can't imagine why it would take 4 minutes to do a 200MB file.

Audio encoding hasn't changed at all.

The stream tab shows the size of the M2TS file.

[colinhunt]

Hmmh. If it's been ages since you used DirectshowSource -- then to what are you comparing FFVideoSource? It is meant as a replacement for DirectshowSource -- so how it compares to anything else is inconsequential.
I compared it to LAVF, which I've been using for the longest time. I figured there was a reason, like a speed or compatiblity gain, behind BD-RB's switch to FFVS as default, and wanted to try it out. That's all there is to it.

[jdobbs]

????? You're missing the point. If you like LAVF keep using it... but comparing LAVF to FFVideoSource is apples to oranges. In previous versions DirectshowSource was the default.

How can you say:...based on my first run with the 0.48.01 (using the new FFVideoSource default) I can say it's a lot slower than 0.47.07.Both versions have LAVF -- so saying there is a speed difference between versions is entirely wrong unless you compare LAVF to LAVF.

No more debating. If you have a bug, report it. Otherwise post in a different thread. The next "I need to prove I'm right" post that serves no purpose will result in a strike. I have better things to do than run down rabbit holes.

[colinhunt]

No more debating. If you have a bug, report it. Otherwise post in a different thread. The next "I need to prove I'm right" post that serves no purpose will result in a strike. I have better things to do than run down rabbit holes.
Yeah, don't worry about it. The receptacle reserved for condescension runneth over; I won't make another peep.

[omegaman7]

Interesting. FFvideosource took 43min, where DGDecNV took slightly over an hour :S I suspect my GPU was bottle necking.

Forget what I said about the extraction process. There's clearly more to it than meets MY eye lol.

I've never seen two MP4 outputs be bit for bit the same size :S Looks like I'm sticking with FFvideosource for the time being :)

[jdobbs]

Yeah, don't worry about it. The receptacle reserved for condescension runneth over; I won't make another peep.It's not condescending when someone calls you on making incorrect statements like "0.48.01 [is] ...a lot slower than 0.47.07" when you have changed frame-serving modes and are working on two different sources. Continually defending those incorrect statements with more incorrect/inaccurate statments only makes you look worse.

[jdobbs]

Interesting. FFvideosource took 43min, where DGDecNV took slightly over an hour :S I suspect my GPU was bottle necking.

Forget what I said about the extraction process. There's clearly more to it than meets MY eye lol.

I've never seen two MP4 outputs be bit for bit the same size :S Looks like I'm sticking with FFvideosource for the time being :)Interesting. In my tests I've found DGDecNV to be slightly faster (when multiple instances are in use). Most of the speed gain happens in pass one. Did you have MULTIPROCESS enabled? What kind of source was it (VC-1, AVC, or MPEG)?

[omegaman7]

Interesting. In my tests I've found DGDecNV to be slightly faster (when multiple instances are in use). What kind of source was it (VC-1, AVC, or MPEG)?

I stopped testing multiple instances a while back. There seemed to be diminished returns. Perhaps I'll set it for auto, for Gits and shiggles lol.

[jdobbs]

I stopped testing multiple instances a while back. There seemed to be diminished returns. Perhaps I'll set it for auto, for Gits and shiggles lol.It may not matter... it depends on your video card. I played with it and decided a setting of "3" works best on mine. It all depends where you CPU usage sits. If you are using less than 90% or so it can usually help. If not, there's little to be gained.

[jdobbs]

I have updated the first post of this thread with a link to the newest version of BD-RB (v0.48.02). Changes for this release:- Corrected an issue in which some DVD subtitle
imports could result in "Source issue, subtitle
n ignored"
- Corrected an issue in which deselecting and
then attempting to select "FFVideoSource" as
the frame server (from the SETUP dialog) would
cause an attempt to browse for DGDecIM.
- Made some modifications to the way in which
IVTC from the streams list is handled.
- Other minor corrections and cosmetic fixes.

Thanks to musiclover for pointing out the issue with selecting FFVideoSource and Wizzu for providing example files for the sup conversion error.

[soneca]

Interesting. In my tests I've found DGDecNV to be slightly faster (when multiple instances are in use). Most of the speed gain happens in pass one. Did you have MULTIPROCESS enabled? What kind of source was it (VC-1, AVC, or MPEG)?

Here the speed difference is still very large.

http://s20.postimg.org/x9hc2wo3x/bd_ffvideosource.png http://s20.postimg.org/k6lpjmxvx/bd_dgdecnv.png

Edit: Multiple instances are not activated when the FFVideoSource is defined.

[jdobbs]

Yeah. That's probably typical... but since pass one uses a lot less time (a smaller percentage of the complete encode time) than pass two, the overall time is reduced by less. Compare the total encoding time after the end of pass 2 and let me know how the difference.

Currently FFVideoSource doesn't use multiple instances (mainly because it isn't frame accurate with an M2TS source).

[wakko709]

----------------------
[08/24/14] BD Rebuilder v0.48.01 (beta)
[14:57:26] Source: UNDER_THE_DOME_SEASON_1_DISC_3
- Input BD size: 23.48 GB
- Approximate total content: [02:08:53.642]
- Target BD size: 22.95 GB
- Windows Version: 6.1 [7601]
- Auto Quality: Good (Very Fast), ABR
- Decoding/Frame serving: FFVideoSource
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[14:57:29] PHASE ONE, Encoding
- [14:57:29] Processing: VID_00000 (1 of 4)
- [14:57:29] Extracting A/V streams [VID_00000]
- [14:59:27] Reencoding video [VID_00000]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 60,262 frames
- Bitrate: 19,899 Kbs
- [14:59:27] Reencoding: VID_00000, Pass 1 of 1
- [15:52:26] Video Encode complete
- [15:52:26] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [15:52:26] Multiplexing M2TS
- [15:56:47] Processing: VID_00001 (2 of 4)
- [15:56:47] Extracting A/V streams [VID_00001]
- [15:58:29] Reencoding video [VID_00001]
- Source Video: MPEG-4 (AVC), 1920x1080
- Rate/Length: 23.976fps, 59,353 frames
- Bitrate: 21,235 Kbs
- [15:58:29] Reencoding: VID_00001, Pass 1 of 1
- [16:47:53] Video Encode complete
- [16:47:53] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [16:47:53] Multiplexing M2TS
- [16:52:06] Processing: VID_00002 (3 of 4)
- [16:52:06] Extracting A/V streams [VID_00002]
- [16:54:20] Reencoding video [VID_00002]
- [16:54:20] Keeping original video (no reencode)
- [16:54:20] Processing audio tracks
- Track 4352 (eng): Keeping original audio
- [16:54:20] Multiplexing M2TS
- Error in attempt to multiplex: MUX_00002.meta
- Can't open file: C:\WORKFILES\VID_00002.AVS.264
[16:54:23] - Failed to build structure, aborted
anyone got any ideas?

[jdobbs]

It says VID_00002.AVS.264 is missing. Is it?