Cvs 2002-03-23

[-h]

What's new in VfW:

- Foxer's alternative 2-pass code (Alt. Curve tab)
- Added Load Defaults button
- Added proper tooltips
- Changed inter4v to only be in modes 5 or 6 (now search precison 4 will actually be different from 5)
- Fixed null mode crash ? always worked for me
- Added debug output on errors instead of just returning -100

For binary guys, there's a pic in the vfw/bin directory that Foxer made regarding the alternative curve technique.

Have fun :)

-h

[-h]

If anyone has been getting crashes (mpeg2avi, xmpeg, etc.), try this build with dbgview running. It should now output to the debug log exactly what the error was triggered by.

If not, I guess something else has gone wrong :)

-h

[wing1]

@-h
Just tested uManiacs build of the new CVS. I do like the sharpness that this new CVS has. The bit bucket thing is still running amuck. After a minute or so it starts to climb no stop and goes beyond 300KB/s even at 50 data rate settings! for 1pass-CBR mode/quantizer(5)/quality(85%). The brightness is back a bit on this new CVS ( I wish that the brightness/contrast level like in nic's old 03-04-2002 is back ). Eversince the new core the brightness/contrast has beeen way too dark.

[-h]

The new core didn't change the brightness at all... it can't, or it wouldn't be spec-compliant. Sounds like a settings issue.

As for the data rate thing, that has me worried. It's all working fine at my end, which leads me to believe it's the compile. I've put the DLL that I'm using up here (http://briefcase.yahoo.com/hstink), give that a go and see what it does for you.

Very very odd.

Oh and CBR is still 100% unusable.

-h

[Nic]

Try mine in contrast at:

http://nic.dnsalias.com

:)

-Nic

[debris]

I'm testing Nic's latest build and after using my favourite new button "load defaults" (only kidding - it's just one of my favourite new buttons) there are no more "ticks" in the CPU optimization tab. I usually let it set to autodetect all CPU-features and I don't know whether these ticks do actually show what kind of optimizations are going to be used when they're greyed out but I noticed that encoding really is 5-7fps slower than with the 2002-03-20 build.
Of course I could set the options manually but if you're "in a hurry" and forget to set them after loading defaults you're gonna wait a bit longer than you would have to...

[Mefisto]

@-h

Well, I've see the new option - Alt. curve

How does it work? Which are optimal values?
In quantizers restrictions (i-frames), the most values are 1 for min, and 31 for max. is it?

Thanks

Regards

[-h]

I'm testing Nic's latest build and after using my favourite new button "load defaults" (only kidding - it's just one of my favourite new buttons) there are no more "ticks" in the CPU optimization tab. I usually let it set to autodetect all CPU-features and I don't know whether these ticks do actually show what kind of optimizations are going to be used when they're greyed out but I noticed that encoding really is 5-7fps slower than with the 2002-03-20 build.

I just noticed they're unticked.. strange that. However, encoding speed is as fast as it ever was for me - As long as the "Force" radio button isn't checked, all available CPU optimisations are enabled, whether or not the individual checkboxes are checked.

Well, I've see the new option - Alt. curve. How does it work? Which are optimal values?

I'll leave that to Foxer :)

-h

[Foxer]

The alternative curve system isn't terribly simple but it is very controllable.

Curve aggression determines how quick it is to change the encoding quality based upon how close the framesize is to the high or low thresholds you define with high and low distances from the average framesize. Each aggression level is quite different from the others but they all reach the same goals. (refer to the alt_curve.gif I scratched up)

Basically, lowering the low distance will move the preference some towards low bitrate frames and raising the high distance will move the preference some towards high bitrate frames.

Automatic minimum relative quality uses a simple calculation and what it sets the min relative quality to depends upon how low the quality of the current encode is (how large the desired size is in comparison to the size you'd get from using a constant quantizer of 2).

Say you choose 50% strength and you set your desired size at half the size of a quant2 encode. That would produce a minimum relative quality of 75% and if you set the desired size to 20% of the size of a quant2 encode, it would produce a minimum relative quality of 60%.

The formula it uses is this.
minimum relative quality = 100 - (100 - encode quality) * strength

Bonus bias is the percentage of the bonus that is distributed in a bias manner and the rest in a proportional manner.

This bonus is a result of how the quality calculations are done. 1.0 = 100% quality, 0.6 = 60% quality and the automatic mode for this merely sets the percentage to the minimum relative quality for now.

Basically, the higher the bonus bias, the more preference to low bitrate scenes.

You can also set this to a value greater than 100% and it'll still reach the desired size but will hurt the quality of high bitrate frames.

As for optimal values.. We just have to test and see :)

I'm sorry but I just made this thing a few days ago and haven't had time to test various settings on the few dvds and video clips I have.

[Teegedeck]

...my poor little brains!:o

[wing1]

@nic

Brightness/contrast = perfect :D thanks.

@-h

Tried using both your xvid.dll and nic's, and they are doing the same thing, except for quantizer(5). It seems that quantizer is slower to rise and is stable at 180-200K/s. Now what i've been able to make it more stable and stay at 125K/s-150K/s is by playing with the buffer size by doubling it and set the bitrate 1200-1500.

I like 1-pass CBR because in the past it has offered me filesize vs. quality for capture just like mpg4v3-VKI but at bigger then 352x240 framesize ( I have optibase mpeg1 for that :D )

A modified Vdub 1.4.7 - settings

1. 480x480 framesize @29.97fps

2. Reduce the vertical resolution by 2 (bicubic) to get rid of interlace artifacts.

3. Crop 32 in the X and 16 in the Y to get rid of all black bars around the video source.

4. Precise BicubicResize to 448x320, and this only stretch the Y direction only since 480-32=448.

5. ATI is set to YUY2 Packed data and YUY2 for Vdub.

6. Capture and slice out commercials afterward. I get about a good 2.5-3.5hrs to 4Gb file size.

7. When the capture hard drive filled up, I would swap it out to my 1900+XP and use AviSynth to sharpen/levels/BicubicResize (512x384) and recompress again with Vdub1.4.8. I can usually get 1CD out of a good 105min movie or 2-3 sitcom episols.

Hardwares for capture is AMD 1.467Ghz(slightly OC) with 1GbSDRAM133. Video capture card is ATI AIW 128 16Mb AGPx2 bt8298BK chipset (not the rage theather - macroblock issues).

The alternative is using either mjpeg or huffyuv codec but that uses way too much hard disk space, and the result is similiar afterward.

[wing1]

OK, I finally decide to use 1-pass quantizer for capture now with setting at 3 and lumni masking on. Data rate is in control and quality is good. However, the CPU usage is now above 60% most of the time :(

[-h]

Ohhh you were using CBR mode - then yes in that case I understand, because CBR is broken. Isibaar was amazed that it was actually working for some people :)

-h

[philippas]

Maybe this is better for the capture section of the forum but anyway…@wing1
Reduce the vertical resolution by 2 (bicubic)
Bad choice just capture at 480x240 it's the same thing, it's a waste of cpu power ! Basically when you do vertical reduce by two you
throw away one field which means you get a framesize 480x240 and then resize at 480x480.

use AviSynth to sharpen/levels/BicubicResize (512x384)
If you capture at 480x480 its a bad thing for the quality if you enlarge the resolution. Always shrink never enlarge the resolution after a video capture. At playback if you think that your cards resize is a bit blurry use the directShow bicubic resize filters which can be found in doom9's page.

If you need quality and a bit more reasonable compression use xvid with quantizer 1. Better compression ratio than huffyuv slightly worse quality(close to lossless).

[Belgabor]

Originally posted by philippas

Bad choice just capture at 480x240 it's the same thing, it's a waste of cpu power ! Basically when you do vertical reduce by two you
throw away one field which means you get a framesize 480x240 and then resize at 480x480.


No, you don't throw away one field, you blend both together. That gives (imho) better looking results than capturing with half vertical resolution. (tried both)

[philippas]

@Belgabor

Avisynth's vertical reduce by 2, is a fast deinterlacing filter that throws away one field of an interlaced source and resize back to the given resolution.

If you mean the virtualdub's vertical Reduce by 2 in the capture mode, i'm not sure 100% but maybe you are right.

[wing1]

@Philippas

I am doing the vertical reduction by 2 and Bicubical resize in virtual dub just before the real time compression with xvid during the capture sequence. By doing so I get rid of the interlace from the video capture card in real time. At that time I am manipulating the real time analog input source before I commit it to compressed digital data. Resolution is amazingly good and sharp. Although I can not approach 512x384 ( perhaps in the near future when CPU speed allow me to do that :D )