Isn't it time for a new compression mode in XviD?

[Eruendil]

Hi!

I'm talking about something between CBR and VBR. Actually a REAL Quality-mode.

I don't mean the old "quality"-mode implemented in earlier versions of XviD, which only sets an average quant. Average quants doesn't work, because dark scenes get almost no bitrate and bright parts let the bitrate explode.

For example when using old xvid "quality"-mode set to 80%, bright parts (for example in a sunny garden) look brilliant, but dark parts (for example dialogue scenes on Deep Space Nine) look completely crappy, especially the faces, which produce extreme block noise while talking (i.e. moving somehow).

All the methods of reaching a certain file size don't interest me. I am burning the files on DVD and all I want is a constant quality; if one file get's a bigger (because of more movement/action parts), that's absolutely OK as I just combine the files differently to fill up my DVDs to the max. But I really want a constant quality!

At the moment I am tricking a bit with the VBR mode, forcing the encoder to give low-bitrate scenes more bits. But that does only work good (that means: constant quality without waste of bitrate), if I know how much movement and/or bright/dark scenes will be in a movie. Dark movies might go with lower bitrates (Donnie Darko for example goes REALLY LOW, at 80% quality TOO LOW!), while normal movies would need medium or high avg. bitrates (or final file size, regarding length of movie).

One more example: An episode of Deep Space Nine with almost only dark scenes (much dialogues) at 80% quality produces 194 MB of video (no audio) for 43 min. An episode with 1/3 bright scenes (yes, I counted the minutes) comes up with 575 MB (around factor 3!); and that's only one third of the length! Anyway, I wouldn't mind so much, but the dark scenes look really crappy! And if I use for example 90% quality (which makes the darker scenes acceptable), the sizes go sky high if the video contains bright scenes (it's mostly about dark/bright scenes; space combat for example, with a lot of motion and explosions also uses pretty low bitrates! -> the background makes the difference).

To cut it short: I need a compression method, that could well be a 1-pass mode, that analyses only some frames at a time. If they are bright/dark or have more/less movement it allocates a quant/bitrate value to achieve a constant viewing quality. For example: (i/p-frame) quant 5 for bright scenes, quant 3 for dark scenes and quant 4 for everything in the middle, b-frames as usual. Actually I think, it might be that simple, although the codec could allow some flexibility here.

Another side effect: Dark scenes consume low bitrates even at quant 2 and bright scenes look brilliant even at quant 5 or 6. I have experienced that movies get much smaller by using fixed quants than by using VBR with an estimated avg. bitrate. A normal movie, almost only bright scenes, 688x288, 25fps, 1:47:00 uses only 650 MB (video only, = 850 kBits/s!) at very nearly DVD quality; and that's with NO b-frames, only i- and p-frames! (And I am a quality freak; I can't count the hours I've spent in front of my monitor searching for block noise and recompressing movies over and over if I found too much noise in a single scene...). With my old VBR-method I would have given 1200 kBits/s avg. bitrate to the movie to ensure quality.

So I am asking for a simpler (just select quality), faster (1-pass) AND better (smaller file size while retaining quality) mode for XviD. It would have one disadvantage: no size predictability (which I don't need since DVD-R is cheap enough). I would do the job myself, but actually I am completely out of practice nowadays.

Doesn't anybody else want such a mode?

Greetings and thanx for reading so far,
Eruendil

[Blue_MiSfit]

Not really... 2 pass VBR and single pass CQ is all I've ever wanted or needed..

~MiSfit

[foxyshadis]

You could probably have just asked for x264's crf mode, with a lot less writing. And you're mixing up two requests: crf mode, and fixing xvid's overly linear approach to dark scenes. (Which lumimasking only makes worse.)

Basing xvid's decision of the hvs content of dark/bright blocks based on a comparison of average block brightness against the average frame brightness when applying lumimasking seems much more sensisble than an absolute threshold.

[sysKin]

I feel obliged to point out that all ratecontrol code is in /xvidcore/src/plugins/. New ratecontrol modules are definitely welcome.

[Eruendil]

Sorry for the many words. It seems, I didn't quite know how to put it, doesn't it :D ?

@Blue_MiSfit: Lucky you! :)

@foxyshadis: Yeah, gimme crf mode!! You could have told us that it's actually called CQ-ASP_Q2_eq(crf)-mode; a simple search for "crf" yielded no results ;) I guess that's exactly what I asked for without knowing.
And perhaps it would be a good idea to do something about XviD's spoiling of dark areas. Couldn't you implement this new brightness-calculating method (it sounded that way ;) )?

@sysKin: Yep, thanks very much. Just took a look at the source code. I really didn't understand much, C is pretty alien to me and I don't know the interface not mentioning most of the abbreviations. Perhaps I could do a very basic hack, but until then we are talking about H.265 in this forum. I stopped studying computerscience and went for theology. So if anyone here needs a good sermon or looks for someone to pray for him, I'M HIS (or HER) MAN. :D The real programming stuff I have to leave for the pros.

Greetings,
Eruendil

[Didée]

Perhaps bugging Tobias (http://forum.doom9.org/showthread.php?p=761022#post761022) could help ...

[foxyshadis]

Sadly, the forum can't search for less than 4 letters at a time. The other name is simply megui's name for it, not x264's. And the last time I got one of my xvid hacking attempts to compile, it put out a bunch of pretty brightly blinking colored boxes before crashing. But it DID use less bitrate (always remember the positives)! So... I'll leave it up to those who know the codebase. ;)

[Blue_MiSfit]

LOL!

Honestly, the search function on this forum isnt happenin...

Can you pipe the whole stupid forum to google and have their engine crawl through it? I've heard of this being done but I just dont know how to...

Sorry this is OT...

[BigDid]

Hi,

You mean something like that:
"crf xvid site:forum.doom9.org" to input the google search box or
the doom9 search plugin (for firefox): http://forum.doom9.org/showthread.php?t=110190 ?

Did

[Eruendil]

:goodpost: Blue_MiSfit!

Still OT, but important:


Not being able to search for abbrevs is quite ennerving in a tech-forum.
I couldn't find out how to activate the "AND"-search. It's always "OR" which isn't useful in most cases.


Surely Google can be used, but why? And think of newbies, who are always told to :search: !

[Kopernikus]

What a funny coincidence. Just today I brought one of my projects to a compileable state. And it happens to be something that might be interesting for you.

Its a HVS Plugin that allows you to fully control adaptive quantization and a brand new technologie called lambda modulation ((c) by sysKin).

http://xvid.ist-dein-freund.de

The plugin allows you to specify custom formula for AQ and LM that

@foxyshadis: can contain the brightness of the frame and the current block and be a almost arbitrary complex function of this (and other parameters)

@Didée: must be provided in Reverse Polish Notation ;)

@Eruendil: might be abuseable as a sort of quality based ratecontrol

I hope the explaining text on the website is clear, if not, feel free to bug me.

There are the sources and Linux Binaries on the site. If someone can explain crosscompiling with MinGW to me, then I might be able to provide Windows binaries.

Bug Reports, Flames and Ideas are always welcome.

Ah, this is a non-official and highly experimental thing, use it on your own risk.

Happy testing :)

[celtic_druid]

Some info on setting up a cross compilation environment at libsdl.org:
http://www.libsdl.org/extras/win32/cross/README.txt

Should be enough to build encraw and or xvidcore.

[unskinnyboy]

a simple search for "crf" yielded no results
That's because the minimum character length required for searching is set to 4 for this board (vBulletin default is 4). To get what you are looking for, search for crf*.

[kypec]

I couldn't find out how to activate the "AND"-search. It's always "OR" which isn't useful in most cases.

Surely Google can be used, but why? And think of newbies, who are always told to :search: !

I have to COMPLETELY AGREE with you. I wasn't able to search for AND'ed expressions like AVI+XviD+CQM or similar words' (rather shortcuts or slang) combinations which are heavily used throughout this forum :angry:

[Kopernikus]

@celtic_druid:

Thanks, I got it. There are now windows binaries available. I hope they work correctly. They do under wine, but I have no windows box here to test it.

[Eruendil]

What a nice piece of work, Kopernikus! :)

Before I try to squeeze .m2v-files (perhaps I have to convert them into .avi(.avs) before?) through the codec, I have some questions to check, if I got it right:

1. This is all about Adaptive (macroblock-) quantization (AQ) (formerly known as Lumi-masking), not general frame-quantizers?

2. Isn't AQ an option which can cause (standalone-) incompatibility (in the end I want to play the videos :sly: )?

3. Which role does the frame-quant play? Is it irrelevant and only the new macroblock-quants define the frame or is there some relation between the two?

4. How can I determine what brightness/contrast-value a certain frame (or even macroblock) has, just to have values to base the formula on? I tried xvid stat-output, stat-file (pass1) and the debug option, but it remains secret. :confused:

5. Would you really recommend this method to construct a crf-mode?

Pooh, and I thought, I had understood something about how mpeg4 works ;).

Actually I would prefer some frame-quant manipulation option based on brightness values because of simplicity. This AQ-plugin is too powerful for this purpose, I presume.

[Didée]

What a nice piece of work, Kopernikus! :)
Yes, indeed! :)


1. This is all about Adaptive (macroblock-) quantization (AQ) (formerly known as Lumi-masking), not general frame-quantizers?
What can be changed is
a) block quantizers (aka lumamasking)
b) Lambda factor, to push the RDO decisions either towards quality or towards smaller bitrate.


2. Isn't AQ an option which can cause (standalone-) incompatibility (in the end I want to play the videos :sly: )?
Should cause no problems. (If it does, the SP is bullsh**)


3. Which role does the frame-quant play? Is it irrelevant and only the new macroblock-quants define the frame or is there some relation between the two?
The basic frame quant comes in as a variable, and you have to calculate the block quants by yourself, based on the frame quant and the other variables.
The restriction that the quants of any neighbor blocks may not differ by more than +/-2 should be safeguarded by XviD, in case your formula produces block quants that would fail this rule. (To be *sure*, lets wait for Kopernikus.)


4. How can I determine what brightness/contrast-value a certain frame (or even macroblock) has, just to have values to base the formula on?
You have those variables available:
gl_lum the average brightness of the current frame
lc_lum the average brightness of the current block
lc_con the average contrast of the current block
quant the quantizer from the rate control for this frame
You can use these variables in the UPN strings, to do whatever calculations you like. For each frame, these variables will automatically contain the corresponding values.

Actually I would prefer some frame-quant manipulation option based on brightness values because of simplicity.
Then just make lambda bigger for smaller values of gl_lum, and watch the bitrate explode. ;)

[Kopernikus]

[quote]
3. Which role does the frame-quant play? Is it irrelevant and only the new macroblock-quants define the frame or is there some relation between the two?[/quant]

The basic frame quant comes in as a variable, and you have to calculate the block quants by yourself, based on the frame quant and the other variables.
The restriction that the quants of any neighbor blocks may not differ by more than +/-2 should be safeguarded by XviD, in case your formula produces block quants that would fail this rule. (To be *sure*, lets wait for Kopernikus.)


Exactly. You can use quant in the formula, and it will contain the value of the quantizer the ratecontrol chose for this frame.

The plugin makes sure that the restrictions are met. The block quantizers are modified so that they are spec conform.

If you don't use quant in your formula, then the block quants depend only on the frame brightness, the block brightness and the block contrast. The frame quantizer is then calculated from the block quants. So the plugin acts as a sort of ratecontrol (that doesn't really control the rate, but only calculates quantizers). That could perhaps be used to construct a sort of "constant quality" mode, thats not exactly constant quantizer. (Maybe it works)

[Eruendil]

The more I think it over, the more I like the idea of having a way of intelligently manipulating each macroblock instead of using the brute force with frame-quants only.

But I still have to nag a bit: :D

I just tried the -hvs_aq option with a value of 2 and cq of 4. In the output there are still only quants of 4, but the "Len"-value increased dramatically. So it's working ;)

My most important question is: How can I get the gl_lum values for certain frames? Or do I have to try and try and try..? I already thought about somthing like
-hvs_aq "gl_lum 10 - theta gl_lum 20 - theta + gl_lum 30 - theta + (and so on...)"
or so just to get an idea about the values. But the result of AQ is not reflected in the frame quant output, so it's no use either. And guessing from len-value will be difficult either...

Hasn't got anybody any ideas? Trying it all out takes so long and is much less precise in the end...

Greetings,
Eruendil

[Kopernikus]

There is a problem with the stats displayed for each frame. The quant is the one the ratecontrol chose, not the real one.

If you are interested in the lum values, perhaps avisynth can help you to get a idea of this value. There is a histogram filter that may be useful and there is the possibility to print the average luminance (probably Didée can help).

[Didée]

In AviSynth, ColorYUV(analyze=true) will print the statistics onto the frames. Histogram(mode="levels") will put a histogram to the right side.

[Eruendil]

Here I go again.

Ok, I also learned AviSynth. Your tip was really nice! Now I have the Luma Y-values for each frame!

But there's another issue coming up. If I use following commandline...


"D:\xvidnew.exe" -i "D:\Videotest\VOBs.avs" -w 640 -h 480 -avi "D:\VOBs out_cq4_aq IF lc_lum LEQ 15 THEN quant-2.avi" -max_bframes 0 -nochromame -cq 4 -lumimasking -hvs_aq "quant 2 15 lc_lum - theta * -" >"D:\log_VOBs out_cq 4_aq IF lc_lum LEQ 15 THEN quant-2.txt"


...simply all of the frames explode in size, although luma-values are around min 14 and max 114 (avg 38). Even if I use a value of 1 insteadof 15, the same thing happens. (I wrote a batchfile that compares two logfiles: the results are absolutely identical.)

Is there something wrong with the commandline? Did I screw up the UPN?

I'd be happy for any help!

[Kopernikus]

Yeah, you screwed up the formula. Multiplication is noted with "x" instead of "*". I will change this.

[Eruendil]

Oh. But it's * on the http://xvid.ist-dein-freund.de/ page... Grmpf, only in the lumimasking formula, the description has it right.

Okay, okay...

[Eruendil]

How's the rounding done? :)
-hvs_aq "25 10 /" --> quant 3 or quant 2?

Greetings...

Ok, I tried it... it's simply truncating.

My forst working try is a Gauss-curve, decreasing quantizer in frames gl_lum < 100 for medium and less than or little above medium bright macroblocks and increasing it for very low and very bright blocks. Quality testing is still underway...

PS: The formula is

-hvs_aq "quant 1 0 lc_lum 117 - 24 1270 / x 2 pow 2 / - exp 250662827 100000000 / / 399999 100000 / 4 10 / / x - 100 gl_lum - theta x +"


Okay, I just did some quality testing. But in the darks scenes the faces don't necessarily look better (compared to a CQ 4 without AQ). Perhaps I shouldn't use the strict values from AniSynth.ColorYUV, but the loose values (better representing macroblock-averages)?

Changed the values to "loose" but I can't see that the differences really are worth the difference in size (over 2x as big, only a bit below CQ 2).

Perhaps the surrounding (darker) macroblocks pull down the quant again? But they aren't dark enough to produce quant 5 and quant 4 would have no effect on quant 2...

Is it the formula? It's supposed to represent

-hvs_aq=if gl_lum < 100 then modify quant by: 1 - (exp((((lc_lum-117)*2,4/127)^2)/-2)/sqrt(2*pi))*(3,9/0,4)

with 117 = center of curve; 2,4 defining steepness; 3,9 max value of curve
(90; 3; 3,5 for loose lumi-min/max)


Ok, I found the error: as the complicated part of the formula gives no truncated values (but alway > 0), I have to add +1.

New version (loose lumi values):

-hvs_aq "quant 2 0 lc_lum 90 - 30 1270 / x 2 pow 2 / - exp 250662827 100000000 / / 35 10 / 4 10 / / x - 100 gl_lum - theta x +"


(I hope I don't irritate you by writing all the progress here, but perhaps somebody sees an error or has similar problems. Besides it helps me thinking it all over.)

[Kopernikus]

Hi,

I updated some things (* for multiplication, added ?, min, max, e and pi). For more Infos see http://xvid.ist-dein-freund.de

I dont think that you need such a great accuracy. I think dividing 25066 by 10000 is more than enough. but still easier would be "2 pi * sqrt"

There are some further simplifications possible to your formula with the new added stuff.

"35 10 / 4 10 / /" is equal to "35 4 /"

The theta thingie can now be written with 100 gl_lum - complicated stuff 0 ?

Another trick is to use the visualizations of ffdshow to check the quantizers of the individual blocks.

[Eruendil]

It get's nicer and nicer, hehe.

Yes, the complicated formula is only to keep an overview over the different factor (to be able to change them without thinking much, which factor had already be calculated together with which constant and so on).

But, after spending hours on testing, I have come to a much simpler formula, that pretty much satisfies me:


Working formula:

-hvs_aq "quant 2 100 gl_lum - theta x lc_lum 20 - theta x 150 lc_lum - theta x -"


Now, this baby increases quality (quant-2) in every frame with avg lumi less than 100 for those macroblocks with an avg lumi between 20 and 150.

Strange values? If I use 30, almost nothing happens, especially to the faces in dark scenes. 20 produces nice results. The 150 might seem high, but in dark scenes there are very few blocks with great brightness and the usage of bitrate is marginal (even 180 doesn't change that much).

Using ffdshow was a good idea: I discovered what made quality checking for me so complicated: In one scene my formula worked and in another there was NO effect. It wasn't gl_lum, that was clear. ffdshow uncovered that in some scenes my formula worked, in some scenes not at all and in others it seemed to be working partially.

I guess the "problem" is, that xvid tries to produce an avg quant of 4 and is quite pushed out of balance by using AQ. Hm. Now how can I get control over the qunatizers? Is it better, using CBR or CQ in combination with high averaging and smoothing values?

Now that might also mean that bitrate consumption would be much higher if the AQ formula had total control over quantization...

Let's test...

I just don't get it... I have a small testvideo (~1 min.) which contains only dark scenes (dialogue).

I do it with this commandline (simplified formula):


"D:\xvidnew.exe" -i "D:\Videotest\testvideo_dunkel.avs" -w 640 -h 480 -avi "D:\testvideo_dunkel out_cq 3_aq if 20 LEQ lc_lum LEQ 30 quant -2.avi" -max_bframes 0 -nochromame -lumimasking -hvs_aq "4 2 lc_lum 20 - theta x 30 lc_lum - theta x -" 1>"D:\log_testvideo_dunkel out_cq 3_aq if 20 LEQ lc_lum LEQ 30 quant -2.txt"


... and the result is either frames consisting completely of quant 2 or completely quant 4 frames. Is it the frame rate control or is the commandline the problem?

(By the way: In my "working" formula try (see above), the videos also had complete 2-quant-frames, as far as the formula worked for the dark scenes. It almost seems to me that, if there are a lot block quant results of "2", the whole frame changes to "2" and if there are only some, it remains with "4". There is no difference, if I use another kind of rate control, for example -cq 3, 4 or -bitrate 3000...)

Question: Is it right that I use the option "-lumimasking" together with "-hvs_aq"?
Answer: NO!!!! "-lumimasking" has to be LEFT OUT. Now the formula does, what I tell it.

[Eruendil]

Ok. After more hours of testing another new formula :) :


-hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 100 gl_lum - theta x +"


This translates (for quicker overview ;) ):
block quant = 4 for frames gl_lum > 100
else block quant = 4 (-1 for 40 < lc_lum < 50; -2 for 50 < lc_lum < 130; -1 for 130 < lc_lum < 140; +/-0 for all other lc_lum)

ffdshow proved that the quants were correctly (and sensibly, I think) calculated and set :sly: . Now I am running a test compression of a complete 43 min. video to see what it looks like and how the bitrate behaves... Perhaps at last..?

@Kopernikus: I tried the new version but it simply terminated after half a second, pretending it had done the job. Either your optimizations are truly amazing ;) , or something is wrong!?

The result LOOKS good AND has a reasonable SIZE! This might actually be my crf-mode! I am going to try this one for longer now.

I can only recommend that you start testing by yourself! I would like to hear about the results... In dark scenes the faces are 99% quant 2 (at least for white (or grey) people; Captain Sisko get's some 3 and 4 quants, but I don't think the codec is intending to be politically incorrect ;) ) and they look really "crispy". And it used less than 1200 kbps with almost only dark scenes, and that's with b-frames off!

My commandline:

D:\>"D:\xvid_encraw.exe" -i "D:\testvideo.avs" -w 640 -h 480 -avi "D:\testvideo out_cq 4_aq ranges 40-50-130-140.avi" -max_bframes 0 -nochromame -hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 100 gl_lum - theta x +" -cq 4 >"D:\log_testvideo out_cq 4_aq ranges 40-50-130-140.txt"

[Kopernikus]

I think I fixed the windows version. On Wine it works, but I cannot check with Windows...

[Eruendil]

Fine, fine, the new version of xvid_encraw works under Windows. :cool: Thanx Kopernikus! I like the new "quantizer used"-output!

I don't know, if it's noticeably faster, but I'll try tonight with some videos.

I also have tried a bit and came to the result that it will be sufficient, if the quant-reduction is only applied on frames gl_lum < 80, not < 100 as before.

So here is my new commandline (including b-frames now, which shrinks the size of the video like a black-hole does with matter :sly: ):


D:\>"D:\xvid_encraw.exe" -i "D:\VOB_Number_01.avs" -avi "D:\VOB_Number_01 out_cq 4_aq ranges 40-50-130-140 for gl_lum LEQ 80.avi" -nochromame -hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 80 gl_lum - theta x +" -bquant_ratio 100 -cq 4 -progress 10


B-frames are alwas quant 5 (CQ 4 plus 1) to ensure that there is no quality loss (in the end it's quality, what this is all about).

By the way: It works fantastic with my Pioneer standalone (MediaTek-chipset)! I almost forgot: I'm checking the results on a 32" (81 cm) LCD-TV and they look very satisfying. :D

Greetings,
Eruendil

PS: Might it be that VirtualDubMod has difficulties opening avis with adaptive quantization? It always crashes, if I try to play any newly compressed videos (but luckily it still multiplexes them...)

[mod]

I wrote an AVS-function that does a real autocrop (using the plugin "AutoCrop.dll") that means, it searches in 20 frames throughout the whole movie for the best crop, not only in n consecutive frames, which might easily lead to wrong cropping. If anybody should be interested...
Here I am :)

[Eruendil]

Er... em... it seems, I misunderstood the description of "AutoCrop.dll" (which isn't exact in this point), sorry :( . But I tested AutoCrop with a Clip starting with 20 black frames AutoCrop( mode = 0, samples = 15, samplestartframe = 1 ) and the result was the right Cropping => AutoCrop DOES take the samples from the middle of the video (an old version of AutoCrop didn't know the "samplestartframe"-variable and that made me suspicious as many movies start with a lot of black frames (title and so on...) and that couldn't really be...)

Well, if AutoCrop wouldn't have worked, it would have been an excellent function :D ...

[mod]

Well, if AutoCrop wouldn't have worked, it would have been an excellent function :D ...
No doubt about that :D

[Eruendil]

@Kopernikus: I have encountered a serious problem with xvid_encraw.exe: As far as I can tell, it delivers an AVI-stream that cannot be opened by VirtualDubMod, if B-frames are activated!!!
Please check the routines and correct the issue (I have opened a lot of AVIs with b-frames before in VDubMod..!?) Thanks!

[Kopernikus]

hmmm, I checked it and it should be ok (it is similar to the "traditional" lumimasking code).

Can you try to open a avi from a unmodified encraw with lumimasking.
Can you try to open it with a different player (Perhaps VDM is buggy)?
Can you post your exact commandline?
Does this bug occur with both versions of modified encraw?
Can someone else confirm this bug?

[Eruendil]

Where do I get unmodified encraw (searched doom9-downloads but didn't find it)?

Lumi on or off does not make any difference, just like the version of the patched xvid_encraw (I tested it in all variations). B-frames on => VDM-error.

Standalone and MediaPlayerClassic (using ffdshow) play it without problems.
But: I just tried to compress the same clip with VDM->XviD1.1.0 with lumi on/off and b-frames on/off and VDM opened the resulting avis without problems in both cases. Only the files from encraw still won't open...

My commandline looks like this:

D:\>"D:\xvid_encraw.exe" -i "D:\VOB_Number_01_trim.avs" -avi "D:\VOB_Number_01_trim out_cq 4_aq NOlumi b-frames test.avi" -nochromame -cq 4 -bquant_ratio 100 -progress 10

[Kopernikus]

celtic_druid compiles encraw without patches.

Then the problem is probably on the side of vdm, that seems not be able to cope with the avis by encraw. You can try to turn packed bitstream on or off, maybe it helps.

[Eruendil]

Hmm. The problem does NOT seem to be the container, as VDM muxes the video without problems. => So it must be some kind of incompatibility in the video stream itself (it's not "packed bitstream", I checked it).

Guess I have to search elsewhere... Can it be that nobody stumbled upon this problem until now??

I tried an unpatched version and it's the same problem. (xvid core 1.1, bitsream 1.1). :confused:

[bond]

what does virtualdub(mod) tell you when you try to open the avi file

[Eruendil]

Opened a new thread for the VirtualDubMod issue, because up to now it doesn't seem to be an xvid_encraw (patched or unpatched) problem...

Thread: http://forum.doom9.org/showthread.php?t=115167

[DDogg]

Eruendil, Thanks for starting this thread and Kopernikus thanks for your work. I want to move all my DVDs to my video server. Like Eruendil, some type of constant quality is my goal and size is not an issue although I don't want to waste space unnecessarily. I would like to stay with Xvid and ac3 for now.

My skills are not uptodate, so I hope some of you might share your actual commandlines for me to try with Kopernikus' xvid_encraw mod. I have difficulty understanding the complex syntax. With some more examples, maybe I can come up to speed.

My goal is to create a somewhat generic bat file with which I can drag and drop my avs files and get a similar look and feel from my encodes. Maybe adding muxing in as part of the bat. Any and all suggestions toward this end would be appreciated .

/add: Kopernikus, I would like to try some of your test commandlines that trigger your additional features as you intended them to work.

[Kopernikus]

Sorry for the late answer.

Have you checked http://xvid.ist-dein-freund.de ? I tried to explain the plugin there.

Yeah, the syntax is difficult. This reverse polish notation is a bit unhandy.

The plugin is mostly intended to "fix" lumimasking by tweaking the adaptive quantisation and to allow people to play with the lambda thing. This constant quality stuff is a bit of a byproduct.

Its a mostly experimental plugin, I don't know if anybody besides Eruendil has used it.

What you basically do is set up a formula that calculates a quantizer/lambda value for each block.

For example "-hvs_aq 5" would set every block_quantizer to five what is about the same as -cq 5.

If you want to give flat blocks a lower quant am complex a , then something like "-hvs_aq 3 5 128 / x lc_con max" is possible. The formula says ( in not rpn):
max(3,(5/128)*lc_con) and assigns a quant between 3 and 10 depending linear on the complexity.

I hope its clearer now. If not, just ask, I will try to help.

[henryho_hk]

or ... "-hvs_aq 3 5 128 / lc_con * max" ?

[Kopernikus]

yes your right :)

[Eruendil]

I think the UPN is quite simple, as formulas tend to "grow" and if I do understand, what one part does, it's actually quite modular and thus easily understandable (at least if the formula was constructed by myself ;) )

Up to now I only used lc_lum. If I got it right, lc_con means the contrast (= complexity) of the block itself (not, for example, the contrast to the surrounding blocks)?

@Kopernikus / henryho_hk: How are the results of this formula ("-hvs_aq 3 5 128 / lc_con * max")?

Greetings,
Eruendil

[DDogg]

Thanks guys. I am struggling a little at the moment with where to place the new syntax and whether it conflicts or nulls other entries in a cmdline created by one of the gui's using the standard x264 build. Will keep at it. It is a good study exercise, but my forhead is getting flatter and I am starting to dislike all things Slavic ;) (all full command lines would be welcome)

[Eruendil]

Hi!

@Kopernikus: If I use the "max" function, encraw interprets it as "min":


D:\> xvid_encraw.exe -i "..." -avi "..." -nochromame -hvs_aq "2 10 256 / lc_con * max" -bquant_offset 200 -bquant_ratio 100 -progress 10
.
.
.
Using quantizer = min(2.00 , ((10.00 / 256.00) * lc_con))


Any ideas?

Greetings,
Eruendil

PS: If I get UPN and the example formula right, the quantizer will increase (that means quality will decrease) with increasing complexity (lc_con)???

[Kopernikus]

its a typo (c&p). it displays min, but uses max.

Yes, the HVS is less sensitive for distortion in more complex areas, the effect is called contrast masking.

[Eruendil]

And here the new formula goes:

D:\>"D:\xvid_encraw.exe" -i "D:\VOB_Number_01.avs" -avi "D:\VOB_Number_01_2nd try_3.3-6-12-24.avi" -nochromame -hvs_aq "6 lc_con 3 - 1 0 ? - lc_con 6 - 1 0 ? - lc_con 12 - 1 0 ? - lc_con 24 - 1 0 ? -" -cq 4 -bquant_offset 200 -bquant_ratio 100 progress 10

or the formula itself:

"6 lc_con 3 - 1 0 ? - lc_con 6 - 1 0 ? - lc_con 12 - 1 0 ? - lc_con 24 - 1 0 ? -"


As you see, I basically reduce the quant of 6 by 1 for every threshold in complexity (lc_lum) reached (3-6-12-24), for a min quant of 2. Although they seem pretty low, the values are tested and produce very nice results in my testmovie (cinema quality DVD, more dark scenes than bright, I'd say).

Compared to my older formula (which was testing lc_lum thresholds in a comparable manner) the new formula

works in dark and bright scenes
consumes almost the same amount of bitrate and
delivers a quality, which is very difficult to distinguish from the old one.


New formula PRO:

+ works always, not only in dark scenes


New formula CON:

- tends to neglect low contrast areas,

which is noticeable in medium or low brightness scenes, where bigger areas of similar contrast begin to flicker and/or produce block noise (effect could be countered by using max quant of 4 instead of 6, but that would increase bitrate above usage of old formula without any noticeable gain in quality)

Summary: Contrary to what I expected, the old formula (constant quant of 4, reduced to 3 or 2 for brighter areas in dark scenes only) seems to prevail. While usually working very good in dark scenes, the -cq 4 is producing very nice results in bright scenes. The new formula is more attractive, because it's a real "quality mode" and is expected to give more detail in high contrast areas, but in the end its results are a little less good than the old formula.

My conversion settings tested as most satisfying up to now:

-nochromame -hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 80 gl_lum - theta x +" -cq 4 -bquant_offset 200 -bquant_ratio 100


Didn't anyone else do any testing? The results stand any comparison to VBR mode in quality and bitrate usage is significantly lower in most cases!

Greetz,
Eruendil

[DDogg]

Didn't anyone else do any testing?Enough to know you guys may be on to something. To help people test, here is a simple little drag and drop batchfile to paste into notepad and save
as something.bat. Then just drag your avs onto it. It will retain the name of avs and simple add a "_.avi" on the end for the output. To save people
from hunting for Kopernikus' patched xvid_encraw_060821.exe find it here (http://xvid.ist-dein-freund.de). Of course, make sure to change the path in the bat to where you put it.

btw, in your example (thanks for it) you might want to add the missing "-" in front of progress.

/add: - remember to change framerate if you are not 23.976 -Just remove framerate for 25.00 (default)
@echo off
Rem Change commandline below to show correct path for your xvid_encraw.exe
Rem Get the avs file name that has been dragged to this batch
@set fname=%1%
Rem make output file names
@set out1=%fname%_.avi
Rem show output file names
Echo %fname%
Echo %out1%
"C:\apps\xvid_encraw_060821.exe" -i %fname% -avi %out1% -framerate 23.976 -nochromame -hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 80 gl_lum - theta x +" -cq 4 -bquant_offset 200 -bquant_ratio 100 -progress 10
rem alternate line with matrix
rem "C:\apps\xvid_encraw_060821.exe" -i %fname% -avi %out1% -framerate 23.976 -nochromame -hvs_aq "4 0 1 lc_lum 40 - theta x - 1 lc_lum 50 - theta x - 1 lc_lum 130 - theta x + 1 lc_lum 140 - theta x + 80 gl_lum - theta x +" -cq 4 -bquant_offset 200 -bquant_ratio 100 -threads 2 -max_key_interval 240 -qmatrix "C:\apps\matrix\Didees SixOfNine.cqm" -progress 10
pause


/add2: Just did SPR with the above and used 6x9 as the matrix. Kept it at cq4. The water scenes AND the church scenes were both
perfect, and I do mean perfect. The command line above, in conjuction with the 6x9 matrix, seems to be a special combination.
Hope more people try it and report back.[]

I added a rem'ed line with the matrix into the batch above if anybody wants to try it. Just rem out the first cmd line and remove the rem from
the second cmd line. Also, change your paths for for the exe and the matrix.