How does the Compressability check in Gknot work?

[Tropican]

How does the compressibility check function work in Gknot? I read a post about doing one manually (without Gordian Knot), but it was mentioned that B-Frames are only calculated correctly in Gordian Knot. How does Gknot handle them then? I don't think it matters, but I plan to encode to XviD.

Thanks,
Tropican

[chros]

That question is interesting me too.
I meen which codec options used by GK ?

eg.: Xvid: 1st pass, single pass ???

[jggimi]

The compressibility check (or compressibility test) in GK works by using a single numeric value that takes into account both the number of bits in the video (bitrate x length = size), and the resolution of the video as well. This single value that takes both into account is:bits / pixels * framesThe actual number produced is not important, except as a possible starting point for your first compressibility check. What's important, though, is the ratio of two b/p*f values: The test compares what the maximum b/p*f value could possibly be, against the bitrate you've currently configured, usually by selecting a file size. It is that ratio, expressed as a percentage of maximum bitrate, that is important.

When you select a compress test, an AviSynth script (.avs file) is configured just as you have selected, with resolution, cropping, and any added filters such as noise reduction or deinterlacing/IVTC. The only difference between this script and the full encoding script is that this one has an extra filter in it that will select only a portion of the frames -- by default, 14 frames out of each 280, or 5% of the entire content.

A first pass encoding is run, which captures an analysis of these frames. That analysis (log file) is then read by GK, and it determines, through reading the log, what the MAXIMUM bitrate (and maximum size) would be through the encoder, with that content at those settings.

It also calculates a bits / pixels * frames value at that bitrate, and resolution. And it also percentage your chosen bitrate is below (or sometimes above) maximum.

As you adjust resolution or bitrate (filesize) in GK's GUI, it recalculates a new expected b/p*f value, and shows new percentage values. These work, but only to a point -- if you make any significant resolution changes, or change filter settings, you should re-run your compressibility test. The reason? Anything that changes how compressible your content is will necessitate rerunning the test. And its not so obvious, but different resolutions change whats in each macroblock and the number of macroblocks, which impact compresibility several ways. Its why best practice is to set your initial resolution and bitrate (file size) to an initial starting b/p*f in the ranges discussed in the guides; they're close enough for starting points, and if you use them, you can reduce the number of compress tests you might need to run for accurate encoded file sizes.

[jggimi]

AFAIK, GK doesn't care, because that first pass is run with your codec settings, whatever they might be, and the log is produced by the codec. If b-frames are set on, you'll get one log file, if b-frames are off, you'll get another. If your "manual" test has you doing a single-pass quality based encoding, there is no log file; instead, there is a usable video file. With multipass encodings, the codecs produce a dummy .avi file on the first pass.

Len0x will correct me if I've misunderstood how GK "manages" b-frames.

[Tropican]

Sorry jggimi, I didn't notice your response before I posted, *delete*

So, is there any way to do all of that manually? (without going too nuts)

[jggimi]

During a point at which GK couldn't deal with the then new DivX (5.1), jonny wrote a tool to do compression checks:

http://forum.doom9.org/showthread.php?s=&threadid=19927

But if you don't want to use GK for encoding, you can still use it for compression testing and .avs generation. Many do.

[len0x]

A little clarification:

- GK uses single pass quant=2 encoding for comp test. The rest of options are same as for normal encoding.
- log file is produced not by codec but by vdubmod and consits of maximum sized frames.
- not all the frames are counted towards comp test result (some are discarded)
- b-frames for xvid requires different frames to be discarded
- there is no way of doing precise manual comp test unless you write your own parser for the log file
- _very_ rough comp test can be done by feeding 5% (or any other) avs source into vdubmod for single pass encoding and comparing the final size of AVI file (divided by % to get full projected size) with your target size.

[jggimi]

Thanks for the correction!:stupid:

[chros]

Thanx for the answers !
I'm trying to summarize these peices of info .... :)