Avisynth: A script to enlarge video final size?
 

As HC Encoder in cqmaxbitrate mode cuts spikes to keep video stream DVD compliant, I noticed that I cant reach a desired final size even though decreasing cqmaxbitrate value HC Encoder tends to undersize.
For this Im wonder if it could be any avs script that increases avg bitrate needed for the stream, increasing quality.
In this way, I think, avg btr will be higher, at a given cqmaxbitrate value. But spikes will be cutted anyway.
I think tendency to undersize will be lesser.

Re: A script to enlarge video final size.
 

Realy is not true that I cant go over a desired final size, but anyway I would want to know how could be such type of script.

Avisynth produce an uncompressed video stream. It doesn't care about bitrate.
Don't mistaken with tricks (like adding noise) that will reduce the capability for the encoder to shrink too much the video, leading to use more bitrate for the compressed video than you would have need without the trick.

As long as the quality of the picture is correct, trying to oversize the file is useless (it's like using CQ=100 in tmpgenc insteed of CQ=90).
If the quality is not correct, and HC continues to cut the peaks, then change the encoder !

So think I also. But it seems that our brain is not happy if in DVD still there is 100Mb free.
Why then we work so hard to obtain a file size so exact. If you think in it 100Mb don't make any difference usually, but we insist in obtain o stream 100Mb bigger.
i.e. I can obtain with HC Encoder in CQmaxbitrate mode video streams betwen 0 and -2 % undersize, but it seems for people it is not enough good.

For the same reason that I put a 90 cap on CQMatic.
After that CQ value, there's no more visual quality gained, so I just encode at that value, regardless of the final undersized file size.

-kwag

I do agree. Those Peak scenes would be original available for playback IF an SAP would support Bits larger than 9800 or whatever per second.

But what I do not unerstand is the following:

If you do a prediction on a movie you do encode parts in the SAME way you do when encoding finally. So IMHO also those peak-cuts should be done when doing the prediction turns, means these bit averages will be taken into account when doing the calculation on that resulted prediction chunk.
The rest is as common, means the more peaks you catch while predictionning, the more the final result will be accurate.

Maybe sometime those peak-prevention rotines will work within the encoding itself and not to be done as a fixing pass afterwards. The common encoders like TmpgEnc and CCE also keep the max while encoding.

Maybe the choice is to do like 5-6 prediction passes using 2pass where EVERY pass is using a clear different offset to the other (more peaks could be cought). After that do parse out of the HCencs log files the Qs used, calculate the average and add or subtract a value you find out including the average diff. between the Q and the real Q needed. Finally encode using that calculated Q.