You Know You Need A New Computer

dduardo

Technology Mentor
Staff Emeritus
1,874
2
You know you need a new computer when you get the following message:

************************************************
**** Your system is too SLOW to play this! ****
************************************************

For those curious, I was trying to play the 1080p trailer of "A Scanner Darkly."

You can find the video here:

http://movies.apple.com/movies/warner_independent/a_scanner_darkly/a_scanner_darkly-tlr2_h1080p.mov

!!!!!!Warning!!!!!!!!

This video is 156MB and you must have the proper decoder.

Linux users wanting to view the video must update to the lastest mplayer and ffmpeg and compile it with h264 support.
 
Last edited:

dav2008

Bubble-Pipe Squirrel
Gold Member
607
1
I tried to play it in my browser but it was too big :(

I'm going to download it and try to run it though Quicktime.
 

chroot

Staff Emeritus
Science Advisor
Gold Member
10,097
33
mplayer does this to me often. It's very un-optimized and uses ridiculous amounts of cpu time.

- Warren
 

ranger

King of all llamas
Gold Member
1,651
1
chroot said:
mplayer does this to me often. It's very un-optimized and uses ridiculous amounts of cpu time.

- Warren
Maybe you could try the linux version vlc media player. Personally I perfer mplayer though.

http://www.videolan.org/vlc/
 

graphic7

Gold Member
448
2
chroot said:
mplayer does this to me often. It's very un-optimized and uses ridiculous amounts of cpu time.

- Warren
Completely untrue. MPlayer is without a doubt the most optimized media player available (speaking from an OSS-perspective). One of the reasons MPlayer lacks multithreaded decoding is because MPlayer is heavily dependent on the CPU cache, which should tell you how optimized it is. Each time the threads switch context, the cache resets, and thus, the cache has to be filled again, wasting time.

As for MPlayer wasting ridiculous amounts of CPU time, can you be a bit more specific?
 

graphic7

Gold Member
448
2
dduardo said:
Linux users wanting to view the video must update to the lastest mplayer and ffmpeg and compile it with h264 support.
Keep in mind that the 'latest' MPlayer is not 1.0pre7try2 which is what most distributions/operating systems include in their ports or binary package repositories. x264/lavc h.264 support has improved quite a bit since the release of 1.0pre7try2, including numerous optimizations for x86/PPC.

We advise any user to use CVS sources over such snapshots, as 1.0pre7try2 is almost a year old, now. MPlayer is just not for Linux, either. :-)
 

dduardo

Technology Mentor
Staff Emeritus
1,874
2
I am using the CVS version. The last time I updated was the middle of this month. (04/14/06)
 

-Job-

Science Advisor
1,122
1
graphic7 said:
One of the reasons MPlayer lacks multithreaded decoding is because MPlayer is heavily dependent on the CPU cache, which should tell you how optimized it is. Each time the threads switch context, the cache resets, and thus, the cache has to be filled again, wasting time.
Does that offer any significant improvement over multithreading? A typical L1 cache has 16 KB for data and 16 KB for instructions. Even without multithreading just the execution of a single thread will require constantly bringing data & instructions into the L1 cache, and since the OS will constantly switch the process out anyway i don't see the point. From an OS perspective the more threads a process has, the more processor time it will have. If you have only a single thread your process will waste alot of time just waiting around because the OS only allows each process to use the processor for very small periods of time (there's always other threads wanting to use the processor) meanwhile it has to wait until it is granted processor time, and if the process happens to be paged out, then forget about it. A single thread process will probably spend a much larger amount of time waiting to use the processor than if it used multiple threads. Doesn't sound like the best strategy.
 
Last edited:

graphic7

Gold Member
448
2
-Job- said:
Does that offer any significant improvement over multithreading? A typical L1 cache has 16 KB for data and 16 KB for instructions. Even without multithreading just the execution of a single thread will require constantly bringing data & instructions into the L1 cache, and since the OS will constantly switch the process out anyway i don't see the point. From an OS perspective the more threads a process has, the more processor time it will have. If you have only a single thread your process will waste alot of time just waiting around because the OS only allows each process to use the processor for very small periods of time (there's always other threads wanting to use the processor) meanwhile it has to wait until it is granted processor time, and if the process happens to be paged out, then forget about it. A single thread process will probably spend a much larger amount of time waiting to use the processor than if it used multiple threads. Doesn't sound like the best strategy.
Simply put -- no, because the majority of the codecs in lavc will fit into the L2 cache nicely. As I said, everytime your mulitprocessor system switches threads (at least on x86), the cache is being flushed, and filled again when the context is switched.
 

-Job-

Science Advisor
1,122
1
Yes, but the OS will switch the process out anyway, it's not like it will stay in the processor for a longer time than if it used multiple threads. Multiple threads at least would offer the advantage of more efficient processor usage and less waiting around.
 

graphic7

Gold Member
448
2
-Job- said:
Yes, but the OS will switch the process out anyway, it's not like it will stay in the processor for a longer time than if it used multiple threads. Multiple threads at least would offer the advantage of more efficient processor usage and less waiting around.
No, it'll be the same situation, except the OS will be clearing out the cache for any processor that's scheduled to run a process during the run-time life of MPlayer.

MPlayer is also perfectly capable of issuing cache controller commands to control what's in the cache and what stays in the cache.
 
Last edited:

-Job-

Science Advisor
1,122
1
Here's what i'm thinking. Suppose 4 processes and MPlayer, with the same priority want to use the processor and that the OS uses a round-robin approach to scheduling. Each process is allocated t miliseconds of processor usage at a time.
So for every 5*t miliseconds MPlayer gets t miliseconds of processor time, 20%. If Mplayer uses 6 threads, then there will be 10 processes waiting for processor time. So for every 10*t miliseconds Mplayer gets 6*t miliseconds of processor time, 60%. Of course now there will be more context switches than before, but all Mplayer's threads have the same address space, same instructions and similar data, so likely this data would be around in an L2 cache and, in the worst case, in main memory, so a context switch would consist of transporting about 32K of data/instructions from an L2 cache to the L1 cache, which should be extremely fast. It seems the advantages of using multiple threads outweighs the added context switches.
 

The Physics Forums Way

We Value Quality
• Topics based on mainstream science
• Proper English grammar and spelling
We Value Civility
• Positive and compassionate attitudes
• Patience while debating
We Value Productivity
• Disciplined to remain on-topic
• Recognition of own weaknesses
• Solo and co-op problem solving
Top