Old AutoRV10 discussion (closed)

[karl_lillevold]

Originally posted by ookzDVD

or it's the M5 -> M6 problem ?
In fact, M6 is slightly faster than M5, with encodingComplexity=very-high, because I tweaked the EHQ levels. Remember, 'very-high' used to correspond to 85, higher than my recommended 80 level. So now 85 = 80. Also, in M6, the old method*) to set EHQ now again works, without my custom DLL. *):The old method is encoderComplexity=<number> in codecProperties, as well as registry key.

To double-check I ran producer.exe on the command line:

producer -i <testfile.avs> -am music -ad c:\autorv9_movie.rpad -lc e,d

and timed it. testfile.avs is 500 frames 704x304 MPEG-2 source.
M6: 1min 17sec
M5: 1min 24sec

So there is nothing wrong with the speed in M6 by itself. I have not yet tried the latest AutoRV9 with it. In order to help find out what/if there is a problem you can also run producer on the cmd line to try to isolate the problem. Other methods of verification includes the <calcPSNR> parameter (use search) which will include in the rv9log.txt file the actual encoderComplexity level. Thanks.

[superdump]

Karl: What complexity levels did you use for that little test? Both 80? Or both very-high? What I'm asking is, is the speed difference due to optimisations in the new milestone or because one is using EHQ at level 85 and the other at 80?

Also, I keep seeing bits and pieces which contradict each other, so I'd like to ask straight out. Does RV9 use any filtering whether it's in loop or not? If so what filtering is used?

[Sirber]

RV9 uses in-loop filtering at encoding time, and no filtering on decoding.

[superdump]

So what does the in loop filtering do? Smoothing?

[deXtoRious]

Well, this is actually the first version of AutoRV9 that ran perfectly from the first time I started it! And that small window on the left you've added which displays a mini-log i MOST helpful when doing video tests ;)

[alx]

DC: Thanks a lot for all your help and your wonderful program!!!
Mmmmmmm, i´ve been thinking......its not possible to do the same thing as with the ending credits, to the starting credits??? The logo of WB, Paramount and the titles of the movie at the beginin??? Just an idea.

karl_lillevold: Thanks to you and all the development team. You are doing a terrific work with rv9.
Maybe you could answer me one question.......the other day i start doing LOTR-The Two Towers with AutoRV9, 2 passes vbr, but after 10 hours, when the analisys ends, and the real code start, 1 or 2 hours from the analysis, i had a problem with the power supply and the machine shutdown, so i lost 12 hours, because Producer does not generate a log file, like "video.stats" in Xvid.......are you planning to make something like this in future releases??? i think it could make things easier to us, not only because of problems like i had, but doing LOTR and "lost" my machine for about 20 hours don´t think it´s a good idea..........usually with Xvid i make 1st. pass one night, and the 2nd. pass in the next night while i´m sleeping.
Or are you planning something new about???

Anyway, keep doing the good work with RV9
Sincerally
A RV9 FAN :)
Alx

PD. My apologies for my horrible english.....my mother tongue is spanish

[karl_lillevold]

@superdump: the difference in speed is due to the (previous) difference between 80 and 85. In order to get quality 85 with M6, you now have to use 90. However, the improvement in quality from 80 to 90 is not worth the extra time for now.

Yes, RV9 has an adaptive advanced in-loop filter, specifically designed to remove block edges before using the reconstructed frame in the prediction loop. Therefore the encoder and decoder filters have to match 100%, and the filtering strength can not be adjusted on the decoder side. It is not the same filter as in H.264, but the principle is the same in both, if you are looking for technical background on the subject. Specifically, one feature RealNetworks proposed to be included in H.264, was a tiny amount of pre-determined dither across filtered block boundaries, because on large (LCD, plasma, DLP) screens, a difference of just '1' in luminance or chrominance level is visible. However, we did not succeed, and the H.264 in-loop filter does not have this feature.

@alx: thanks! that's a very good suggestion. We have already considered this option, and it may be included in Producer 9.3, but not in 9.2, since it requires quite a few producer changes. One problem is that a current requirement is that the two passes are run with the exact same parameters, including bitrate, resizers, pre-filters. If any of those are accidentally changed, the 2nd pass would be messed up, usually resulting in too small filesize.

[alx]

Karl, usually with Xvid i make the 1st pass in the first night and see with a Q=2 maximun filesize........let´s say that it is 750 mb. then i go for a 1CD rip in my 2nd pass.
If in the 1st. pass filesize is (for ex.) 1800mb. obviously i consider a 2CD rip or 3CD rip.
The only thing that i change is the final size for the 2nd. pass..........
Anyway, it was just an idea that normally save to do the 1st pass 2 times.
Thanks a lot for your work and time to answer my "newbies" questions.
Alx

[superdump]

Thanks for the reply Karl, interesting stuff. I thought that would be the main reason for the speed difference. :D Nevertheless, as everyone keeps saying, keep up the good work.

[ookzDVD]

@karl_lillevold,

Thank you for the test,
I'll try to check on my system.

[alx]

Karl, sorry to bother you with another question.........aren´t you planning to add support in the .rmvb container to put more audio streams???. Usually i like to make backup of dvd´s with the original track and the track in my language.
My firsts experiments with matroska wasn´t very good.
Thanks
Alx

[karl_lillevold]

@alx: no, I don't think this feature is being planned. it would have worked, since there is support for multiple streams in the RM file format. The problem is that no one has used the feature, because there is no mechanism to switch streams on playback, and there is also no tool to create such a stream. In order to have multiple languages in RM, you currently need to use SMIL and multiple files.

On the topic of Matroska, that has worked well for me, after a few RM bugs were fixed, but I have not yet tried multiple languages, just merging one audio track with a video track and adding subtitles. If you have problems getting it to work, my experience is that the Matroska developers are very eager to fix any problems you have to report, especially if you have an easy repro case.

[ookzDVD]

@karl_lillevold,

I just replace the rv9_light from the autorv9 (beta 5),
from ML5 to ML6 and I have speed problem, the ML6 is
somehow slower compared with ML5 with the same audience file.
I will provide the log later.
Thank you.

[karl_lillevold]

@ookzDVD: very strange. Like I wrote, I do not have this problem on my system, and I do not understand what could be wrong. Maybe for some reason you were never actually using EHQ in M5... I will see how reasonable your encoding speed is when you provide the logs. Also remember to include your main system specs. A few things you can look into:

1) check that producer.exe in both cases uses 80-90% of the CPU in task manager. Maybe in one case it runs at IDLE and some other app is using all the CPU cycles.

2) check that you do not have any registry keys to over-ride the encoding complexity. This is in HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9

3) enable calcPSNR with this reg file (http://www.lillevold.com/files/calcPSNR.reg), and check that in both cases (M5 and M6), the rv9log.txt file starts with "cpu_scal: 85". rv9log.txt is appended to, so check the entry that corresponds to your latest main encode. Remember to disable this after testing, by removing the key with regedit. Same location as above.

[ookzDVD]

@karl_lillevold,

Here is the log file for both ML5 and ML6.

http://www.japati.com/mib_2_LogFile_ml5.txt
http://www.japati.com/mib_2_LogFile_ml6.txt

I hope you could find something from the logs.

PS. I only add registry with EHQ reg patch.

Thank you.

[Dark-Cracker]

@ookzDVD

avoid to use registry patch for EHQ level. let autorv9 add it in the audience.

it seems to me M5 doesn't take care for the registry patch while M6 use in priority the registry patch.

i think karl wait the rv9log.txt file not the autorv9 log file :) because in rv9log.txt u can see the encoder complexity.

PS: do u know in beta 6 u have a "speed test" option ?

Bye.

[karl_lillevold]

@ookzDVD: i think the problem is simply that you did not actually use EHQ with Milestone 5, and the slower speed with Milestone 6 is that you are now (finally) encoding with EHQ. The registry method to enable EHQ never worked with Milestone 5, unless you correctly replaced the encoder DLL, like I described here (http://forum.doom9.org/showthread.php?s=&threadid=58196).

This is good news. Sorry it is slower though, but all the CPU cycles are spent wisely to obtain better video quality, I assure you.

[olorin]

Hi

I really like RV9 and would like to use it. I tried to encode Naked gun 33 1/3 with AutoRV9b6, using lower quality for credits. However, AutoRV9 was not able to join the two files. Neither was I afterwards using AVI/MPEG/RM/WMW joiner 4.48. The two files both play fine in RealOne and MPC (though jerky playback in both). Here is the log file, hopefully the cause of the problem can be found there. Thanks in advance.

http://www.direktdemokrati.net/Nakedgun33_LogFile.txt

olorin

[karl_lillevold]

@olorin: This is caused by a change in rmeditor in Milestone 6, where it will not merge files with a different maxBitrate. Here is what you need to do to get around that, until AutoRV9 1.3 final comes out.

1) Find a copy of an older AutoRV9, or Producer Milestone 5.
2) find the old rmto3260.dll in producer's tools folder. In AutoRV9 this is in Softs\Rp9_Light\tools
3) Goto the same folder in the new AutoRV9.
4) replace its rmto3260.dll (6.0.11.434) with the old one (in my case v 6.0.11.433)

now you can merge the files you just encoded manually:

5) open cmd line window, cd to AutoRV9\softs\Rp9_Light
6) then type

rmeditor -i <main_file.rmvb> -i <credits_file.rmvb> -o <final.rmvb>

Also, since you just replaced rmto3260.dll, the next time you encode something like this, it will merge just fine.

[Sirber]

Why can't we do that anymore? Merge 2 files with 2 different maxBitrate?

[karl_lillevold]

https://helix-dna.helixcommunity.org/issues/show_bug.cgi?id=288

[Dr Satan]

I'm getting some strange results from the compresability check. It produces results of 240%+ when it obviously should be producing something sub 100%. Also, when checking the comp check output file, many frames are missing.

I know it only encodes 5% of the film, but at points it only runs at about 3fps, from a 25fps source.

[hubereevez]

i made a few compcheck......
It seems that they're not very accurate.....
But I don't exactly know....dark?
hubhub

[Dark-Cracker]

hi,

sorry i have take 2 days of holidays :)

for the compressibility test, in fact rv9 doesn't work exactely like other codecs, in other codec it made a first pass was made at quantizer 2 (=quality 100%) and adjust the bitrate curve to obtain the desired file size.

a basic explication :

HOW A COMPRESSIBILITY TEST WORK :
---------------------------------

the compressibility test work like this : it select 14 frames each 280 frames. to get 5 % of the movie. after u encode it at max quality.
and u analyse the obtained file. u get the size of this compressibility sample by adding each frame size but skipping for each packets (our 14 frames lenght) the first frame and the last frame, because there is an virtual scene change beetween each packets and the codec add a keyframe and a keyframe is much bigger than a normal frame. once u have the size of 5% of the movie u can estimated it for the full movie. and the % of compressibility is the ratio beetween the desired size and the estimated final size.

for example if once u have made the 5% at max quality u get an estimated final size for the movie around 1000 mb and u want to encode the movie at 700 mb u will have a compressibility % = 70 % because : (700/1000) * 100 = 70%

why UNDERSIZED file :
-----------------------

it's used because for exemple if u estimate the first pass at max quality = 1000 mb and u want to encode the movie on 1400 mb u will obtain a final file around 1000 mb because the codec have encode it at MAX quality, and u will have an undersized file.
(in this case the comp % = (1400/1000) * 100 = 140 % ).

why OVERSIZED file :
----------------------

and same thing , if u ask a final size = 300 Mb while the first pass
say u the movie request 1000 mb for a perfect quality, even if the codec try to very very compress it, it will never rush a so little size.

-----------------------------------------------------
this is correct for the divx3,4,5,xvid ... codec but for the rv9 the codec apparently doesn't work like this.
first in rv9 the keyframe are not bigger than a normal frame, skipping frame during compresibility test is useless.
and rv9 can skip frame or smooth them to get close to the desired bitrate.
and at max quality there is not a huge difference beetween the same sample at different resolutions.


to sumup made an accurate compressibility test for rv9 is strong :( and request a lot of tests and i have no time for this, sorry.

and sorry again for my poor english hope u have anderstand my little explinations.

Bye.

[karl_lillevold]

As you may know, the compressibility number is a measure of your current bits/pixel number (calculated from your target filesize and video resolution), relative to the number of bits/pixel needed for MAX quality. The dilemma with RV9 is that its Quality=100 mode will create a huge file, with much higher fidelity than you can really appreciate. Therefore, if compressibility in RV9 was calculated relative to Quality=100, you would get very very small numbers. So when I assisted D-C with RV9 compressibility, I chose like Quality=83 to be the "max" quality. This seems to provide reasonable compressibility numbers for some test content (40-60%).

So what does it mean when RV9 compressibility is > 100. It simply means that with the target filesize you have chosen for your video, it would be encoded at higher quality than Quality=83. In the case of 240%, you would get extremely high quality, and your target filesize is most likely much too high.

It may be that our "max reference" quality of 83 is too low, so please provide some feedback so D-C can tune this number.

Generally, I don't use compressibility too frequently. I tend to look at which number of bits/pixel my target filesize corresponds to. For RV9-EHQ I try not to go below 0.13 bits/pixel, but I have been told for some content, one can go below this. Any higher than 0.18-0.20, and you would probably be better off encoding at a higher resolution, or lower filesize.

Hope this helps.

[Dr Satan]

Thanks for the response, however I think I might have phrased the problem wrong...

Y'know how real player drops frames to meet target bitrate, well it's doing this in the compressibility check, therefore giving inaccurate results since it's encoding at what looks like 3fps in parts.

This is what I believe lead to the oversized compressibility. Is there a way to force the producer to compress all frames for the check?

[ookzDVD]

@karl_lillevold,

You are right,
I just delete the reg key for the EHQ and now ML 6 is working well.

Thank you.


Generally, I don't use compressibility too frequently. I tend to look at which number of bits/pixel my target filesize corresponds to. For RV9-EHQ I try not to go below 0.13 bits/pixel, but I have been told for some content, one can go below this. Any higher than 0.18-0.20, and you would probably be better off encoding at a higher resolution, or lower filesize.


How about the normal mode, not EHQ ? Should be > 0.13 ?


@DC,

Just can't wait to have the final one :)

[Dark-Cracker]

hi,

i have say it i have do it :)

FINAL VERSION !!!

DOWNLOAD LINK :
----------------
http://rackspeed.he.net/~adntat/dark/modules.php?name=Downloads&d_op=getit&lid=17
(remember u can download the VB runtime needed in the other download setion in my site web : www.dark-angel.does.it)

PS: i have bundle the real audio 5.1 package, and the fixed dll needed for the join :).

Changelog :
-----------

- add DTS audio input
- add a speed test
- improve Hight Motion filtering
- improve finale file size calculation
- improve .smil file
- multilanguage support
- use latest millestone 6
- support anamorphic encode
- work with avisynth v2.5.1
- support .avs input (this mean avi/directshowsource can now open : .rmvb/.mkv/.omg/.avi/.wmv/.mpg/.qt )
- support the "Real Audio 5.1" codec
- support audio 2.0 (stereo) =>5.1 (surround) conversion
- added EHQ mode
- add chapters support for .smil
- add transparent subtitle for .smil
- detect the avisynth error msg
- improve avisynth editor (support credits .avs).
- change latency at 60 sec
- added support for Multichannel (create 6 separate .wav mono file)
- add support for 5.1 input wav file.
- rewritte the rv9 header parser
- improve P4 Hyperthreading support.
- improve the split : more accurate & fix the black screen bug on second part
- fix the problem for the update of avisynth script file
- anamorphic encode support
- support .wav audio input file
- improve smil file for 4/3 movie.
- improve audio part (full azid comfiguration possible,add boost, pre gain .... etc )
- add bicublin resize
- support 1 pass QB 100%
- support 1 pass CBR
- support 1/2 pass VBR
- add a compressibility test.
- improve crop window
- add ratio 1:1 to enter manualy your resize value.

[ookzDVD]

@DC,

It's fast :)

Btw, the Program title windows still : AutoRV9 Beta 6 :)
it's coming with ML 6 :) not ML 5 is it ??

[Dark-Cracker]

dohhh i forget to change the title :( i will secretly replace the .exe file :) and yes it come bundle with Millestone 6.

EDIT : i forget to say it come bundle with 8 language file (french, german, turkish, chinese, italian, spanish, japanese, english)

if some people are interested to translated it in other language u are welcome :) .

Bye.

[karl_lillevold]

Originally posted by Dr Satan
Y'know how real player drops frames to meet target bitrate, well it's doing this in the compressibility check, therefore giving inaccurate results since it's encoding at what looks like 3fps in parts.

This is what I believe lead to the oversized compressibility. Is there a way to force the producer to compress all frames for the check?
As far as I know, that's how the 5% of the movie is supposed to be encoded for the compressibility test. The Avisynth function SelectRangeEvery(Video,280,14) is used (see "filename_CompCheck.avs"), which extraxts 14 frames every 280 frames. If you were to encode all the frames for the test, it would take as long as encoding the complete file.

Actually, while I am running this test right now, I noticed a problem in AutoRV9 1.3b6. Not sure if it has been fixed in 1.3Final. maxBitrate in AutoRV9_CompTest.rpad is set to 999999, which over-rides the vbrQuality=83 parameter. This will limit the quality of the compressibility encode, resulting in too high compressibility numbers, I think. maxBitrate for the comp test should be set to something like 99999999 to avoid it affecting the result.

@ookzDVD: yes, something like 0.18-0.2 bits/pixel was my experience required before EHQ, but your milage may of course vary. Experiments well tell.

@D-C: congratulations on completing version 1.3!

[Big_Berny]

Hi,
since beta6, I think, I have a problem:
I captured the Simpsons with a resolution of 384x288. Then I crop it:
Up: 10
Down: 6
Left: 10
Right: 6

Now I don't want to resize the movie, so I deactivate it manually by editting the final avs-file. If I use "2dClean" the producer crashes at the beginning. But if I use "Mipsmooth" it works normally.
I also tried to set the resize-resolution to the cropped resolution (368x272), but it crashes too.

Do you understand my problem?
It crashes when "croppedsize=resizesize + 2dclean"

Any solution?
Thx
Big_Berny

[Dark-Cracker]

hi,

@karl
yes finaly i was motivated :) and i have work all the night to release the final version, i still have some idear to improve it but i will keep them for the next release :)

@Big_Berny
i have tested and i can't reproduce this bug, try with an Millestone 5 if u say this doesn't happen with the previous beta.
another suggestion is to be sure your resolution was a modulo 4 .
and my last suggestion is to be sure u have all the msvcrt7 runtime because generaly some avisynth filters have this for dependency.

PS: does the preview with avisynth in the mediaplayer crash ? or only when the encode start ?

BYe.

[karl_lillevold]

@Big_Berny: hard to tell where the problem is. After a configuration that as crashed, could you try the following:

open cmd line window
cd to your_autorv9_folder
cd softs\rp9_light
then type:
producer -i <path_to_contents\yourfilename_Movie.avs> -ad c:\autorv9_Movie.rpad -lc e,d -am music -o output.rmvb

what happens? which module crashes? is there anything in producer.log?

Then edit yourfilename_Movie.avs to remove the 2dclean filter.

Try the same procedure again.

In both cases, try to open this avs file in VirtualDub or MPC. Is there a problem there as well? If yes, then it's a 2dclean problem.

[olorin]

Great prog this AutoRV9! :)

I'm just trying out the new v1.3 and get some strange comp test results. I get like >5000% on every movie. Don't know but maybe it has something to do with the .rpad file?

<avgBitrate type="uint">1</avgBitrate>
<maxBitrate type="uint">16000</maxBitrate>

EDIT: Ok, maybe not...
<encodingType type="string">vbrQuality</encodingType>
<quality type="uint">80</quality>

So you decided to lower it from 83 instead of increasing it :)

olorin

[Big_Berny]

I can reproduce the error with all my avis!

It's not the producer also the VideoPreview crashes.
If I deactivate 2dClean or Crop, encoding works but not the VideoPreview.
With Milestone 5 I have the same problem.

Clonclusion: I think the problem with the Videopreview is not the same as the encoding problem. And the problem is somewhere in the 2dClean+crop, because with Mipssmooth it works!

Some thing else to test?

[jollytim]

I was very skeptical of using a different codec, I haven't had much success in the past with anything but DivX (in most flavors). Lately I've been interested in the progress of new codecs and encoding schemes with wavelet and fractal codecs being of paticular interest. Well anyhow I stumbled upon this thread and downloaded the 1.3 version of AutoRV9. Using a fresh vob of StarTrekIV (okay maybe I could have found a video that exercised this codec more) but I recently encoded using Divx5 (Kaukuri beta) and was moderately happy. I tried using AutoRV9 with all the quality features (I don't recall the exact settings though I could post the log if requested) and 40 hours later (it took that long with my P3800) I'm done. I was very disappointed with the extremely long encode time until I looked at the results......WOW. I thought I was looking at DVD. Far better than my beloved Divx. Great job on a quality codec and great job on a quality GUI package. I've used BeSweet almost since it inception and am glad you included it. I shot for a 700MB filesize and that was accomplished. The encode was around 855kB for the video even with 192kB audio. It doesn't matter if I use Divx Player (2.5) or MPC, the results are fantastic.

[Big_Berny]

Another thing that is strange, is, that when I put the crop-command on the avs-file which I open with AutoRV9 it works!

[Dr Satan]

Originally posted by karl_lillevold
As far as I know, that's how the 5% of the movie is supposed to be encoded for the compressibility test. The Avisynth function SelectRangeEvery(Video,280,14) is used (see "filename_CompCheck.avs"), which extraxts 14 frames every 280 frames. If you were to encode all the frames for the test, it would take as long as encoding the complete file.
I must have worded what I'm trying to say badly. I know only 5% of the file is to be encoded for a comp check, and I understand how it picks those frames. This is not the problem however.

You know RV9 will drop the frame rate to meet a given bitrate? Well, it's doing this during comp checks. I got a high % after a check so I viewed the file, and in parts it was running as low as 3fps. In parts it was like watching a still image slideshow. The low framerate kicked in after a few scenes of high motion. The framerate was not dropped in this fashon in the final encode.

Now I know frames are dropped during a comp check, but the frame rate is supposed to stay the same as the original right?

In the check I did, because the rv9 codec was dropping some of the frames it was being sent (hence the low framerate) it was in fact encoding less than the requested 5% of the movie.

Sorry for the confusion.

[karl_lillevold]

i understand what the problem is now. Thanks for clarifying. I am pretty sure it's related to the maxBitrate parameter used in AutoRV9's compression test audience file (c:\AutoRV9_CompTest.rpad). In my test it was 999999, which is too low. olorin says it's as low as 16000. What happens when Producer encodes at fixed quality 83, and it exceeds the maxBitrate, is that it will lower the quality, and eventually also skip frames. Like I wrote, maxBitrate in the CompTest case, needs to be a very very large number, like 99999999. This is a problem that should be corrected in AutoRV9.

@DrS: can you check what the maxBitrate is in your c:\AutoRV9_CompTest.rpad file?

[Dark-Cracker]

i have made some changes in the compressibility test :) (i have forget to change the 16000 value used during my tests , sorry ... )

i have reupload the archive, and i give u a direct link :

http://www.eclipsedvd.firstream.net/autodub/autorv9_comptest.zip

(replace the old .exe by this one and say me if all work fine :) ).


PS : does someone know a siteweb where i can send my software submission ? version 1.3 is very stable and i want other people know it and of course use rv9 :)

@all
thank u for your support, this give me my motivation :)

Bye.

[bond]

first of all i have to say that thanks to d-c's new release (great prog!!!) i tested rv9 again after a long time and i was really impressed!
i will test it a little bit more on full 1cd rips but till now it seems that rv9 is going to be my second favourite video codec (equally to xvid) :)
karl really made a great codec (the only thing we still need is a vcm codec to use it in virtualdub :D )

only one thing which i really dislike is the very strong (too strong) smoothing in high motion scenes leading to ugly results, perhaps there is already a way to avoid this somehow?

Originally posted by Dark-Cracker
i have made some changes in the compressibility test :) (i have forget to change the 16000 value used during my tests , sorry ... )i think you use 1 pass for the comptest?
i got a value of 120% with your fixed .exe, but if i make a full 2-pass encode i dont get an undersized file with the same source!? why that?

PS : does someone know a siteweb where i can send my software submission ? version 1.3 is very stable and i want other people know it and of course use rv9 :)point doom9 to your new version, i am sure he will post it on his main page

[Dr Satan]

Originally posted by karl_lillevold
@DrS: can you check what the maxBitrate is in your c:\AutoRV9_CompTest.rpad file?
It was 999999. Thanks for the response.

[Dark-Cracker]

@bond
thank u :)
karl is working on 2 pass vbr and i think this smooth effect in hight motion will soon disapear :) :) :)

for the 120% compressibility is because it made the pass at 75 % quality because 100% give really to huge file, and more i think there is always a % error because the compressibility test is only on 5% of the movie. just to know which lenght of the movie, and desired final file size, and resolution ?

i have alreday point it at doom9 but i think he can't post a new each time a people send it a request , and i understand he ignore it :) i have see for divx-digest.com siteweb :) but it the only software siteweb i know, ... autorv9 is perhaps designed to stay "underground" :)

@Dr. Satan
perhaps should u test the new .exe file i have change the compressibility test.

Bye.

[olorin]

@D-C
Thanks for the new exe! :) The comptest works great now.

@all
I would ask all testers to share your experiences of this new comptest (based on 75% quality now in the latest version). What % have you used with good results and not so good? Myself I have not yet had the time to encode anything with the new exe, but I'll get back.

olorin

[bond]

Originally posted by Dark-Cracker
karl is working on 2 pass vbr and i think this smooth effect in hight motion will soon disapeargoodie :)
nothing against smoothing in high-mo, but now it is far too strong imho

for the 120% compressibility is because it made the pass at 75 % quality because 100% give really to huge file, and more i think there is always a % error because the compressibility test is only on 5% of the movie. just to know which lenght of the movie, and desired final file size, and resolution ?hm, i tested a short clip of a movie (~5min, 640x..., 20mb)
because of that i also used 100% (not 5%) in the comptest too!

[Griniaris]

Hi there!
I am new to the rv9 world and I tried my first encode using AutoRv9.
I was aiming at 696Mb and got a file of 716Mb. Is there something I could have done wrong?
I only used undot from the filters list and sharpest motion, EHQ very high level, improve high motion scenes options.
BTW is there a recent guide explaining the various options autorv9 is offering somewhere?
Last but not least, I am using MPC with the dll package to playback the real video files. I was wondering if there is a way to somehow include some dll files and filters with the movie to make a standalone cd (no installation but filter and dll registring on the fly) Are really all of the dlls MPC installs necessary just for the playback? If not which are the ones needed?
Thanks!

[deXtoRious]

You did allright. I don't know why, but I always get a bigger filesize too. You should select 680mb next time.

[Dark-Cracker]

hi,

the hihg motion scene option noise&sharp hight motion to get more details and more details need more bitrate it's surely for this u have obtain an oversized file. have u made a 2 pass encode ?

i am sorry u have an oversized file :( hope u have endcredits and u can remove them using : rmeditor -i "input.rmvb" -o "output.rmvb" -s 0 -e "xx:xx:xx.xxx"

replace by the end time where u want to split (i think u need remove the 1 or 2 last minute).

for the moment there is no guide i have no time to work on it but perhaps someone will made one :) (normaly a people is working on a german guide and a french guide but i have not receive there files for the moment :) ).

Bye.

PS: i suppose and improve in the 2pass vbr for the rv9 will also improve final file size precision :)

++

[Synaps]

I hope sagittaire works on french guide :D