BD Rebuilder crf=18 output file size variation

[ilancas]

Hi,

I just want to check something:

I have encoded "The TIme Traveller's Wife" twice with BD Rebuilder using identical settings (movie only mode), except that one specified High Quality (Default) and the other Better (Faster). I'm specifying FIXED_CRF=18 since I'm concerned with quality, not output file size (within reason).

Now, the Default option gives a NSIZE=8679327744, but the Faster option NSIZE is 6019713024.

Is such a large variation to be expected?


[15:36:27] BD Rebuilder v0.37.03 (beta)
- Source: TIMETRAVELERSWIFE
- Input BD size: 15.93 GB
- Approximate total content: [01:47:25.063]
- Target BD size: 10.00 GB
- Windows Version: 6.1 [7600]
- MOVIE-ONLY mode enabled
- Quality: High Quality (Default), CRF
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[15:36:30] PHASE ONE, Encoding
- [15:36:30] Extracting A/V streams [VID_00000]
- [15:39:41] Reencoding: VID_00000 (1 of 1)
- [15:39:41] Collecting video information
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 154,527 frames
- [15:39:41] Performing CRF Prediction...
- [15:39:41] Encoding using constant rate factor.
- [18:39:39] Video Encode complete
- [18:39:40] Reencoding audio tracks (if req'd)
- [18:39:40] Multiplexing M2TS
[18:44:06]PHASE ONE complete
[18:44:06]PHASE TWO - Rebuild Started
- [18:44:06] Rebuilding BD file Structure
[18:48:05] - Encode and Rebuild complete
- WORKFILES folder removed.
[18:48:06]JOB: TIMETRAVELERSWIFE finished.


[Status]
LABEL=TIMETRAVELERSWIFE
VERSION=v0.37.03 (beta)
SOURCE_SIZE=17105338368
SOURCE_VIDEO_SIZE=17105338368
TARGET_SIZE=10737418240
REDUCTION=.627723229380083
RESIZE_1080=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=-1
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00000]
AUDIO=10
PGS=1
M2TS_TARGET=10737418240
NSTART=27000000
NEND=317027520
NSIZE=8679327744
FLINK=0
MLINK=0



[13:05:39] BD Rebuilder v0.37.03 (beta)
- Source: TIMETRAVELERSWIFE
- Input BD size: 15.93 GB
- Approximate total content: [01:47:25.063]
- Target BD size: 10.00 GB
- Windows Version: 6.1 [7600]
- MOVIE-ONLY mode enabled
- Quality: Better (Faster), CRF
- Audio Settings: AC3=0 DTS=0 HD=0 Kbs=640
[13:05:39] PHASE ONE, Encoding
- [13:05:39] Extracting A/V streams [VID_00000]
- [13:08:00] Reencoding: VID_00000 (1 of 1)
- [13:08:00] Collecting video information
- Source Video: VC-1, 1920x1080
- Rate/Length: 23.976fps, 154,527 frames
- [13:08:00] Performing CRF Prediction...
- [13:08:00] Encoding using constant rate factor.
- [14:43:38] Video Encode complete
- [14:43:39] Reencoding audio tracks (if req'd)
- [14:43:39] Multiplexing M2TS
[14:46:46]PHASE ONE complete
[14:46:46]PHASE TWO - Rebuild Started
- [14:46:46] Rebuilding BD file Structure
[14:49:20] - Encode and Rebuild complete
- WORKFILES folder removed.
[14:49:21]JOB: TIMETRAVELERSWIFE finished.


[Status]
LABEL=TIMETRAVELERSWIFE
VERSION=v0.37.03 (beta)
SOURCE_SIZE=17105338368
SOURCE_VIDEO_SIZE=17105338368
TARGET_SIZE=10737418240
REDUCTION=.627723229380083
RESIZE_1080=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
BACKUP_MODE=1
MOVIEONLY_TYPE=0
USE_LAVF=-1
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00000]
AUDIO=10
PGS=1
M2TS_TARGET=10737418240
NSTART=27000000
NEND=219552358
NSIZE=6019713024
FLINK=0
MLINK=0

[ilancas]

Well, I can answer my own question, but I don't understand. The version encoded with "Better" outputs at only 1hr 11 minutes! i.e. the movie ends 2/3 the way through!

How the hell did that happen? DB Rebuilder's log shows it encoded successfully.

Looking again at the .INF files, NEND is wrong on the second example.

I think I'll run it through on Better again to see what happens.

[ilancas]

Well, it looks like it's going to remain a mystery. The rerun produced the expected movie length/file size.

Is it possible that something else that I was doing on my PC could have adversely affect BD Rebuilder such that it stopped encoding prematurely without realising that an error situation had been encountered?

[jdobbs]

It's possible that X264 crashed midstream but no error was returned. Any chance you are overclocked? That's the usual culprit for that kind of behavior.

[ilancas]

Yes, I am overclocked, but Prime stability checked for 48hrs+.

If X264 can crash without BD Rebuilder being notified then I will in future double check movie lengths after every encode since theoretically it could happen, overclocked or not, without warning.

Perhaps there's a double check you could put in the program, say number frames in encoded stream equals frames expected?

[jdobbs]

Yes, I am overclocked, but Prime stability checked for 48hrs+.

If X264 can crash without BD Rebuilder being notified then I will in future double check movie lengths after every encode since theoretically it could happen, overclocked or not, without warning.

Perhaps there's a double check you could put in the program, say number frames in encoded stream equals frames expected?It's rare that crashing without notification can happen... but it can. Normally only when overclocking is the issue.

Prime stability doesn't do the trick. X264 will find issues that aren't found in Prime... I've seen it happen over-and-over and the symptom is always exactly as you've described. Try backing down your speed slightly and you'll likely never see the problem again. It sounds like you don't want to accept this -- but I'm just telling you the facts.

[ilancas]

I do accept what you say and had already backed off my overclock.

All I was saying was that it doesn't seem satisfactory that BDRB can be unaware that X264 has encountered a problem. Is it not conceivable that it could in future glitch for reasons other than overclocking?

[jdobbs]

I do accept what you say and had already backed off my overclock.

All I was saying was that it doesn't seem satisfactory that BDRB can be unaware that X264 has encountered a problem. Is it not conceivable that it could in future glitch for reasons other than overclocking? Normally errors are returned by X264... and BD-RB picks them up. But it is unpredictable what might happen in an overclocking situation -- because everything is unpredictable when the processor glitches.