SGI: Video

MPlayer 1.0pre3 tardist - Page 1

Hi!

I uploaded a tardist of the new MPlayer 1.0pre3 release: http://www.kanera.de/irix/MPlayer-1.0pre3.tardist

Key features of this build:

- built with MipsPro 7.4.1 and heavy optimizations (including IPA) - i can try to provide a recursive diff of the changes after I cleaned up the mess a bit. 99% of it was typical GCCisms, albeit a lot of them ;-)
- includes mips4 and mips3 selections
- ffmpeg libavcodec, libmpeg2, libvorbis codecs included
- x11, opengl and sdl video-out plugins included
- sgi, sdl and esd audio-out plugins included
- no prereqs as I linked all non-system libs statically

both mplayer and mencoder were tested with several files of different formats without major problems. The only problem I know of is Sorenson Video 3 (SVQ3) which is broken currently (probably endianness). It was already reported on the mailinglist so I hope it gets fixed soon.

a few hardware related notes:

The build was tested on MGRAS based Octanes (ESI, ESI+T, EXMI), Odyssey based Octanes (VPro8), O2 and Indigo² (MGRAS - HighImpact).
If you lack hardware Texturing you'll have to live with x11 or sdl video output and avoid scaling, as the software scaler is dead slow on Mips. If you still insist on the software scaler, use sdl instead of x11, its a bit faster..
For the x11 plugin make sure to have -depth 24 -class TrueColor in your /var/X11/xdm/Xservers

If you have Hardware Texturing you can choose one of the two OpenGL plugins to get hardware scaling. The gl2 plugin is the best choise in almost all cases - its faster than the gl plugin, it keeps the movie aspect when resizing and the OSD works well with it. If you experience broken colors with the GL plugins, force the output colorspace with -vf format=RGB24 on your command line or add vf=format=RGB24 to your config file. Note that on MGRAS gl2 doesn't work at all without that switch..
If you use the gl plugins make sure they can get a double buffered visual with enough colors. (findvis db tells you). On SI+T or ESI+T use one of the 1280x1024_XY_32db modes to achieve this.

Its always a good idea to have -framedrop enabled so mplayer starts skipping frames if needed (to keep a-v sync if the video is too much for the hardware).

I've included a default mplayer.conf with some IRIX related comments. Have a look at it and change it to your needs - or better: create your own ~/.mplayer/config to override those default settings.

so long,
Timo
Wow, great work on porting that! downloading now...
configure complete, now type 'make' and pray.
Thanks Timo, much appreciated!
Thanks for the tardist. Unfortunately for me (and I'm a complete novice on this) the film I'm trying to view still complains:


Code: Select all

Playing oe_112~1.wmv.
Cache fill: 10.94% (917504 bytes)    ASF file format detected.
============ ASF Stream group == START ===
object size = 38
stream count=[0x2][2]
stream id=[0x1][1]
max bitrate=[0x20161][131425]
stream id=[0x2][2]
max bitrate=[0x193723][1652515]
============ ASF Stream group == END ===
VIDEO:  [3VMW]  480x360  24bpp
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, 16 bit (0x20), ratio: 16005->176400 (128.0 kbit)
Selected audio codec: [ffwmav2] afm:ffmpeg (DivX audio v2 (ffmpeg))
==========================================================================
vo: X11 running at 1600x1024 with depth 24 and 32 bpp (":0.0" => local display)
==========================================================================
Requested video codec family [wmv9dmo] (vfm=dmo) not available.
Enable it at compilation.
Requested video codec family [wmvdmo] (vfm=dmo) not available.
Enable it at compilation.
Cannot find codec matching selected -vo and video format 0x33564D57.
Read DOCS/HTML/en/codecs.html!
==========================================================================
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...
Video: no video
Starting playback...


Also, the audio which worked with your previous release is now garbled. I aplogize for needing so much hand-holding.
squeen wrote: Requested video codec family [wmv9dmo] (vfm=dmo) not available.
Enable it at compilation.
Requested video codec family [wmvdmo] (vfm=dmo) not available.
Enable it at compilation.


Windows Media 9 will only play on x86 for now, as mplayer needs the win32 dlls to support it until libavcodec gets native support for it.

squeen wrote: Also, the audio which worked with your previous release is now garbled. I aplogize for needing so much hand-holding.


*sigh* indeed. I just dug out a similar file to test it. Looks like wma2 audio decoding is broken currently too.. I'll add the file to my growing collection of test fodder for future builds.

so for now your best way to get this to play on Irix is to use mencoder on some x86 machine and convert it to some more friendly format.. windows media should be boycotted anyway ;-)

so long,
Timo
schleusel wrote: windows media should be boycotted anyway

amen! (and thanks for the info)
I must join the congratulations. I spent a lot of time hacking at mplayer myself, but I never got opengl output working. Good job!
[edit]
okay, i got a little too excited. -vo gl2 -vf format=RGB24 is not working for me for the "classic evangelion comedy", although it works fine for an *.ogm file I have. Unfortunately, my system (195MHz Octane SI+T) is still too slow to play much of anything without -nosound. Oh, well.
Timo, can you post the configure options you used? I have an *.avi file here that I can play with my compiled player:

Code: Select all

Opening audio decoder: [liba52] AC3 decoding with liba52
No accelerated IMDCT transform found
AC3: 5.1 (3f+2r+lfe)  48000 Hz  384.0 kbit/s
No accelerated resampler found
AUDIO: 48000 Hz, 2 ch, 16 bit (0x20), ratio: 48000->192000 (384.0 kbit)
Selected audio codec: [a52] afm:liba52 (AC3-liba52)

but dies with yours:

Code: Select all

Opening audio decoder: [liba52] AC3 decoding with liba52
No accelerated IMDCT transform found
AC3: 5.1 (3f+2r+lfe)  48000 Hz  384.0 kbit/s


MPlayer interrupted by signal 10 in module: init_audio_codec
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.

Maybe just send me a message so we don't clog this thread.
0ctane wrote: okay, i got a little too excited. -vo gl2 -vf format=RGB24 is not working for me for the "classic evangelion comedy", although it works fine for an *.ogm file I have.


it works fine for 90% of the files I have here. There are a few that don't work - all of those are quite high res/high bitrate videos, so I suppose the problem is texture size limit on mgras (if so, this problem shouldn't exist on CRM or Odyssey) - I have yet to look deeper into this. For most files it should work fine on your SI+T (i tested it on ESI+T with many files) - just make sure it gets the double buffered high color visual it wants..

Octane wrote: Unfortunately, my system (195MHz Octane SI+T) is still too slow to play much of anything without -nosound. Oh, well.


yeah, smaller divx files and mpeg1 (and probably low bitrate mpeg2) works quite well on lower clocked r10k, anything larger can get painfull..

Octane wrote: Timo, can you post the configure options you used? I have an *.avi file here that I can play with my compiled player:

Code: Select all

Opening audio decoder: [liba52] AC3 decoding with liba52
No accelerated IMDCT transform found
AC3: 5.1 (3f+2r+lfe)  48000 Hz  384.0 kbit/s
No accelerated resampler found
AUDIO: 48000 Hz, 2 ch, 16 bit (0x20), ratio: 48000->192000 (384.0 kbit)
Selected audio codec: [a52] afm:liba52 (AC3-liba52)

but dies with yours:[code]Opening audio decoder: [liba52] AC3 decoding with liba52
No accelerated IMDCT transform found
AC3: 5.1 (3f+2r+lfe) 48000 Hz 384.0 kbit/s


MPlayer interrupted by signal 10 in module: init_audio_codec
- MPlayer crashed. This shouldn't happen.

..
Ok, thanks for the hint. I got this fixed now. MipsPro was the problem in this case.. I overlooked (yet another) __GNUC__ ifdef in liba52/bitstream.h. Do you have an urgent need for software AC3 decoding? Otherwise i'll try to get a few other things working too before I update the package..

thanks for the feedback,
Timo
schleusel wrote: Do you have an urgent need for software AC3 decoding? Otherwise i'll try to get a few other things working too before I update the package..

thanks for the feedback,
Timo

No rush. AC3 would just make the program a little more complete. The offending video I have seen numerous times anyhow. I think you have done such a great job so far that we can wait a little while. Anticipation can be fun.
Cheers!
BTW, when did Sorenson Video 3 break? I got it working during the pre2 and have that build sitting around. Also, on the mailinglist a while back someone was working with the Octane digital audio I/O. Any thoughts on getting that working? I don't ever use my Octane's digital I/O, but it might be an interesting feature. :)
0ctane wrote: BTW, when did Sorenson Video 3 break? I got it working during the pre2 and have that build sitting around.


It was still working in CVS around November iirc. It wasn't fixed yet.. so maybe i'll dig through the ffmpeg cvslog and try to find out which change broke it. Or I just send a proper bug report to the ffmpeg people instead.

Octane wrote: Also, on the mailinglist a while back someone was working with the Octane digital audio I/O. Any thoughts on getting that working? I don't ever use my Octane's digital I/O, but it might be an interesting feature. :)


hmm, shouldn't setting the default output to digital in apanel be all thats needed for this? If you are feeding it into an amp with integrated 5.1 (Dolby Digital, DTS) decoder it might be worth to try -ac hwac3 (AC3 through SPDIF) to make use of it (given an input file with ac3 of course). I have not the slightest idea if any of this works as I don't have the proper equipment to test it currently.. ;)

so long,
Timo
I've just gotten that mplayer binary build installed on my Octane (R12k/270MHz, ESI) and it works very well, DivX4v3, over NFS and without the framedrop option :). Anyway I don't have TRAM module and cannot scale the movie fullscreen... I'd report results with more video streams latter.
The system looks quite responsive while that thing is playing.
LAMMEN GORTHAUR
If you have a (fast) x86 machine with Linux on it, you can recode a proprietary WMV9/RM video to something you wish with MPlayer's MEncoder thus resulting in possibility to use native codecs on a broader number of OSes, because of the openness of the codec you use then. Exactly what i'm doing all the time with Real garbage (their codecs are far from the definition "open source"). I'm not using this method to play movies on my SGI computers, but you could, if you want, given XViD and MP3 are supported by the MPlayer port, and your SGI machine can handle it. I'm afraid none of mine can.

Here's what i'm doing with RealMedia video's:
$ mplayer -dumpstream -dumpfile test.rm -rtsp-stream-over-tcp rtsp://streams3.omroep.nl:554/tv/vpro/r ... 0040121.rm
$ mencoder test.rm -o test.avi -ovc xvid -oac mp3lame


Voila, an XViD was born. The RTSP URL is just as example; -rtsp-stream-over-tcp matters only when the RTSP protocol is used (ie. for Real, but also for ie. QuickTime) for firewalls or broken connections, though it's possible to forward UDP connections on a firewall too. As you can see i'm using XViD + MP3. When Theora is ready i'd love to use OGG Vorbis + OGG Theora instead. Regarding files: test.rm is the output file in the first command, and the input file in the second command. It can be deleted afterwards; while test.avi is the output of the second command which you'll want to view with ie. MPlayer afterwards.

If you see the above i think it's pretty straightforward of what exactly happens and i think the same can be done regarding WMV9. I never tried, though. I did succesfully done the conversion with QuickTime 6.

Finally, i wrote a few extended howto's for this process (for Real), but it's not in English. The MPlayer documentation explains it too, though pretty short. I hope this is useful for anyone up here!
$ cat TODO
Learn Inner Sanctuary; Act Autonomous; Forge Future; Experience Enthean Enlightenment.
I get sound from the file I want to play, but the picture is grey. This is on an Octane
MXI. How can I be sure the system is in a double buffered video mode? xsetmon
suggests the system is using (DX) 1280x1024_72 from:

/usr/gfx/ucode/MGRAS/vof/2RSS

I notice there is a 1280x1024_72_32db in the directory above, but setmon complains
when I try to use that.

Note that the DivX file plays fine on my O2.

The mplayer.conf has:

vo=gl2
vf=format=RGB24
ao=sgi
framedrop=1
zoom=no
osdlevel=2
monitoraspect=4:3
cache = 8192

I'm guess the video isn't running in 32db, but I'm not sure how to force it.

Oh, the example file is on my site if anyone wants to replicate things:

http://www.futuretech.blinkenlights.nl/ ... movie1.avi

Thanks for any assisstance!

Ian.

SGI Depot: http://www.futuretech.blinkenlights.nl/sgidepot/
Email: mailto:[email protected]
Backup email (send copy to this too): mailto:[email protected]
Home: +44 (0)131 477 1142 (best to call this number first)
Mobile: 07743 495403 (usually off; leave a message and I'll call back)

SGI/Future Technology/N64: http://www.futuretech.blinkenlights.nl/
Mirror site: http://futuretech.mirror.vuurwerk.net/
Doom Help Service (DHS): http://www.gamers.org/dhs/
Hi Ian,

mapesdhs wrote: I notice there is a 1280x1024_72_32db in the directory above, but setmon complains
when I try to use that.

Note that the DivX file plays fine on my O2.


Yes, there is a problem with the gl plugins on MGRAS (mostly with high res/bitrate files) - see the fist comment from Octane above for example. I don't think its a double buffering thing (if it doesn't find a double buffered visual, the gl plugin bombs out earlier), I rather think its a texture size issue.. the problem doesn't exist on Odyssey and O2. I bet it displays smaller files without problems, right?

Btw. I'm planning to update the package when 1.0pre4 is out at some point in the next weeks. I'm currently playing with cvs and all looks good so far - at least all the codec problems reported in the above posts are fixed (SVQ3, WMA, AC3..). Unfortunately I don't have any MGRAS machine around anymore (switched to Odyssey), so I can't really experiment with the above issue currently. Hopefully I'll be able to pick up some r10k High Impact indigo2 in the near future to keep at least one MGRAS machine around..

mapesdhs wrote: Oh, the example file is on my site if anyone wants to replicate things:

http://www.futuretech.blinkenlights.nl/ ... movie1.avi

*fetching*

so long,
Timo
Hey - I've been playing with mplayer a bit, and my own CVS-current build with the freeware gcc gets exactly the same (or so) -benchmark results as the MIPSPro build above. Bit disappointing. I'm testing with MPEG2 VOB files and the same files mencoded to raw video/audio.

I'm a dual 300 SSE and I can only get 15-20 FPS playing DVD rate MPEG2, playing the uncompressed version is fine (mmm, Cheetah X15 :)) but with rather alarming CPU usage - 50% of each processor at least. For us people without TRAMS , I imagine one could do a much better job using glDrawPixels() instead of icky XImages. It also looks like all MGRAS cards could do hardware YUV-RGB with the SGI_color_matrix GL extension. Not sure how fast that would be. I may have a go at writing an output plugin. Perhaps one could use XSGIvc to switch to a better resolution too. If glPixelZoom() is too slow for full screen, which I image it is, it would be nice to have a 720x480_59.94_db32 mode but playing with the BlockSync template and VFC I can't seem to make one. And it would be the wrong aspect ratio anyway, and I doubt most monitors would like it. I use a 640x480_89.91 mode and chop the edges off at the minute :)

One could use the various video extensions to get proper synchronisation with the vertical retrace too. If one could get an interlaced mode, maybe it could be possible to split each frame into lines and get actual proper like-a-TV interlaced output :)

Of course, mpeg2lib is stil waay to slow to play DVDs. I don't suppose anyone is handy with the MADD instructions and feels like optimizing it? ;) Way over my head sadly. If assembly is asking too much, maybe some of the motion compensation and IDCT could be rewritten using routines from the SCSL , which is presumably pretty speedy?

More thoughts: How come xdpyinfo shows an XVideo extension, and there are headers, but no libraries? How come I can't build mplayer with ./configure --enable-profile? GCC complains about ftell being redeclared in IRIX's stdio_core.h.

Oh, and to get mplayer to play anything at all smoothly I have to use both -cache <lots> and -ni, which I thought were somewhat mutually exclusive...

Oh, and almost all of the -lavc codecs core when I try to encode with them. I was hoping that HuffYUV might let me play stuff without each file taking up 20Gib of disk...

AND, why does the whole screen revert to 1.0 gamma when the cursor is over the video window? I though television gamma was more like 2.2?

Sorry for all the questions... I'm also consideing porting the dvdlibs that mplayer uses. I'd have to basically write all the dvd ioctls, but it's already been done for BSDI using the user space ds SCSI stuff.
If anyone cares, I've attempted to write a new output plugin using glDrawPixels(). Rather embarassingly it's actually slower than the regular X11/SHM one at the moment. I'm not sure why. Using the colour matix extension for colour space conversion works fine, but it's not very fast at all, possibly no faster than doing it entirely in software. Maybe it's accelerated more on something other than Impact graphics?

Having to unpack everything from planar 4:2:0 YUV into packed RGBA is a major pain. I've done it the obvious way with nested for() loops, but does anyone with more clue about algorithm design know of a better way?

I managed to get all the work of the drawing onto the other CPU with some very (VERY) crude use of pthreads. This breaks slices support and is generally a Bad Thing, but I get much better framerates using this and -noslices, so I don't care :)

If anyone has any suggestions on how it could go faster, do let me know :) I still can't get profiling to work. I may tidy it up and make a binary or a diff, but for now the guts in case there's something obviously wrong:

Code: Select all

#include "video_out.h"
#include "video_out_internal.h"
#include <pthread.h>
#include <semaphore.h>
#include <GL/glx.h>
#include <stdio.h>

static vo_info_t info = {
"OpenGL output for SGI machines without hardware texturing",
"flour",
"Lewis Saunders <[email protected]>",
""
};

sem_t sem;
Display* dpy;
GLXWindow glxWin;
uint8_t* Y;
uint8_t* U;
uint8_t* V;

LIBVO_EXTERN(flour)

void artist(void* dontCare);

static uint32_t preinit(const char* arg) {
pthread_t child;

sem_init(&sem, 1, 0);
pthread_create(&child, NULL, (void*)artist, NULL);

return(0);
}

static uint32_t control(uint32_t request, void* data, ...) {
switch(request) {
case VOCTRL_QUERY_FORMAT:
if(*(uint32_t*)data == IMGFMT_YV12) {
return(VFCAP_CSP_SUPPORTED |
VFCAP_CSP_SUPPORTED_BY_HW |
VFCAP_HWSCALE_UP |
VFCAP_HWSCALE_DOWN);
} else {
return(0);
}
break;
}
}

static uint32_t config(uint32_t width,   uint32_t height,
uint32_t d_width, uint32_t d_height,
uint32_t fullscreen, char* title, uint32_t format) {
return(0);
}

static uint32_t draw_slice(uint8_t* src[], int stride[],
int w, int h, int x, int y) {
Y = src[0];
U = src[1];
V = src[2];
sem_post(&sem);
}

void artist(void* dontCare) {
XVisualInfo*         xVisual;
XSetWindowAttributes xWinAttrs;
XEvent               event;
Window               xWin;
GLXFBConfig*         fbConfigs;
GLXContext           glxContext;
GLfloat              yuv2rgb[16] = {1.000,  1.000,  1.000,  0.000,
0.000, -0.344,  1.770,  0.000,
1.403, -0.714,  0.000,  0.000,
0.000,  0.000,  0.000,  1.000};
static uint8_t       packed[480][720][4];
int                  i, j;
int                  xWinAttrMask;
int                  fbCount;
int                  fbAttrs[] = {GLX_DOUBLEBUFFER,  True,
GLX_RED_SIZE,      1,
GLX_GREEN_SIZE,    1,
GLX_BLUE_SIZE,     1,
None};
dpy = XOpenDisplay(NULL);

fbConfigs = glXChooseFBConfig(dpy, DefaultScreen(dpy),
fbAttrs, &fbCount);

xVisual = glXGetVisualFromFBConfig(dpy, fbConfigs[0]);

xWinAttrMask = CWColormap | CWEventMask;
xWinAttrs.event_mask = StructureNotifyMask;
xWinAttrs.colormap = XCreateColormap(dpy,
RootWindow(dpy, xVisual->screen),
xVisual->visual, AllocNone);
xWin = XCreateWindow(dpy, RootWindow(dpy, xVisual->screen), 0, 0,
720, 480, 0, xVisual->depth, InputOutput,
xVisual->visual, xWinAttrMask, &xWinAttrs);
XFree(xVisual);
XMapWindow(dpy, xWin);
do {
XNextEvent(dpy, &event);
} while (event.type != MapNotify || event.xmap.event != xWin);

glxContext = glXCreateNewContext(dpy, fbConfigs[0], GLX_RGBA_TYPE,
NULL, True);
glxWin = glXCreateWindow(dpy, fbConfigs[0], xWin, NULL);
XFree(fbConfigs);
glXMakeContextCurrent(dpy, glxWin, glxWin, glxContext);

glDisable(GL_ALPHA_TEST);
glDisable(GL_BLEND);
glDisable(GL_DEPTH_TEST);
glDisable(GL_DITHER);
glDisable(GL_FOG);
glDisable(GL_LIGHTING);
glDisable(GL_LOGIC_OP);
glDisable(GL_STENCIL_TEST);
glDisable(GL_TEXTURE_1D);
glDisable(GL_TEXTURE_2D);
glDisable(GL_TEXTURE_3D_EXT);
glDisable(GL_CONVOLUTION_1D_EXT);
glDisable(GL_CONVOLUTION_2D_EXT);
glDisable(GL_SEPARABLE_2D_EXT);
glDisable(GL_HISTOGRAM_EXT);
glDisable(GL_MINMAX_EXT);
glPixelTransferi(GL_MAP_COLOR, GL_FALSE);
glPixelTransferi(GL_RED_SCALE, 1);
glPixelTransferi(GL_RED_BIAS, 0);
glPixelTransferi(GL_GREEN_SCALE, 1);
glPixelTransferi(GL_GREEN_BIAS, 0);
glPixelTransferi(GL_BLUE_SCALE, 1);
glPixelTransferi(GL_BLUE_BIAS, 0);
glPixelTransferi(GL_ALPHA_SCALE, 1);
glPixelTransferi(GL_ALPHA_BIAS, 0);
glPixelZoom(1.0, -1.0);
glRasterPos2i(-1, 1);
glMatrixMode(GL_COLOR);
glLoadMatrixf(yuv2rgb);
glPixelTransferf(GL_GREEN_BIAS, -0.5);
glPixelTransferf(GL_BLUE_BIAS, -0.5);
glClearColor(0.0, 0.0, 0.0, 1.0);
glClear(GL_COLOR_BUFFER_BIT);
glXSwapBuffers(dpy, glxWin);
glClear(GL_COLOR_BUFFER_BIT);

for(;;) {
sem_wait(&sem);
for(i = 0; i < 480; i++) {
for(j = 0; j < 720; j++) {
packed[i][j][0] = Y[i*720 + j];
packed[i][j][1] = U[(i/2)*360 + j/2];
packed[i][j][2] = V[(i/2)*360 + j/2];
}
}
glDrawPixels(720, 480, GL_RGBA, GL_UNSIGNED_BYTE, packed);
glXSwapBuffers(dpy, glxWin);
}
}

static uint32_t draw_frame(uint8_t* src[]) {}
static void draw_osd(void) {}
static void check_events(void) {}
void uninit(void) {}
void flip_page(void) {}


If you want to try it out, bung it in the libvo folder of an mplayer source tree, add the reference to video_out.c and fiddle with the configure script extensively...
Hi,

if something seems slow I would advise to get precise measurements before trying to optimize things. One kandidate seems to be this loop:

Code: Select all

for(i = 0; i < 480; i++) {
for(j = 0; j < 720; j++) {
packed[i][j][0] = Y[i*720 + j];
packed[i][j][1] = U[(i/2)*360 + j/2];
packed[i][j][2] = V[(i/2)*360 + j/2];
}
}


You are always calculating things inside the loop which can be done via simple additional indices

i*720 + j is a good candidate

(i/2)*360 is the same as i*180

(i/2)*360 + j/2 is used twice within this twodimensional loop. Try to optimize it away.

But maybe it just the glDraw call.

Good luck

Matthias
Life is what happens while we are making other plans
I think this is really cool. I'll try and find time to get it set up on my machine and test it out once my DVD drive arrives.. I love the notion of multi-threading across CPUs. Do you have any experience creating SYSTEM scope pthreads, i.e. one's than span more than one CPU? I apologize for the question if you are already doing this. They require a privledge user to run (see the capabilities man page). Another option is to just to fork the process and use the IRIX shared memory facilities.

Code: Select all

int ixPixel=0;
int ixPixel2=0;
for(i = 0; i < 480; ++i)
{
for(j = 0; j < 720; ++j)
{
int ixPixel3 = ixPixel2 + j/2;
packed[i][j][0] = Y[ixPixel];
packed[i][j][1] = U[ixPixel3 ];
packed[i][j][2] = V[ixPixel3 ];
++ixPixel;
}
ixPixel2 +=180;
}


Also the navigation with a 3-dimensional array is far from efficient. But check first if the glDrawPixel is the reason for slowness.

Regards

Matthias
Life is what happens while we are making other plans