How fast is Linux in encoding???

[Razorblade2000]

Faster than Windows???

(Using Xvid)

[Razorblade2000]

HELLO??? GUYS???
:mad: :mad: :mad: :mad: :angry: :angry:

[cofferscuffs]

erm... (im not 100% sure) but you can't enocde XviD in linux unless you emulate windows.. which really defeats the point of switching to linux to encode in XviD.

BTW, just because no-one answered your post it doesnt mean you have to get pre-menstral tension ok?

[Antti]

You can encode with Xvid on Linux using mencoder (www.mplayerhq.hu).
How fast is it? Well, Xvid is Xvid. Encoding speed doesn't depend on the OS you are using. (in principle)

[Razorblade2000]

"you can't enocde XviD in linux unless you emulate windows"
Why sould I emulate Windows??? Can't I just compile the xvid source in linux???

"just because no-one answered your post it doesnt mean you have to get pre-menstral tension ok?"

I was just angry because a simple yes or no would have satisfied me! (BTW: I don't wanna explain more, I have a terrible headache... :D ;) )

"Xvid is Xvid"
Windows isn`t Linux... Other file-system, Linux won't use direct show(or will it?), Linux maybe support more CPU specific features like sse,mmx (does it?). Otherwise nobody would use it (TCP/IP is TCP/IP, computer is computer... it sure isn't!)

[Nic]

The speed will be a bit different because you'd probably have to compile it with GNU gcc

But in essence, there would be little speed difference...I hear "transcode" is one of the main linux programs people use.

Linux doesn't use directshow & doesn't use any more CPU instructions...(obviously)

-Nic

[Antti]

Windows Xvid doesn't use Directshow either for encoding. How is it possible Nic didn't know that?

;) ;) ;) ;)

Visual C++ optimizes a little better than GCC, usually. I wouldn't expect much difference anyway.

[Razorblade2000]

You needn't tell me how to encode under linux. I found a very good document here (http://www.bunkus.org/dvdripping4linux/single/index.htm)

Have you ever made experiences with the libavcodec???

libavcodec or short lavc is another Open Source MPEG4 compliant video codec which is superior in performance and quality to DivX 5 and even to XviD. This codec suppports b-frames*. It is part of the ffmpeg project.

Sounds VERY, VERY good!!!!!!!

[buba king]

Give us the url please, I dont feel like "googleing" today :P

edit1:
after looking around.. i got the idea that libavcodec is only a decoder, no?

[Diable]

Out of the box Linux is any faster than Windows when encoding but if you compiled the entire OS with the proper flags set for your CPU using a newer build of GCC it could be.

[Razorblade2000]

http://www.bunkus.org/dvdripping4linux/single/index.htm

(you could have klicked on the "here"...)

I think CODEC means COmpressor-DECompressor... therefore...

[Razorblade2000]

Originally posted by Diable
Out of the box Linux is any faster than Windows when encoding but if you compiled the entire OS with the proper flags set for your CPU using a newer build of GCC it could be.

Do you mean ...isn't any faster???

[c0p0n]

on my box, I did some testing with a single video, with same parameters on linux and win.
on win the speed was about 17 fps, on linux (kernel 2.4.18, recompiled for my box) with all the necessary stuff compiled with gcc 2.95 it was about 19fps, using mencoder (no sound processing on both encodings)

[tiki4]

I guess one should do some real comparison between Windows and Linux DivX encoding. Sorry, but 17 to 19 fps isn't so much of a difference to me. Well I did some testing for myself with transcode and DivX 4 then and Windows was definitely faster with VirtualDub than Linux.

O.K., that doesn't mean anything. The problem is that a comparison done today is no longer valid tomorrow as tools like trancode and also XviD develop too fast to keep up to date all the time. Just an idea: How about noodleing the complete transcode linked to the XviD coded through the Intel compiler 6.0 which is available free for Linux. I tried with 5.0.1 some time ago, but landed on the nose. For the moment I don't feel like trying that again, as installing of the avifile library and all the other stuff you need for encoding is an endless task of at least one evening.

There is another point that I don't understand: Why do you think that the Linux kernel has something to do with encoding speed? I don't think that it comes to using the TCP/IP stack of the kernel for encoding, with one exception: When you use the cluster mode of transcode!

If someone feels like doing a comparison with different movies and codecs and so on, I'd appreciate it, but I think the Linux tools still have a long way to go to get near the easiness of the Windows tools (I like that GordianKnot).

tiki4

[Razorblade2000]

If you would take a 90 min movie and compress it:

With 17fps it would take 7941,1764705882352941176470588235 seconds
With 19fps it would take 7105,2631578947368421052631578947 seconds
So there is a difference of 835,913312693498452012383900929 seconds, which would be 13,931888544891640866873065015483 Minutes

:sly: :D :D :D :D :D :sly:

P.S. You missunderstood the thing about TCP/IP, I meant the protocal is the same, but most people would prefer it running on Linux...

[tiki4]

I didn't mean any offense!

Your calculations are of course right:)

I just wanted to point out, that the Linux kernel has nothing to do with the encoding speed IMHO. Of course you can improve your overall system performance by throwing out the unnessesary pieces of the kernel and compiling with the optimizations of your likings, but I guess that doesn't affect encoding too much (but: which Windows user doesn't dream of getting rid of all the unnecessary stuff you have to carry around with your Windows box...).

Also gcc 2.95.3 isn't the best compiler when it comes to getting fast code on modern CPU's. This one doesn't know anything about PII, PIII, P4 or Athlon (XP) processors. The optimization possibilities stop at the Pentium Pro. Gcc 3.1 is around as far as I know, but still most Linux software gets compiled with the older gcc.

Using the Intel compilers has given a huge speed improvement on some software in Windows (think of BeSweet's lame_enc.dll, or libVorbis.dll by John33), so the logical thing to do is use the same compiler under Linux. It's available with no support and for no charge on the Intel developers page. Unfortunately I've always run into problems when I tried to compile software written for gcc with that compiler.

And there's really a cluster mode available with transcode, so it uses the TCP/IP stack of Linux...

Happy encoding,

tiki4