RB v1.26 bitrate redistribution

[mc2man]

using cce with any high bit rate matix will cause 1 or more segments to abort. Which segment(s) are affected changes with the matrix used and the available space for video, i.e. how many audio streams kept.
for example with
fox h.keeping all audio - seg.15
fox h. 1 ac3 - seg, 0, seg. 15, seg. 16
high_med. with all audio - seg.17, seg. 15
high_med with 1 ac3 - seg. 1, seg. 15, seg. 17,
ect., ect.
all these seg. have high bitrate swings from 3-8+
Using the default matrix produces no aborts with only some minor variances with cceaqm on or off

[Carpo]

so is it safe to assume that we should not use any matrix other than the dvdrb default if we are to use the redist option ?

[Sharc]

@mc2man
I would bet if you were using the Q from RB-Opt you won't run into the abortion problem even with a high bitrate matrix. The Q will be much higher compared to DVD-RB, though.

[jdobbs]

That's hardly the point. CCE shouldn't crash -- and that's where the error is. In similar circumstances RBOpt will very probably do the same thing!!!

Can you post the matrix that was used?

[jdobbs]

so is it safe to assume that we should not use any matrix other than the dvdrb default if we are to use the redist option ?
Don't know that for a fact. The problem is that there are so many matrices out there -- you never know whether they are even using legal values. Let me get ahold of the matrix and test it.

My guess (but only a guess) would be that any of the "standard" matrices would likely work just fine.

[archaeo]

That's hardly the point. CCE shouldn't crash -- and that's where the error is. In similar circumstances RBOpt will very probably do the same thing!!!

Can you post the matrix that was used?

Yes, here's the matrix that was used for the encode:

08 08 10 11 13 14 15 17
08 08 11 12 14 15 17 19
10 11 13 14 15 17 17 19
11 11 13 14 15 17 19 20
11 13 14 15 16 18 20 24
13 14 15 16 18 20 24 29
13 14 15 17 19 23 28 35
14 15 18 19 23 28 35 42

08 09 09 10 10 11 11 12
09 09 10 10 11 11 12 12
09 10 10 11 11 12 12 13
10 10 11 11 12 12 13 14
10 11 11 12 13 13 14 14
11 11 12 12 13 14 14 15
11 12 12 13 14 14 15 16
12 12 13 14 14 15 16 17


Original (I believe identical, unless I missed a value):

08 08 10 11 13 14 15 17
08 08 11 12 14 15 17 19
10 11 13 14 15 17 17 19
11 11 13 14 15 17 19 20
11 13 14 15 16 18 20 24
13 14 15 16 18 20 24 29
13 14 15 17 19 23 28 35
14 15 18 19 23 28 35 42

08 09 09 10 10 11 11 12
09 09 10 10 11 11 12 12
09 10 10 11 11 12 12 13
10 10 11 11 12 12 13 14
10 11 11 12 13 13 14 14
11 11 12 12 13 14 14 15
11 12 12 13 14 14 15 16
12 12 13 14 14 15 16 17


*AQM enabled for all tests

[jdobbs]

Hmmm... it looks like all the values are approximately cut in half from the standard MPEG matrix. One thing I can say -- this probably isn't the right matrix for the bitrates I'm seeing in this example... but then on the other hand, they really should crash CCE.

[mc2man]

the orig. source uses cceaqm matrices, i.e. mpeg standard, 1/2, 1/4

[Boulder]

Would it be an reasonable option to always check whether the encoded m2v file really has the correct number of frames? It shouldn't make the process that much slower. It would also be useful in cases when the kids have been messing with the computer and I'm never sure whether all segments have been correctly encoded. My projects usually tend to take more than 24hrs to finish so I have to leave the encoding process running while I'm at work.

[robot1]

What about changing the base_q according to the matrix used?
I know it's not a linear process, but maybe it's possible to find a good compromise to change the base_q proportionally to the average of the values in the matrices, for example.

[kumi]

I would go one step further and ask for a Q-calculation pass a la RBOpt, IMO the added time required is well worth it. The way it works now doesn't inspire much confidence: non-identical (sub-optimal?) redistributions dependant on matrix choice.

[mc2man]

non withstanding that multiple prep runs on same source will produce slightly different results I think the behavior on this title will prove to be fairly rare and hard to miss/ignore

[jdobbs]

I just don't seem to be sinking in... no matter how you do this you still have the problem that CCE will crash with certain combinations of matrices and q values. If I redo the Q value for this one, and it goes away -- it will return with another disc. It could just as easily have happened to RBOpt and not DVD-RB... it all depends on the combination. The problem has to either be fixed in CCE, or another encoder (HC?) has to be used for the redistribution.

Scanning each resulting M2V to count frames will double the PREPARE phase time -- and the odds are that retrying it again will only get the same crash.

[Sharc]

.....In similar circumstances RBOpt will very probably do the same thing!!!

YES, if you set in RB-Opt the same (low) Base_Q as for DVD-RB, and NO, if you let RB-Opt calculate the Q by few iterations.
Unfortunately I do not have this DVD, but I have seen similar in another cases happening.

In general, DVD-RB overestimates the Q for low bitratre matrices and underestimates the Q for high bitrate matrices which may cause the abortion - just my experience.

I do agree however that CCE should never abort, irrespective of the Q that is used for redistribution.

[jdobbs]

I feel like I'm talking to myself. The point is completely missed. The Q value DVD-RB uses has absolutely nothing to do with the problem. Are you telling me that with some matrices you can't use certain Q values? That's just plain silly.

I feel like I'm wasting my breath here. I'll let you guys finish this discussion... I'm outta this one.

[Sharc]

Sorry to be silly. I am just sharing my expereince and make a suggestion for a workaround (?) of a CCE problem. No less and no more. I am not an expert, but I have done a lot of testing with redistribution - and shared the results. I also did report about the CCE abortion much earlier but at that time I thought that there might be somethiong odd with my system, so I didn't take it serious until I read the recent post by archaeo.

[archaeo]

I guess I'm missing something here, too... and sorry to waste your time jdobbs if it's ignorance on my part...

But, If RB Opt can take the same project, same parameters, calculate the redistribution w/CCE, and then complete the redistribution without that weird segment allocation, why can't this same thing be done through DVDRB? It's a CCE crash, I understand - but why isn't the crash occurring w/CCE (as far as I can tell) when this process runs thru RB-Opt?

Is it that it could happen through RB opt, but just hasn't in this particular sample?

[jdobbs]

But, If RB Opt can take the same project, same parameters, calculate the redistribution w/CCE, and then complete the redistribution without that weird segment allocation, why can't this same thing be done through DVDRB? It's a CCE crash, I understand - but why isn't the crash occurring w/CCE (as far as I can tell) when this process runs thru RB-Opt?Because RBOpt is using a different Q... but, if it had used that same Q, it would have done the same thing -- and under other circumstances it very well might -- and the crash assuredly will happen then whether using DVD-RB or RBOpt. It just happens that this time it was with DVD-RB... but that may not be the case next time.

So my changing the Q will not fix the problem. My making other predictions for Q will not fix the problem. My checking the length of the output file will not fix the problem. The problem is within CCE and happens when you try certain Q values with certain matrices -- but it can only be fixed in CCE.

Of course on the other hand, if you don't feed it matrices with exceptionally low values on encodes that are using bitrates in need of stronger matrices it may not happen in either case.

Is it that it could happen through RB opt, but just hasn't in this particular sample?Exactly.

[archaeo]

OK, thanks for clarifying.
When I ran a quick test through RB Opt, it 'hiccuped' as well on the same Q value of 26:

--- Calculating Bitrate distribution
segment 1: original 4086 - redist. 4784
segment 2: original 4141 - redist. 4651
segment 3: original 3731 - redist. 4303
segment 4: original 4195 - redist. 3568
segment 5: original 3909 - redist. 4453
segment 6: original 3635 - redist. 3946
segment 7: original 3967 - redist. 4562
segment 8: original 3760 - redist. 4054
segment 9: original 3532 - redist. 4734
segment 10: original 3993 - redist. 4942
segment 11: original 3882 - redist. 4971
segment 12: original 3797 - redist. 4871
segment 13: original 3614 - redist. 3802
segment 14: original 3312 - redist. 4653
segment 15: original 3994 - redist. 4730
segment 16: original 4337 - redist. 1730
segment 17: original 4351 - redist. 5045
segment 18: original 4579 - redist. 3374
segment 19: original 4915 - redist. 2064
segment 20: original 4338 - redist. 3869
segment 21: original 2202 - redist. 2640


Segment 19 is also showing low bitrate, too.

[Sharc]

Does this mean that CCE will also fail in OPV mode under similar circumstances? Is there any experience of such failures?

[Boulder]

OK, thanks for clarifying.
When I ran a quick test through RB Opt, it 'hiccuped' as well on the same Q value of 26:

segment 16: original 4337 - redist. 1730

Segment 19 is also showing low bitrate, too.Could you run the redistribution pass and see (I mean actually watch through the encoding process of those segments) what really happens there? I've never seen such a thing occur with CCE so this is quite interesting. Q26 isn't even a low value.

[mc2man]

While it's ironic that the title in question here has nothing to gain in terms of pq from redis (IMHO). As far as the cce error(s) here's a different view that you may find some info in (mostly greek to me). aborts on seg. 15, 16 fox high 1 ac3

***** CCE SP Trial Version started at 2007/07/16 02:29:37 *****
-- CCE SP Trial Version version 2.70.02.06
-- SDK version 2.70 (built at 17:19:40 Apr 18 2005)
cce created.
fexp thread created.
fixme:listview:LISTVIEW_SetColumnOrderArray iCount 6 lpiArray 0x900963c
TC in: 00:00:00:00
TC out: 00:01:05:12
video file: C:\SPOT\D2VAVS\V040015_REDIST.m2v
encoder initialized.
uncompressed YUY2.
encoding started at 2007/07/16 02:29:38.
>> received encoding start notification
>> received encoding start notification
>> received encoding stop notification
cce encoding failed: OPV VBV ovf frame# 564 (00:00:23:14) I 122384 max 121322.23 rel 1061.77 1.01 qsv 11.60->11.60
sync stopped.
encoding stopped at 2007/07/16 02:29:53.
fdev0 closed.
fdev1 closed.
>>>> Performance <<<<
Source : 24.274 seconds (582 frames)
Elapsed: 14.866 seconds
---------------------------------------------------
>> File reading 8.194 55.122 %
>> Decoding 0.000 0.000 %
>> Resizing 0.000 0.000 %
>> Deinterlacing 0.000 0.000 %
>> RGB -> YUY2 0.000 0.000 %
---------------------------------------------------
>> MPEG encoding 6.672 44.878 %
fexp thread terminated.
fixme:avifile:AVIFileExit (): stub!
***** CCE SP Trial Version started at 2007/07/16 02:29:54 *****
-- CCE SP Trial Version version 2.70.02.06
-- SDK version 2.70 (built at 17:19:40 Apr 18 2005)
cce created.
fexp thread created.
fixme:listview:LISTVIEW_SetColumnOrderArray iCount 6 lpiArray 0x900963c
TC in: 00:00:00:00
TC out: 00:00:43:00
video file: C:\SPOT\D2VAVS\V040016_REDIST.m2v
encoder initialized.
uncompressed YUY2.
encoding started at 2007/07/16 02:29:55.
>> received encoding start notification
>> received encoding start notification
>> received encoding stop notification
cce encoding failed: OPV VBV ovf frame# 60 (00:00:02:12) I 128920 max 127322.73 rel 1597.27 1.01 qsv 7.67->7.85
sync stopped.
encoding stopped at 2007/07/16 02:29:57.

[Boulder]

It's the classic VBV buffer overflow error. For some reason, CCE sometimes doesn't recover from these whereas HC will grind the GOP in question till the problem with the VBV buffer overflow is taken care of (hence the slowdowns people have observed).

[Carpo]

am doing a few tests with this redist option to see of using different matricies actually do affect the outcome, what is dvdrbs default? is it mpeg standard ? just saves me having to use that one if its the deafult - 1 less test to do :)

on a side note has anyone used 1800-3500 AVAMAT7.mtx and 3500-9500 AVAMAT6.mtx

AVAMAT7.mtx

8 16 19 22 26 28 32 38
16 16 22 24 28 32 38 44
19 22 26 28 32 38 44 48
22 22 26 32 38 44 48 54
22 26 32 38 44 48 54 64
26 32 38 44 48 54 64 74
32 38 44 48 54 64 74 84
38 44 48 54 64 74 84 94

16 20 24 28 36 42 46 52
20 24 28 36 42 46 52 58
24 28 36 42 46 52 58 62
28 36 42 46 52 58 62 68
36 42 46 52 58 62 68 78
42 46 52 58 62 68 78 88
46 52 58 62 68 78 88 99
52 58 62 68 78 88 99 99

AVAMAT6.mtx

8 16 19 22 26 27 29 34
16 16 22 24 27 29 34 35
19 22 26 27 29 34 35 38
22 22 26 27 29 34 35 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 50
26 27 29 35 40 48 50 60
27 29 35 40 48 50 60 62

16 20 24 28 32 36 40 44
20 24 28 32 36 40 44 48
24 28 32 36 40 44 48 52
28 32 36 40 44 48 52 56
32 36 40 44 48 52 56 58
36 40 44 48 52 56 58 60
40 44 48 52 56 58 60 62
44 48 52 56 58 60 62 62

[archaeo]

Could you run the redistribution pass and see (I mean actually watch through the encoding process of those segments) what really happens there? I've never seen such a thing occur with CCE so this is quite interesting. Q26 isn't even a low value.


@boulder, it looks like mc2man ran the test you were looking for...

Interesting.
I wonder if all CCE versions will show this buffer overflow error?

[Boulder]

I've seen it for a long time now so I suspect every version may cause it.

[dynamis]

i just tried to encode my problem segment with CCE SP 2.67.00.23 and it went through.
this segment has a still picture with credits fading in and out:


--- Encoding VTS 4 VobID 1 segment 12
Original Bitrate: 3549
- Waiting for encoder...

=== Completed encoding VTS 4 VobID 1 segment 12
Size of the segment: 5632 KB
Segment bitrate: 3466

20% samples, Q=1
edit: got the same bitrate at Q=5. it this... good? :P

with 2.70.02.12 and 2.70.02.01 the segment 12 calculation would die and spit out 327.
this is only one of the few movies i had this problem with, so... i'm gonna try some more. i'm going to try with CCE SP 2.50 that's on the other rig too.



edit: 2.50 gave me .... 3792

[stereo]

Does all this mean, we'd better not use the CCE + redistribution method (DVD RB as well as RB-Opt) untill this issue has been solved?

I just encountered this in RB-Opt:

--- Found Q factor: 24
[...]
--- Calculating Bitrate distribution
Bitrate for VTS 1 VobID 5 segment 1: original 3078 - redist. 2835
Bitrate for VTS 1 VobID 5 segment 2: original 3905 - redist. 3671
Bitrate for VTS 1 VobID 5 segment 3: original 3409 - redist. 3468
Bitrate for VTS 1 VobID 5 segment 4: original 2832 - redist. 2618
Bitrate for VTS 1 VobID 5 segment 5: original 4608 - redist. 4973
Bitrate for VTS 1 VobID 5 segment 6: original 2872 - redist. 2117
Bitrate for VTS 1 VobID 5 segment 7: original 3663 - redist. 3210
Bitrate for VTS 1 VobID 5 segment 8: original 4089 - redist. 3329
Bitrate for VTS 1 VobID 5 segment 9: original 5579 - redist. 6029
Bitrate for VTS 1 VobID 5 segment 10: original 5132 - redist. 5307
Bitrate for VTS 1 VobID 5 segment 11: original 4674 - redist. 4573
Bitrate for VTS 1 VobID 5 segment 12: original 2632 - redist. 1367
Bitrate for VTS 1 VobID 5 segment 13: original 4484 - redist. 4510
Bitrate for VTS 1 VobID 5 segment 14: original 4222 - redist. 4457
Bitrate for VTS 1 VobID 5 segment 15: original 4601 - redist. 4527
Bitrate for VTS 1 VobID 5 segment 16: original 5124 - redist. 5491
Bitrate for VTS 1 VobID 5 segment 17: original 5025 - redist. 5492
Bitrate for VTS 1 VobID 5 segment 18: original 3654 - redist. 3522
Bitrate for VTS 1 VobID 5 segment 19: original 2543 - redist. 1556
Bitrate for VTS 1 VobID 5 segment 20: original 3176 - redist. 1854
Bitrate for VTS 1 VobID 5 segment 21: original 4193 - redist. 3983
Bitrate for VTS 1 VobID 5 segment 22: original 2593 - redist. 2167
Bitrate for VTS 1 VobID 5 segment 23: original 3268 - redist. 2701
Bitrate for VTS 1 VobID 5 segment 24: original 4308 - redist. 4955
Bitrate for VTS 1 VobID 5 segment 25: original 3708 - redist. 4136
Bitrate for VTS 1 VobID 5 segment 26: original 3064 - redist. 3041
Bitrate for VTS 1 VobID 5 segment 27: original 4515 - redist. 5397
Bitrate for VTS 1 VobID 5 segment 28: original 4270 - redist. 4887
Bitrate for VTS 1 VobID 5 segment 29: original 4967 - redist. 5827
Bitrate for VTS 1 VobID 5 segment 30: original 4932 - redist. 5917
Bitrate for VTS 1 VobID 5 segment 31: original 3959 - redist. 4557
Bitrate for VTS 1 VobID 5 segment 32: original 3305 - redist. 3345
Bitrate for VTS 1 VobID 5 segment 33: original 2906 - redist. 2186

- and segment 12 (as well as af few others) seems odd or at least very, very low.

Using DVD RB 1.26.2 RB-Opt 0.33, CCE 2.70.02.06
Matrix: Encoder default

[archaeo]

Best to check the segments visually - some of these low bitrates may be OK, depending on what's going on.

[stereo]

OK, so you suggest I re-encode it, and check each of the (possibly) problematic segments?

[robot1]

Bitrate for VTS 1 VobID 5 segment 12: original 2632 - redist. 1367

- and segment 12 (as well as af few others) seems odd or at least very, very low.

Using DVD RB 1.26.2 RB-Opt 0.33, CCE 2.70.02.06
Matrix: Encoder default

Have you checked the quality of the encoded segment?
If CCE crashes with std matrix and Q 24, it could have great problems.

[stereo]

No, I haven't checked the segments yet. I'll encode the disc and see what happens.

[stereo]

BTW, is there a way to encode just one segment in DVD RB (I mean without having to encode the entire disc)?

[kumi]

You can do it from the Preview/Edit Window. Set all segments except the one(s) you want encoded to "No Reencode". Then press "Save & Quit".

ALternatively, you can cut out the unwanted segments' [item] and [file] sections from the REBUILDER.ECL file in the Working Path with a text editor.

[stereo]

OK, thanks, will give it a try.

[Carpo]

has anyone tried this with autoqmatenc ? - i think i'll just have to use HC like jdobbs said in an earlier post if cce is being a tit, or is it a case as long as you check the redist.txt file and it all loks ok in there to go ahead and use cce ?

[stereo]

Have you checked the quality of the encoded segment?
If CCE crashes with std matrix and Q 24, it could have great problems.

I have encoded and checked the following (bold) segments:

--- Found Q factor: 24
[...]
--- Calculating Bitrate distribution
Bitrate for VTS 1 VobID 5 segment 1: original 3078 - redist. 2835
Bitrate for VTS 1 VobID 5 segment 2: original 3905 - redist. 3671
Bitrate for VTS 1 VobID 5 segment 3: original 3409 - redist. 3468
Bitrate for VTS 1 VobID 5 segment 4: original 2832 - redist. 2618
Bitrate for VTS 1 VobID 5 segment 5: original 4608 - redist. 4973
Bitrate for VTS 1 VobID 5 segment 6: original 2872 - redist. 2117
Bitrate for VTS 1 VobID 5 segment 7: original 3663 - redist. 3210
Bitrate for VTS 1 VobID 5 segment 8: original 4089 - redist. 3329
Bitrate for VTS 1 VobID 5 segment 9: original 5579 - redist. 6029
Bitrate for VTS 1 VobID 5 segment 10: original 5132 - redist. 5307
Bitrate for VTS 1 VobID 5 segment 11: original 4674 - redist. 4573
Bitrate for VTS 1 VobID 5 segment 12: original 2632 - redist. 1367
Bitrate for VTS 1 VobID 5 segment 13: original 4484 - redist. 4510
Bitrate for VTS 1 VobID 5 segment 14: original 4222 - redist. 4457
Bitrate for VTS 1 VobID 5 segment 15: original 4601 - redist. 4527
Bitrate for VTS 1 VobID 5 segment 16: original 5124 - redist. 5491
Bitrate for VTS 1 VobID 5 segment 17: original 5025 - redist. 5492
Bitrate for VTS 1 VobID 5 segment 18: original 3654 - redist. 3522
Bitrate for VTS 1 VobID 5 segment 19: original 2543 - redist. 1556
Bitrate for VTS 1 VobID 5 segment 20: original 3176 - redist. 1854
Bitrate for VTS 1 VobID 5 segment 21: original 4193 - redist. 3983
Bitrate for VTS 1 VobID 5 segment 22: original 2593 - redist. 2167
Bitrate for VTS 1 VobID 5 segment 23: original 3268 - redist. 2701
Bitrate for VTS 1 VobID 5 segment 24: original 4308 - redist. 4955
Bitrate for VTS 1 VobID 5 segment 25: original 3708 - redist. 4136
Bitrate for VTS 1 VobID 5 segment 26: original 3064 - redist. 3041
Bitrate for VTS 1 VobID 5 segment 27: original 4515 - redist. 5397
Bitrate for VTS 1 VobID 5 segment 28: original 4270 - redist. 4887
Bitrate for VTS 1 VobID 5 segment 29: original 4967 - redist. 5827
Bitrate for VTS 1 VobID 5 segment 30: original 4932 - redist. 5917
Bitrate for VTS 1 VobID 5 segment 31: original 3959 - redist. 4557
Bitrate for VTS 1 VobID 5 segment 32: original 3305 - redist. 3345
Bitrate for VTS 1 VobID 5 segment 33: original 2906 - redist. 2186


- and while CCE didn't crash, the segments looked absolutely horrible.

Setup:
Movie: Windtalkers Pal (Nordic Special Edition)
Avg. bitrate: 3.950
Redistribution: RB-Opt 0.33 (q sample: 25 % - OPV prediction sample: 1 %)
Q: 24
CCE: 2.70.02.06 (2 passes: 1 vaf + 1)
Matrix: Encoder Default

I don't know if this has to do with the questions and problems described in this thread, but the Rebuilder.ecl did show the line "qmat= [matrix]" in exactly these - and only these - segments. I thought there wasn't supposed to be a matrix involved with a constant Q.

Anyway, I'll just go with a regular 3(4) pass vbr on this one.

[dynamis]

hey stereo, i don't know if this will work for you, but have you tried using CCE SP 2.70.02.01 or earlier for Bitrate Redistribution?

[stereo]

hey dynamis, no I haven't tried these early versions on redistribution. I actually did try 2.70.02.12, and CCE SP2 - none of them worked with RB-Opt.

For the moment being, I've decided to drop redistribution on the sources that look like trouble. I've been doing hundreds of great 3(4) passes using 2.70.02.06, and I don't mind going back to that (for the time being) - even though I quite like the idea of bitrate redistribution...

[mc2man]

reading thru this and other threads concerning methods of 'blanket" style redistribution (vs.seg.editing) it strikes me that it's receiving too much credit based on seg. averages, graphs showing this or that ect. Ultimately though it still just an average. A more relevant comparison would be to chart/graph an individual seg. created by the various methods. i've compared a number of segs. produced by cce w/custom matrix; cce w/cceaqm; cce w/cceaqm and segment editor; and cce default w/redistribution. My money's on cce w/cceaqm and seg. editor tweaking in terms of retaining PQ and possibly shortening encoding times to to extraction. (in most cases).
Personally i was hoping that the redis. feature could give me a decent 'preset' for the segment editor, unfortunately once you run a redis. pass and then open the segment editor and click on any segment the seg. editor basically becomes fubar till you do a reinstall. It's behavior becomes erratic and starts blanking segs.
on it's own. This continues even on new projects without using a redis. pass (at least on my machine)

[dynamis]

sorry, stereo, i might have done something wrong earlier. only 2.67.00.23, 2.67.00.27 and 2.50 seemed to work for me.

but your way sounds best for now.

[stereo]

No prob, I wasn't going to try these versions; they're simply too old (I used to use 2.67.00.23 a lot).

But thanks for the heads up.

[Carpo]

now i always used to use cceaqm and AVAMAT6/7 depending on the bitrate untill someone told me that cceaqm is not compatible with some players, always had grat results mind you (still use those maticies though and still have great results :) ) , but can we have a deffinitive answer as to wether or not we use the redist option with cce, im guessing it works fine with HC just not with cce, i have tried a fair few discs and all looks fine in the redist file, although i am using avisynth 2.5.7 with no filters - although that shouldnt make a difference

[Sharc]

The discussion on the CCE bug seems to be stuck.
I wonder if there is no workaround such as to trap the unusual exit of CCE (is this possible?), increase the Q by 1 and try again until CCE exits normally.
In the few cases I have seen CCE aborting, increasing the Q has always helped.

[Boulder]

Pretty much the only thing that can be done is to check the number of frames in the encoded m2v file and compare it against the expected number of frames. If they differ, increase Q and try again.

[Sharc]

I thought there might be a flag or something set by CCE indicating that CCE terminated abnormally. Maybe it's not that simple, unfortunately.

[Carpo]

i have a few backups to do and am wondering if its safe to use redist or what

[archaeo]

i have a few backups to do and am wondering if its safe to use redist or what

As jdobbs mentioned in an earlier post:

Of course on the other hand, if you don't feed it matrices with exceptionally low values on encodes that are using bitrates in need of stronger matrices it may not happen in either case.


So carpo to answer your question - yes - when using the standard matrix with CCE as a 'failsafe' method. The problems seem to come when using a custom matrix with too low of values, as I chose in my apocalypto backup. Generally speaking, you may be taking some chances if you use a custom mtx with CCE when using bitrate redistribution.

[Boulder]

If you use HC, you are perfectly safe :)

[Carpo]

i did do a test with hc and the results were visually apparent, guess i'll just have to use the encoder default with redist on i suppose, shame as AVAMAT6/7 do normally give good resualts