Log in

View Full Version : Target Way To Small

Elvispookie
4th December 2009, 07:07
This is the first time after about 30 compressions that i have run into a problem.. Using Forrest Gump (movie only -34.1GB) I ended up with a movie that was 5.77GB after the processed finished. I was setup for BD-25 on single pass CRF. Here is my log:

[17:25:40] BD Rebuilder v0.31.02 (beta)
- Source: FORREST_GUMP_D1_AC
- Input BD size: 34.15 GB
- Approximate total content: [02:22:09.395]
- Target BD size: 22.46 GB
- Windows Version: 5.1 [2600]
- MOVIE-ONLY mode enabled
- Audio Settings: AC3=0 DTS=0 HD=1 Kbs=640
- Resuming from previously started job.
[17:25:42] PHASE ONE, Encoding
- [17:25:42] Reencoding: VID_00004 (1 of 1)
- [17:25:42] Collecting video information
- Video: 1920x1080, 23.976fps, 204,501 frames
- [17:25:42] Performing CRF Prediction...
- Analyzing 20.97 [35.49]
- [17:31:59] Encoding using constant rate factor.
- [00:13:45] Video Encode complete
- [00:13:45] Reencoding audio tracks (if req'd)
- [00:13:46] Multiplexing M2TS
[00:15:41]PHASE ONE complete
[00:15:41]PHASE TWO - Rebuild Started
- [00:15:41] Rebuilding BD file Structure
[00:28:19] - Encode and Rebuild complete
- WORKFILES folder removed.
[00:28:19]JOB: FORREST_GUMP_D1_AC finished.


And my setup info

[Status]
LABEL=FORREST_GUMP_D1_AC
VERSION=v0.31.02 (beta)
SOURCE_SIZE=36673142784
SOURCE_VIDEO_SIZE=36673142784
TARGET_SIZE=24117248000
REDUCTION=.657626976287454
RESIZE_1080=0
AUDIO_TO_KEEP=eng;
SUBS_TO_KEEP=eng;
BACKUP_MODE=1
QUICK=0
ENCODE_STEP=0
COMPLETED=1
REBUILD_COMPLETE=1
[00004]
AUDIO=10000
PGS=10000
M2TS_TARGET=24117248000
NSIZE=1347416064
FLINK=0
MLINK=0

I dont see anything wrong in the setup and again this is truly the first time this has happened. Any suggestions?
Elvispookie
4th December 2009, 16:17
Nevermind, I think I found the answer from another post on here. FFDShow apparently needs to be an older version or something. Strange how this worked fine on Terminator Salvation but not on Gump. Oh well, compressing is like a box of chocolates I guess...
jdobbs
4th December 2009, 17:32
Nevermind, I think I found the answer from another post on here. FFDShow apparently needs to be an older version or something. Strange how this worked fine on Terminator Salvation but not on Gump. Oh well, compressing is like a box of chocolates I guess... Use the version referenced on the first page of the bug reports thread and you won't go wrong.
Elvispookie
4th December 2009, 18:26
Thanks for the response JDobbs.. unfortunately the one that is referenced is the one I have. v.3133 from Nov 17. I recently downloaded that and have encountered the problem. I read in another post to not use the most current version and to go back to version 2857.

Could that possibly be right? I want to take the chance on that because this is the one time since the FFDShow upgrade that it caused the small file.
jdobbs
4th December 2009, 19:38
I guess its always a possibility -- but I've been using that one for a while now and I haven't had any issues with undersizing. I do know that a previous version in the same month was causing crashing on Win7 64 bit.
Elvispookie
4th December 2009, 21:45
Thanks for the reply JDobbs. I will revert back and see if the problem resolves itself. At the very least it could eliminate a post or 2 on here regarding this.

I will post back here when I see the results. Thanks again for the awesome product.
Elvispookie
6th December 2009, 03:16
As expected version 2857 made no difference. I think it might be something with the movie (Forrest Gump). One thing I have noticed was the CRF prediction. I usually get 4 or 5 passes to determine the rate.. this time was just one each time. I dont know how much that has to do with anything but that is about the only difference.
I ran another movie through today and it worked fine. So again, I am just going to chalk it up to the movie and move on. Maybe one day I will come back to it.
jdobbs
6th December 2009, 04:52
Hmm... I just noticed that. It really shouldn't be possible for this:

- Analyzing 20.97 [35.49]

to happen. That's too big a jump for the selection to be made...
Sharc
6th December 2009, 09:14
@jdobbs
I noticed that there is often a huge swing between the initial crf[0] and the first calculated crf[1].
I found that the the following formula can bring the crf[1] closer to the final value:
crf[1] = crf[0]-8.4*log(target_file_size/actual_file_size)
or equivalent
crf[1] = crf[0]-8.4*log(target_bitrate/actual_bitrate)
My experience is mostly with BD5 media and 720p.
Category 5
10th December 2009, 20:10
Had this same problem on Brothers Bloom BD. Never did figure out a solution to the problem.