So what;s the difference between the codecs ??

[scottp]

Hope this doesnt sound too dumb, but what is the difference between all of the codecs ??

From what I understand, essentially, they all perform a number of algorighmic cals (discreet cosine transform, motion esitmation, and many more)... So what are current developers doing to make them perform better ?? Are new calcs being run, or more refined calcs, or are totally new schemes and approaches being tested and implementd ??

Thanks a ton...

ScottP

[-h]

Hope this doesnt sound too dumb, but what is the difference between all of the codecs ??

Not to me, I still struggle with the theory :)

The MPEG4 codecs (DivX 3.11, DivX 4, and XviD) all have a very similar encoding steps:

Encode I-frame:

- Perform a forward DCT on an 8x8 block of pixel data
- Quantize DCT coefficients
- De-quantize and iDCT coefficients, to use in motion estimation during the next frame
- Decide whether to use AC/DC coefficient prediction
- Decide which zig-zag scanning direction to use for the resulting coefficients

Encode P-frame:

- Perform motion estimation:

-- Decide on how we will find similarities between the current 16x16 pixel block, and the previous frame.
-- Create "possible" search locations, which the codec thinks it will likely find a good match (i.e. no movement, the same movement as blocks around it, etc.)
-- Decide whether to use a single motion vector for a 16x16 block (fast), or four motion vectors, one for each 8x8 block in the 16x16 block (slow)
-- Decide whether to use the current match (which has large motion vector information), or a "worse" match (which has more compressible motion vector information)

- Decide whether to encode 16x16 block of pixels as motion compensated, or on its own (just like an I-frame).
- Perform a forward DCT either on the pixel data from the current frame, or the difference between the current frame and the previous (as per the motion vector)

That is a large abstraction, and I've skipped/simplified/reordered some steps, but as you can see there's already a fair bit going on.

Now, DivX 3.11 is dead. There will be no more optimization - all we can do is wildly tweak settings and hope they pay off. DivX 4 is doing who knows what - there have been no specific announcements as to what is being worked on (apart from "better motion estimation").

The areas being looked at in XviD that will bring about the biggest bitrate reductions are:

- B-frames (discussed elsewhere) - significant reduction in bitrate
- Improved motion estimation:
-- Better choice between an inter-block (motion compensated from previous image) and intra-block (coded on its own, without referring the previous frame) - significant reduction in bitrate for high-action scenes
-- Method of handling scene fades / superimpositions - Should reduce the huge spiking in frame sizes currently seen in fades.
-- alternate methods of comparing current frame to previous, apart from standard SAD method.
- Interlaced frame support - reduces interlaced files by around 6% in my testing, should reduce by more if motion estimation is tweaked for interlaced content
- Better "psychovisual" modelling - lumi masking is an example of more heavily compressing areas which aren't obvious to the human eye - motion masking may be next
- Quarter-pel motion estimation was looked into but ditched

But everything takes time.

-h

[Teegedeck]

-h, you've really written the manual on codecs on this board! :)

[scottp]

h-

Thanks a ton for the info... I am really trying to absorb as much as I can...

Got another question...

Of the processes you mentioned, and possibly others you havent, have any of them been discarded due to lack of processing power ??

I mean, are there better compression techniques available for higher powered processors ??

Thanks again,

ScottP

[scottp]

h-

Thanks a ton for the info... I am really trying to absorb as much as I can...

Got another question...

Of the processes you mentioned, and possibly others you havent, have any of them been discarded due to lack of processing power ??

I mean, are there better compression techniques available for higher powered processors ??

Thanks again,

ScottP

[-h]

Of the processes you mentioned, and possibly others you havent, have any of them been discarded due to lack of processing power ??

Quarter pel interpolation "theoretically" can reduce bitrates by around 10%, but it slowed down suxen_drol's machine by 20 times. That is, from 5 fps to 0.25 fps. That, and the files actually got bigger.

A brute-force intra/inter decision would lower the bitrate on scenes where movement is occuring, but this will halve encoding speed regardless of CPU type.

A brute-force motion estimation phase will lower bitrates by around 10%, but will slow encoding speed by about 10-fold (almost as bad as quarter-pel performance).

That's about all that's been avoided for performance reasons.. though they might pop up some time in the future for masochists.

-h

[scottp]

Thanks -h,

Just to lyk what we are doing, we are developing a video capture device that runs on a 72bit, 792 bit bus, 2.4 bops video processor...

It is currently being developed using h263+, but we will be adding many other functions as we further our developments...

And as you can see, the power of the processor will allow for very high end calcs to be run in real time to significantly improve video quality...

Thanks again,

Scott