View Full Version : questions about separated pass encoding
rezard
23rd November 2004, 05:48
questions during my first realvideo encoding.
1.
I get a warning message,
"VBR Unconstrained bitrate can only be performed with two pass encoding changing to VBR bitrate with maximum bitrate"
when using following setting.
<encodingType type="string">vbrUnconstrainedBitrate</encodingType> and
<rcPassNumber type="uint">1</rcPassNumber> in <codecProperties>.
does the message mean that producer changed encodingType to vbrBitrate, itself?
is it impossible to encode separate pass of vbrUnconstrainedBitrate type?
2.
output rmvb of first pass is affected by value of the <avgBitrate>.
what does that mean?
3.
does <encoderComplexity> in <codecProperties> override <encodingComplexity> of audience?
rezard
29th November 2004, 02:51
I get oversized result file in case source is a very compressible anime.
the log file of rateControl reveal that a frame size of quant 3 or 4 is far bigger than target size of that frame.
is it possible to prevent the RC from assigning such low quants?
if they affect only size without quality improvement like xvid's quant 1.
when I use xvid, I keep xvid's 1st pass file of quant 2 without 2nd pass if it's size is less than target size. with full quality 1st pass setting.
I am using helix producer 10.0.0.545 and rv10 codec 2004-11-24 and new RC.
Sirber
29th November 2004, 03:59
Originally posted by rezard
1.
I get a warning message,
"VBR Unconstrained bitrate can only be performed with two pass encoding changing to VBR bitrate with maximum bitrate"
when using following setting.
<encodingType type="string">vbrUnconstrainedBitrate</encodingType> and
<rcPassNumber type="uint">1</rcPassNumber> in <codecProperties>.
Producer thinks you are only doing 1 pass, not 2 pass.2.
output rmvb of first pass is affected by value of the <avgBitrate>.
what does that mean?Set the filename with ".null" at the end, the file will be 0 bytes.3.
does <encoderComplexity> in <codecProperties> override <encodingComplexity> of audience? I really don't know :(
rezard
29th November 2004, 05:44
thanks.
the different behavior of producer and xvid about 2 pass encoding confused me.
by the way, quant 6 of rv seem to be similar to quant 2 of xvid.
correct me if I'm wrong.
I wish to be able to set quant-limitation like xvid.
karl_lillevold
30th November 2004, 19:36
hi rezard:
1) For separate pass encoding and the new (curve compression) rate control, please use option
<codecProperties type="bag">
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
</codecProperties>
instead of vbrUnconstrainedBitrate. Anything inside <codecProperties> goes directly to the codec. Also make sure your rcPassNumber option is inside the codecProperties tag, and that you run Producer in 1 pass mode (with -dt or disable 2 pass in job file).
The problem is that Producer does not really support separate passes. This is a feature I added to the codec separately, Producer is not aware of it, and you need to tell the codec what to do, not Producer ;)
2) If output of 1st pass is affected by avgBitrate, you are not running the 1st pass of the curve compression rate control.
3) Anything inside <codecProperties> is the *final* word, i.e. the <encoderComplexity> EHQ number sets the actual complexity used by the encoder, no matter what Producer's <encodingComplexity> string value is set to.
Hope this helps.
P.S. Since RV10's reference 1st pass quantizer defaults to 6, this is indeed similar to XviD's quantizer of 2. I am afraid quant limits are currently not an option in RV10 rate control.
rezard
1st December 2004, 07:00
thanks.
but, I have used all those tags correctly since first encoding with reading your 'RealVideo 10 codecProperties' thread.
I just didn't know that the new RC ignore the <encodingType>.
now I guess the 'MSL' in the description of rcEnableCurveCompression have same meaning with 'encodingType'.
about 2),
it is strange.
when I first encoded separated 1st pass with <avgBitrate type="uint">1</avgBitrate> with using <rcTargetVideoSize> tag,
the outputed rmvb was very tiny resolution-reduced though I expected constant quantizer's like xvid.
following is my job file.
value-changed tags from first encoding are
<avgBitrate>, <rcOverFlowControlStrength>.
new added tags from first encoding are
<firstPassComplexity>, <encoderComplexity>, <chromaModeDecision>, <rcBestPSNRMode>, <encodeAllFrames>.
also, codec was updated from that of producer 10.0.0.545 to 2004-11-24 version.
and I deleted some default-value tags.
<?xml version="1.0" encoding="UTF-8"?>
<job xmlns="http://ns.real.com/tools/job.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/job.2.0 http://ns.real.com/tools/job.2.0.xsd">
<enableTwoPass type="bool">false</enableTwoPass>
<clipInfo>
<entry>
<name>Generated By</name>
<value type="string">Helix DNA(TM) Producer 10.0 for Windows, Build 10.0.0.545</value>
</entry>
</clipInfo>
<inputs>
<input xsi:type="avFileInput">
<filename type="string">source.avs</filename>
<disableAudio type="bool">true</disableAudio>
<prefilters>
<prefilter xsi:type="videoDupFrameDropper">
<enabled type="bool">true</enabled>
<maxDroppedFrames type="uint">65535</maxDroppedFrames>
<maxAvgSSD type="uint">1</maxAvgSSD>
<maxAreaSSD type="uint">1</maxAreaSSD>
<maxAvgChromaSSD type="uint">1</maxAvgChromaSSD>
<maxAreaChromaSSD type="uint">1</maxAreaChromaSSD>
<earlyExit type="bool">true</earlyExit>
<enableDetailedLogInfo type="bool">false</enableDetailedLogInfo>
<pluginName type="string">rn-prefilter-dupframedropper</pluginName>
</prefilter>
</prefilters>
</input>
</inputs>
<parOutputs>
<output>
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">output.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<outputHeight type="uint">0</outputHeight>
<outputWidth type="uint">0</outputWidth>
<videoMode type="string">normal</videoMode>
<audienceRefs>
<audienceRef>mine</audienceRef>
</audienceRefs>
</mediaProfile>
</output>
</parOutputs>
<audiences>
<audience>
<avgBitrate type="uint">1000000</avgBitrate>
<maxBitrate type="uint">5000000</maxBitrate>
<name type="string">mine</name>
<streams>
<stream xsi:type="videoStream">
<codecName type="string">rv10</codecName>
<encodingType type="string">vbrUnconstrainedBitrate</encodingType>
<maxKeyFrameInterval type="double">10.0</maxKeyFrameInterval>
<maxStartupLatency type="double">60.0</maxStartupLatency>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecProperties type="bag">
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<rcAnalysisFileName type="string">c:\realvideo.pass</rcAnalysisFileName>
<rcLogFileName type="string">c:\realvideoRC.log</rcLogFileName>
<encoderComplexity type="uint">100</encoderComplexity>
<firstPassComplexity type="uint">100</firstPassComplexity>
<rcPassNumber type="uint">1</rcPassNumber>
<rcTargetVideoSize type="uint">120247</rcTargetVideoSize>
<rcOverFlowControlStrength type="uint">2</rcOverFlowControlStrength>
<rcMaxOverflowImprovement type="uint">1</rcMaxOverflowImprovement>
<rcMaxOverflowDegradation type="uint">1</rcMaxOverflowDegradation>
<maxConsecutiveBFrames type="uint">0</maxConsecutiveBFrames>
<inloopCutOffQuant type="uint">0</inloopCutOffQuant>
<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">false</inloopCutOffBUseRefQuant>
<chromaModeDecision type="bool">true</chromaModeDecision>
<rcBestPSNRMode type="bool">false</rcBestPSNRMode>
<encodeAllFrames type="bool">false</encodeAllFrames>
</codecProperties>
</stream>
</streams>
</audience>
</audiences>
</job>
rv output much less block,ring artifacts and clear outline.
but some high motion sections are more blurry than xvid's.
I doubt the RC.
added p.s.:
what quality value should I use for constant quantizer of 6 encoding?
karl_lillevold
1st December 2004, 23:50
ah, the problem is if you set the bitrate extremely low, is that the codec's RPR functionality accidentally kicks in (RPR = Reference Picture Resampling). This is a feature where it for very low bitrates downsamples the video internally, but the output is upsampled before display. This is a bug, with the curve compression rate control, RPR should have been automatically disabled. You can manually disable it with the enableRPR flag set to false. I will fix this, and will be included in whatever is the next encoder update.
Also, some suggestions about your job file:
1) remove option encodeAllFrames or set to true. If set to false, this may interfere with CC RC which needs to encode all frames.
2) set firstPassComplexity to 50. Using 100 is a waste of time.
3) B frames are recommended... You have turned them off..
4) Why is video dup frame dropper included? With those thresholds it does not do anything, except slow down the encoding (slightly) and other potential problems.
5) Your rcOverflow parameters are strange. I have never tried such low numbers.
To find the vbrQuality that corresponds to quantizer 6, you can use the calcPSNR option to get rv9log.txt. This will include the quantizer value.
rezard
2nd December 2004, 05:25
thanks.
then I guess the separated 1st pass essentially result in constant quantizer 6 output, without some features like inloop filtering.
I will use vbrQuality setting only when the CC RC produce oversized file with distributing quantizer value below 6.
about your suggestions.
2) I will lower the value when I have no time or if you declare a value above xx is totally useless.
3) in my thinking, B frames make some spots bad while improving overall quality. I hesitate.
4) threshold 1 is for the dup filter of avisynth. I followed 'RV9 Animation DropDupe Pre-filter' thread.:) by the way, the maximum 3 consecutive droppings limitation seem to be disappeared. I saw hundreds of consecutive droppings.
5) they work well for me. a small adjustment may be required for rare cases.
rezard
2nd December 2004, 14:19
in fact, I don't know exact meanings of those RC overflow settings.
increasing values of the MaxOverflowImprovement and MaxOverflowDegradation seem to be able to prevent distributing very low or very high quantizers.I will try very big values.
I hope that the RC compare a frame's actual result size with that frame's target size and adjust quantizer.
rezard
3rd December 2004, 11:23
high values for rcMaxOverflow.. tags did not help.
the following is first part of the RC's log.
source was grainy and first 5 frames were dropped by the dup frame dropper prefilter.
result file was huge oversized, maybe rcOverFlowControlStrength value seem too low for that source.
RealVideo Rate Control 2nd pass log:
Framerate: 23976/1000 = 23.976000 fps
Total number of frames: 28189
Target filesize: 123654144 bytes
Keyframe boost adj: 1.00 Nonlinear adj: 1.00
CtrlStrngth: 2 MaxOFlowImpr: 100 MaxOFlowDegr: 100
Num Type Quant Size Scaled AdvSc Target Actual Error OFlow
0 i 7 979 904 904 904 978 74 -74.00
1 p 7 1635 1510 1510 1508 1565 57 -168.00
2 p 7 2383 2190 2190 2186 2231 45 -250.00
3 i 7 1814 1670 1670 1670 1720 50 -300.00
4 p 7 2046 1886 1886 1880 1822 -58 -258.67
5 p 6 2916 2662 2662 2656 2913 257 -532.33
6 p 7 3007 2754 2754 2743 2677 -66 -483.00
7 i 7 2197 2021 2021 2021 2100 79 -562.00
8 p 7 2567 2357 2357 2346 2316 -30 -558.33
9 p 7 3430 3112 3112 3101 3299 198 -782.67
10 p 7 2780 2546 2546 2530 2489 -41 -768.00
11 i 7 4280 3869 3869 3869 3177 -692 -76.00
12 p 7 3940 3584 3584 3582 3351 -231 385.67
13 p 6 3019 2752 2752 2759 3023 264 352.33
14 p 7 4083 3721 3721 3727 3820 93 490.00
15 i 6 3891 3532 3532 3532 3891 359 131.00
16 p 4 4217 3830 3830 3832 6133 2301 -2241.80
17 p 7 3902 3542 3542 3498 3447 -51 -2262.60
18 p 7 5285 4781 4781 4737 4348 -389 -1945.40
19 p 7 5285 4775 4775 4737 4271 -466 -1551.20
20 p 7 4537 4111 4111 4080 3861 -219 -1404.00
21 i 7 5272 4750 4750 4750 4269 -481 -923.00
22 p 7 5620 5079 5079 5061 4592 -469 -385.29
23 p 7 4941 4465 4465 4457 4124 -333 16.43
24 p 6 4880 4413 4413 4413 4868 455 -369.86
25 p 7 4767 4316 4316 4308 4128 -180 -121.14
26 p 7 6130 5528 5528 5525 4975 -550 497.57
27 p 7 5438 4905 4905 4914 4574 -340 906.29
28 p 7 5224 4723 4723 4740 4425 -315 1290.00
29 i 7 6816 6109 6109 6109 5401 -708 1998.00
30 p 7 6084 5484 5484 5522 5074 -448 2547.14
31 p 7 5751 5179 5179 5228 4768 -460 3108.29
32 p 3 5307 4790 4790 4850 11066 6216 -3006.57
33 p 7 5480 4944 4944 4885 4445 -440 -2465.43
there is strange distribution of quant 4 or 3 while some other section have quant 12 or 13.
such low quants distribution seem to occur if source is very compressible or difficult to compress. I also saw a few quant 5 with common source.
by the way, with 2/1/1 setting for overflow relating tags,
there are no higher quants than 8, though quant 4 and 3 exist similarly and a bit more bigger file was produced.
so, I will maintain low values for rcMaxOverflow.. tags and adjust rcOverFlowControlStrength.
karl_lillevold
3rd December 2004, 16:49
rezard: I have never tried such low number for overflow adjustment, but when I set them to 5, I got very oversized files for short encodes. If you set rcBestPSNRMode to false, you will avoid the strange distribution of lower quants :) I am pretty sure the combination of very low overflow numbers and rcBestPSNRMode led to the oversized file. For general encodes I would recommend rcBestPSNRMode set to false. By the way, from your log file, it seems the overflow numbers are 100. Strange, I will have to try 2/1/1 myself and see what happens.
rezard
3rd December 2004, 17:51
I tested both 2/1/1 and 2/100/100 setting.
and of course, the log was output of 2/100/100.
I have never set the rcBestPSNRMode to true, just set encodeAllFrames to true from the previous job file.
the 2/1/1 setting worked well for my previous encoding.
as said, the low quant distribution occured only to very easy or difficult source for compressing, though I have not done many rv encoding.:)
now I am encoding the same tested source with spatial denoiser filter of avisynth.
[added]
I forgot mentioning that I added the calcPSNR tag and set it's value to true.
does the calcPSNR override the rcBestPSNRMode?
rezard
4th December 2004, 04:45
I noticed another very strange thing from that previous log of which first part was showed in my 2nd previous post.
the size of first pass rmvb was 256Mb and my taget file size was 118Mb.
but the 'scaled' size of the log was not reduced enough from the value of 'size' column.
karl_lillevold
4th December 2004, 05:20
rezard: you are making things soooo complicated. The curve compression RC is known to work very well with default parameters. Just remove all the advanced parameters and you will see.
calcPSNR does not affect the quality in any way, just outputs a log file rv9log.txt with a lot of detailed information.
rezard
4th December 2004, 09:36
I will adjust parameters until I am satisfied.:)
another strange thing I realized.
the both resulting rmvb from 2/1/1 and 2/100/100 overflow setting were above 200mb.
but the last frame's OFlow value of log file was -4912865.00 for 2/1/1 and -5496.00 for 2/100/100 despite the huge size difference.
karl_lillevold
5th December 2004, 02:07
rezard: remember rcTargetVideoSize is video only. I am guessing the oversize is audio...
rezard
5th December 2004, 08:49
karl, as you could see from previous job file, I don't encode audio and video together. my rmvb would be muxed with vorbis into mkv.
the strange scaling problem seem to occur again during my recent encoding with denoised source.
I will provide realvideo.pass, job file and RC log file after encodnig end.
rezard
5th December 2004, 14:38
encoding ended.
1st pass file size: 252,094,530 bytes
target file size(rcTargetVideoSize value): 120756 kb
resulting file size: 193634 kb
realvideo.pass file:download (http://hjwng.vsix.net/hjwng/realvideo.pass)
RC log file:download (http://hjwng.vsix.net/hjwng/realvideoRC.log)
producer log of 2nd pass without huge VideoDupFrameDropper diagnostic messages:
,Diagnostic,Command Line,2004/12/05 10:57:00,0,"producer -lc e,w,i,d -j e:\util\job.rpjf" command line being run
,Diagnostic,File Reader,2004/12/05 10:57:03,8050,--------- Input File Properties from rn-avfile-directshow
,Diagnostic,File Reader,2004/12/05 10:57:03,8051,Input Filename: e:\util\source.avs
,Diagnostic,File Reader,2004/12/05 10:57:03,8052,File Size: 0KB
,Diagnostic,File Reader,2004/12/05 10:57:03,8053,Total Duration: 23:15.060
,Diagnostic,File Reader,2004/12/05 10:57:03,8080,Video Track
,Diagnostic,File Reader,2004/12/05 10:57:03,8081, Dimensions: 640 x 480
,Diagnostic,File Reader,2004/12/05 10:57:03,8082, Frame Rate: 23.976 FPS
,Diagnostic,File Reader,2004/12/05 10:57:03,8083, Format: YUY2
,Diagnostic,File Reader,2004/12/05 10:57:03,8084, Duration: 23:15.060
,Diagnostic,File Reader,2004/12/05 10:57:03,8054,--------- End Input File Properties
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper EarlyExit Enabled
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper DetailedLogInfo Enabled
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper Enabled
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper maxAreaChromaSSD 1
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper maxAreaSSD 1
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper maxAvgChromaSSD 1
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper maxAvgSSD 1
,Diagnostic,Video Pre-filters,2004/12/05 10:57:03,0,VideoDupFrameDropper maxDroppedFrames 65535
,Diagnostic,SDK Configuration,2004/12/05 10:57:03,10405,Audience mine written to memory
,Diagnostic,SDK Configuration,2004/12/05 10:57:03,10409,Audience mine loaded from memory
,Diagnostic,SDK Configuration,2004/12/05 10:57:03,10405,Audience mine written to memory
,Diagnostic,SDK Configuration,2004/12/05 10:57:03,10409,Audience mine loaded from memory
,Informational,SDK Encoding,2004/12/05 10:57:03,15000,Starting encode
,Diagnostic,SDK Encoding,2004/12/05 10:57:03,0,FilteredLoadHeadings: Reference Time, Stream Time, Delay, Interval Load, Average Interval Load, Processing Load, Stream Interval, Reference Interval, Accrued Delay, Average Delay, Load Level
,Diagnostic,SDK Encoding,2004/12/05 10:57:03,0,Using mine Audience
,Diagnostic,SDK Encoding,2004/12/05 10:57:03,0,Using video codec: rv10 (2500000 bps)
,Diagnostic,Video Codec,2004/12/05 10:57:04,20049,Setting video packet size to 15000
,Diagnostic,File Output,2004/12/05 22:18:09,7040,Finished Writing Volume ID 1.
,Diagnostic,File Output,2004/12/05 22:18:09,7042,Finished writing RealMedia File.
,Informational,Statistics,2004/12/05 22:18:10,19010, Out: Total Audio Video Avg Avg Pre- Audience Name
,Informational,Statistics,2004/12/05 22:18:10,19011, Aud kbps kbps kbps FPS QI roll
,Informational,Statistics,2004/12/05 22:18:10,19013,S1: 1:1 1131 n/a 1131 20.3 10 3 mine
,Informational,Statistics,2004/12/05 22:18:10,19020, Out: Min Min Min Min Audience Name
,Informational,Statistics,2004/12/05 22:18:10,19021, Aud FPS FPS Time QI QI Time
,Informational,Statistics,2004/12/05 22:18:10,19022,S2: 1:1 1.1 00:11:33 10 00:00:00 mine
,Informational,Statistics,2004/12/05 22:18:10,19002,Total Bitrate = 1131 kbps
,Informational,Command Line,2004/12/05 22:18:10,10535,Encoding successful!
job file:
<?xml version="1.0" encoding="UTF-8"?>
<job xmlns="http://ns.real.com/tools/job.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/job.2.0 http://ns.real.com/tools/job.2.0.xsd">
<enableTwoPass type="bool">false</enableTwoPass>
<clipInfo>
<entry>
<name>Generated By</name>
<value type="string">Helix DNA(TM) Producer 10.0 for Windows, Build 10.0.0.545</value>
</entry>
</clipInfo>
<inputs>
<input xsi:type="avFileInput">
<filename type="string">e:\util\source.avs</filename>
<disableAudio type="bool">true</disableAudio>
<prefilters>
<prefilter xsi:type="videoDupFrameDropper">
<enabled type="bool">true</enabled>
<maxDroppedFrames type="uint">65535</maxDroppedFrames>
<maxAvgSSD type="uint">1</maxAvgSSD>
<maxAreaSSD type="uint">1</maxAreaSSD>
<maxAvgChromaSSD type="uint">1</maxAvgChromaSSD>
<maxAreaChromaSSD type="uint">1</maxAreaChromaSSD>
<earlyExit type="bool">true</earlyExit>
<enableDetailedLogInfo type="bool">true</enableDetailedLogInfo>
<pluginName type="string">rn-prefilter-dupframedropper</pluginName>
</prefilter>
</prefilters>
</input>
</inputs>
<parOutputs>
<output>
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">e:\temp\pass2.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<disableAudio type="bool">true</disableAudio>
<outputHeight type="uint">0</outputHeight>
<outputWidth type="uint">0</outputWidth>
<videoMode type="string">normal</videoMode>
<audienceRefs>
<audienceRef>mine</audienceRef>
</audienceRefs>
</mediaProfile>
</output>
</parOutputs>
<audiences>
<audience>
<avgBitrate type="uint">1000000</avgBitrate>
<maxBitrate type="uint">5000000</maxBitrate>
<name type="string">mine</name>
<streams>
<stream xsi:type="videoStream">
<codecName type="string">rv10</codecName>
<enableLossProtection type="bool">false</enableLossProtection>
<encodingType type="string">vbrQuality</encodingType>
<encodingComplexity type="string">high</encodingComplexity>
<maxFrameRate type="double">30.0</maxFrameRate>
<maxKeyFrameInterval type="double">10.0</maxKeyFrameInterval>
<maxStartupLatency type="double">60.0</maxStartupLatency>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<quality type="uint">1</quality>
<codecProperties type="bag">
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<rcAnalysisFileName type="string">e:\temp\realvideo.pass</rcAnalysisFileName>
<rcLogFileName type="string">e:\temp\realvideoRC.log</rcLogFileName>
<encoderComplexity type="uint">100</encoderComplexity>
<firstPassComplexity type="uint">100</firstPassComplexity>
<rcPassNumber type="uint">2</rcPassNumber>
<rcTargetVideoSize type="uint">120756</rcTargetVideoSize>
<rcOverFlowControlStrength type="uint">2</rcOverFlowControlStrength>
<rcMaxOverflowImprovement type="uint">1</rcMaxOverflowImprovement>
<rcMaxOverflowDegradation type="uint">1</rcMaxOverflowDegradation>
<maxConsecutiveBFrames type="uint">0</maxConsecutiveBFrames>
<inloopCutOffQuant type="uint">0</inloopCutOffQuant>
<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>
<chromaModeDecision type="bool">true</chromaModeDecision>
<rcBestPSNRMode type="bool">false</rcBestPSNRMode>
<encodeAllFrames type="bool">true</encodeAllFrames>
<calcPSNR type="bool">true</calcPSNR>
<enableRPR type="bool">false</enableRPR>
</codecProperties>
</stream>
</streams>
</audience>
</audiences>
</job>
karl_lillevold
5th December 2004, 17:28
ok. I know what is going on now :scared:
There was a bug in an intermediate release of the latest RV10 update, where rcBestPSNRMode would be set to ON, just by having the parameter in the jobfile. It looks like you are using this version, because I am 100% certain rcBestPSNRMode is ON, based on your log file. What happens is that with your low overflow control numbers, the codec can not compensate for the lower quant values every 16 frames, and you get overflow.
Please get the latest erv4.dll (20041124) from
https://helixcommunity.org/project/showfiles.php?group_id=50
or remove the rcBestPSNRMode parameter from your job file.
Here is the changelog that describes this fix:
** 2004-10-25:
Fix: encodeAllFrames and rcBestPSNRMode would always
be ON if included in audience, if if set to 'false'
rezard
6th December 2004, 05:56
the version of my rv codec was definitely 2004-11-24.:confused:
because I first tried rv encodnig recently, there is no reason for maintaining intermediate version.
rezard
6th December 2004, 06:07
I started another 2nd pass after eliminating rcBestPSNRMode tag itself.
but first part of RC log was equal to that of last encoding, so I pressed ctrl-break.:(
karl_lillevold
6th December 2004, 06:17
then I have no idea what's going on, because your log file indicates rcBestPSNRMode is ON.
Did you ever use any reg keys? Maybe one (rcBestPSNRMode) got left behind...
Are you sure you replaced the right DLL in the right location when you updated with the 11/24 version?
In any case, the first few lines of rv9log.txt should say exactly which options are being used. Could you please post or send me these?
(rv9log.txt is enabled with calcPSNR set to true, which you already do)
rezard
6th December 2004, 07:47
ok, rv9log.txt (http://hjwng.vsix.net/hjwng/rv9log.txt) .
and I confirmed that there are only 'RealJukebox' and 'RealPlayer' in HKEY_LOCAL_MACHINE-SOFTWARE-RealNetworks in my reg.
and I am sure about placing correct dlls in codecs directory.
by the way, the 'Scaled' values(not reduced enough) of RC log were equal to those of last encoding even when using the old default codec(erv4.dll) of the producer with making the new tags to comments.
so, I think the scaling problem is not related to rcBestPSNRMode.
[added]
it's mysterious why the last 'OFlow' value of RC log is so small despite the huge size difference.
rezard
6th December 2004, 09:29
of course, the default overflow setting '5/50/50' also output the same 'Scaled' values.
there is nothing I can try.:(
rezard
6th December 2004, 11:19
there are 'RealMediaSDK', 'Preferences', 'Update', etc except 'RV9' in HKEY_CURRENT_USER\Software\RealNetworks in my registry.
do those affect encoding?
karl_lillevold
6th December 2004, 19:53
rezard: thanks for being so persistant! It turns out I made a mistake in the 11-24 build that would flip one of the switches that happens with rcBestPSNRMode. Please try the 12-06 build available from
https://helixcommunity.org/project/showfiles.php?group_id=50
That should get rid of the quant scaling problem, but I don't think it will fix your oversize file problem. Please try in any case.
When the overflow number in the log file is low, it means the codec thinks everything is fine.. This could be caused by a mismatch in source framerate. Let us figure that one out once the above problem is resolved.
rezard
7th December 2004, 04:32
yeah, with this version, the rcBestPSNRMode problem disappeared.:)
thanks and good luck.
[added]
of course, now I know it was wrong that I said the low quants distriubtion is related to source.
I had done only few encodnigs after updating codec to 11-24 version.:)
karl_lillevold
7th December 2004, 23:37
rezard, if you still have the oversize file problem, please try one encode using the corrected DLL, 5/50/50 overflow numbers (default), and make available the rv9log.txt and RC.log files. Thanks!
rezard
8th December 2004, 02:16
yeah, I still got oversize file with the 12-06 version.
I will try default overflow numbers.
karl_lillevold
8th December 2004, 02:21
Great, and please also remove the videodupframedropper from the job file, just in case. thanks again.
rezard
8th December 2004, 02:41
ok.
by the way, eliminating the videodupframedropper seem to require 1st pass for it. so I will encode both passes.
rezard
9th December 2004, 02:35
encoding ended.
resulting rmvb was of suitable size.
but, strangely, the ratio between the 'Size' and 'Scaled' value was not consistent. the scaling quantity was getting more and more gradually.
job file:
<?xml version="1.0" encoding="UTF-8"?>
<job xmlns="http://ns.real.com/tools/job.2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/job.2.0 http://ns.real.com/tools/job.2.0.xsd">
<enableTwoPass type="bool">false</enableTwoPass>
<clipInfo>
<entry>
<name>Generated By</name>
<value type="string">Helix DNA(TM) Producer 10.0 for Windows, Build 10.0.0.545</value>
</entry>
</clipInfo>
<inputs>
<input xsi:type="avFileInput">
<filename type="string">e:\util\source.avs</filename>
<disableAudio type="bool">true</disableAudio>
<prefilters>
<!-- <prefilter xsi:type="videoDupFrameDropper">
<enabled type="bool">true</enabled>
<maxDroppedFrames type="uint">65535</maxDroppedFrames>
<maxAvgSSD type="uint">1</maxAvgSSD>
<maxAreaSSD type="uint">1</maxAreaSSD>
<maxAvgChromaSSD type="uint">1</maxAvgChromaSSD>
<maxAreaChromaSSD type="uint">1</maxAreaChromaSSD>
<earlyExit type="bool">true</earlyExit>
<enableDetailedLogInfo type="bool">true</enableDetailedLogInfo>
<pluginName type="string">rn-prefilter-dupframedropper</pluginName>
</prefilter>
--> </prefilters>
</input>
</inputs>
<parOutputs>
<output>
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">e:\temp\pass2.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<disableAudio type="bool">true</disableAudio>
<disableVideo type="bool">false</disableVideo>
<outputHeight type="uint">0</outputHeight>
<outputWidth type="uint">0</outputWidth>
<videoMode type="string">normal</videoMode>
<audienceRefs>
<audienceRef>mine</audienceRef>
</audienceRefs>
</mediaProfile>
</output>
</parOutputs>
<audiences>
<audience>
<avgBitrate type="uint">1</avgBitrate>
<maxBitrate type="uint">5000000</maxBitrate>
<name type="string">mine</name>
<streams>
<stream xsi:type="videoStream">
<codecName type="string">rv10</codecName>
<enableLossProtection type="bool">false</enableLossProtection>
<encodingType type="string">vbrQuality</encodingType>
<encodingComplexity type="string">high</encodingComplexity>
<maxFrameRate type="double">30.0</maxFrameRate>
<maxKeyFrameInterval type="double">10.0</maxKeyFrameInterval>
<maxStartupLatency type="double">60.0</maxStartupLatency>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<quality type="uint">1</quality>
<codecProperties type="bag">
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<rcAnalysisFileName type="string">e:\temp\realvideo.pass</rcAnalysisFileName>
<rcLogFileName type="string">e:\temp\realvideoRC.log</rcLogFileName>
<encoderComplexity type="uint">100</encoderComplexity>
<firstPassComplexity type="uint">50</firstPassComplexity>
<rcPassNumber type="uint">2</rcPassNumber>
<rcTargetVideoSize type="uint">120756</rcTargetVideoSize>
<rcOverFlowControlStrength type="uint">5</rcOverFlowControlStrength>
<rcMaxOverflowImprovement type="uint">50</rcMaxOverflowImprovement>
<rcMaxOverflowDegradation type="uint">50</rcMaxOverflowDegradation>
<maxConsecutiveBFrames type="uint">0</maxConsecutiveBFrames>
<inloopCutOffQuant type="uint">0</inloopCutOffQuant>
<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>
<chromaModeDecision type="bool">true</chromaModeDecision>
<encodeAllFrames type="bool">true</encodeAllFrames>
<rcBestPSNRMode type="bool">false</rcBestPSNRMode>
<calcPSNR type="bool">true</calcPSNR>
<enableRPR type="bool">false</enableRPR>
</codecProperties>
</stream>
</streams>
</audience>
</audiences>
</job>
1st pass file size: 304842 kb
target file size: 120756 kb
resulting file size: 121294 kb
realvideo.pass (http://home.paran.com/hjwng/realvideo-noDrop-5_50_50.pass)
realvideoRC.log (http://home.paran.com/hjwng/realvideoRC-noDrop-5_50_50.log)
rv9log.txt (http://home.paran.com/hjwng/rv9log-noDrop-5_50_50.txt)
I doubt the videoDupFrameDropper is related to the oversize problem.
now another 2nd pass is in progress with 2/1/1 overflow setting and no videoDupFrameDropper.
karl_lillevold
9th December 2004, 02:46
I suspected a problem with the dup frame dropper, because when you specify a target video size, the encoder assumes a fixed framerate for the duration of the video, and thus a certain number of frames to be encoded. If a lot of frames are dropped, the calculation gets messed up. More details later. Why are you using the dup frame dropper again?
rezard
9th December 2004, 04:27
I'm not using the dup frame dropper.:confused:
rezard
9th December 2004, 04:57
for reference,
the following is the producer log corresponding to the past encoding, with diagnostic messages of dup frame dropper.
producer.log (http://home.paran.com/hjwng/producer.log)
good luck.:)
karl_lillevold
9th December 2004, 05:01
videoDupFrameDropper = "dup frame dropper", and you were using it in your earlier encodes, that ended up oversized. I'll study your log files tomorrow. Thanks!
karl_lillevold
10th December 2004, 01:41
rezard: I am not sure if there is any problem right now, either in the rate control or with the dup frame dropper. I have tested both, using your job file. The only way I can make over-sized or under-sized files is to set control params very low 1/2/2. As you may know, this means that the codec is only allowed to adjust only a tiny amount per frame. And since the codec can not 100% accurately predict how large a frame will become, you are likely to end up with over or undersized files. I can imagine for very noisy clips, they might easily become oversized. I would recommend to stick with 5/50/50.
rezard
10th December 2004, 03:35
no!!!!!
I did'nt get oversize file when I did same encoding as the last one except 2/1/1 overflow setting.
with 2/1/1 setting, the size of resulting file was 121639 kb, and quant-distribution was much more consistent than the default 5/50/50 setting.
and as you could see from comparing RC logs, dropping frames is definitely distorting target size(the value of rcTargetVideoSize).
karl_lillevold
10th December 2004, 06:08
I apologize rezard, but I am a little confused. I looked at one log file corresponding to an oversized encode, and that was clearly caused by the wrongly scaled quantizers, combined with low overflow adjustment numbers.
Are you saying that
1) with the corrected DLL, and
2) videodupframedropper
you get oversized files, but without the videodupframedropper everything works fine?
Then could I ask you one more favor? Post the log files that correspond to an encode /with/ the videodupframedropper that resulted in a oversized file, even though the RC.log file indicates that there is little overflow at the end? Or point me to them again, if you already posted them previously in this long thread :)
rezard
10th December 2004, 09:43
karl, as I said,
the RC log file corresponding to my past oversized encoding
showed that the values of 'Scaled' column were not reduced enough from the values of 'Size' column though the 1st pass rmvb size was twice bigger than the target size.
then all other remaining RC processes including the quants-decision should be based on the 'Scaled' values.
of course, the wrong scaling problem was not solved by the default overflow setting because this problem is not related to overflows.
and, yeah, this (http://home.paran.com/hjwng/realvideoRC`4.log) is RC log of oversized encoding with corrected dll(12-16) and dup frame dropper.
of course, without dup frame dropper, I never get such huge oversized file.
good luck.:)
karl_lillevold
10th December 2004, 18:32
rezard: I (finally :eek: ) understand your description of the problem, and once I find some time to look into it further I will. Having the .pass file corresponding to your latest RC.log file would help a lot, but even better would be the source file itself and .avs script. Thanks.
rezard
11th December 2004, 04:48
I provided two .pass files in past posts.
the first one was with the dup frame dropper and the latter one was without it.
I thought .pass files had no problems. otherwise, the corrected dll affect those?
and I'm sending files according to your PM.
it seem to require long time.
[added]
of course, the RC log of my last post correspond to the first realvideo.pass I provided.
karl_lillevold
11th December 2004, 05:11
thank you, I will try to sort everything out. There were a lot of encodes, and options, before and after the quant scale problem fix. We'll get to the bottom of this. Thanks for your help.
karl_lillevold
11th December 2004, 20:11
Originally posted by rezard
and, yeah, this (http://home.paran.com/hjwng/realvideoRC`4.log) is RC log of oversized encoding with corrected dll(12-16) and dup frame dropper.
of course, without dup frame dropper, I never get such huge oversized file.
I am sorry, I tried several files, with dup frame dropper set to drop plenty of frames, and I can not reproduce your problem. Also, looking at the above reference RC.log file, where you say you get huge oversize, the log file indicates just a little oversize (942114 bytes). This means that as far as the rate control is concerned, it did a good job with the scaling. In any case, there is not much more I can do without your exact source files. (I sent the ftp upload address via PM, but the ftp server needs to be restarted before this will work. I have asked someone to do that..)
karl_lillevold
12th December 2004, 07:36
ftp server restarted and open for uploads...
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.