IRIX and Software

Right, this is the second time I'm posting this as my first attempt was foiled by a new kitten! "Hey dad, what you typing on the interwebs, I can type too?!"

Anyway, I've download a teaser sample of a MP4 video file from here , but as soon as I play it back with mplayer I get garbled video, audio plays fine. I get video OK with the -vo gl or gl2 flags, but I end up with error messages about currupt frames, with serious frame drops.

Any ideas? I can covert the video with mencoder to a .mov, but at 2fps its a bit barking to convert the whole thing...

OR is my box just too slow to play the file?

-J

JacquesT wrote: Anyway, I've download a teaser sample of a MP4 video file from here , but as soon as I play it back with mplayer I get garbled video, audio plays fine. I get video OK with the -vo gl or gl2 flags, but I end up with error messages about currupt frames, with serious frame drops.

the skewed display is a known problem with vo_sgi with many h.264 videos. You can work around it by using external colorspace conversion (-vf format=rgb24), which makes it essentially behave exactly like vo_gl2 on your VPro.

Any ideas? I can covert the video with mencoder to a .mov, but at 2fps its a bit barking to convert the whole thing...

OR is my box just too slow to play the file?

In short: yes

I tried it on my 600MHz Fuel and with disabled audio (i.e. without dropping frames) I get around 4fps (vs. 63fps on my laptop ) so as soon as you add audio it will drop just about everything. After converting it to Xvid4 the Fuel plays it without issues at around 50% CPU though, so your Octane should still do fine there.

schleusel wrote: In short: yes

I tried it on my 600MHz Fuel and with disabled audio (i.e. without dropping frames) I get around 4fps (vs. 63fps on my laptop ) so as soon as you add audio it will drop just about everything. After converting it to Xvid4 the Fuel plays it without issues at around 50% CPU though, so your Octane should still do fine there.

Oh piff! My 1Ghz Tibook plays it fine. Guess I'll have to get it set up next to me...Will try the Xvid4 conversion. Did you use 'mencoder'?

-J

JacquesT wrote: Will try the Xvid4 conversion. Did you use 'mencoder'?

no, i was lazy and used avidemux and the original libxvidcore on Linux. Using mencoder or ffmpeg (libavcodec) should work just fine too though..

Just curious, how does one interpret the output from mplayer to find out the frame rate achieved? For the
speeder_teaser.mp4 movie, I get:



Does the output imply that ideally the movie should play at 10fps?

The command I used to play the file was:



Ian.

mapesdhs wrote: Does the output imply that ideally the movie should play at 10fps?

yes. Given the material, 10fps is reasonable. Capturing more would probably slow down the creator's system and you're not missing much.

Just fyi a 1.5ghz pentium 4 plays the clip fine in VLC. maybe 35% cpu.

So how does one interpret mplayer's benchmark results output? Couldn't find a ref in the man page.

Ian.

well, if you want something to compare it to:


Fullscreen playback:



Just a wild guess, but here is my theory: in seconds and percentage, the VC is the time spent decoding the video, VO is the time spent (added:) outputting the video, A is the audio, and sys is other processes (I've got folding going in the background here as well as a bunch of other stuff)

With the -vo null option it will just decode as fast as possible and not worry about displaying (compare the SYS usage between the first and second tries)

you might try some tea leaf reading through google searches if nothing else.

Is there somewhere it says how many frames are in the movie? Just wondering how people are calculating
their fps numbers from the output.

Ian.

mapesdhs wrote: Is there somewhere it says how many frames are in the movie? Just wondering how people are calculating their fps numbers from the output.

I'd bust out the hourglass and slide rule There's probably a switch to show it but bugger all if I can find it.

mapesdhs wrote:

Code: Select all

V: 189.3 1894/1894 70% 19%  0.0% 0 0 0%


- current video position: 189.3 seconds
- 1894 of 1894 frames played
- 70% CPU usage for decode
- 19% CPU usage for display
- 0% CPU usage for audio playback
- 0 frames dropped
- no automatic post processing done
- 0% cache fill

if audio is enabled, even more information is shown. Here is the full list:
http://www.mplayerhq.hu/DOCS/HTML/en/faq.html#id2811815

The CPU usage for display with vo_null is because by adding -vf format=rgb24 you enforced colorspace conversion even without displaying anything.
If you really want to benchmark the codec only, skip that one.

These percentage scores are momentary values, the -benchmark output gives overall results instead:

Code: Select all

BENCHMARKs: VC: 132.943s VO:  36.990s A:   0.000s Sys:   1.198s =  171.131s
BENCHMARK%: VC: 77.6848% VO: 21.6152% A:  0.0000% Sys:  0.7000% = 100.0000%


- 132.943s for decode
- 36.990s for display
- 0.000s for audio playback
- 1.198s used by the OS
- 171.131s total

i.e. 1894 frames / 171 seconds = 11 fps for decoding and colorspace conversion but without video and audio playback.
The second line gives percentage scores of the same.

The command I used to play the file was:

Code: Select all

mplayer -vo gl2 -vf format=RGB24 -osdlevel 0 -benchmark -nosound -vo null speeder_teaser.mp4


The -vo gl2 is overridden by the -vo null, the -vf format=rgb24 enforces the extra colorspace conversion (with gl2 this shouldn't be needed anyway. I just mentioned it as a workaround for the display problem with vo_sgi mentioned above). For comparison, here are the numbers from my Fuel:

- decode only (-osdlevel 0 -benchmark -nosound -vo null):

= 9.7 fps. As you can see, without the -vf format=rgb24 filter, nearly no time is spent for VO.


- decode + colorspace conversion (added -vf format=rgb24, same as you did):

= 7.5 fps. So I assume you tested on a 700MHz machine?


- decode + gl2 display (-vo gl2 -osdlevel 0 -nosound -benchmark):

= 4.2 fps..


And the inevitable comparison.. decode only on a 1.8GHz Core2Duo (Linux):

= 109 fps H.264 is really not the stuff to feed the irix mplayer with..

The CPU usage for display with vo_null is because by adding -vf format=rgb24 you enforced colorspace conversion even without displaying anything.
If you really want to benchmark the codec only, skip that one.

ah ha! That's what I was suspecting at first but I couldn't figure why it would be using so much CPU doing nothing .

It's encoded at 10fps. For a tutorial there is no point in going above 15fps.

Guess I'll stick to my now-ancient powerbook for H.264 playback...It manages...just!

Does anybody have a 1Ghz Tezro or 900Mhz Fuel to test this on?

-Jacques.

Wow, my Core Duo laptop plays it with only 15% CPU (CoreAVC). To top it off, it''s so simple relatively that it's shocking that even a Fuel would struggle to decode it.

ritchan wrote: it's shocking that even a Fuel would struggle to decode it.

The h264 path in mplayer isn't optimized for MIPS at all. dexter1 did a lot of great work optimizing mplayer's xvid path for MIPS, but at the time he did this h264 wasn't even part of the software.