Reature req: XViD

[DimChief]

I'd like to see an option for VHQ mode in XViD codec. I prefer "VHQ mode 4 (Wide Search)" & "Motion search precision 6 (Ultra High)" - it gives me the best picture quality.

[len0x]

Motion search precision is 6 already and I see no real benefit in wasting too much time encoding in VHQ4 mode (assuming we're talking about AutoGK)

[DimChief]

Originally posted by len0x
Motion search precision is 6 already
Yeah, I just figured that.
and I see no real benefit in wasting too much time encoding in VHQ4 mode (assuming we're talking about AutoGK) [/B]
There is real benefit in VHQ4 mode. Trust me. One real benefit is: VHQ4 encoding nearly eliminates so called "background tremor" & significantly decreases "gradient areas blocking" artefacts.

Probably, it's possible to make a "hidden option"?

PS: encoding time means nothing to me. Electric power cost near nothing for me. :)

[len0x]

And how much slower VHQ4 is? Speed is very important for mass-encoding tools like AutoGK. Speed/quality ratio is much better for VHQ1.

P.S. I remember seeing some posts about doing 8 or more passes with DivX and seeing a "real" difference to just two passes - there will be always ppl that would like exceptionally slow encoding no mattter what, but that's not the purpose of AutoGK.

[DimChief]

Originally posted by len0x
And how much slower VHQ4 is?Yes, I can't deny this fact - VHQ4 is MUCH slower than VHQ1. 4-5 times slower approx.
Speed is very important for mass-encoding tools like AutoGK. Speed/quality ratio is much better for VHQ1.
There is nothing to object. You're right. But there always are a lot of 'perfectionists' (or 'quality maniacs' :) )...
P.S. I remember seeing some posts about doing 8 or more passes with DivX and seeing a "real" difference to just two passes - there will be always ppl that would like exceptionally slow encoding no mattter what, but that's not the purpose of AutoGK. [/B]:) XViD does near perfect after 2nd pass, no need in such madness as 8-pass encoding. But VHQ4, as I can see, gives MUCH better result in a reasonable time.

PS: if answer is 'NO', than OK with it. AGK is good anyway. And anyway, I still can use these outstanding avs-scripts AGK produces...
:thanks:

[Richter]

Check out AGKExpert (http://forum.doom9.org/showthread.php?s=&threadid=85451). It may solve your problem.

Hint: check out the ReadMe, and use the SetVideo=true setting to change XviD settings before processing (which is notably _before_ the compression test).

[PiXuS]

My say doesn't really matter, but I think len0x is right. AutoGK should aim for the best quality-speed factor. Saying VHQ4 is MUCH better than VHQ1 is an overstatement.

And, IMHO, if you want to specify encoding to this granularity, you shouldn't be using AutoGK anyway!

Just my 2¢.

[FSB-SPY]

Can this be added as a hidden option? Or at least for M2 (milestone)?

[Teegedeck]

How about letting the user select the speed/quality ratio with a slider or dropdown-menu?

(God, I must have been carrying this idea all over the forum, but no-one wants to code it for me. ;) (http://forum.doom9.org/showthread.php?s=&postid=526413#post526413) Last victim was Nic. )

[Richter]

Hm. For now, I don't want to get into all this processing data format stuff that AutoGK passes to VD. But I might later. I agree that it would be nice to have an extra user interface for those who have some idea of what they do, but still don't want to go through all the big Gordian Knot hassle (which pretty much describes myself :) ).

For now, AGKExpert offers a way to abort the various VD passes (particularly _comptest), in order to change settings before execution. The modifications can be saved in a special vcf file, which is then merged with the AGK settings on each subsequent pass. So far, this solution works quite well for me. However, it requires quite some VD knowledge, which is pretty much the opposite of the AutoGK approach.

Ugh - not sure - I think it's exactly Codec changes that AGKExpert does not preserve. This is the ones that I couldn't easily decipher. AGKExpert only works for Filters, not for the compression. At least AGKExpert permits you to abort also the last VD job, and determine yourself what the last pass settings should be - including the compression.

If I could finally get that ... VirtualDubMod source to compile with VC6, I would probably try to create a special VD-AGK version that uses VD's processing code, but provides an easier interface just for that purpose. But heavens - why does the source come with a VC6 project file if it does not compile?

Maybe I'm going to try NanDub. Other disadvantages may arise with it, but at least that one I can compile.

Or maybe we are lucky, and one day Lenox still decides to provide us with the source, so we can build Semi-Auto-GK...

[len0x]

Originally posted by Teegedeck
How about letting the user select the speed/quality ratio with a slider or dropdown-menu?

I think having a choice leads to:

1) user will always try to get best quality and therefore choose the slowest option first, then complain that it is too slow
2) when realizing that slow is not an option chooses Normal (or whatever we call it) but will always feel that "he's not getting enough quality"

So unless user has done test VHQ1 vs VHQ4 and knows exactly what he's gaining/loosing this option is not that useful. And since the tool is designed for very beginners its highly unlikely that they would do that. Do you see my point here?

[Richter]

I see your point, Lenox. And the tool being good for beginners is what I like the most about it.

Really the only thing I'm complaining about is: some do not remain beginners for all times. But stepping from AutoGK to GK seems quite a leap to me. I'm looking for a solution in between. Give those the options who want them, and make clear that they're not for everyone.

Still working on my AGKExpert tool. I think I will get there. Don't worry about it.

Roland

[Teegedeck]

Originally posted by len0x
I think having a choice leads to:

1) user will always try to get best quality and therefore choose the slowest option first, then complain that it is too slow
2) when realizing that slow is not an option chooses Normal (or whatever we call it) but will always feel that "he's not getting enough quality"

I understand those reasons. Good points indeed. I recommend AutoGK to any non-advanced user and think you actually keep AutoGK well-balanced to deliver a good performance/quality ratio.

I always forget that people could complain about speed; because complaining about too slow speed would never occur to me, as long as the quality is the best I can get. :)

If you were to allow for breaking that balance you should really make it clear that it isn't what the original application is about - maybe a patch with lots of warnings and disclaimers...

Thanks again for your work!

[Unregistered16]

Originally posted by len0x
I think having a choice leads to:

1) user will always try to get best quality and therefore choose the slowest option first, then complain that it is too slow
2) when realizing that slow is not an option chooses Normal (or whatever we call it) but will always feel that "he's not getting enough quality"

I think you're being a little pessimistic about that... I think it'd be a great idea to add a VHQ4 feature, or at least some choice like Teegedeck suggested.

And as for PiXuS saying that VHQ4 being "much" better than VHQ1 is an overstatement... VHQ4 does make quite a noticeable difference in quality.

More advanced programs you can use for settings like these are:
DVX (Preferred)
http://www.planetdvb.net/
or Gordian Knot
http://gknot.doom9.org/

[len0x]

You guys made me curious enough to make some tests under AutoGK environment and in the end it just proved that VHQ4 is not the way to go in AutoGK at all:

1) For quality-based encodings VHQ4 is useless (actually its much worse that VQH1) because its compressibilty is higher and therefore final size is less and that introduces more blocks and less details. Since quality based encoding doesn't care about final size I see no reason for artificially lowering the limit of compression.

2) Low bitrates (1CD or less). VHQ4 is designed for them as it improves compressibility quite a bit. Unfortunately AutoGK already uses very smooth low bitrate matrix (Jawor's 1CD), so I don't see the point of removing even more details (even though it might help some tough scenes).

3) High bitrates. (> 1 CD) Via better overall compressbility VHQ4 is enable to improve some tough frames (but visible only in frame-by-frame mode, but not during normal playback), but again it removes details from static scenes and looks less sharp (although again only in frame-by-frame view). So why would one want to spent 4 times as much time encoding if he doesn't even see the difference during normal playback?

Just remember - AutoGK uses a unique combination codec settings, matrixes and filters that usually different from what one is doing manually. Everything is tuned to produce a certain result and in this environment VHQ4 doesn't really offer any benefit even if it wasn't slow (it may be personal choice like a cutom matrix, but you don't ask to include your favourite matrix in AutoGK, do you?). I do agree that you might have a setup where you can clearly see the difference (may be you don't use any filtering or custom matrixes) but this doesn't apply to AutoGK.

P.S. Now I know why Koepi actually didn't recommend to use VHQ4 for the best quality encodes where enough bitrate is available.