You Know You Need A New Computer

[dduardo]

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.

 

[dav2008]

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]

mplayer does this to me often. It's very un-optimized and uses ridiculous amounts of cpu time.

- Warren

 

[ranger]

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]

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]

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]

I am using the CVS version. The last time I updated was the middle of this month. (04/14/06)

 

[-Job-]

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 a lot 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.

 

[graphic7]

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 a lot 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-]

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]

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.

 

[-Job-]

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.