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.

[Eruendil]

Hi to all!

Inspired by DDogg I decided to work over a batchfile creator I wrote for personal use (which happens to be a batchfile itself):

It is called "VCBatchGen" (Video Conversion Batchfile Generator) and is intended to make video creation easier (as GordianKnot or even VirtualDubMod) without sacrifising control over the process (AutoGK etc.) And it certainly makes use of Kopernikus' xvid_encraw.exe!

Absolute newbies might get confused, it's something for experienced users, I think.

So basically what it does: VCBatchGen creates
1. a batchfile and
2. an AVS-script.

Just copy the folder in the archive to any directory, modify two batchfiles ("VideoConvert\VCBatchGen Link.bat" and "VideoConvert\VCBatchGen\vcbatchgen.bat" - don't worry, it's all about program and file paths!) and Drag and Drop the folder containing your "VIDEO_TS"-dir on the (modified) "VCBatchGen Link.bat" file.

VCBatchGen will then ask some questions concerning VOB number (for example VTS_01_*.vob, if you have several movies/episodes in one VIDEO_TS folder) , interlacing, picture format and so on).

Considering your answers, a batchfile will be created in the folder you specified in vcbatchgen.bat and an AVS-script in the folder you dropped on "VCBatchGen Link.bat".

Just execute the batchfile and (if you have set the paths in vcbatchgen.bat correctly), your rip will be demuxed and video and audio converted automatically.

There is a little helpfile provided as well as a help function in VCBatchGen (vcbatchgen.bat -? or /?).

Sounds complicated, but if you know what a batchfile is, you'll have this thing running in notime. And it really helps to make film converting much easier without worrying about pixels and filters or loosing control over the steps!

Ah yes: You need some programs installed: DGIndex, AVISynth 2.5, BeSweet and certainly xvid_encraw from Kopernikus.

Some necessary AVISynth-plugins are provided in the archive (they can be difficult to find and don't take much space). Just copy them in your AVISynth plugin directory. NOTE: I am using VCBatchGen in a PAL country, so some modificatons might be necessary. ANOTHER NOTE: VCBatchGen is tested with good and noisy DVD-material, but not with (good or bad) VHS-material, so the "bad" source mode remains experimental.

Feel free to ask any questions!

Greetings,
Eruendil

PS: Programs can be downloaded here:
http://www.doom9.org/index.html?/software2.htm

xvid_encraw from Kopernikus is found here:
http://xvid.ist-dein-freund.de/

------------------------------------ UPDATE --------------------------------
/Update: Newer, NTSC-compatible version of VCBatchGen is found in this posting: http://forum.doom9.org/showthread.php?p=906702#post906702
----------------------------

[DDogg]

Attachment still not approved. Eruendil, could you make available temporarily? check has temp (http://files.project357.com/) storage for this community.

I am wondering why there seems to be no interest. The folks here nearly always experiment with any new idea, so I am thinking I must be missing something?

[Eruendil]

Ok, I uploaded the file to:

http://files.project357.com/uploads/index.php?dir=&file=VCBatchGen_plus_files.zip/

With best regards,
Eruendil

------------------------------------ UPDATE --------------------------------
/Update: Newer, NTSC-compatible version of VCBatchGen is found in this posting: http://forum.doom9.org/showthread.php?p=906702#post906702
----------------------------

[Kopernikus]

I compiled a new version, with the typo fixed and the code cleaned up a bit. It is based on a 1.2 cvs from today.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_hvs_061105.exe

[DDogg]

I compiled a new version, with the typo fixed and the code cleaned up a bit. It is based on a 1.2 cvs from today.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_hvs_061105.exeKopernikus, thanks for the new build. I used it and Eruendil's cmdline on several encodes and the results are excellent.

I wish more people would try this method and report their results. Seems like it is just a better way to go if one wishes to put encodes on a server. I did a 2 hour source with no filters and no matrix. It came in at 700 megs. Bright and sharp, no blocks, real nice.

[Romario]

Guys, please, give me link for 1.2 CVS (builds and changelog for 1.2, each revision)

Thanks.

[foxyshadis]

xvid.org?

This isn't even a thread about cvs, it's about a non-cvs patch.

[henryho_hk]

Dear all, I ran the following for a test. I thought the I frames would be at quant. 3 and the B frames would be at quant. 5 (3*1.00+2). But then "t.stats" tell me that the B frames are also at quant. 3. Have I done anything wrong?

xvid_encraw_hvs_20061105.exe -zones 0,q,3,KO -nopacked -progress 100 -max_key_interval 300 -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000 -quality 4 -vhqmode 0 -max_bframes 1 -bquant_ratio 100 -bquant_offset 2 -qtype 1 -qmatrix "Didees-SixOfNine.cqm" -nochromame -turbo -framerate 29.970030 -hvs_aq "3 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 3 -pass1 "t.stats" -type 2 -i "t.avs" -avi "t.avi"

-------------------

I know what's wrong now. It should be "-bquant_offset 200"

-------------------

It seems this xvid_encraw is much slower than squid's compile. Is it due to compilation settings or the new encoding mode?

[tyee]

I just tried the VCBatchGen method and I got this at the end of the command window. I did disable the audio part of the batching too.


Trying to retrieve width and height from input header
Non YV12 input colorspace DIB ! Attempting conversion...
AVIStreamReadFormat read 40 bytes.
width = 772, height = 56, planes = 1
Compression = , 0
Bits Per Pixel = 32
AVIStreamGetFrameOpen successful.
40 0 0 0 4 3 0 0 56 0 0 0 1 0 12 0 89 86 49 50 80 253 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0
xvidcore build version: xvid-1.2.0-dev
Bitstream version: 1.2.-127
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
Detected 2 cpus, using 2 threads.
Using quantizer = (4.00 + (((((0.00 - (1.00 * theta((lc_lum - 40.00)))) - (1.00
* theta((lc_lum - 50.00)))) + (1.00 * theta((lc_lum - 130.00)))) + (1.00 * theta
((lc_lum - 140.00)))) * theta((80.00 - gl_lum))))

241 frames(100%) encoded, 358.63 fps, Average Bitrate = 23kbps
Tot: enctime(ms) = 672.00, length(bytes) = 28708
Avg: enctime(ms) = 2.78, fps = 360.12, length(bytes) = 118
I frames: 1 frames, size = 14431/ 14431, quants = 4 / 4.00 / 4
P frames: 80 frames, size = 127/ 10163, quants = 4 / 4.00 / 4
B frames: 159 frames, size = 25/ 4114, quants = 6 / 6.00 / 6
Press any key to continue . . .


Can you see what's wrong. It only ran for about a second before terminating.


PS. I think I have the wrong version of DGDecode.dll.

PS. That was it, DGIndex/DGDecode were mismatched! Working good now except that I think there is a bug when I input that the source is progressive, the -FO switch in DGIndex is not changed to progressive!!

[Kopernikus]

Has anyone a freely available, short (1000-2000 frames) sample, that pushes Xvid to its limits? I would like to run some further tests, but lack proper samples.

[ripernh]

Why this problem of dark scenes is not the priority of sites as divx and xvid.org?
I don’t speak english, sorry
I am using translating

[DDogg]

Has anyone a freely available, short (1000-2000 frames) sample, that pushes Xvid to its limits? I would like to run some further tests, but lack proper samples.Some HD source If you have broadband here (http://orange.blender.org/download).

[henryho_hk]

that pushes Xvid to its limits?

It depends which XviD's limit you want to test. You can try the samples in this thread: http://forum.doom9.org/showthread.php?t=116746

[Eruendil]

@tyee: Happy that it's working :) !
Actually I didn't really understand what this -FO option is good for. I only remember to have read somewhere that "Force Film" is an option that is necessary in some cases in NTSC-countries. As far as I came, I thought that honor/igone pulldown-flags is about dropping specific frames..?

Anyway, I never needed the option for my movies. But I can implement a version that does if you tell me, in which cases which values have to be set for that option...

Greetings,
Eruendil

/add1: Perhaps the modification could also be useful for people not living in an NTSC-country, but just intending to convert NTSC-material ;)

/add2: Why does xvid_encraw tell me that it calculates 30.48 fps, if it actually does only do 13.85 fps (121301 frames, 2h26m / 146 min conversion time) :confused: ..?? The total frames xvid_encraw prints is correct, but the total time and fps values are pure fantasy. Are these some kind of internal values considering some internal duration of conversion of a single frame or so?

[tyee]

Eruendil
In vcbatchgen.bat, if we change this part --

echo @echo on>>"%OUT%"
echo "%DGINDEX%" -AIF=[%WORK_DIR%\VIDEO_TS\VTS_%VOB_NUM%_1.VOB] -IA=3 -FO=0 -TN=%TRACKS% -OM=1 -OF=[%WORK_DIR%\VOB_Number_%VOB_NUM%] -EXIT>>"%OUT%"

by changing the -FO=0 to -FO=1, I think that will do it. This would make it progressive as default, and then when avsgen.bat executes, this part of avsgen.bat --

@echo INTERLACED OR PROGRESSIVE SOURCE
@echo in = interlaced: activate deinterlacing
@echo pr = progressive: no deinterlacing
:GET_DEINT
set /p DEINT="Interlaced / progressive source: "
IF "%DEINT%" NEQ "in" (
IF "%DEINT%" NEQ "pr" @echo Unrecognised input, please repeat.&&GOTO :GET_DEINT )

IF "%DEINT%" == "in" @echo in = in.TDeint( mtnmode = 0 )>>"%DIR%\VOB_Number_%NUM%.avs"


should change it to interlaced if required.
I think this would work for me here as NTSC. What do you think?


BTW - Why did you decide to split the batchfile up into two - vcbatchgen and avs_gen? What would happen if it were all one batch file??

[Eruendil]

Hi!

@tyee:
So, the only thing to be changed is "-FO=0" to "-FO=1", if I got it right. For all types of source material? Then all that has to change is the one number "0"->"1" in vcbatchgen.bat.

Or do you mean that "-FO=1" may only be applied for progressive material and must be "0" for interlaced sources?

Would these settings work for PAL also, or is there a different version (or simply a parameter NTSC=yes/no) needed?

About splitting vcbatchgen.bat and avs_gen.bat: I'm not sure anymore, why I split the two. Could be that I was liking the idea of modularity, or I simply was not familiar with how to use batchfiles and it was supposed to be a workaround of some kind...

As you see, I also use help_bat.txt to insert lines into the generated batchfile that operate with variables, which wouldn't have worked with the "echo"-command, which would have tried to replace all the variables by their values, so there will always be more than one file needed... And passing some variables to avs_gen.bat won't hurt, I think, and that way it remains "modular" ;)

Greetz,
Eruendil

[tyee]

Eruendil


"Or do you mean that "-FO=1" may only be applied for progressive material and must be "0" for interlaced sources?"

Yes, that is what I mean. Most of our NTSC dvd's are progressive on the disk and -FO=1 would inverse telecine (remove the pulldown flags, I believe) the dvd so we get 23.976fps for our encoding to xvid, but this could be changed when the avs_gen.bat asks us if it is interlaced or progressive.

tyee

[Eruendil]

Ok, I've got a working NTSC version on my harddrive now :D .

One question: Do I have to publish a special NTSC-version or do the settings -FO=1/0 work for PAL correctly also :confused:? Then I just could replace the old file. Can anybody tell for sure?

CU,
Eruendil

[henryho_hk]

How does the division operator work? Both cmdlines below give a quantizer of zero:

xvid_encraw_hvs_20061105.exe -progress 100 -hvs_aq " 3 4 \ " -cq 3 -single -i input.avs -avi output.avi

xvid_encraw_hvs_20061105.exe -progress 100 -hvs_aq " 4 3 \ " -cq 3 -single -i input.avs -avi output.avi

[Eruendil]

@henryho_hk:
If I remember right, I once noticed a strange behaviour of the -hvs_aq option: If the first value is a "calculated constant" (like "3 4 /" is a constant value) it produced senseless results... I'm not sure, if it was exactly the problem I describe here, but somehow in that direction...

Also I would be careful with leading spaces and such..!?

/add1: Perhaps you could try something like -hvs_aq "lc_lum 3 * lc_lum 4 * /" and "lc_lum 4 * lc_lum 3 * /" and see if it's working... Except this problem I don't remember to have encountered any other problem with formulas. Sorry :( that I didn't report it sooner!

/add2: The applied quant is the formula value cut off after the point. So 4.99999 would be quant 4.

[Kopernikus]

@henryho_hk: its "/" not "\" :)
But I guess I should add a error message

@eruendil: any example for strange behaviour?

And I will round the value instead of cutting it.

[Kopernikus]

Here is a new version:

-rounding
-warning if there is something wrong with the formula
-more code cleanup
-new parameters to play with:

lc_ssim: approximated (luma) ssim value of this macroblock in the frame before. 1 is lossless, 0 is very bad quality (even 0.8 is very bad).
gl_ssim: frame average of lc_ssim.

The ssim (a psychovisual quality metric, corresponds quite good to some aspects of human perception) values are 1 frame old, but I can not calculate ssim without having compressed the frame. And its still useful as the bad artefakts stay in place for more than one frame.

http://xvid.ist-dein-freund.de/stuff/xvid_encraw_061119.exe

[tyee]

Eruendil

"One question: Do I have to publish a special NTSC-version or do the settings -FO=1/0 work for PAL correctly also ? Then I just could replace the old file. Can anybody tell for sure?"

From what I remember, only NTSC uses the -FO=1 setting. PAL never uses it. I believe it removes the 3:2 pulldown flags, which is only used in NTSC. This will convert a 29.97fps NTSC movie to a 23.976fps progressive movie for us to encode.

[henryho_hk]

And I will round the value instead of cutting it.

It seems the AQ reported is a bit confusing.

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 1.5 1.5 + " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 2 and max I-Q = 3

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 3 3 + 2 / " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 3 and max I-Q = 3

xvid_encraw_hvs_20061119.exe -progress 100 -hvs_aq " 3 2 + 2 / " -cq 3 -single -i input.avs -avi output.avi
........... gives AQ = 2.5 and max I-Q = 3

[Eruendil]

@Kopernikus:
Sorry, but I don't have the formulas anymore, but I remember sweating some time about the problem and all worked fine after rearranging the formula (perhaps an error which wasn't repeated after regrouping the formula - I don't think so, but possible).

Regarding the new version of xvid_encaw: Do you really think it is wise to change the basic behaviour (rounding instead of cutting) of the formula now? I mean: In the end it doesn't matter at which point the quant is changed, the formula has to be adapted for both cases (although the "feeling" might be a bit better if rounding occurs... but that's for the sake of losing continuity, if something like this exists up to now).

@tyee:
The point is: Will -FO=1 do any harm to (progressive) PAL-material (always using "0" worked fine for PAL)? If I get you right, it doesn't matter if it's "1" or "0" for PAL-material.

PS: What strange fps-values NTSC uses! I guess this had some technical reason in the past?

/add1 @henryho_hk wrote
-hvs_aq " 1.5 1.5 + "
As far as I know, you can't use floating point values "1.5". You have to use "15 10 /" instead.

-hvs_aq " 3 + 3 2 / "
Here you use an operator needing two arguments after only giving one "3 +"... Do you perhaps mean "3 3 + 2 /"?

-hvs_aq " 3 + 2 2 / "
Idem.

Greetings,
Eruendil

[Kopernikus]

It The 1.5 is parsed as an int -> 1+1 = 2
3 + 3 2 / seems not a valid formula to me, and it is parsed as 3 2 / and gives AQ = 1.5 here

3 + 2 2 / -> AQ = 1.0

Seems all correct.

The Quantizer that is displayed per frame is not affected by the plugin. It is even different from the one written to bitstream, but there is a comment in the sources, so I assume it has a reason that I don't see.

@eruendil: I think rounding is better, and it is better to change it now.

[henryho_hk]

BTW, Kopernikus will you merge to a new code base by squid_80? It has an improved AVI writer.

http://members.optusnet.com.au/squid_80/sources/

[Kopernikus]

It is better to bug squid_80 to send a patch to the xvid-devel mailinglist.

[henryho_hk]

I want to modify Eruendil's formula as below hoping to limit the I/P quantizer range to 2~5 because I think 6 seems too aggressive.

"lc_lum 130 - theta lc_lum 140 - theta + lc_lum 40 - theta - lc_lum 50 - theta - 80 gl_lum - theta 3 * * 15 + 4 /"
or
"lc_lum 130 - theta lc_lum 140 - theta + lc_lum 45 - theta - 80 gl_lum - theta * 3 +"
or
"lc_lum 135 - theta lc_lum 40 - theta - lc_lum 50 - theta - 80 gl_lum - theta * 4 +"

In above these cases, how should I put the -cq parameter? And does it affect the B-frames only?

--------------------------------------------------------------------------------------------------

Answering myself, it's mostly in the document. "-hvs_aq" works on I and P frames only. B-frames seems to depends on the original rate control algorithm and, in the case of single CQ encode it depends solely on -cq, -bquant_ratio and -bquant_offset.

And ffdshow's visualization really helps a lot. It's fun to see different quantizers within a frame.

[Kopernikus]

The Quantizer that is displayed per frame is not affected by the plugin. It is even different from the one written to bitstream, but there is a comment in the sources, so I assume it has a reason that I don't see.


Yes, its a little bit confusing, the displayed Quantizer is not correct, for now just ignor it. I will try to find out why not the real quantizer is displayed, but the one frome ratecontrol.

[tyee]

Eruendil

@tyee:
The point is: Will -FO=1 do any harm to (progressive) PAL-material (always using "0" worked fine for PAL)? If I get you right, it doesn't matter if it's "1" or "0" for PAL-material.

I think the -FO=1 will do harm to PAL, so best to use -FO=0 for PAL at all times. I may be wrong so if anyone else knows please correct. So, to summarize, use -FO=0 for all PAL and -FO=1 for NTSC progressive and -FO=0 for NTSC interlaced.

[Eruendil]

Hi there!

Ok, here it goes (sorry for letting you wait, but I had some quite busy days): A fully PAL and NTSC-compatible version of VCBatchGen (V 1.6) ...

Either as attechment to this posting or at project357:

http://files.project357.com/uploads/index.php?dir=&file=VCBatchGen_plus_files_2006-11-25b.zip/

You simply will be asked if it's PAL or NTSC material and -FO will be 0 in all cases except for a progressive NTSC source. I thought that a seperate version would be nonsense anyway as someone might want to encode NTSC and PAL with one installation. Enjoy!

Greetings,
Eruendil

[tyee]

Thanks a lot Eruendil!! Much appreciated!

[henryho_hk]

Stealing the idea from Eruendil's formula:


-nochromame -cq 4 -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - "


If gl_lum > 153, all blocks are at Q=4. Otherwise, those with lc_lum between 0.5*gl_lum and 0.25*(255-gl_lum) will have Q=3.

BTW, does this HVS plugin work between with non-HVS matrices such as 6of9, MPEG or even H.263?

[DDogg]

henryho_hk, glad to see you are investigating this method. What are your thoughts so far in comparison to non patched xvid encodes? Btw, here is some data from a recent job using the formula above. I don't do many xvid encodes so I've not drilled down on what exactly the lines mean - would appreciate your comments on:

Detected 2 cpus, using 2 threads.
Using quantizer = (quant - ((theta((lc_lum - (gl_lum * 0.50))) + theta(((((255.0
0 - gl_lum) * 3.00) * 0.25) - lc_lum))) * 0.50))

141241 frames(100%) encoded, 92.13 fps, Average Bitrate = 959kbps
Tot: enctime(ms) =1533143.00, length(bytes) = 676975854
Avg: enctime(ms) = 10.85, fps = 92.13, length(bytes) = 4792
I frames: 2409 frames, size = 12169/29315491, quants = 4 / 4.00 / 4
P frames: 63254 frames, size = 8196/518470581, quants = 4 / 4.00 / 4
B frames: 75440 frames, size = 1712/129188678, quants = 6 / 6.00 / 6
N frames: 138 frames, size = 8/ 1104 Used this full line: -i %fname% -avi %out1% -nochromame -cq 4 -bquant_offset 200 -bquant_ratio 100 -hvs_aq " quant
lc_lum gl_lum 2 / - theta 255 gl_lum - 3 * 4 / lc_lum - theta + 2 / - " -bquant_offset 200
-bquant_ratio 100 -progress 10 Encode was @ 640x272 - finished video size was 648 MB - source was 94 minutes long

[Kopernikus]

HVS matrices are AFAIK matrices that try to exploit some properties of the human vision (as quantizing different frequencies differently is such a property, you could call every matrix HVS).

The Plugin changes the quantizer of blocks as a function of several parameters, that is something a QM cannot do. And I cannot imageine a reason why a different CQM should interfere with the plugin.

@DDogg: The data you posted is not very usefull, the displayed quants are totally wrong, I guess I should fix this.

How does the result look, and are there problematic parts?

[DDogg]

@DDogg: The data you posted is not very usefull, the displayed quants are totally wrong, I guess I should fix this.

How does the result look, and are there problematic parts? Looks very well. Zooming to 200% finds a few problems with a few frames in the middle of an explosion (in water) - I think I can live with that :)

[henryho_hk]

What are your thoughts so far in comparison to non patched xvid encodes?

As always, "I don't know what I am doing." ^_^

Actually, I do not know if it is a good idea to have a higher (4) quantizier for bright & dark areas and a lower (3) quantizier for the medium ones.

[squid_80]

Kopernikus: Could you put up the source for the November 19th build? I tried to use the source from 5th November but it seems to get stuck in an infinite loop somewhere on certain frames.

[Kopernikus]

I will try to put it up asap, but my ISP has disconnected me for a unknown reason, so it may take a while.

[Kopernikus]

So, here is the source for the most recent version (I am not sure if it is identical to the one from Nov 19th):

http://xvid.ist-dein-freund.de/stuff/cg_hvs_061209.diff

It works here, but if you encounter any problems just ask.

[squid_80]

One thing in xvid_encraw.c: if(ARG_HVS_LMB != 0 || ARG_HVS_AQ != 0){
plg_hvs_param_t* hvs_param;
hvs_param = (plg_hvs_param_t*) malloc(sizeof(plg_hvs_param_t));

Is that malloc free'd anywhere? Is it safe to free it after the encoder is created with XVID_ENC_CREATE?

[squid_80]

The infinite loop I'm seeing is something to do with trellis.
line 988 in mbtransquant.c: while(i>=0) {
Out[Zigzag[i]] = Nodes[i].Level;
Sum += abs(Nodes[i].Level);
// if (!(Nodes[i].Run))
// fprintf(stderr, "Warning! Nodes[i].Run == 0 (i = %d)\n", i);
i -= Nodes[i].Run;
}
(The commented lines I added.)
The hvs_aq string I'm using is "quant lc_lum gl_lum - 64 / -". When I uncomment the above lines it gets stuck in that loop on some frame (depends on the input clip) with i = 37. I don't really know how trellis works so I don't know what to look for.

[Kopernikus]

One thing in xvid_encraw.c: if(ARG_HVS_LMB != 0 || ARG_HVS_AQ != 0){
plg_hvs_param_t* hvs_param;
hvs_param = (plg_hvs_param_t*) malloc(sizeof(plg_hvs_param_t));

Is that malloc free'd anywhere? Is it safe to free it after the encoder is created with XVID_ENC_CREATE?

Hmmm, it seems that I forgot to free that memory. I will try to check that and reproduce the trellis bug when I am at home.

Thanks for the report.

[squid_80]

I found the other problem. The Lambda values passed to the plugin were all messed up half the time. I modified encoder.c (starting line 772): if(pEnc->mbParam.plugin_flags & XVID_REQLAMBDA) {
int block = 0;
emms();
data.lambda = pEnc->temp_lambda;
for(i = 0;i < pEnc->mbParam.mb_height; i++)
for(j = 0;j < pEnc->mbParam.mb_width; j++)
for (k = 0; k < 6; k++)
data.lambda[block++] = 1.0f;
}
and all is well. Telling the compiler to target SSE2 also hides the error, maybe that's why no-one noticed it before?

[squid_80]

I tried to send a bug report about the missing emms but can't get through to the mailing list - both xvid-devel@list.xvid.org and xvid-devel@xvid.org bounce back. I thought I might have been kicked off the list but if I try to subscribe I get an email telling me I'm already subscribed. I would really like to get this bug fixed rather than hack xvid_encraw around it or link to xvidcore statically.

[Kopernikus]

The list works again, I have send a mail with a patch, hope it will be fixed soon.

Edit: Michael said it works, but it seems not so, the mail bounced again.

[squid_80]

No email from the list has landed in my inbox :(
I decided to hack around it anyway since I can't be sure the user doesn't have a bad xvidcore.dll. I use a dummy plugin to set the lambda values to 1.0f before the hvs plugin is called.

[squid_80]

Ok now I got your email to the dev list with the patch and Michael's reply about 15 mins later. Thanks.

[plugh]

squid_80 / Kopernicus - a question...

In enc_init, you add the hvs plugin to the array _before_ the pass1/pass2 plugins. Doesn't this plugin want the frame quant assigned by these plugins?

Shouldn't it be added to the array after them, like the lumimasking plugin? Or am I misunderstanding things...

(was thinking about incorporating this into my vfw front end)

[squid_80]

From memory the rate control plugins do their work when opt=XVID_PLG_BEFORE and xvid_plugin_hvs does its work when opt=XVID_PLG_FRAME. So the order in the plugin array isn't really important.

[plugh]

Yes, RC does its thing 'before' (and 'after'). I missed the 'frame' bit. Thanks.

[Eruendil]

Happy new year to this thread ;) !

I just encoded some more movies (after pausing since december) and I have to say that I'm pretty amazed about the quality (and size in relation) of the results... It works fine, not more and not less!

:thanks: again, Kopernikus :D

[plugh]

Finally got around to putting together an xvidvfw.dll with this plugin for experimenting...

Notes:

This is a 'stripped down' version of the plugin, only offering adaptive quant equation (no lambda equation) and no ssim variables. -- I wanted this to work with xvidcore 1.1.2 and lambda access isn't available in that version, and the ssim stuff adds overhead for something I don't use. (Both are trivial to reenable with a couple #define's and a rebuild).

Basically, I hooked it in as a replacement for the lumi-masking plugin. The existing GUI "Adaptive Quantization" checkbox enables it, and by default it will use the "lumi-masking equation" if no other is defined. As this is for experimentation and I was feeling lazy, I didn't muck with the GUI - you must specify your desired AQ eqn via the "XVIDAQ" environment variable.

This also includes my '2nd pass alt' plugin and related changes (see this (http://forum.doom9.org/showthread.php?t=118419) for details). All sources included. See changelog.txt for more info.

EDIT: update below

[olnima]

Your link isn't a link :) can You / mods fix that please?

Thanks for your work

Olnima

[plugh]

Your link isn't a link :) can You / mods fix that please?

You are correct - it isn't a link, it's an attachment, which requires mod approval (which has been granted). You just have to give them a little time...

[plugh]

Well, results of my first experiment are disappointing...

I encoded the same clip twice, once with the 'normal' lumi-masking routine, once with the hvs plugin and the lumi-masking equation posted on Kopernikus web-site.

hvs plugin output file was about twice as large.

hmmm. time to start digging...

[plugh]

Well, that was "easy" - the lumi-masking expression on his web-site calculates a scale factor, but doesn't apply it! Small addition to the expression, re-ran the comparison - nearly identical output file sizes. I suspect the slight difference is due to numerical accuracy and rounding variations.

So, new version available. Also did some code clean-up and some enhancements. Attached are two builds:

A 'stripped down' Adaptive Quant only, 1.1.2 compatible build like above, tested against the standard lumi-masking plugin.

A 'full featured' 1.2.x compatible build with AQ and Lambda eqn and ssim variables. Use the "XVIDLMB" environment variable to supply the lambda equation. Note that THIS build is untested as I don't have a 1.2.x baseline to compare against nor any idea what to try for a lambda modulation equation. Also, based upon squid_80's comments earlier in this thread about a missing 'emms', you might need a current cvs build of xvidcore to use the lambda stuff .

Both builds are from the same sources, just differant compile time defines.

Side note:
If your interest is the sources, use this kit rather than the preceding one as I cleaned up the hvs_plugin conditional compilation stuff a bit (now DO_LAMBDA and DO_SSIM are independant of each other). There are also what I believe to be two bug-fixes on the Lambda eqn code path (relevant now since that code is activated in this build). I started with the version of the hvs plugin code used in squid_80's 121306 encraw build, which I think was based upon Kopernikus's 120906 .diff posted earlier in this thread. If either person wants to comment, look for "//del" in the hvs plugin source.

Have fun!

[plugh]

Received a suggestion/request that seemed reasonable, so...

Instead of always using the hvs_plugin, but with a default lumi-masking AQ equation if no other hvs equation is defined, make the default case the standard xvidcore resident lumimasking plugin.

Thus, if you select the vfw GUI "Adaptive Quantization" checkbox with an hvs eqn environment variable defined you get the hvs plugin, otherwise you continue to get the lumimasking plugin you know and love :rolleyes:

I wouldn't normally release an update for something like this (it was just a couple lines of code) but I liked the idea of only activating the hvs plugin if someone took explicit steps to do so (ie defining an environment variable), so here it is. We'll let the download counts determine the 'winner' :) Both flavors (stripped-down 1.1.2 vs full-featured 1.2.x) are in the attachment.

PS - the 'fix' to the lumimasking eqn on Kopernikus web-site was to add "quant *" at the end - ie multiply the computed scale factor times the current quant to get the final quant.