![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![broken1.png](/povray.off-topic/attachment/%3C490f7196%40news.povray.org%3E/broken1.png?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Orchid XP v8 <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] nawaz org<<<<<<
anl
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |