Which codec and player is best on slow machines?

[tempe]

Hi everyone!

Well, the subject says it all: Are there differences in codecs/players/filters/settings that make it easier to have a non-stuttering playback?

Bye,
tempe

[hakko504]

Player: Somewhat surprisingly, the best player is the media player classic. It is not using that much resources, but can be used on quite low-end machines.

Filter/settings: always playback in a window without resizing will be the least CPU consuming strategy. Of course, if the video size is 640xyyy you can always change screen size to 640x480 and then playback in full screen without resizing.

Codec: The codec that uses the least of the CPU for playback is the old MPEG-1 (VCD). If you have a CPU like P2-300 or less, I'd say that it's your only sensible choise. DivX/XviD isn't an option until you have a machine is a P3 or celeron-400. And for playback purposes, you will always gain performace from using b-frames, as the CPU will discard these first if it can't keep up with playback speed. On the other hand b-frames require much more CPU when you create the AVI, so it's something you'll have to consider too.

[jeremymacmull]

when u say slow machine !! what exactly do you mean post some specs

Personally i used mplayer classic or sasami2k with most of the post processing in the divX filter set to half way

ive got a p3 850 256 mb ram

However i successfully got divx's working for a long period of time on a p2 233 160 mb ram by changing screen res to 640 X 480 and then playing in a fresh install of win98 se (i had a dual boot system on for general use the other with nothing except divx watching stuff)

i used this for more than a year but only divx 3 was out then not 5 or xvid!!



JEREMY

[doaa]

On my old P2-266 with 64mb Ram I was able to watch all Divx files, using Divx5 postprocessing off, all ran smoothly just couldn't do stuff at same time:rolleyes:

[jeremymacmull]

have u tried using FFDSHOW its quite good especially for low processor usage ??

[OvERaCiD23]

ffdshow runs at about 30-35% CPU usage, and DivX runs about 40-60% CPU (varying b/c of post-processing settings). This is on a P3 900mhz w/ 256mb RAM. Quite a difference I would say.

[N_F]

I've been in the same situation and just like jeremymacmull says, lowering your desktop resolution to 640 or 800 (that is, if you are not already that low) can work wonders.

[Kamui-Dash]

MPC for sure :D

[BiaTch 5.0]

Originally posted by Kamui-Dash
MPC for sure :D
& While your @ it create DS filter for mpc which won’t show much gain anyway. Could B frames, GMC, Qpel effect decoding speed?

[Acaila]

Could B frames, GMC, Qpel effect decoding speed?Yes, when you use those options you need a LOT more cpu power than without them. I would highly recommend not using them if you have a slow computer (=anything under 1 GHz).

But on your Athlon 1700 it should be just fine.

[N_F]

@Acaila

That's what I thought, but hakko504 seems to be of a different opinion?

And for playback purposes, you will always gain performace from using b-frames, as the CPU will discard these first if it can't keep up with playback speed.

[hakko504]

Well, yes, you'll loose some performace when you enable b-frames, but let's say you have a computer that can playback a FILM (24fps) video at 20fps without b-frames. that video will stutter. Now turn on b-frames. b-frames require more processing, ~2x the processing for a p-frame. During a second there is 12 p-frames in a DivX5 FILM video. the difference between 20 and 12 can be used for decoding b-frames=> 8/2=4 b-frames/ second, resulting in a final video of 16fps that will not stutter! It simply discards the b-frames it can't handle while still presenting all p-frames on screen correctly together with some b-frames. Sure, some frames are lost, but you can keep up with the audio and it shouldn't be too noticeable that some frames are discarded. If you use p-frames only, anything less than full speeed will stutter, as audio has to stop for a moment and wait for the video to catch up.

[iwod]

Divx on a P233?? My god i think i will need to test this out....

So i assume most of the time by not resizing the play back would save you a lot of CPU resources........