Log in

View Full Version : MPEG2 Encoding Details


Malcolm
15th June 2004, 15:41
I have a question about the MPEG2 encoding, esp the Q factor + VBR:
I know some separate things about mpeg2 encoding like the dct conversion, the quantization and the huffman compression. but i still have some questions:
What i know in brief (i'm leaving out motion-search + I,P,B stuff):
- Every frame is processed in parts of 8x8 pixels. (macroblocks)
- Every macroblock is transformed to frequency-space by the dct conversion
- The generated 8x8 values are divided by the intra or inter quantization matrix.
- Am i right, that these values are then divided again by some value to get to the final bitrate / movie size? Is this the Q (or quantization) factor??
- The last step then is the huffman-compression

Can someone confirm what i've written? Is it that simple?
Where happens the 'magic' in MPEG2 encoding? Where & how is decided how much space (bits) is given to a specific frame (bitrate distribution over the length of the movie (VBR))? How is this calculated? That means: is the Q factor computed one time for the whole movie and the same for all 8x8 matrices (that would be CBR), or is the q factor different for every 8x8 matrix (dark areas, fast moving areas, I,P,B frames)? How is this calculated?

I'm really interested in a good explanation, but i don't want to be thrown with formulas and such :)

Thank you

Greetings,
Malcolm

Amnon82
16th June 2004, 14:17
The Q value is only intressting for 1-Pass VBR.

1-Pass VBR creates variable bitrate streams by one pass. In this mode, minimum and maximum bitrates and the degree of distortion are specified. The average bitreate cannot be specified in this mode.

In CCE this mode is called MPEG-2 (ES, One-pass VBR).
It creates a MPEG-2 Video elementary stream in one-pass VBR mode. The bitrate of each GOP varies but quantization scale is almost the same.
The quantization scale may be changed in order to keep upper and lower bounds of bitrate.

Bitrate and Q.factor:

Bit amount per one second is called bitrate. I think You know this already. The higher the bitrate, the better the quality and larger the file size. (1 kilo bits is regarded as 1,000 bits.)

I do a example to explain this better.
We will reach 4,000 kbits/sec for a 2 hour movie to get 3.6 GB for the video elementary stream. This will be then:

2 x 60 x 60 x 4000 x 1000 / 8 = 3,600,000,000 bytes

(To convert form bits to bytes, I divided it by 8.)

But we can't specify the average bitrate, as you know. So we must do it with the Q.factor.

Q.factor is a parameter unique to the Cinema Craft Encoder. This parameter influences quatization scale and can be specified only in one pass VBR mode.

Not all values of the Q.factor are the best. Here the meanings of each range:

1 to 40 - Priority is given to image quality over compression rate.
40 to 80 - Standard setting
80 to 120 - Priority is given to compression rate over image quality
above 120 - Image quality deteriorates considerably

So now You know all the basic, but You want to know where the magic came form. Not every film is the same. Some are darker, some have more action in it. So You can't specify the Q.value to easy. You need a tool.

So I come into the play. I developed QCCE further. My QCCE CYBER EDITION has new matrices and new standard settings. If you use my tools, so you'll get a q.value between 1 and 40.

You have to load your source with a AVS-Script into my app. Enter the wanted size for the video elmentary stream. Specify the path to EclCCE and it "New Job" + "Start all jobs". QCCE CE will find the right q.value.

Try it out. I think I helped you with this.

Malcolm
16th June 2004, 15:34
Thank you Amnon,
you described the practical way of MPEG2 encoding. since i'm doing mpeg2 encodings for over 2 years now, i know already what to do to get to the wanted result. nevertheless - thank you for your reply!

i'm really interested in the theoretical or let's say 'internal' way of mpeg2 encoding. what's done by the encoding software to decide how much bitrate is given to the current GOP or the current macroblock. how is calculated how to achieve bitrate x over the whole movie. how is the variation of the bitrate explained (please don't say it's because of the complexity/movement/detail of the current scenes).
How can it be achieved that a movie with length x is exactly 2000 MB in size? Just at which point the transformed/quantized video data is compressed by factor X to get it to 2000 MB in the end??

Greetings,
Malcolm

Amnon82
16th June 2004, 17:14
To dig deep visit my page (http://www.brckomania.net/CYBERNETSOFTWARE/htm/mpeg2faq.htm)

Kika
16th June 2004, 17:24
@Malcolm

All Encoders do have their special tricks. So it's impossible to give you a detailed answer.

A couple of things:
8x8 Pixels are called a Block, 2x2 Blocks are a Macroblock.
And yes, the Encoders are acting like you wrote. They are deviding the elements of a Block again by their own way, if the Bitrate does not match the given rate.
But that's not the only mechanism. A second thing is the Motion Search precision and the lenght and number of Motion Vectors. Encoders also can decide to "drop" Macroblocks if they are similar enough to other Blocks in the same Frame or an other Frame in the same GOP (like: Hey, MB x/y is nearly the same than MB y/x, and Bitrate is running out, let's drop x/y and use y/x instead).

Sorry, but that's all i can say about that in english. :(

Amnon82
16th June 2004, 17:48
Hi KiKa,

I'm also from germany. If You have more things to tell, PM me in german and I'll translate it.

@ Malcolm;

KiKa is right. Each encoder do it his special way. This is why all encoder are different, so the results.
CCE is one of the big 3. Also the big movie studios use CCE for mastering. But I think, they use Multipass.

I hope also my page with the FAQs might help You. MPEG Myth (http://www.mpeg2.de/doc/mpeg2faq/faq_v38.htm#tag4)

All FAQs are here (http://www.brckomania.net/CYBERNETSOFTWARE/htm/mpeg2faq.htm)

Kika
17th June 2004, 08:45
@Amnon82

Thanks for the offer to translate. But after reading the Site you posted, i think, there's no other explanation needed. :cool:

Amnon82
17th June 2004, 11:28
Yes I know! Thats why I posted my page! :D