Orchid XP v8 wrote:
> Question: Does anybody still make MPEG acceleration cards for the PC any 
> more?

They're usually built into either the video output card or the capture 
card. I imagine some people make stand-alone MPEG cards, but it's not 
the sort of thing you'll see on the shelf at Circuit City. Getting a TV 
tuner card with a built-in MPEG compressor isn't difficult, tho.

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

Post a reply to this message

Orchid XP v8 wrote:

> I should probably just start over with a better test video!

OK, so I started again, this time with a custom-rendered Electric Sheep 
video. In other words, it features intricate fractal detail, vibrant 
colours, full-frame complex swirling motion, and high-quality motion blur.

S026m-Anim2.avi

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

Uncompressed:         498 MB

Huffyuv: 0:08 encode, 105 MB
FFV1:    0:37 encode, 176 MB

MPEG1:   0:16 encode, 3.40 MB
Theora:  0:28 encode, 4.16 MB
DivX 3:  0:08 encode, 1.96 MB
XviD:    0:12 encode, 2.11 MB
H.264:   0:38 encode, 4.73 MB

Well that definitely says... something. (In particular, FFV1 now does 
drastically worse than Huffyuv, despite being much slower to encode and 
too slow for realtime codecing.) But how good does the lossy video look?

All of the video was encoding at "900 Kbit/sec average bitrate". And 
yet, they differ fairly widely in file size. Perhaps unsurprisingly 
then, we find the following:

- MPEG1 looks *horrible*! I mean, *really* horrible. (Recall that with 
my previous test, 900 Kbit MPEG1 actually looked not much different from 
the uncompressed original. Clearly I picked a test case that was far too 
easy!)

- DivX 3 looks even worse than MPEG1. And not by a small margin.

- XviD looks better than MPEG1.

- Theora looks quite a bit better than XviD.

- H.264 looks really very good indeed. Considering the file is over 100x 
smaller than the original, there is surprisingly little distortion.

So we have roughly

   DivX < MPEG1 < XviD < Theora < H.264

This follows the file sizes almost exactly, except for MPEG1.

I had assumed that given the same average bitrate, all the codecs would 
produce a file roughly the same size. This isn't really the case here. I 
guess now I'll have to spend a few hours trying to get each codec to 
produce a file of roughly the same size so I can compare those...

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

Post a reply to this message

Orchid XP v8 wrote:
> - DivX 3 looks even worse than MPEG1. And not by a small margin.

I may be wrong, but I think DivX3 is quite an old version...

Post a reply to this message

Orchid XP v8 wrote:
> - DivX 3 looks even worse than MPEG1. And not by a small margin.

Current DivX version is 6.8

Wikipedia on Version 3:
DivX ;-) 3.11 Alpha and later 3.xx versions refers to a hacked version of the
Microsoft MPEG-4 Version 3 (MPEG-4v3, Microsoft internal numbering scheme,
unrelated to MPEG-4 parts) video codec (which was actually not MPEG-4

Gej) in Montpellier. The Microsoft codec, which originally required that the
compressed output be put in an ASF file, was altered to allow other containers
such as Audio Video Interleave (AVI). Rota hacked the Microsoft codec because
newer versions of the Windows Media Player wouldn't play his video portfolio

Rota and German hacker Max Morice decided to reverse engineer the codec, which
"took about a week".[5]

So DivX3 is not what you should use if you want a relaistic picture of current
codecs

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I guess now I'll have to spend a few hours trying to get each codec to 
> produce a file of roughly the same size so I can compare those...

  Remember to use multipass encoding for those codecs which support it.
It will generally produce better results (although it might not with such
a short video; doesn't hurt to try, though).

  Usually it's done by selecing "multipass, 1st pass" or whatever option,
encoding, then the "multipass, 2nd pass" and then encoding again. This will
actually produce a viewable video.

  Some codecs support even more passes, but usually the 3rd and subsequent
passes have only very minimal effect on the quality.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Remember to use multipass encoding for those codecs which support it.

And in case it wasn't obvious by now, multipass encoding is generally 
what helps a lot with making B-frames work well. :-)

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

Post a reply to this message

Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> I guess now I'll have to spend a few hours trying to get each codec to 
>> produce a file of roughly the same size so I can compare those...
> 
>   Remember to use multipass encoding for those codecs which support it.
> It will generally produce better results (although it might not with such
> a short video; doesn't hurt to try, though).

Yeah, I could certainly do that. I just haven't quite figured out how yet...

>   Usually it's done by selecing "multipass, 1st pass" or whatever option,
> encoding, then the "multipass, 2nd pass" and then encoding again. This will
> actually produce a viewable video.

I see the options. So, what, the first pass produces a video file that 
just isn't viewable, or...?

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

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Remember to use multipass encoding for those codecs which support it.

> And in case it wasn't obvious by now, multipass encoding is generally 
> what helps a lot with making B-frames work well. :-)

  It also helps the encoding process to distribute the bitrate throughout
the video. When it has processed the input video once it will have a much
better idea which parts should use more of the bitrate and which parts need
less. This way it avoids much better the phenomenon where sudden complex
video content looks like crap for several seconds before it stabilishes.
When the encoding process has seen these difficult parts, it can allocate
more of the bitrate to those parts in advance, and not waste it on parts
which don't need it so much.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >   Usually it's done by selecing "multipass, 1st pass" or whatever option,
> > encoding, then the "multipass, 2nd pass" and then encoding again. This will
> > actually produce a viewable video.

> I see the options. So, what, the first pass produces a video file that 
> just isn't viewable, or...?

  I suppose it depends on the codec, but most codecs only produce data for
the secondary pass.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> I see the options. So, what, the first pass produces a video file that
> just isn't viewable, or...?
> 

I think ffmpeg produces a viewable video file, along with a giant file
containing statistics. But I doubt DirectShow- or VFW-based codecs can do
that... (VirtualDub gives them chunks of data, not a path to a file, so how
would they know where to save the stats?)

Post a reply to this message