SGI: Video

Horsepower required to play H.264 video?

I'm not expecting smooth 720p playback on SGI MIPS machines, but I still do want something fast enough to play my H.264 anime episodes, otherwise it wouldn't be that practical. What kind of CPU/speed would I need to play a 704x480 H.264 video using mplayer? What about slightly larger sizes (848x480, 1024x576)? Does video output performance depend very much on texturing hardware, or can mplayer use an overlay?
That's one of things I'm hoping dexter1 can eventually optimize in mplayer if he has time. Right now, it's basically impossible to play back H.264 anime smoothly even at 800MHz.

_________________
私のホバークラフト は鰻が一杯です。
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
h264 MKVs are even slow on my 2.2GHz opteron, I really hate that codec/wrapper :/

_________________
:Indy: :rx2600: :Indigo2: :Octane2: :hpserv: :hpserv: :O2: :Indigo2: :Indy: :Indy: system info on my website
nekoneko, what exactly is the problem with mplayer's code? Optimized for 32bit machines perhaps?

D-EJ915: impossible. Stop using -vo x11 and use -vo xv, xvidix. My Athlon XP 1800+ can play 720p just fine.
ritchan wrote:
nekoneko, what exactly is the problem with mplayer's code? Optimized for 32bit machines perhaps?


It's just not optimized for MIPS. Dexter1 did extensive mplayer MIPS optimization before H.264 was added a few years ago which made an enormous difference, but the path for H.264 isn't similarly optimized at this point in time.

_________________
私のホバークラフト は鰻が一杯です。
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
I've briefly looked into this, since this codec is becoming increasingly popular among recent Blu-Ray formats and small handheld devices because of the higher quality and lower stream bandwidth requirements than conventional mpeg streams.

This codec is a real CPU hog. It looks to be an upgrade over the Sorensen codec which is used in early Quicktime designs in Mplayer from 2005. I did do some optimisations on this codec when i was busy with simple_idct.c for the mpeg codec, but the codec algorithm has much more branching and much finer idct blocking (4x4 instead of 8x8) so i only got a speedup of 5% or so.

To make a significant change in processing speed, i believe we have to resort to Assembly on the R10k/R12k and you probably need a second processor to handle the brunt of the remaining workload, like color conversion and loading/storing imaging, audio and openGL stuff.

Guess what i am reading at the moment? Yep: MIPS R10000 Microprocessor User Manual

This looks to be fairly complicated, because of the different design compared to X86 CPU's with mmx. If you browse ffmpeg source for H.264, you will see that this codec has extensive mmx/sse Assembly code for x86 architechture, so even there people had to resort to Assembly to speed things up.

Anyway, i will browse a bit and form some ideas.

_________________
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP: :O2000: :Onyx2:
European nekoware mirror, updated twice a day: http://www.mechanics.citg.tudelft.nl/~everdij/nekoware
ftp://mech001.citg.tudelft.nl rsync mech001.citg.tudelft.nl::nekoware
Yay. Well, I might get a VPro in the future to speed up video output, so don't you dare give up on this halfway! I've already got two TRAMs on the way...
Often in my case is mutch better/ faster to run mplayer in this way:
Code:
npri -r 100 -s RR mplayer something.avi


This setting may cause (if video is too big to play smooth) total stop for other applications, even mouse pointer can stop responding.

Dexter - thanks for fantastic optimizations made to mplayer, I'm using it often so any even small improvement is welcome :)

_________________
:O2: R7000/600 576MB Ram CDRW 18+9Gb HDD
http://www.tomosgi.co.cc