OK, so my PC has spent the entire evening encoding and re-encoding the 
same AVI over and over again. And the results are in:

12-Flower3-v1-Part.avi

6,351 frames, 720x576 pixels, 24 bits/pixel, 25 frames/second.

Uncompressed:         7,901.797 MB,               14% CPU on playback.
FFDshow Huffyuv:        746.872 MB, 1:45 encode,  20% CPU on playback.
FFDshow FFV1:           547.746 MB, 5:09 encode, >50% CPU on playback 
(failed to play in realtime).
FFDshow MPEG1:           28.947 MB, 1:35 encode, Completely broken on 
playback.
FFDshow MPEG2:           28.947 MB, 1:35 encode, Playback refused.
FFDshow XviD:            28.782 MB, 1:39 encode,  13% CPU on playback.
FFDshow DivX:            28.952 MB, 1:45 encode,  13% CPU on playback.
FFDshow Theora:          28.298 MB, 2:19 encode,  16% CPU on playback.
FFDshow H.264:           29.061 MB, 3:50 encode,  21% CPU on playback.
FFDshow H.264 Lossless: 252.069 MB, 4:22 encode, Completely broken on 
playback.
TPMGEnc MPEG1 30Mbit:   148.213 MB, 1:47 encode,  17% CPU on playback.
TPMGEnc MPEG1 900Kbit:   27.168 MB, 1:43 encode,  17% CPU on playback.

As you can see, this conclusively proves... something.

Actually, you know what? My head hurts!

All of the ones that say "FFDshow" where encoded using Virtual Dub and 
the selected codec with all defaults. (Apparently that means 900 
Kbit/sec in one-pass average bitrate mode. I didn't even *look* at the 
defaults for the advanced settings...)

As far as lossless codecs go, only Huffyuv is actually usable. FFV1 
produces somewhat smaller files, but it's too slow for realtime 
playback. (As you can see, it locked up one core of my dual-core 
processor.) H.264 lossless was smaller still, but on playback the 
picture was spectacularly broken. Even in Virtual Dub, all the colours 
are mixed up and there are random lines everywhere and it basically 
looks like a bug in the codec. It is *not* lossless!

It also appears that putting an MPEG1/2 data stream into an AVI fail is 
a "bad" thing to do. Oh well!

As for the lossy codecs... well the numbers speak for themselves. 
Suffice it to say that most of the codecs are pretty similar in CPU 
requirements. (And obviously, at the same average bitrate, they produce 
similar files sizes!)

I am a little bit puzzled as to how some of the codecs manage to have 
slightly lower CPU load than completely uncompressed video. Obviously 
this is impossible - unless you're seriously telling me it takes 14% CPU 
to transfer 7.9 GB of data from HD to RAM?

In terms of visual quality, things are more complicated. Actually *all* 
of the codecs look quite good at 900 Kbit/sec with my test video - which 
probably means I've chosen a bad video for test purposes. The video in 
question is a POV-Ray animation. Most of the frame is jet-black. The 
parts that aren't black are all the same shade of green, varying in 
brightness only.

I should probably just start over with a better test video! Tomorrow 
I'll probably do that. (I think I have some fractal zooms kicking around 
somewhere. That should be a better test!)

 From what I've seen tonight, I can say this:
1. ALL of the codecs look pretty similar at 900 Kbit/sec.
2. MPEG1 does look very slightly worse.
3. Theora looks better than MPEG1, but slightly worse than everything else.
4. Beyond that, it's hard to say.

At lower bitrates, the ridiculously-named codec "H.264" seems to look 
slightly better than Xvid, which looks a bit better than DivX, which 
looks quite a bit better than MPEG1.

But anyway, the main result of tonights exploration is this: Last time I 
tried to use an MPEG-4 codec (I'm pretty sure it was DivX), the results 
were abomination. If you take a photo, save it as JPEG with quality=5, 
and then open it again, you'll get some idea of the level of quality I'm 
talking about. Large general features of the video were unrecognisible 
due to the extreme distortion. More importantly, no amount of increasing 
the quality settings had any effect on the garbage produced.

However, tonight I encoded a video with both DivX and XviD, and it came 
out looking... well, not that different, actually. They both look like 
codecs you could actually use, in the real world.

I am not, however, seeing the reputed "massive" difference in image 
quality. I think I need to pick a better video. A project for tomorrow, 
then.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> H.264 lossless was smaller still, but on playback the 
> picture was spectacularly broken. Even in Virtual Dub, all the colours 
> are mixed up and there are random lines everywhere and it basically 
> looks like a bug in the codec. It is *not* lossless!

In case anybody wanted to know what I mean by "spectacularly broken"...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Attachments:
Download 'broken1.png' (128 KB)

Preview of image 'broken1.png'

Orchid XP v8 <voi### [at] devnull> wrote:
> At lower bitrates, the ridiculously-named codec "H.264" seems to look 
> slightly better than Xvid, which looks a bit better than DivX, which 
> looks quite a bit better than MPEG1.

  They will look better at lower bitrates if you use multipass encoding.

> I am not, however, seeing the reputed "massive" difference in image 
> quality.

  Not in image quality. In quality/size ratio. Try lowering the bitrate
for all the codecs (trying to keep all the resulting file sizes about
the same) and until you start seeing significant differences.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> At lower bitrates, the ridiculously-named codec "H.264" seems to look 
>> slightly better than Xvid, which looks a bit better than DivX, which 
>> looks quite a bit better than MPEG1.
> 
>   They will look better at lower bitrates if you use multipass encoding.

OK, I'll try that. Like I said, I basically just ran the codecs with 
everything at default.

>> I am not, however, seeing the reputed "massive" difference in image 
>> quality.
> 
>   Not in image quality. In quality/size ratio. Try lowering the bitrate
> for all the codecs (trying to keep all the resulting file sizes about
> the same) and until you start seeing significant differences.

Well, all the files came out almost exactly the same size, as you can 
see. (And given the same average bitrate, you'd expect that.)

In the dying minutes of last night, I quickly tried using a different 
video, and got radically different results. I think my test video is 
just too easy to compress. (It's 80% black pixels, and 20% green pixels 
of varying brightness.) So I think I should rerun my experiment on a 
harder video.



The slightly weird thing is that if I play back, say, a DivX video in 
WMP, there are a small amount of visual artifacts. But if I take the 
DivX video and use Virtual Dub to decompress it to an uncompressed AVI 
and then play that in WMP, I get slightly different visual artifacts... WTF?

(Also, as I mentioned, this happens with "lossless" codecs. When I play, 
say, a Huffyuv video in WMP, it looks very slightly fuzzy, and the black 
becomes dark grey. But if I decompress it and play the decompressed 
version, it looks perfect again. Very odd...)

Post a reply to this message

Orchid XP v8 wrote:
> I am a little bit puzzled as to how some of the codecs manage to have
> slightly lower CPU load than completely uncompressed video. Obviously
> this is impossible - unless you're seriously telling me it takes 14% CPU
> to transfer 7.9 GB of data from HD to RAM?

	Those were the _lossy_ codecs.

-- 
The worst thing about censorship is .


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

Mueen Nawaz wrote:
> Orchid XP v8 wrote:
>> I am a little bit puzzled as to how some of the codecs manage to have
>> slightly lower CPU load than completely uncompressed video. Obviously
>> this is impossible - unless you're seriously telling me it takes 14% CPU
>> to transfer 7.9 GB of data from HD to RAM?
> 
> 	Those were the _lossy_ codecs.

...and?

In the uncompressed case, you take some data on disk and copy it to the 
framebuffer. In the compressed case, you take some data on disk, copy it 
to RAM, perform a vast amount of highly compute-intensive work on it, 
and *then* copy it to the framebuffer. Obviously the latter shouldn't 
use less CPU power than the former.

Post a reply to this message

Invisible wrote:
> In the uncompressed case, you take some data on disk and copy it to the 
> framebuffer. 

Not quite. You need to align the scanlines, perhaps reorder the R, G, 
and B, etc. You can't just blit the whole image to the screen like you 
could with an Amiga.  And I'd highly expect that it goes through RAM on 
the way between disk and screen.

> In the compressed case, you take some data on disk, copy it 
> to RAM, perform a vast amount of highly compute-intensive work on it, 
> and *then* copy it to the framebuffer. Obviously the latter shouldn't 
> use less CPU power than the former.

Depends on how expensive decompressing into the frame buffer is compared 
to moving the uncompressed data in and out of RAM.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Invisible wrote:
>> In the uncompressed case, you take some data on disk and copy it to 
>> the framebuffer. 
> 
> Not quite. You need to align the scanlines, perhaps reorder the R, G, 
> and B, etc. You can't just blit the whole image to the screen like you 
> could with an Amiga.  And I'd highly expect that it goes through RAM on 
> the way between disk and screen.

Well actually, WMP is playing it back at 200% original size, if you want 
to be picky about it.

Even so, moving data from A to B has to be faster than performing highly 
elaborate arithmetic over it. Unless DMA really does require *that much* 
CPU power.

> Depends on how expensive decompressing into the frame buffer is compared 
> to moving the uncompressed data in and out of RAM.

Bearing in mind that the video data in question is many, many times 
larger than any L1 or L2 cache on Earth...

Post a reply to this message

Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> In the uncompressed case, you take some data on disk and copy it to 
>>> the framebuffer. 
>>
>> Not quite. You need to align the scanlines, perhaps reorder the R, G, 
>> and B, etc. You can't just blit the whole image to the screen like you 
>> could with an Amiga.  And I'd highly expect that it goes through RAM 
>> on the way between disk and screen.
> 
> Well actually, WMP is playing it back at 200% original size, if you want 
> to be picky about it.
> 
> Even so, moving data from A to B has to be faster than performing highly 
> elaborate arithmetic over it. Unless DMA really does require *that much* 
> CPU power.
> 
>> Depends on how expensive decompressing into the frame buffer is 
>> compared to moving the uncompressed data in and out of RAM.
> 
> Bearing in mind that the video data in question is many, many times 
> larger than any L1 or L2 cache on Earth...

If the decompression CODEC is in any way hardware accelerated you're 
then talking about shoving a small stream down the video pipeline versus 
shoving an enormous stream down the video pipeline. Video memory is very 
fact, hardware MPEG processors are very fast at decoding MPEG, which 
means less CPU usage, less memory bottleneck. In opposition, reading the 
frames into memory, copying the (relatively large) frames to video 
memory, then instructing the video card to flip frame buffers ~30 times 
a second is much more CPU consuming. In the MPEG case, the system will 
feed blocks of stream data to the video card at a much more leisurely rate.

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:

> If the decompression CODEC is in any way hardware accelerated

...then it'll take much less CPU power. ;-)

Given that the fastest codecs are DivX and Xvid, I doubt that's the answer.

Question: Does anybody still make MPEG acceleration cards for the PC any 
more?

Question: Do such hardware acceleration schemes accelerate the whole 
pipeline? Or just key parts of it?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message