Poor quality for a poor computer

[Apexi]

Well my friend has a Asus EeeBox PC EB1501 that's old and i piece of crap if you ask me, but i've promise him to help him out with .mkv playback.

So how would the "worst" setup" look like for a old computer regarding to playback?
The computer i newly formated with a brand new copy of Win7 + all the new drivers.


I'm using MPC-HC as player + LAVfilters. I've tried EVR custom as Directshow video, but that did not work out, atlest for 1080p.
GPU-Z tells me that GPU usage stays around 60-70%, so i guess that the CPU is the bottleneck. If i use DXVA the GPU usage rush up to 99%


So is there any other way to "lower" the video quality? I told him to buy a new computer, but that was a long shoot

[El Heggunte]

Please define "did not work out"

Also, if the device is not "powerful enough", it's silly to expect smooth playback of Hi-Def video while running an antivirus and/or a useless service and/or a video encoder in the background.

[Baldrick]

Try also morr players. Potplayer,smplayer,vlc,etc.

[Apexi]

Please define "did not work out"

GPU-Z tells me that GPU usage stays around 60-70%, so i guess that the CPU is the bottleneck. If i use DXVA the GPU usage rush up to 99%

Also, if the device is not "powerful enough", it's silly to expect smooth playback of Hi-Def video while running an antivirus and/or a useless service and/or a video encoder in the background.

No AV is running. As i said before, it is a clean install of Win7.
The Box came out as a "1080" compatible computer, but i can't se that happen. So my question, is there any way to lower the quality to make that happen?

[jagabo]

First try using Divx as the h.264 decoder. It was the fastest last time I checked. You can use Handbrake to reduce the frame size and re-encode to make it easier for the old computer to play.

By the way, it looks like that's a 1.6 GHz dual core Atom CPU. Probably enough for 1080p playback. Maybe if you use low complexity settings and low bitrates.

[Apexi]

First try using Divx as the h.264 decoder. It was the fastest last time I checked. You can use Handbrake to reduce the frame size and re-encode to make it easier for the old computer to play.

By the way, it looks like that's a 1.6 GHz dual core Atom CPU. Probably enough for 1080p playback. Maybe if you use low complexity settings and low bitrates.

Thanks for the reply mate.
I have no idea how to setup that. Any explanation or how to is appreciated

EDIT: 1080p lags all the time. 720p lags once every 5sec. It's not the GPU usage, so i have no clue what's wrong.
I've done playback on older machine then this without any problems.

EDIT 2: No problems with the temps either.

[jagabo]

The GPU isn't doing much of anything when you aren't using DXVA. Atom CPUs are much weaker than "real" x86 CPUs. And there are many advanced features in h.264 encoding that can make it very difficult for wimpy CPUs. Make sure you don't use those when encoding.

[Apexi]

The GPU isn't doing much of anything when you aren't using DXVA. Atom CPUs are much weaker than "real" x86 CPUs. And there are many advanced features in h.264 encoding that can make it very difficult for wimpy CPUs. Make sure you don't use those when encoding.

Yes i know, but as i typed in my first post.
Without DXVA the GPU usage stays at 60-70% "1080p" and around 30% "720p"
If i enable DXVA the GPU rush to 99% and gives my massive lags.

[jagabo]

How much CPU usage are you seeing?

[Apexi]

How much CPU usage are you seeing?

Give 1 min

EDIT: Not much. Pending between 40-70%

[hello_hello]

I still don't know why.... I even asked about it in the MPC-HC thread over at doom9 with no result..... but I had the occasional stuttering problem playing video using this PC (XP, E6750 dual core, 8600GT video card), and it'd stutter really badly when srt subtitles were enabled, and for 1080p video the audio sync would generally be way out..... but believe it or not I stopped it from happening by (either) disabling over-clocking, or by manually setting the PCI Express frequency in the BIOS to 99MHz (by default it's set to "auto").

What I did notice during the process of tearing my hair out, was a huge difference between DXVA (for which I use ffdshow) and Nvidia CUVID in respect to CPU usage. Even for 1080p though, CPU usage never got close to 100%, but playback stuttered badly. Back then, CPU usage was probably averaging 25% for DXVA and around 70% for Nvidia CUVID. Once I found the fix, CPU usage dropped to the same level for Nvidia CUVID as it was for DXVA.

I just ran the first 1080p video I found and looked at CPU usage. It was averaging around 7%. According to GPU-Z, GPU usage was sitting at roughly 45%.

Anyway... that's my little story which may not help you, but while I didn't do much further testing of media players at the time, I'm fairly sure MPC-BE didn't have the same issue MPC-HC did, which would lead me to suggest either trying it instead, or try going back to a pre-LAV Filters version of MPC-HC to see what happens. There's something a little odd going on (maybe it's just a hardware issue in my case) but I'll probably go to my grave never learning the "why" for this one. Oddly enough though my second PC, which has exactly the same motherboard and video card as this one, has never suffered from any CPU usage/stuttering problem even though I use the same player/decoder/renderer etc. Computers....

PS. The reason I discovered the above was because of an issue with SRT subtitles causing stuttering and high CPU usage (in some cases). 720p video wasn't a problem for me even with SRT subtitles and as I don't use them much I didn't have any playback problems until I needed subtitles with a 1080p video. You haven't mentioned subtitles yourself so I assume they're not a factor, but just in case..... unchecking "allow animation when buffering" under Subtitles in MPC-HC's options seems to fix that one.
Oh... and the "srt subtitles causing stuttering" problem seems to only happen while the subtitles are being displayed. The subtitles can be enabled but while there's none being displayed playback should be "normal"

[El Heggunte]

IF a better computer is not an option to your friend, then I second Baldrick's suggestion, give a try to alternative software.
FWIW, Mplayer, being a command-line application, is faster than the GUI-based players.

[Hoser Rob]

Actually I'd suggest SMplayer (which is a GUI front end for mplayer) for playback on less powerful machines. It has very, very useful settings for slower computers.

The main one is the cache size for local files. Set this to 8192Kb. This makes a huge difference. Every video player should have this option but they usually don't. Even VLC dropped it for reasons I can't fathom.

Also allow frame drop if it still has problems, and possibly hard frame drop.

Smplayer and VLC don't need silly 3rd party codecs that can mess up windows registry. I don't quite know why the first impulse of noobs is to start installing codec packs at the first sign of trouble. They don't make that much of a difference in speed, definitely, and they can cause system conflicts.

[_Al_]

What is faster?

MPC-HC + ffdshow + Haali Media Spliter
or
MPC-HC + LAVfilters

I only use first setup only.

[hello_hello]

Actually I'd suggest SMplayer (which is a GUI front end for mplayer) for playback on less powerful machines. It has very, very useful settings for slower computers.

Pity it doesn't yet (to the best of my knowledge) support DXVA decoding, which would be handy when using a PC with limited CPU power if it has a video card capable of doing the decoding.

The main one is the cache size for local files. Set this to 8192Kb. This makes a huge difference. Every video player should have this option but they usually don't. Even VLC dropped it for reasons I can't fathom.

I'd be very keen to understand how it makes such a huge difference.

I'd be surprised if they all didn't cache. Maybe they don't always assume the user knows best. MPC-BE has options to specify how much to queue in memory before playback starts and the maximum amount to queue. File cache size is separate and 64KB by default. Would the file cache setting be something like the amount of data the player loads from the drive at a time, or maybe the amount of data the hard drive has to provide before it's then added to the queue in memory, rather than it being some sort of hard drive/playback buffer?

I'm confident MPC-HC works in a similar manner to MPC-BE even though it doesn't seem to give the user a way to change any cache settings, although the LAV splitter lets you specify the maximum queue memory which is 256MB by default (same default for MPC-BE). I've unplugged an external drive from which MPC-HC was playing video a few times and not realised the error of my ways for several minutes because that's how long it took before MPC-HC ran out of queued video in memory and stopped playing. Given the amount of queued video memory I'm struggling to understand how increasing the file cache makes a difference to playback quality at all.

I hunted around briefly in Potplayer's options and found a file cache setting which once again was 64KB by default.

VLC's cache settings specify a duration rather than size. The default for the file cache is 300ms. And yes.....
every time I've read a post where you've complained about VLC dropping the file cache option, I've replied and pointed out they didn't, it was moved to a different location in VLC's preferences. I think last time I even supplied a screenshot to show the various cache settings do still exist.

Out of curiosity I ran a 1080p video and checked MPC-HC's display stats. Admittedly I don't fully understand the buffering numbers yet and they probably have nothing to do with file cache but I might investigate that some time soon unless someone can educate me as I'm curious now.
A 1080p video using CPU decoding.

Smplayer and VLC don't need silly 3rd party codecs that can mess up windows registry.

Why is it you don't quite grasp the distinction between "needing to" and "being able to". There's a difference between not being able to play something without 3rd party codecs and being able to play something without third party codecs while the option to use them remains available. I know which I'd prefer, although I'm not aware of any players these days which "need" third party codecs in order to play all the common formats.

I don't quite know why the first impulse of noobs is to start installing codec packs at the first sign of trouble. They don't make that much of a difference in speed, definitely, and they can cause system conflicts.

Just to clarify.... are noobs using players such as SMPlayer and VLC exempted from the "installing codec packs at the first sign of trouble" generalisation, or could they be a first step in the evolution of a new super-noob, installing third party codec packs in an attempt to fix a problem with a player which can't use them, while blaming the codec pack installation for retrospectively causing the problems they'd hoped installing it would fix?