The Big Question

[InThaHouse]

Since Xvid got alot of bugs , still under development and isn't

offical out so give me ur vote about this Quesiton

Which of the following player is the best in Quality :

Cninpak Codec, DivX MEPG-4 fast-motion, DivX MEPG-4 low-motion

DivX 4.12, Huffyuv v2.11, IndoVideo 5.10, Inet 4:2:0 VidoeV2.50

Intel Indeo(R) Video R3.2, Intel Indeo Video 4.5, Intel Yuv Code

Microsoft H.261 Vidoe codec, Microsoft H.263 Vidoe codec

Microsoft MPEG-4 Video Codec , Microsoft MPEG-4 Video Codec V1

Microsoft MPEG-4 Video Codec V2 , Microsoft RLE

Microsoft Video 1

[Franko30]

Well, I can't find any XVID bugs at the moment - currently encoding 5 more movies with it. :D



The answer to your question is:


There is no "best codec" (I guess that's what you meant by asking for the "best player").

It all depends on what you want to do and what you like when actually watching it.

The listing you give looks like what you get when opening the compression dialogue in VirtualDub, so I think you want s.th. like "Hey, what do I use for which purpose".

And since you posted in Doom9's forum I'd say you are thinking about video compression for backing up your DVDs or recording from analogue source to harddisc (recording TV shows) and the burning them on CD.

For this purpose I recommend DivX 3.11, DivX 4.12 or XVID - depending on which codec "look and feel" you like best and how much time you want to invest in achieving good results.

Again:

First, find out what you want to do and how to do it.
Then, after reading all the Guides on doom9.org, reading all the fucking manuals and trying out some codecs and settings for yourself you should come back to the forum and ask more specific questions.

If you don't want to do an MPEG4 quality comparison yourself, I recommend Doom9's "MPEG4 shootout" summary.

Frank

[Teegedeck]

Clear answer: What you are looking for is DivX4 (get it at www.divx.com, they also got a newbie-forum) as a codec and Vidomi as an encoder (get that one, too, at www.vidomi.com). You need both, in case, you're wondering. Install DivX4 and Vidomi, start up Vidomi and there you go!

(The codecs in your listing really couldn't be compared - they are designed for different purposes; some were VERY old and outdated, also.)

[-h]

Hi.

Since Xvid got alot of bugs

If you give us a bug report we can fix it.

You do seem.. new to video compression :) Here are my opinions anyway.

- Cinepak
Woeful quality, very outdated. Only useful for extremely slow computers (486, etc.). Doesn't even appear to use a transform, but leaves images in the spatial domain.

- DivX fast/slow motion
Reasonably fast. Illegal hack of 2 MPEG4V3 codec builds from Microsoft. Should never be used on their own, but always with the assistance of Nandub. Better quality than DivX 4.12.

- DivX 4.12
Getting close to MPEG4 compliance, still has a ways to go in terms of profiles supported. It's the most widely used MPEG4 video codec, and the fastest too if you have a P4. High video quality with default parameters.

- Huffyuv v2.11
Perhaps the best (useful?) lossless video codec around at the moment. Compression ratio could be better (lossless MPEG4 variant would give great results).

- Indeo
"Intel" Indeo codecs are now owned by Ligos. Indeo 5 was half decent for its time, but now (like the other Indeo codecs) is only of interest on very low-spec PCs. Quality is far below MPEG4.

- Microsoft H.261/H.263
Can't be used outside of NetMeeting.

-h

[Suman]

-h you've set a fine example about forum manners. Excellent reply :)

[ChristianHJW]

excellent work -h ... wonna consider adding this to any Q&A here ?

[movmasty]

a second opinion....
- Cinepak
lives in the past like compression(big size)but in the future like speed, very slow on p800, cant even wonder how it would work on a 486...

- DivX fast/slow motion
the slow needs an encoder able to set it(nandub),the fast is setted near to mpg vcd quality,and can be used alone for medium quality.
i cant understand why with all those "patched" divx around, no one made a simple divx with quantizers settings to use in all the video editors.

- DivX 4.12
still some work to do........

-Huffyuv v2.11
buggy, messed up some of my movies encoded with it,and output is totally fucked up under certain circumstances.
Compression ratio cant be better as losseless codec,and i cant even imagine what a "losseless mpg4" could be.
pic video mjpeg got also a losseless codec in it,about same compression as huffy, not buggy

-indeo codecs
only the 5 and the yuv("raw") can be considered,
the 5 goes as far as can go a "light" compression codec,is better than divx to encode "slide show movies",low fps and frames independent between them.
setted at 100% quality, kf every 1 frame, and checking quick compress, is like a mjpg codec,fast,free, and easy to find.

yuv is still a valid "losseless" codec, in the way that yuv intends losseles.
it gives less size than huffy and pic losseless mjpeg codecs(picvideo 45% of rgb,huffy 38% but buggy, indeo yuv 35%).
its is yuv9, then compresses chrominace heavyer than 4:2:0(yuv12).
the way it works is giving a chroma information only every 16 pixels(4x4),instead that every 4(2x2),but,except that for computer graphics,usually you cant note any loss.

-Microsoft H.261/H.263
i have some movie encoded with them, not very bad.....

-XviD
hey! seems that someone is doing a very good work there!!!!!

[Koepi]

MOVMASTY!

PRETTY PLEASE!

WHERE DO YOU GET THIS STUFF FROM?
DivX fast motion is set to VCD quality?!?!?!?

Well, first I nearly got a heart attack by so much dumbness.
But now I only have to laugh....

HARHARHAR!

[-h]

lives in the past like compression(big size)but in the future like speed, very slow on p800, cant even wonder how it would work on a 486...

Hmm you must be using a large resolution? Cinepak was a wonder for its time. Yes slow to encode, but actually playable on low-spec machines (well, postage stamp sized anyway).

buggy, messed up some of my movies encoded with it,and output is totally fucked up under certain circumstances.

Haven't experienced this...

Compression ratio cant be better as losseless codec,and i cant even imagine what a "losseless mpg4" could be.

Huffyuv (and pic lossless) don't look at previous frames to perform motion estimation - this decreases frame sizes significantly. It would not be difficult to fork XviD into a non-MPEG4-compliant lossless codec, which would outperform both hyuv and pic.

indeo codecs

Indeo is useful for another thing - static input which changes very little (security camera input, for example).

yuv is still a valid "losseless" codec, in the way that yuv intends losseles.

Huffyuv files should really be in the YUV colorspace to make the comparison fair..

-h

[Ookami]

>a second opinion....

a third opinion to your second one ;-) .

> - Cinepak
lives in the past like compression(big size)but in the future like speed, very slow on p800, cant even wonder how it would work on a 486...

Hihi... With speed in the future, you mean encoding speed, right?

> - DivX fast/slow motion
the slow needs an encoder able to set it(nandub),the fast is setted to mpg vcd quality,and can be used alone for medium quality.
i cant understand why with all those "patched" divx around, no one made a simple divx with quantizers settings to use in all the video editors.

? I disagree on all points. You can use Divx ;-) (yes, this is right spelling, no DivX, Divx...) very well without Nandub. Nandub is a great tool and SBC is useful, but it's certainly not inevitable. It all depends on your needs (and if you set a high bitrate you really don't need Nandub).

> - DivX 4.12
still some work to do........

There is always some work to do. This doesn't say anything.

> -Huffyuv v2.11
buggy, messed up some of my movies encoded with it,and output is totally fucked up under certain circumstances.
Compression ratio cant be better as losseless codec,and i cant even imagine what a "losseless mpg4" could be.
pic video mjpeg got also a losseless codec in it,about same compression as huffy, not buggy

Buggy? Some bugs are fixed (fixed, take a look in the developers forum). Output? This codec is not meant for playback. PIC video can be lossless? MJPEG can be lossless, am I missing something?
Please, explain...

> -indeo codecs
only the 5 and the yuv("raw") can be considered,
the 5 goes as far as can go a "light" compression codec,is better than divx to encode "slide show movies",low fps and frames independent between them.
setted at 100% quality, kf every 1 frame, and checking quick compress, is like a mjpg codec,fast,free, and easy to find.

Yep, they are often underestimated and its free :-) .

> -XviD
hey! seems that someone is doing a very good work there!!!!!

Agree.

Thank you for your input.

Cheers,

Ookami.

[movmasty]

> - Cinepak
encoding,of course, we talk about encoding here
(@ -h, yes, mpg playback takes more resources than cinepack, but regard this(use on 486) the contemporary indeo codec(the 3.1/3.2)is better than cinepack, also for the lower bitrate used)

> - DivX fast/slow motion
.....to use low motion at reasonable bitrate.......

>- DivX 4.12
still some work to do........to reach the divx3.11....and more to go beyond it

>-Huffyuv v2.11
"output" is the video encoded in huffyuv to use in another editor,the intermediate file,when you need it.
many of the clips that i encoded with huffy came out with a noticeable number of bad frames,and for the totally fucked "output" see the attachment, part of a clip encoded in huffyuv with ulead mediastudio.
that only happens when you dont apply any filter but just change speed and/or framerate,and use for output the same codec that movie was encoded with(huffy in this case).
then the editor goes similar to vdub direct copy,and this is the result.... (see attachment below)
>>>PIC video can be lossless? MJPEG can be lossless.....
pic video mjpeg comes with 3 codecs, 1)the motionjpeg, 2)a wavelett codec, 3)a codec called "lossless mjpg" (PVLJPG),if losseless cant be really jpg thought,
it gives a compression like the faster RGB of huffy,and the result is always good

(@ -h, i understand what you mean: dont compress frames in themselves, but use only the interframe "compression".
well,this cant be done as losseless, since the interframe compression is always lossy)

[movmasty]

hey -h, could i ask you how you became a "Kilted Yaksman" :confused:

i dont like to be a "gray" member... :(

[-h]

(@ -h, i understand what you mean: dont compress frames in themselves, but use only the interframe "compression".
well,this cant be done as losseless, since the interframe compression is always lossy)

Inter-frame compression isn't innately lossy, it just depends on the implementation. If you're just doing a memcpy() from one frame to another, it's perfectly lossless :)

I'll look into a new lossless codec when I quit my job (shouldn't be long now, the travel is killing me).

I set my status in the "Edit Profile" screen.

-h

[movmasty]

ok, good luck for your "losseless with kf" codec
we all need a more compressed lless codec
but.....

if u copy block between frames when they are 100% equal,you will have very few to copy,also for random noise,
and this is always a cut&paste
if you set a threshold....it is not lless....
in fact no one was able to do that before.

(i dont see any status field in my profile....)

[-h]

if u copy block between frames when they are 100% equal,you will have very few to copy,also for random noise,
and this is always a cut&paste
if you set a threshold....it is not lless....
in fact no one was able to do that before.

That's why you copy close, not exact, matches (as they rarely exist), then store "error data" for every pixel in the frame. If, say, I found a similar block in the last frame, and after copying it across every pixel only differed from the "correct" values by 0 or 1 or 2, storing those 0's and 1's and 2's is going to use far less space than storing the raw frame data.

(i dont see any status field in my profile....)

I guess it's a moderator thing then? I don't know much about the forum :)

-h

[Teegedeck]

It IS a moderator-thing! But some of us are just too lazy... :)

[Koepi]

I could change that myself, so it's no moderator thing...
but wait...

somehow I _AM_ a mod...

Well, forget it ;)

Regards,
Koepi

[movmasty]

ill wait to see if after 100 posts the status field rise in my profile

then i will ask some supModerator for it....

[Emp3r0r]

Ok, here is a "tack on" for this wonderful thread. Which codec is best for streaming? Could it be one that is easy to edit, yet streams like ogg?

[wing1]

-> -h

"It would not be difficult to fork XviD into a non-MPEG4-compliant lossless codec, which would outperform both hyuv and pic."

Is this possible? will it happen? would love to see that happen in the very near future. Currently, I am using mpeg4v3 vki (1800kbps) as my primary capture codec ( I have used huffyuy and mjpeg before and I don't care about the file size they produced ). Based on the performance of xvid, i'd like to see it as my replacement for MS Mpeg4v3 :)

[-h]

@Emp3r0r - If you're looking to stream, I'd still stick with Real or WMV - they've been engineered for this purpose and manage it half-decently. There isn't currently a good streaming codec with the editing capabilities you're after, that I know of anyway :)

Is this possible? will it happen? would love to see that happen in the very near future.

It will happen. Not in the near future however :)

I plan on using PNG as the lossless compressor:

- Compress "I-frame" with PNG
- Compress "P-frame" using XviD's existing motion estimation
- Separate "P-frame"'s intra and inter blocks into separate streams, compress each with PNG separately.

I'd try to merge in B-frames once they show up in XviD too. If PNG turns out to be too slow/crap, I'll mock up a fast linear predictor, or just use huffyuv's existing code.

You can already use XviD instead of MSMPEG if you want, it's a pretty nice capturing codec. I'll be adding interlaced frame support to XviD in a week or so, which will perform much better in this situation.

-h

[movmasty]

what are the characteristics of a streaming format?

why divx cant be considered a good streaming format??

[Koepi]

*SIGH*

[wing1]

Yes!!! interlace support (woohooo!)

I decide to bump the bitrate up in xvid to see what will happen for my capture, and I like what I see. The bump does not significant raise my file size either; I get approximately 105-130K/s data rate, which translates to 2hrs / 700Mb CD!

xvid settings :
1-pass CBR 2860kbps, H263, 5 motion, min q = 3, max q = 5, and
the rest is set to default.
Bitrate max out at 3000 and major video noise can be observed. If bitrate is set between 2800-2880 video is sharp and it exhibits very little macro block noise during fast action scene.

capture settings :
frame size = 464x480 @ 29.97fps ( 1/2 reduction in vertical + crop ), resize using precise bicubic 0.75 to 448x304 (like to make it 1.45 exact but 1.46Ghz CPU won't let me :) ).

I am looking forward to the next release ( drooling ).

Once again, thank you guys for an excellent codec.