Alexander writes:
One thing that just begs to be asked: since when decoding 1080p became
an interactive task?
Normally, decoding video would not be considered an interactive task,
unless you are doing things like stepping through frame-by-frame.
Playing video, and/or audio is a true real time task. The computer
must perform the work at a specific rate, not faster, not slower.
Recording video and/or audio is also a true real time task, If
the machine/OS drops the ball you have a spoiled recording, and most
of the time you can't try again.
Bruce writes:
you
can have a load of 100 or more before the system becomes unusable
whereas people are amazed to see loads of more than 15 on Linux.
The load average leaves much to be desired as a metric.
I have generated an obscenely high lead average while retaining
great responsiveness, and done a simple "cp /disk1/file1 /disk2/"
resulting in the machine taking *minutes* to respond to the simplest
command.
Andriy writes:
Well, I am not sure if I can agree about CPU-bound-ness.
Depends on the exact video file, of course, but certain high-quality
1080p are
very CPU intensive unless decoding is offloaded from the CPU.
Depends on
decoder code too. I had some videos that were CPU-bound on my Athlon
II X2 250
with then-version of mplayer from ports.
The bitrate is more useful than saying "1080p". The speed of the CPU is
important, the codec, the efficiency of the decoder, whether parts can
be
offloaded to a GPU or hardware decoder, if the output is being scaled,
etc.
If playing a video maxes out the CPU, then the video isn't going to be
displayed correctly.
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"
