New Version of Avi.net

[audioman]

Thanks MARK

This is absolutely what I was meaning
a compression test is very useful , some movies are more or less compressible !!!

Another question to INFO

Concerning quality based ( 1 pass quant ) and size based ( 2 pass ) , what parameter do you advise to use to get the best from a movie ?

Thanks

[Jacquers]

I see you switched to DivXMux.exe instead of vdubmod for muxing.

Just a warning: DivXMux has a "bug" where audio delays greater than +-1000ms are just ignored and dont get applied when muxing.

[AjnabiZ]

Any reason for moving from VdubMod to DivXMud ?

[Jacquers]

Probably because of the 2gb limit or better standalone compatibility.

ps. forgot to mention that DivXMux has a 4GB limit for muxing.

[iNFO-DVD]

This is absolutely what I was meaning
a compression test is very useful , some movies are more or less compressible !!!I completely understand but what I'm trying to say is what use to avi.NET would this have? Due to standalone support there's certain options I can't use and thus can't let the user select e.t.c. If avi.NET gets to the target size (within reason) anyway, then what use would the compression test have? What ever results I'd get from a compression test I don't see how they can help.

Concerning quality based ( 1 pass quant ) and size based ( 2 pass ) , what parameter do you advise to use to get the best from a movie ?In general or with avi.NET? Because of standalone support there's not any codec parameters as such you can change in avi.NET. Please expand.....

DivXMux has a "bug" where audio delays greater than +-1000ms are just ignored I know nothing about that..... > +-1000 would only happen in rare circumstances, I'll have to see how that goes, maybe it's not a problem, DivXNetworks sent me the DivXMux to include in avi.NET, they asked me to use only this version, it's a higher build than the one that got released normally. Hopefully it wont be a problem.

Any reason for moving from VdubMod to DivXMud ?Well, smaller, easier to use, specific for the job and look at 'Jacquers' answer.

[audioman]

Hi INFO

Let me try to explain...
In AVI.NET, would you advise me to select quality based movie ( 1 pass quantity for example 3 ) or just choosing a 2 pass ( size based movie )
Can you explain me the differences between the Two parameters
I always wanted to keep my movies close to original dvd lol :)

[ricardo.santos]

lets say you converted a movie ( 1 pass quantity for example 3 ) and final size was 2 gig, for what ive seen here written in the forum a 2 pass conversion set for 2gig will look better than a 1 pass quality mode.

i never do quality based pass

[audioman]

lets say you converted a movie ( 1 pass quantity for example 3 ) and final size was 2 gig, for what ive seen here written in the forum a 2 pass conversion set for 2gig will look better than a 1 pass quality mode.

i never do quality based pass

Can you tell me which posts you've read ?

Your answer is pretty weird , I just made a test on a movie and the quality is awesome with quantizer 3
The final avi file is 1.2 go and Bitrate 1800 for a 100 mn movie

How can you say it will look better with a two pass mode ? Weaver can you help ?

[Jacquers]

Would it be possible to add support to use .ifo files as input?
The IFO parsing part would be the hardest part, but combining the vobs in the avs script is easy and if you have multiple vobs in DGIndex as input the audio still gets demuxed to a single file.

Some of my newer dvds (legally owned) have tough copy protections on them that I could only get to my hdd with RipIt4Me, which doesnt give me one large vob. I could combine them into one vob with a simple dos copy cmd, but then extracting the subtitles dont work as the ifo points to the seperate vobs, not the combined one.

Any ideas?

[iNFO-DVD]

Would it be possible to add support to use .ifo files as input?
The IFO parsing part would be the hardest part, but combining the vobs in the avs script is easy and if you have multiple vobs in DGIndex as input the audio still gets demuxed to a single file.

Some of my newer dvds (legally owned) have tough copy protections on them that I could only get to my hdd with RipIt4Me, which doesnt give me one large vob. I could combine them into one vob with a simple dos copy cmd, but then extracting the subtitles dont work as the ifo points to the seperate vobs, not the combined one.

Any ideas?IFO Parsing wouldn't be 'hard', I already do this in 'rip.NET' but you're worrying over nothing. What makes you think you need your VOB in a single file?

[ricardo.santos]

Can you tell me which posts you've read ?

I´ve read here that (can remember the post/who wrote it, but i remeber someone saying that 2 pass mode will always give better quality than a 1 quality pass (both with same size)


Your answer is pretty weird
english is not my native language.

I just made a test on a movie and the quality is awesome with quantizer 3
The final avi file is 1.2 go and Bitrate 1800 for a 100 mn movie

How can you say it will look better with a two pass mode ?

Ive decided to do some tests, perhaps i done something wrong in the last ones i did a while back, i used avi.Net and choose quantitizer 3 and converted a 10 minute vob file, the final size was 150 megs. Picture quality was good

I then converted the same vob file in two pass mode and set final size as 150 megs and i was surprised to see that the quality was the same as the 1 pass conversion.

there were some diffrences but standing away from the pC i couldnt see any differnce at least on this movie.

But final size is a no go for me in 1 pass, i usually capture shows from tv and for 45 m show the size would be 700 megs, witha 2 pass i can put 2 shows on a cd with same quality.

So you were right and i was wrong about the quality. a 1 pass conversion takes as much as twicw size of a two pass

[mod]

Usually, a 2 pass encode can "distribute" better the bits all over the movie length, depending on the source.
ie, if the movie is 2 hours long, 1 hour people talking in a room and 1 hour cars running in a street (wtf ^^) then a 2 pass encode will give more bits to the second hour.
A (low) fixed quantizer encode will use a lot more bits for the 1st hour then the "needed" ones, so the 1st hour of movie will be bigger without giving a higher quality.
If the avg bitrate of the 2 pass encode is "high enough" to give a good output in the second hour of the movie, then what you get is a movie the same quality but with a "cheaper" 1st hour.

[Jacquers]

I thought avi.NET only accepted a single vob at a time as input? Wasnt this the reason why rip.NET exists, to have the movie as one big vob instead of multiple files?

I would have used rip.NET but the copy protection on the disc meant I had to use RipIt4Me

[ricardo.santos]

Usually, a 2 pass encode can "distribute" better the bits all over the movie length

So that i can understand it better, what 1 pass quality mode does to overcome that problem is raises the bitrate to bypass/overcome "bitarte shortfalls" but on the downside makes the file size bigger because of the increase in bitrate.

is that it?

[iNFO-DVD]

I thought avi.NET only accepted a single vob at a time as input? Wasnt this the reason why rip.NET exists, to have the movie as one big vob instead of multiple files?No, it was developed beacuse of the lack of standalone compatible programs that were available at the time.

I would have used rip.NET but the copy protection on the disc meant I had to use RipIt4MeThat's fine, you don't need to use rip.NET.

The point you have to remember is to convert a DVD to AVI or anything for that matter you really should take the relevant PGC to convert. If after you have ripped a DVD, lets say a 'traditional' file rip, nothing fancy, so you end up with a bunch of (usually 1GB) VOB files. These are NOT good to use as input, some movies that have multiple angles and more importantly seamless branching will do some right weird things if you try to convert. Imagine a movie that has different versions in the same VOB SET...... One of the X-MEN movies did this and I think ID-4 or was it a TERMINATOR, can't remember. Realisticly you need to take just the correct version, the correctly PGC that you want to convert. I usually rip it to a single file so then I can see that it's a PGC rip and not just the 'normal' ripped files. Some DVD's may require ripping, then some sort of re-ripping once on the hard drive to get the desired PGC, with rip.NET for example, or one of the many processing tools available for the job, this would only be relevant for some of the later newer protection DVD's.

[MarkCurly]

I completely understand but what I'm trying to say is what use to avi.NET would this have? ... If avi.NET gets to the target size (within reason) anyway, then what use would the compression test have? What ever results I'd get from a compression test I don't see how they can help.
When a user converts some video, they get to choose the bitrate or filesize.

They might choose to convert a 4:3 aspect 1 hour movie into a 700MB file, with a screen width of 640 pixels. Qf might be calculated around 0.20.
(They might think "0.20 sounds OK, lets go!")

BUT the movie might contain a LOT of detailed scenery and a LOT of movement. Some movies compress better than other movies. It may be that Qf=0.20 is not enough bits to get a good quality encode. But the user will not know this until the encode has finished, and they see the blockyness and smearing and whatever damage the codec did because it did not have enough bits.

BUT if before they converted it, they were able to run a compression test, the test would say: "Woah! this stuff does not compress well! You need Qf around 0.30. You need to either increase the filesize, or decrease the framesize."

Or suppose the video was Anime with little moving frames. The compression test would say: "You are wasting space, you only need a Qf of 0.20, how about increasing the frame size to 720 width for more quality?" Or it might say: "If I turn off b-frames, the quality should be better."

In any case, the user gets some feedback on the parameters they have chosen before they waste however many hours on an encode that didn't look good enough.

Due to standalone support there's certain options I can't use and thus can't let the user select e.t.c.
The options the compression test helps set are the inter-related Qf/filesize/bitrate/framesize options.
Not (necessarily) the more esoteric options.

[iNFO-DVD]

BUT if before they converted it, they were able to run a compression test, the test would say: "Woah! this stuff does not compress well! You need Qf around 0.30. You need to either increase the filesize, or decrease the framesize."

Or suppose the video was Anime with little moving frames. The compression test would say: "You are wasting space, you only need a Qf of 0.20, how about increasing the frame size to 720 width for more quality?" Or it might say: "If I turn off b-frames, the quality should be better."Sorry but that is unacceptable. I cannot realistically do a comptest, gives results to the user and wait for them to redo their settings. That will really p*ss people off.

The theory of what you say I completely agree with, it's the practicallity of it that's the problem.

[weaver4]

Usually, a 2 pass encode can "distribute" better the bits all over the movie length, depending on the source.
ie, if the movie is 2 hours long, 1 hour people talking in a room and 1 hour cars running in a street (wtf ^^) then a 2 pass encode will give more bits to the second hour.
A (low) fixed quantizer encode will use a lot more bits for the 1st hour then the "needed" ones, so the 1st hour of movie will be bigger without giving a higher quality.
If the avg bitrate of the 2 pass encode is "high enough" to give a good output in the second hour of the movie, then what you get is a movie the same quality but with a "cheaper" 1st hour.

A single pass constant quality will give considerably more bits to to those frames that have more action in them. In your example the second hour would get (significantly) more bits. The first hour would only have the bits that are needed to give the quality that you asked for. Look at it this way, in a single pass the encoder looks a each frame and make the determination on how many bits it needs to allocate to get the quality you desire of the next frame. If the two frames are identical it will use none (well close to none). In a two pass system the first pass will look at the frames and the second pass will determine where it needs to make quality sacrifices to get the filesize you want.

You might want to look at the documentation for AutoGK and Staxrip, you will see that they concur on the quality of single-pass.

Some movies need 800kbs average bit rate, some need 1600kbs to get good quality. Without a compressibility check how do you know? Use single-pass and let the Codec figure it out.

[Jacquers]

Ok, thanx for your answer iNFO-DVD, I managed to do the following: Rip to hdd with RipIt4Me in movie-only mode, then process with rip.NET. And avi.NET is happy with the input.

I still think it would be nice if avi.NET could have .ifo as input because the files from RipIt4Me did contain only one angle, but I get your point that loading from ifo can be an issue of someone hasnt ripped it correctly

[mod]

@weaver4: I agree with you, maybe my english isn't very good ^^.
I was trying to say that "given the same filesize" the 2 pass encoding distributes better the bits. Of course a quality-based encoding uses the bits needed for every frame, but this doesn't allow a good control of the final filesize.
[ Atm I'm working to add a comp check to my tool sARc, as it sounds like "don't say that the result is ugly, I told you that 20% was TOO low!!" ;) ]

[iNFO-DVD]

because the files from RipIt4Me did contain only one angleBearing everything in mind about what I said earlier, you can if you wish add the files directly from RipIt4Me, I've never used the program, but if you have a bunch of VOB files, VTS_01_1.VOB _2.VOB e.t.c. you can use them for input, just load the first one into avi.NET, it will process the whole set automatically.

[iNFO-DVD]

I'm tying with the idea of a compression test, it seems a lot of people would welcome it, there's lots of information about the forum of how this is done e.t.c. the problem I have is it's implementation..... How would I actually integrate it into avi.NET? Would it be something used all the time? Used for both 1 pass and 2 pass? Would it be an individual button? The problem I have is what to do with the result..... Do I just run a comptest when a button is pressed and relay the % result to the user before the real encoding starts?

I really need to know where I'm going with this before I can start to do any code.

Thanks

[ricardo.santos]

..... How would I actually integrate it into avi.NET? Would it be something used all the time? Used for both 1 pass and 2 pass? Would it be an individual button?

If youre going for it i reckon for both is a good idea, and if possible to leave it as an option. If im converting episodic dvds i dont need the test for each one.


.....
The problem I have is what to do with the result..... Do I just run a comptest when a button is pressed and relay the % result to the user before the real encoding starts?

I really need to know where I'm going with this before I can start to do any code.


I would like to see the actual comptest encoding.

[iNFO-DVD]

Actually this is going from bad to worse. I'm kind of all geared up now to mess with the compression test stuff but.....

This is what I was thinking:
At the start of the encode automatically do a comptest, display this value to the user in the log window as normal then automatically choose a compatible matrix, let's say a low, medium, high matrix depending on the compression test value. Now here's the problem.....

(If I'm wrong here I hope someone can correct me)
To use a custom matrix I need to use the Quantization Type: MPEG-Custom which I can't use as I need to be using a standalone player profile. If I changed to unrestricted then I can't alter the VBV values.......

[Sharktooth]

Ah... that could be a problem.
AFAIK AutoGK use unrestricted settings except for ESS and MTK chipsets.
So i guess the DXN profiles just want h263 quantization.

[ricardo.santos]

cant help you on the second part but i have a question about:
All the user gets to see after the comptest is a "bunch of numbers"?

I thought it would be up to the user after visually checking the comptest to enable the use of matrice or just increase the final size?

[Sharktooth]

well i was thinking to run the comp.test with the user settings and checking the PSNR or SSIM of the comp.test encode.
if results are too low then some "countermeasures" should be taken.
That, at least, was my idea for the MeGUI compt.test (still not implemented).

[weaver4]

I have used alternate matrix under autogk and I personally don't feel it is worth it. I have found that I select the SAP-ESS option (so it uses h.264) the filesizes are much smaller. With the default setup the filesizes are much larger when you are using the same quantizer. And I don't think the picture is much better (the experts say it is better though). Try it yourself run the same movie twice on AutoGK once with the defaults and once with the SAP-ESS option on compare the filesizes and then look at the picture.

I am very happy with the picture quality with respect to filesize on AVI.net; so please don't mess it up.

[iNFO-DVD]

New version up, v2.1.8.2, fixes the shutdown bug refered to HERE (http://forum.doom9.org/showthread.php?t=115290) and also another bug concerning the job list and HDTV.

[MarkCurly]

Actually this is going from bad to worse. I'm kind of all geared up now to mess with the compression test stuff but.....

This is what I was thinking:
At the start of the encode automatically do a comptest, display this value to the user in the log window as normal then automatically choose a compatible matrix, let's say a low, medium, high matrix depending on the compression test value. Now here's the problem.....

(If I'm wrong here I hope someone can correct me)
To use a custom matrix I need to use the Quantization Type: MPEG-Custom which I can't use as I need to be using a standalone player profile. If I changed to unrestricted then I can't alter the VBV values.......
Because you want to retain standalone compatibilty, I would not muck-about too much with the matrix.

The major thing you want to change based on a compression test is the Qf value used (which means changing the bitrate and/or framesize).

AutoGK (IIRC), if it decides that a video source is less than normally compressible, may decide to use the H263 matrix (which is softer). If it decides that the video source is more than normally compressible, it may decide to use the standard MPEG matrix and/or to disable B-frames.
(It always uses a standard matrix, either H263 or MPEG.)

You perhaps don't need the compression test to be ALWAYs run; you could make it an optional step that the user can run if they want to before doing the main compress. The main compress would NOT automatically start after the compression test had finished, so that the user has a chance to read the results and decide how to change the convert parameters. It could run and display information (probably in conjunction with the bitrate calculator?) and perhaps make some suggestions for changed bitrate and/or framesize. Maybe with a button to copy the suggestions to the current convert setup.

[audioman]

I think Mark Pointed out the right way for you INFO
Just knowing the right QF to use for every movie

But How to implement the comptest in AVI.net , that is the question :(

Good Luck and thanks again for your wonderful piece of software , I know it must be a tough work

AVI.NET rockkkkkkkkkkks

[Sharktooth]

AutoGK (IIRC), if it decides that a video source is less than normally compressible, may decide to use the H263 matrix (which is softer). If it decides that the video source is more than normally compressible, it may decide to use the standard MPEG matrix and/or to disable B-frames.
(It always uses a standard matrix, either H263 or MPEG.)
No, it uses EQM V2 instead of MPEG standard.

[MarkCurly]

No, it uses EQM V2 instead of MPEG standard.
I forgot to say I would have the ".compatability, Enable standalone support: ESS" option enabled.
I don't know, but wouldn't it then use either H263 or a standard MPEG matrix?
Sorry.

[Sharktooth]

IIRC h263 only.

[unskinnyboy]

@iNFO-DVD, A question..mostly about the future direction of avi.NET.

Do you always plan to center the development of avi.NET around yours and your mate's standalones? Like I said in another thread, newer, cheaper and better standalones come out every other day and these babies play almost anything. You feed them any of those files which you considered yesterday to be fully standalone incompatible, and chances are that these standalones will play them. And on the consumer side of things, people are upgrading, slowly but surely. Most of the upgrades are due to the fact that people want to be able to play files which are of better quality and at least some are due to the fact that they get fed up of recompressing their downloaded files (the downloaded files might be using advanced features which their standalones wouldn't support). And of course, there are people who buy standalones for the first time, and they will surely buy one of those play-it-all ones.

The point here is that, soon, making a file standalone compatible wouldn't be such a big deal anymore, so what would you do with avi.NET then? Will it always be based on the very picky 2 standalones you have? Or would you rather shed the strict standalone-compatible stipulations you have and go after implementing more features to fully milk the MPEG-4 ASP unrestricted profile?

P.S: Do you or your mate plan to upgrade your standalones? :-p

[iNFO-DVD]

I would like to think avi.NET would change with the times and use more codec options as and when.

Just because some players come out in the last couple of months or year which will play whatever I can't then start using an unrestricted profile just because that player can play them and obviously on the other hand that doesn't mean I wont change anything.

I have a Sigma chipset based player from 3 years ago and I tell you this it plays far more AVI's than any of the newer MTK and ESS based players we have in the UK that I've tried. Mine's fine, I can play unrestricted profile and custom matrices, it's them bloody cheap MTK and ESS eastern imports that I test I dislike which flood our shops.

If people don't like the fact that current standalone playback machines is my priority then don't use avi.NET.

[iNFO-DVD]

It has occured to me after all these standalone player conversations that maybe I could relax certain options, do you think this would be a good idea:

To have any option that would relax the XVID standalone profile for people who have players that can deal with this? I don't want to go to far just yet, I was thinking more on the line of this option using a profile that would then allow me to use custom matrices, the 3 EQM ones for example.

[MarkCurly]

It has occured to me after all these standalone player conversations that maybe I could relax certain options, do you think this would be a good idea:

To have any option that would relax the XVID standalone profile for people who have players that can deal with this? I don't want to go to far just yet, I was thinking more on the line of this option using a profile that would then allow me to use custom matrices, the 3 EQM ones for example.
That would be a great idea.

My player cannot handle custom matrices (well I hear there are some it can handle...), BUT I would like to enable 2 consecutive B-frames. The XviD (IIRC) and DivX Personal Theatre profiles only allow 1 consecutive B-frame.

I'm ->||<- this close to hacking into AutoGK myself to allow 2 consecutive B-frames (via AGKPal)...

If avi.NET had a compression test and allowed tweaking of the encode parameters a little, I'd throw AutoGK away and never look back!

[Sharktooth]

@info-dvd: maybe adding a "strict divx profile compliance" checkbox in the options would be an idea...
when disabled it will allow the codec to use 2-bframes and (in case of xvid) custom matrices.

[iNFO-DVD]

@info-dvd: maybe adding a "strict divx profile compliance" checkbox in the options would be an idea...
when disabled it will allow the codec to use 2-bframes and (in case of xvid) custom matrices.That sounds OK to me.

I've been messing around with all the comptest stuff, I'm just trying to sort the first part out first can some just tell me if what I'm doing so far sounds about right:

1. Running a 1st pass and doing 5% of movie (selectrangeevery) in chunks of 14 frames.
2. Parsing the video.pass file, for now, dismissing frame 1 and 14 of each chunk.
3. Adding these values (*20 for all movie as I only done 5%)

Q1: This would then give me the maximum (comptest value 100%) size for the movie (in bytes, see below)?
Q2: I'm assuming by the value that the number I'm getting from the video.pass file is in bytes?

Once I know I have this part sorted I can move on.
Thanks

[MarkCurly]

1. Running a 1st pass and doing 5% of movie (selectrangeevery) in chunks of 14 frames.
2. Parsing the video.pass file, for now, dismissing frame 1 and 14 of each chunk.
3. Adding these values (*20 for all movie as I only done 5%)
That sounds about exactly right.
Except I'd multiply by 20*14/12 = 23.3, because you are not counting frame 1 and 14; only counting every 12 frames in 280.

Q1: This would then give me the maximum (comptest value 100%) size for the movie (in bytes, see below)?
Yes.
AutoGK does a 1 pass quality based, quantizer=2, framesize=original source framesize encode for the compress test.
I presume quantizer=2 is considered "as good as it gets" = 100% (more or less).
If the user intends to override some setting (matrix, b-frames), then I suppose the comptest should be run with those overrides as well, to compare apples with apples.

That filesize would then be converted into a Qf value.
(the "100%" Qf value.)

Then (IIRC, these are approx figures) it considers that between 40% to 60% of that video bitrate is needed by a two-pass encode to get good quality.

If the current user chosen Qf is already between 40%-50% of the "100%" Qf value, then all is good to go.

If the current user chosen Qf is <40%, then it needs to be increased by increasing the target filesize (bitrate) or decreasing the target framesize.

If the current user chosen Qf is >60%, then it could be decreased by choosing a smaller target filesize (bitrate), or increasing the target framesize.

(I'm not sure if I've got my %'age figures exactly correct above.)

Q2: I'm assuming by the value that the number I'm getting from the video.pass file is in bytes?
I don't know.
I recall reading that one or other of the codecs (XviD or DivX) did not create a pass file, so you might have to do different things for each codec. If you can manage it, parsing or decoding the resultant comptest AVI directly and counting the framesizes might be a way to do it.

[mod]

According to
this (http://forum.doom9.org/showthread.php?p=866097#post866097) thread, you have to discard only the 1st of every 14 frames (the I frame).
I've implemented it for xvid_encraw and atm it works if no bframes are used. With 5% of source the error is minimal.
With B-frames, you have to discard frame 1 (type I), and frames 2-3-12-13-14 from the computation.

[iNFO-DVD]

Except I'd multiply by 20*14/12 = 23.3, because you are not counting frame 1 and 14; only counting every 12 frames in 280.Oh yes, good point.

I'm not sure if I've got my %'age figures exactly correct aboveTo be honest I'm not worried about that at the moment, just want to get the first part sorted first, but I'll come back to that.

With B-frames, you have to discard frame 1 (type I), and frames 2-3-12-13-14 from the computation.wow, hold on, are you saying I have to discard 6 frames of every 14? I have also noticed that frame 1 of the 14 frame chunks isn't always an I frame.

EDIT: I think my last question or two is answered in that link, cheers. One last stupid question..... I see IIRC pop up in a lot of threads can someone be kind enought to tell me what it means.

[Gehenna]

. I see IIRC pop up in a lot of threads can someone be kind enought to tell me what it means.

Errr. If i remember correctly it actually stands for If i remember correctly tends to be its most common usage

[iNFO-DVD]

Thanks

[iNFO-DVD]

I feel this is easier than I originally thought which makes me think I'm doing something worng.

I doing the stuff with the video.pass, I'm doing the relevant calculations and getting the total bytes at maximum.

Well if I get this maximum value and divide it by the size in bytes that I've chose for my encode it gives me a value, like: 0.40 or 0.68 or whatever, which is obviously a %. Is that it? Is that the comptest? Is that all I need to do?

I'm not bothered at the moment about what I do with the result just want to know whether I've got the comptest value.

EDIT: Forget that, I'm doing it wrong (i think, lol).

[iNFO-DVD]

framesize=original source framesize encode for the compress test.Now that's interesting, no wonder I was getting a high value with HDTV sources. So I keep all settings as I would for the real encode but the resolution has to be the same as the original input?

[MarkCurly]

Well if I get this maximum value and divide it by the size in bytes that I've chose for my encode it gives me a value, like: 0.40 or 0.68 or whatever, which is obviously a %. Is that it? Is that the comptest? Is that all I need to do?
EDIT: Forget that, I'm doing it wrong (i think, lol).
Remember that the chosen filesize for the encode includes audio, but the comptest does not include audio (at least the AutoGK comptest does not include audio).
Also, the comptest is at full source framesize, but the chosen encode is likely at a smaller framesize, so the filesizes are not directly comparable.
I think converting it all into a Qf value will allow an "apples-with-apples" comparison.

Suppose the comptest came up with a recommended filesize, but *suppose* that the calculation did not depend upon the target framesize?
User says: "Convert this to 720x576", comptest says "You need 500MB".
User says: "Convert this to 320x240", comptest says "You need 500MB".
WTF? Surely the smaller framesize needs less bits?
A rule that just uses filesize won't work. I'm sure working with Qf will get the expected result.

I suggest the rule should (IMO) be based on Qf:
User says: "Convert this to 720x540", comptest says "You need Qf ~ 0.25 (implies, for example, video size 500MB+audio 27MB = target filesize 527MB)".
User says: "Convert this to 320x240", comptest says "You need Qf ~ 0.25 (implies, for example, video size 100MB+audio 27MB = target filesize 127MB)".

(example numbers use 30 minutes of 24 frame/s video.)


"MarkCurly: framesize=original source framesize encode for the compress test."
Now that's interesting, no wonder I was getting a high value with HDTV sources. So I keep all settings as I would for the real encode but the resolution has to be the same as the original input?
All I can say is that that is what AutoGK does.

I personally would have though that the comptest should be done at the same framesize as the intended encode, but then I hardly know anything about it anyway...

Imagine if the reason the video source was not compressible was because of high frequency (small), high contrast detail?
The comptest would recommend a higher Qf to retain that detail.
BUT, that detail might be removed as the frame was resized to the target framesize (because of its small size), and then the higher Qf is not needed and goes to waste.

(This is a worst case. Usually, the detail and/or movement that made the source hard to compress will largely be retained even after resizing the frame - or so I would have thought... Stop listening to me now, I don't know what I'm talking about! ;))

[iNFO-DVD]

I think converting it all into a Qf value will allow an "apples-with-apples" comparisonThat's kind of what I'm doing.

I already have the program bits/pixel (QF) value in avi.NET, I'm getting the frame sizes after the comptest and calculating the average size of a frame, thus, I can then get the predicted bits/pixel (QF) which then allows me to have the comptest %.

It does all seem to be roughly working, the problem I've been having, or at least the most time consuming thing, is trying to find the optimal frames to keep and discard, as I'm dealing with B-Frames I've been working around discarding the first 3 and last 3 of a chunk after following above link and other links. My values are not the same as AutoGK but similar in the way the value with rise and fall with different sources.

Two points, using the source resolution completely threw the value. It seemed to work much better using the encoding resolution. Point 2, HDTV sources seem to have a large comptest value, 70% to 80% using the standard QF of 0.20. I don't know, maybe it's right, just seems a little high, these HDTV sources are massive, nice though.

I also read some threads concerning oversized b-frames, so I've been checking for them and discarding them, I found it seems to give me better results.

[iNFO-DVD]

v2.1.8.4
1. Fixed/Altered the HDTV routines and fixed a potential problem.
2. If/When the PID dialog is shown, the AV PID selection is now seperate for audio & video.
3. Fixed possibility of incorrectly displayed information in Audio list.
4. Minor bits and bobs.

CloneAD (http://www.clonead.co.uk)

Now I can spend my time doing that 'comptest', may release something later (after the football).