Nekochan Net

Official Chat Channel: #nekochan // irc.nekochan.net
It is currently Mon Sep 01, 2014 5:40 am

All times are UTC - 8 hours


Forum rules


Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.



Post new topic Reply to topic  [ 123 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 9  Next
Author Message
 Post subject: MPlayer
Unread postPosted: Sat Sep 04, 2004 8:45 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
Very exciting, guys! Congratullations! ;)

...I've just downloaded to give it a try on one of my O2(s).

What's supposed to be the best start point to play any video from the O2?

I mean, the new video out plugin and optimization options, are detailed on "man mplayer", or something?

Thanks in advance! ;)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 8:51 am 
Offline

Joined: Sun Oct 05, 2003 7:42 am
Posts: 786
Location: Frankfurt (Rhein-Main Area) / Germany
Hi Schleusel,

thanx for uploading again. If this is really max CPU power usage, I bet I am on the safe side. CPU utilization peaked out at 90%, going up and down mostly between 35% and 75%. Width was 1280, height approx 512 I estimate (should be resolution independent, i guess there's no fill rate problem on the VPro with textures). I wonder if people below R14K550 V10 have serious fun with it :roll:

Is there still anything to tune on my setup (settingwise) ?

Code:
[mplayer/bin] % mplayer /tmp/WarIII_Trailer1024.avi.1
MPlayer 1.0pre5 - MIPSpro Compilers: Version 7.4.2m (C) 2000-2004 MPlayer Team

CPU: SGI MIPS
Reading config file /opt/mplayer/etc/mplayer/mplayer.conf
Reading config file /usr/people/ms/.mplayer/config
Reading /usr/people/ms/.mplayer/codecs.conf: Can't open '/usr/people/ms/.mplayer/codecs.conf': No such file or directory
Reading /opt/mplayer/etc/mplayer/codecs.conf: 73 audio & 180 video codecs
font: can't open file: /usr/people/ms/.mplayer/font/font.desc
Font /opt/mplayer/share/mplayer/font/font.desc loaded successfully! (206 chars)
Using usleep() timing
Can't open input config file /usr/people/ms/.mplayer/input.conf: No such file or directory
Can't open input config file /opt/mplayer/etc/mplayer/input.conf: No such file or directory
Falling back on default (hardcoded) input config

Playing /tmp/WarIII_Trailer1024.avi.1.
Cache fill:  1.76% (147456 bytes)    AVI file format detected.
VIDEO:  [XVID]  1024x468  16bpp  24.000 fps  1503.5 kbps (183.5 kbyte/s)
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2&3 finished, tables done
AUDIO: 44100 Hz, 2 ch, 16 bit (0x20), ratio: 28000->176400 (224.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
vo: X11 running at 1280x1024 with depth 15 and 15 bpp (":0.0" => local display)
==========================================================================
Trying to force video codec driver family ffmpeg...
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm:ffmpeg (FFmpeg MPEG-4)
==========================================================================
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, big endian signed int
AF_pre: 44100Hz 2ch Signed 16-bit (Big-Endian)
ao_sgi, init: Samplerate: 44100Hz Channels: Stereo Format Signed 16-bit (Big-Endian)
AO: [sgi] 44100Hz 2ch Signed 16-bit (Big-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Starting playback...
[mpeg4 @ 10772a60]looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag
VDec: vo config request - 1024 x 468 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [sgi] 1024x468 => 1024x468 Planar YV12
[sgi] VPro (Odyssey) Hardware detected:
        using software colorspace conversion (rgb)
        drawing via textures
A: 142.2 V: 142.2 A-V: -0.000 ct: -0.058  3414/3414  61% 10%  2.6% 103 0 1%%
Broken frame at 0x3D36D0                                                 
A: 143.3 V: 143.2 A-V:  0.001 ct: -0.042  3439/3439  61% 10%  2.6% 103 0 0%
ao_sgi, uninit: ...

BENCHMARKs: VC:  86.297s VO:  15.941s A:   3.668s Sys:  36.853s =  142.758s
BENCHMARK%: VC: 60.4499% VO: 11.1662% A:  2.5691% Sys: 25.8148% = 100.0000%
BENCHMARKn: disp: 3408 (23.87 fps)  drop: 6 (0%)  total: 3414 (23.91 fps)
ao_sgi, uninit: ...

Exiting... (End of file)


The dropped frames could be because netscape had a short peak in between
Matthias

_________________
Life is what happens while we are making other plans


Last edited by Brombear on Sat Sep 04, 2004 9:02 am, edited 4 times in total.

Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 8:52 am 
Offline
Moderator
Moderator
User avatar

Joined: Sun Mar 30, 2003 4:29 am
Posts: 2477
Location: Kabul, Afghanistan, Asia
Diego, check /opt/mplayer/etc/mplayer/mplayer.conf.

It's all in there. There's quite a few O2 specific options.

Have fun!

_________________
...only chemist in .af?
Eroteme.ch - eternally unfinished and never started


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 9:07 am 
Offline

Joined: Sun Oct 05, 2003 7:42 am
Posts: 786
Location: Frankfurt (Rhein-Main Area) / Germany
And here a last one in fullscreen mode, but that didn't change much:

Code:
[sgi] VPro (Odyssey) Hardware detected:
        using software colorspace conversion (rgb)
        drawing via textures

Broken frame at 0x3D36D0                                                 


BENCHMARKs: VC:  85.527s VO:  15.932s A:   3.636s Sys:  37.663s =  142.758s
BENCHMARK%: VC: 59.9103% VO: 11.1600% A:  2.5471% Sys: 26.3826% = 100.0000%
BENCHMARKn: disp: 3410 (23.89 fps)  drop: 4 (0%)  total: 3414 (23.91 fps)
ao_sgi, uninit: ...


Matthias

_________________
Life is what happens while we are making other plans


Top
 Profile  
 
 Post subject: Mplayer
Unread postPosted: Sat Sep 04, 2004 9:13 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
Hakimoto wrote:
Diego, check /opt/mplayer/etc/mplayer/mplayer.conf.

It's all in there. There's quite a few O2 specific options.

Have fun!


Hey! Hakimoto! ...I'll check it right now! ;)

Thanks in advance! :)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 10:13 am 
Offline

Joined: Thu Jan 23, 2003 11:34 am
Posts: 706
for O2 support, no command lines are really necessary...

I generally run with
mplayer -vo sgi -framedrop moviefile.avi

O2 support uses the O2s native colorspace conversion, and dmbuffers for copying the converted buffer to a texture for displaying (minor hit in windowed, much MUCH faster in fullscreen)

For anyone using glDrawPixels (either due to it being selected by default or by passing :drawpixels

Scaling WILL be mildly slow, this is an unfortunate fact, and fullscreen scaling can cause a LOT of slowdown...if you intend to sit down and watch a video and not do anything else, try dropping your res as low as possible and that will save you a bit, but really, watching normal-sized in a window will be much faster.


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 10:17 am 
Offline

Joined: Mon Oct 20, 2003 5:49 am
Posts: 495
Location: NRW, Germany
Brombear wrote:
I wonder if people below R14K550 V10 have serious fun with it :roll:

hehe, well.. its quite a bad ass file, we didn't name it "the beast" for no reason ;-) 80% of the divx/xvid content out there isn't even half as heavy, so theres plenty headroom for lower end machines..

Brombear wrote:
Is there still anything to tune on my setup (settingwise) ?

the two fastest routes on Odyssey are 1. colorspace conversions in software and drawing via textures and 2. colorspace conversions in hardware using SGIS_pixel_texture and drawing via glDrawPixels.
2. is a bit faster but as pixel_texture only works with drawpixels for now, 1. looks a lot better, especially scaled. We chose quality over a speed as the default in this case.. feel free to check out the other route too though :-) Just start mplayer with -vo sgi:pixeltex


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 10:25 am 
Offline

Joined: Sun Oct 05, 2003 7:42 am
Posts: 786
Location: Frankfurt (Rhein-Main Area) / Germany
schleusel wrote:
Brombear wrote:
Is there still anything to tune on my setup (settingwise) ?

the two fastest routes on Odyssey are 1. colorspace conversions in software and drawing via textures and 2. colorspace conversions in hardware using SGIS_pixel_texture and drawing via glDrawPixels.
2. is a bit faster but as pixel_texture only works with drawpixels for now, 1. looks a lot better, especially scaled. We chose quality over a speed as the default in this case.. feel free to check out the other route too though :-) Just start mplayer with -vo sgi:pixeltex


No need for that, if I only loose a few promille frames I can easily live with it. Maybe someone decides to spent some tuning tries in another section of code and then I am able to get all frames :twisted:

Nono, I won't use the octane as my regular video watching device ... I really love silent computers :shock:

Matthias

_________________
Life is what happens while we are making other plans


Top
 Profile  
 
 Post subject: The Beast
Unread postPosted: Sat Sep 04, 2004 12:10 pm 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
vegac wrote:
for O2 support, no command lines are really necessary...

I generally run with
mplayer -vo sgi -framedrop moviefile.avi

O2 support uses the O2s native colorspace conversion, and dmbuffers for copying the converted buffer to a texture for displaying (minor hit in windowed, much MUCH faster in fullscreen)

For anyone using glDrawPixels (either due to it being selected by default or by passing :drawpixels

Scaling WILL be mildly slow, this is an unfortunate fact, and fullscreen scaling can cause a LOT of slowdown...if you intend to sit down and watch a video and not do anything else, try dropping your res as low as possible and that will save you a bit, but really, watching normal-sized in a window will be much faster.


Hi Vegac!,

thanks a lot; I'm currently downloading the so difficult to play1024_width video, a.k.a. "The Beast" :lol:

I'm very anxious to give it a try first with the beast, then with a few DVD rips that I have here (that I've used a few times to take the *.tga sequences useds as input for my projects, just like these ones from "The Matrix").

I'll test it on my O2 (R5K / 180MHZ / 768MB_RAM / 4GB_HD / 2GB_HD / 3x9GB_Stripped_HD)

I'll be a lot happy with any enhancement on the XviD/DivX performance thanks to the magic of you guys!

"Neko-Tunning" :D

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Sat Sep 04, 2004 6:05 pm 
Offline
Moderator
Moderator
User avatar

Joined: Thu Feb 20, 2003 6:57 am
Posts: 2062
Location: Voorburg, The Netherlands
I've just completed some optimisations on libmpeg2's mpeg12 codec, needed for MPEG1 and 2 (DVD's for example).
The mpeg12 codec is now slightly faster than the ffmpeg12 codec, which i optimised some time ago. Need to try some more tricks, but i'm happy this seems to speed up MPEG movies.

In the meantime, try out Schleusel's MPlayer and throw every DVD/DviX/mpeg movie you can lay your hands on...


Top
 Profile  
 
 Post subject: Neko-Buffer
Unread postPosted: Sun Sep 05, 2004 4:11 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
dexter1 wrote:
In the meantime, try out Schleusel's MPlayer and throw every DVD/DviX/mpeg movie you can lay your hands on...


Hi Dexter! ;)

...I've already done last night. I've tried at least twenty different DivX/XviD CDROMs, with movies like "Shrek", "The Matrix", "The Animatrix", "A Bug's Life", etc...

All the CoDecs are perfectly recognaizeds and decodeds. All the audio track are equally decoded, without great performance differences between they. I mean, all the movies that I have, are playing almost equally in terms of performance; no matter if it's DivX/XviD, etc... ; but a lot better in all the cases that with the previous MPlayer version.

I could love a greater processor on my baby, to sit me here to play a few movies at full rate / full frame, but seems that the O2 (R5K / 180MHZ / 768MB_RAM / 4GB_HD / 2GB_HD / 3x9GB_Stripped_HD) is just not enough; a thing that I was awared from the start, but stills...

The thing is that with my display with settings of 640x480 I can *almost* play any of theses movies at full motion; but well... "almost" :roll: ...unnafortunately, the slow-down is very notorious on the audio track mainly. Turns impossible the audition; but very good if you try to add a track to a movie on the leagues of "Exsorcist III", since the audio seems some kind of satanic thing... :oops: ...yup! ...It scares me!

Another thing: I've assigned 65536 (64K) to the input buffer; and seems slightly benefited from the larger buffer. My question is: could be assigned a bigger amount, just like... let's see :roll: 400000 ???

The idea is; on systems with very large amount of unused memory, get a larger pre-processing cache, to fit on memory all the pre-assembled sound/video_component matrix, just passing the pre-processed frames to the graphic subsystem...

It makes any sense for you? ...I've not browsed the MPlayer source, and I'm not awared if even could be possibly; but seems a great way to accelerate the process on systems with more than 384 MBytes of RAM.

It is exactly what I'm doing on VideoTrackerRT and works great. If it works here, we could get full motion even on lower-end O2(s). In my case, the only "hard-battle" is when you add some kind of real-time processing effect, that cause a big slow-down, since the power of the R5K/180MHZ clearly is not enough to attach the complexer effects before the buffer be empty. But I'll correct it later; since I'm not using all the accelleration capabilities of the O2 currently. With many basic effects runs good. Not bad if you remember that it is only an R5K; and I think I'll can push it a little bit more.

Of course; exists a price to pay: You'll need to wait the full filling of the buffer... probably as much as ten minutes or maybe more (of course; not in the case of VideoTrackerRT were it is an almost instantaneous thing, because the video is processed on little chunks!), depending of the size of the buffer, kind of compression, etc... but seems a price not so high, if you can watch full_frame/full_motion movies with a 180MHZ processor using the new "Neko-Buffer"! ;)

Like a side note; I'm very-very happy with the MPlayer development that you guys are currently leading!, It's completely stable, and makes a very happy use of the MIPS/IRIX system resources. A jewellers piece!

Cheers! ;)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Sun Sep 05, 2004 7:19 am 
Offline
User avatar

Joined: Thu Nov 27, 2003 12:30 pm
Posts: 547
Location: london
Mplayer's cache is before the codec, it's designed to smooth reading from slow access things like DVDs and NFS servers. You could always use -vo tga and convert it to uncompressed, then play it in something which caches, Blender or Illusion do :)


Top
 Profile  
 
 Post subject: Neko-Buffer
Unread postPosted: Sun Sep 05, 2004 7:54 am 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
lewis wrote:
Mplayer's cache is before the codec, it's designed to smooth reading from slow access things like DVDs and NFS servers.


Oh; I've just under such impression, because the so slight enhancement of the playing using cache... :roll:

lewis wrote:
You could always use -vo tga and convert it to uncompressed,


Yes; I know: is the way I'm obtaining those beautiful *.tga sequences to feed my VideoTrackerRT and test it! ;)

And of course; works perfect!

lewis wrote:
then play it in something which caches, Blender or Illusion do :)


Hehehehe!!! VideoTrackerRT can do it very well! ;)

But I was under the "illusion" here, that this could be reached directly on RAM, in the same way that I'm working here in my program. Any chance to put a secondary buffer of greater size *behind* the CoDec?

Take for sure that when the absolut limit of the processing power is reached, no other tunning could give a full_size/full_motion playing.

Hey!, this could be added anyway to the MPlayer "ToDo" list? ;)

A lot of O2 users could love the MPlayer team even more! :D

I can guarantee that it will WORK!

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
 Post subject:
Unread postPosted: Sun Sep 05, 2004 10:05 am 
Offline

Joined: Thu Jan 23, 2003 11:34 am
Posts: 706
The problem with the idea of the initial buffering is that no matter how big of a buffer you make, it will eventually run out because the slower O2's can't keep up with the codec...

Meaning: Even if you buffer 10 frames, by the time you hit frame 15 your buffer is depleted and you're lagging again - the only way to really do this would be to buffer enough to compensate for the remaining of the decode time - roughly 2/3 of the video would have to be pre-buffered, and if it runs slower than realtime (which it obviously does since you're having slowdown in the first place) that means to watch a movie you're taking a 90 minute pre-buffering before you even get the chance to enjoy your movie...
90 minutes of decompressed video would take more ram than these machines can hold!

On top of this there's the large number of audio sync issues it would introduce, as audio and video are decoded on their own and we'd have to also make a large buffer for audio...

Realistically, there's a limit to how much these machines can do, and these O2s especially are limited compared to say, Octanes.


Top
 Profile  
 
 Post subject:
Unread postPosted: Sun Sep 05, 2004 12:28 pm 
Offline
User avatar

Joined: Tue Oct 21, 2003 1:07 am
Posts: 4226
Location: Rosario / Santa Fe / República Argentina
vegac wrote:
The problem with the idea of the initial buffering is that no matter how big of a buffer you make, it will eventually run out because the slower O2's can't keep up with the codec...

Meaning: Even if you buffer 10 frames, by the time you hit frame 15 your buffer is depleted and you're lagging again - the only way to really do this would be to buffer enough to compensate for the remaining of the decode time - roughly 2/3 of the video would have to be pre-buffered, and if it runs slower than realtime (which it obviously does since you're having slowdown in the first place) that means to watch a movie you're taking a 90 minute pre-buffering before you even get the chance to enjoy your movie...
90 minutes of decompressed video would take more ram than these machines can hold!

On top of this there's the large number of audio sync issues it would introduce, as audio and video are decoded on their own and we'd have to also make a large buffer for audio...

Realistically, there's a limit to how much these machines can do, and these O2s especially are limited compared to say, Octanes.


Yes; I'm aplying the idea here on VideoTrackerRT with real success; but again, I'm working with shortest video-chunks, and in many cases the total-video-lenght fits perfectly on RAM; so, no problemas here! :D

But you're right, even if you could store 512 MBytes of uncompressed video in RAM, does not cover then the total lenght of the movie, and when the buffer be empty, the new process could not be attached on the processor schedule successfully with the movie even playing from RAM... :roll:

At this step, 60 seconds of uncompressed video without audio, on a typical DVD-rip resolution could be 900MBytes (60seconds x 15MBytes_per_second)

So, if you set a buffer-warning-level of about 20%, then the video could suffer an slowdown every 48 seconds; wich does not seems very comfortable.

On the case of VideoTrackerRT, it's using buffer-to-disk behind the second level of buffering, so, every video-preview with lenghts greater than 15 seconds is automatically writing to disk on uncompressed format. Then, you can play a preview at full rate motion quality.

Anyway, this method is suppossed to work with at least a 2x7200RPM striped array, to sustain easily more than 24 MBytes second.

I'm not running in troubles with the audio synch, since I have not audio processing even! :D

I think the only ways to do the job on this *crazy* (yeah!, I know, I Know!) way that I'm propossing could be:

1) Wait 100 minutes or more, browsing Neko-Forum with Mozilla, while your O2 fill a huge buffer on disk with uncompressed audio/video (81 GBytes for 90 minutes of very good quality video) :roll: :oops: :lol:

2) Take an hybrid aproach (like me), playing from disk while you render in RAM in background the next chunk before the new write down to disk. There is a complicated balance needed between the different processes: decoding, mem_buff, playing, decoding, write_mem_buff, write_mem_to_disk, etc...) But really works if the sum of bandwidths is less than max allowed, and specially if the playing action leaves some deegree of free resources on the processor and a lot of free resources in RAM.

3) Cray-Link two O2(s), and use one to decode to memory, and the second to play directly the result from RAM! :lol: Beautiful if possibly! :lol:

Well; I guess that now, the math reveals that my aproachs are mainly intended for dual processor systems, or really big proc/mem/HD setups...

Or in my case, for movies of less than 10 minutes of duration! ;)

Catch-up! ;)

_________________
Oh!, let me write that!

https://www.facebook.com/GeekTronix
https://geekli.st/GeekTronixShop
https://www.rebelmouse.com/GeekTronixShop/
http://twitter.com/GeekTronixShop
http://www.youtube.com/GeekTronixStream


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 123 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 9  Next

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group