O2 Vice MPEG2 discovery

Video, software tools and techniques on SGI systems.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
jodys
Donor
Donor
Posts: 129
Joined: Tue Feb 06, 2007 1:33 am
Location: Denver, CO

O2 Vice MPEG2 discovery

Unread postby jodys » Sun Oct 04, 2015 12:07 pm

The O2 has the vice engine. This was an architecture designed just before things like the Pentium got MMX and MIPS got MDMX. Instead of extra instructions on the main CPU, VICE is actually three completely seperate execution units that talk via a mapped region in main memory (not a big deal on the O2's UMA architecture). The three units are the MSP, BSP and a DMA engine. I'll talk more about the specifics of this architecture in future posts (time permitting). Additionally, two hardware versions of the VICE were released, DX and TRE with TRE being the most recent version.

This unit is used by two parts of Irix: the ImageVision library for accelerating 2D image operations and by dmedia for accelerating various image compression tasks. Specifically

Code: Select all

     SGI versions 1, 2 and 3 (supported compression formats: uncompressed,
     MVC1, MVC2, JPEG, RLE8, RLE24, RLE32)

     Microsoft AVI (Audio Video Interleaved)

     MPEG1 (ISO 11172) - read, play, and append only

     Raw DV/DVCPro DIF files - read, play, and export only

Notably missing is MPEG2. Everything I've read on the net supports this, as well, the O2 can't do realtime MPEG-2 (please, correct me if I'm wrong about this assumption.) However, I was able to locate some internal documentation for the VICE engine and references to MPEG-2 decoding is littered through the documentation. MPEG2 decoding was definitely one of the design goals.

Furthermore, I find some compelling evidence of the ability to decode MPEG2 in 6.5.30m. Because the MSP and BSP are seperate executing units, Irix must keep object files around to run on those units.

The ImageVision MSP/BSP objects are found in

Code: Select all

/usr/gfx/ucode/CRM/vasm/

The dmedia objects are found in

Code: Select all

/var/arch/vicetre/
...
mpeg1dec.bex
mpeg1dec.mex
mpeg2dec.bex
mpeg2dec.mex
mpeg2dec_fld.bex
mpeg2dec_fld.mex
...

So... at the bottom of the dmedia stack there is some solid evidence that Irix supports mpeg2 decoding, because there is code to run on the Vice.

But does the rest of Irix know how to decode mpeg2? I cobbled some C together from the dmedia manpages and examples to introspect the dmedia image converters (the image compression section of dmedia) to see what converters it knows about.

Code: Select all

...
Contents of Parameter/Value List for IC 34:
 DM_IMAGE_COMPRESSION=MPEG-2 Video
 DM_IC_REVISION=0(int)
 DM_IC_VERSION=1(int)
 DM_IC_SPEED=NONREALTIME
 DM_IC_CODE_DIRECTION=DECODE
 DM_IC_ENGINE=The mpeg2 decoder
 DM_IC_ID=mpg2
Contents of Parameter/Value List for IC 35:
 DM_IMAGE_COMPRESSION=MPEG-2 Video
 DM_IC_REVISION=0(int)
 DM_IC_VERSION=0(int)
 DM_IC_SPEED=REALTIME
 DM_IC_CODE_DIRECTION=DECODE
 DM_IC_ENGINE=Vice
 DM_IC_ID=dvc
...
Contents of Parameter/Value List for IC 37:
 DM_IMAGE_COMPRESSION=MPEG-2 Video
 DM_IC_REVISION=0(int)
 DM_IC_VERSION=2(int)
 DM_IC_SPEED=REALTIME
 DM_IC_CODE_DIRECTION=DECODE
 DM_IC_ENGINE=Vice
 DM_IC_ID=mpeg
...

The output is bit conflicting (why is the dvc decoder listed with a "MPEG-2 Video"). I compiled this with the debug version of dmedia (export LD_LIBRARY_PATH=/usr/lib/debug) without any problems. But, the way I read the output is that, at least at the image compression level, there is support for hardware (DM_IC_SPEED=REALTIME) and software (DM_IC_SPEED=NONREALTIME) mpeg2 decoding. Now support for the compression scheme is only part (albeit a major one) of displaying mpeg2 on the screen. The next step is to learn more about dmMovie which supports the various container formats. Is there support for a mpeg2 container there?

I've attached a copy of the source of the tool to list the available imageconverters. If anyone else wants to run this on their O2, I'd be interested to see if there is any difference in versions of Irix (did 6.3 have dmedia?) I've become a bit obsessed by the VICE and I hope to keep updating this thread with more that I discover, especially about mpeg2.
Attachments
test_ic.c
(2.56 KiB) Downloaded 62 times
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:

rooprob
Posts: 73
Joined: Wed Sep 01, 2010 7:20 am

Re: O2 Vice MPEG2 discovery

Unread postby rooprob » Mon Oct 05, 2015 7:19 pm

Nice! Keep going!
:O2: r12 400 mapleleaf :Indigo2IMP: r10 195 IRIS :Cube: NeXT
New Zealand

Lalle
Posts: 1
Joined: Sat Aug 29, 2015 1:47 pm
Location: Skåne, Sweden

Re: O2 Vice MPEG2 discovery

Unread postby Lalle » Thu Oct 15, 2015 11:37 am

Sounds very interesting! Keep going!
O2 r5k 200mhz and O2 r10k 250mhz

macroexp
Posts: 26
Joined: Wed Feb 25, 2004 8:23 pm
Location: Falls Church, VA

Re: O2 Vice MPEG2 discovery

Unread postby macroexp » Thu Oct 15, 2015 5:55 pm

I don't have any O2 running on anything but 6.5.30m, which I think is what you are running on as well, but I went ahead and compiled and ran the program for the sake of verification. The output is attached.

I'd be glad to test anything else you have, or if you have any suggestions on things to delve into myself, I could try that too - I'm handy enough with C-like languages.
Attachments
test_ic.txt
output from my 6.5.30m O2
(9.15 KiB) Downloaded 54 times
:O2: (janus): 400MHz R12k, 576MB, 73GB 15k, modded PSU fan
:Indigo2IMP: (indigo2): 195MHz R10k, 512MB, SI, 36GB
Sun Ultra80 (mizar): 4x450MHz USII, 4GB, XVR-1200, 2x73GB 15k ZFS
2x :1600SW:+ML, :Octane: 195MHz R10k, currently not booting

User avatar
jodys
Donor
Donor
Posts: 129
Joined: Tue Feb 06, 2007 1:33 am
Location: Denver, CO

Re: O2 Vice MPEG2 discovery

Unread postby jodys » Sat Oct 17, 2015 9:33 am

Thanks for the encouragement! It feels a bit weird spending all this time thinking about something that is, basically, unimportant in the grand scheme of things; the architecture was a dead end, Irix is long expired, and who cares about MPEG2 these days? Well, apparently, I do. It isn't some wish to go back, but, by golly, just because the rest of the world decided to be finished with this stuff doesn't mean I have to be finished with it!

I was a bit concerned about 'MPEG-2 Video' being listed for every vice related engine. Perhaps I was pulling the value from the string stored behind the dmedia library when it wasn't valid (e.g. left over from the previous image decoder)?

Reversing the order

Code: Select all

     for(i=n;i>=0;i--){
                 status = dmICGetDescription(i, params);
                 PrintParams(params, i);
     }

Sure enough, something weird going on.

Code: Select all

Contents of Parameter/Value List for IC 37:
 DM_IC_REVISION=0(int)
 DM_IC_VERSION=2(int)
 DM_IC_CODE_DIRECTION=DECODE
 DM_IC_SPEED=REALTIME
 DM_IC_ENGINE=Vice
 DM_IC_ID=mpeg

This certainly looks like a mpeg1 decoder, which we know works. Bad news? I dunno, there is still a lot of evidence pointing to a mpeg2 vice decoder. Even though the imageconverter library doesn't expose it, we still have those bits of code for the MSP and BSP on the vice. However, am I misinterpreting the names of those code files?

Experiment: run a mpeg1 file and see what .mex and .bex files it loads.

First, I wanted a minimal player that used dmedia (I don't think any of the legacy media stuff supports vice?). I found a simple example in /usr/share/src/dmedia/movie/miscGL/simplemoveGL. Second, I need a working mpeg1 movie file. This was in /usr/demos/O2/Birth_of_O2/data/product_manager/System_components/avModule.mpg. Third, I need a way to watch what system calls (specifically open calls) are made when I run the movie player with the mpeg1 file. par(1) does this easily enough.

Code: Select all

par -n open ./simplemovieGL /usr/demos/O2/Birth_of_O2/data/product_manager/System_components/avModule.mpg
...(some rld stuff)
    6mS                 : open("/usr/lib32/libmovieplay.so", O_RDONLY, 05) = 3
    7mS                 : open("/usr/lib32/libmoviefile.so", O_RDONLY, 05) = 3
    7mS                 : open("/usr/lib32/libdmedia.so", O_RDONLY, 05) = 3
    8mS                 : open("/usr/lib32/libX11.so.1", O_RDONLY, 05) = 3
    9mS                 : open("/usr/lib32/libGL.so", O_RDONLY, 05) = 3
   10mS                 : open("/usr/lib32/libm.so", O_RDONLY, 05) = 3
   11mS                 : open("/usr/lib32/libcl.so", O_RDONLY, 05) = 3
   11mS                 : open("/usr/lib32/libmutex.so", O_RDONLY, 05) = 3
   12mS                 : open("/usr/lib32/libGLcore.so", O_RDONLY, 05) = 3
   13mS                 : open("/usr/lib32/libXsgivc.so", O_RDONLY, 05) = 3
   15mS                 : open("/usr/lib32/libXext.so", O_RDONLY, 05) = 3
   16mS                 : open("/usr/lib32/libvice.so", O_RDONLY, 05) = 3

I believe that the vice is exposed to the kernel via an entry in /dev that can be controlled via a variety of ioctls and libvice.so wraps that up in a nice api.

Code: Select all

   42mS                 : open("/dev/zero", O_RDWR, 01757312210) = 3
...(a bunch of X and openGL calls)
   50mS                 : open("/usr/lib32/dmedia/imageconverters/libmpeg1video.so", O_RDONLY, 05) = 4
   66mS                 : open("/usr/lib32/dmedia/imageconverters/", O_RDONLY|O_NONBLOCK, 01505656520) = 4
   68mS                 : open("/usr/lib32/dmedia/imageconverters/libmpeg2.so", O_RDONLY, 05) = 4
   70mS                 : open("/usr/lib32/dmedia/imageconverters/vicedv.so", O_RDONLY, 05) = 4
   73mS                 : open("/usr/lib32/dmedia/imageconverters/vicempeg.so", O_RDONLY, 05) = 4
   75mS                 : open("/usr/lib32/dmedia/imageconverters/vicers.so", O_RDONLY, 05) = 4
   76mS                 : open("/usr/lib32/dmedia/imageconverters/vicejpeg.so", O_RDONLY, 05) = 4
   79mS                 : open("/dev/vicedms", O_RDWR, 0570) = 4

I think here libvice.so is starting to control the vice

Code: Select all

 
   80mS                 : open("/dev/dms", O_RDWR, 070) = 5
   81mS                 : open("/dev/dms", O_RDWR, 070) = 6
   83mS                 : open("/dev/dms", O_RDWR, 0130) = 7
   89mS                 : open("/dev/dms", O_RDWR, 03) = 8
   89mS                 : open("/dev/dms", O_RDWR, 0130) = 9
  173mS                 : open("/dev/dms", O_RDWR, 03) = 10
  195mS                 : open("/dev/vicedms", O_RDWR, 0570) = 4
  196mS                 : open("/dev/dms", O_RDWR, 070) = 5
  197mS                 : open("/dev/dms", O_RDWR, 070) = 6
  199mS                 : open("/dev/dms", O_RDWR, 0130) = 7
  204mS                 : open("/dev/dms", O_RDWR, 03) = 8
  205mS                 : open("/dev/dms", O_RDWR, 0130) = 9
  266mS                 : open("/dev/dms", O_RDWR, 03) = 10
...(a bunch of X and openGL calls
  592mS                 : open("/var/arch/vicetre/mpeg1dec.mex", O_RDONLY, 017777605604) = 27
  593mS                 : open("/var/arch/vicetre/mpeg1dec.bex", O_RDONLY, 010000) = 27

With the /dev/vicedms already open (from above) the library loads up the mpeg1dec.mex and mpeg1dec.bex files to the MSP and BSP, respectively. Thus, running an mpeg1 file uses the mpeg1dec.mex and mpeg1dec.bex files. So what? Well there are still

Code: Select all

mpeg2dec.bex
mpeg2dec.mex
mpeg2dec_fld.bex
mpeg2dec_fld.mex

in /var/archer/vicetre/. Who uses those files?

Code: Select all

$ strings /usr/lib32/dmedia/imageconverters/vicempeg.so | grep mpeg2
mpeg2dec.mex
mpeg2dec.bex
mpeg2dec_fld.mex
mpeg2dec_fld.bex


The very same vicempeg.so that runs mpeg1. Then why does vicempeg.so tell the dmIC library that it can do mpeg1 but not mpeg2?

A mystery.

The next question that emerges in my mind; what is going on in vicempeg.so? Finding the addresses of the mpeg1dec.mex and mpeg1dec.bex strings in vicempeg.so could provide enough info to run dbx(1) or cvd(1) along with test_ic.c and see if I can't see how the dmIC introspection interacts with vicempeg.so. I'm mildly encouraged since there does exist a /usr/lib/dmedia/debug/vicempeg.so. Perhaps, it has not been stripped of symbols and use the function names to understand where I am in the code. If it is stripped I think that it might be possible to at least follow the pattern for mpeg1 and see if I can find a branch that skips mpeg2. Maybe a decompiler will help here?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: O2 Vice MPEG2 discovery

Unread postby dexter1 » Tue Nov 03, 2015 4:30 pm

Jodys, i'm going to run the test_ic.c on my O2. I'm interested in what you have found already. Disassembly of vicempeg.so is an option, though it is not for the faint of heart.

Above all, i just need some courage to run the system knowing that i have to turn it on and off for some time before i can run it 24/7. I need to make it a bit more silent...
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
jodys
Donor
Donor
Posts: 129
Joined: Tue Feb 06, 2007 1:33 am
Location: Denver, CO

Re: O2 Vice MPEG2 discovery

Unread postby jodys » Wed Nov 04, 2015 6:27 am

Looking at the docs for dbx I think I can set a break when entering a system call. From there I think I can at least isolate where in vicempeg.so those files are loaded. I thought a useful first thing to try would be to at least build a call tree for mpeg1 which I think is doable with dbx and the symbols in vicempeg.so.

A question related to compiling with debug ('-g') turned on. How do you know if a given binary was compiled with '-g'?
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:

robespierre
Posts: 1573
Joined: Mon Sep 12, 2011 2:28 pm
Location: Boston

Re: O2 Vice MPEG2 discovery

Unread postby robespierre » Wed Nov 04, 2015 7:45 am

there would be a DWARF section in the binary.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:

vegac
Posts: 745
Joined: Thu Jan 23, 2003 11:34 am
Contact:

Re: O2 Vice MPEG2 discovery

Unread postby vegac » Wed Nov 04, 2015 9:55 am

I sadly don't have anything to offer to this thread, and my O2 is currently in a non-functional state, but I love that this is happening :)

User avatar
pentium
Posts: 4742
Joined: Mon Aug 28, 2006 6:29 pm
Location: Kamloops, BC

Re: O2 Vice MPEG2 discovery

Unread postby pentium » Thu Nov 05, 2015 2:54 am

I'd five you results as well but my compiler is not playing nice with me.
:Crimson: :Onyx: :O2000: :O200: :O200: :PI: :PI: :Indigo: :Indigo: :Indigo: :Octane: :O2: :1600SW: :Indigo2: :Indigo2: :Indigo2IMP: :Indigo2IMP: :Indy: :Indy: :Indy: :Cube:

Image <-------- A very happy forum member.

User avatar
Indyboy
Posts: 233
Joined: Tue Nov 21, 2006 9:05 am
Location: Lost in EU

Re: O2 Vice MPEG2 discovery

Unread postby Indyboy » Thu Nov 05, 2015 9:42 am

Interesting project, keep up the good work!
:O200: :Indigo: :O2: :Indigo2IMP:

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: O2 Vice MPEG2 discovery

Unread postby dexter1 » Sat Nov 07, 2015 4:24 pm

test_ic_dexter1_O2_6530.txt
(9.16 KiB) Downloaded 48 times


What strikes me is that even Macroexp and i have the same IRIX version, our test_ic.txt differ. I'm running an R12K@270 system with AV board
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:

User avatar
vishnu
Donor
Donor
Posts: 3183
Joined: Sun Mar 18, 2007 3:25 pm
Location: Minneapolis, Minnesota USA

Re: O2 Vice MPEG2 discovery

Unread postby vishnu » Sun Nov 22, 2015 5:10 pm

jodys wrote: question related to compiling with debug ('-g') turned on. How do you know if a given binary was compiled with '-g'?


The file command will tell you; file binaryname and it will say either stripped or not stripped.
Project:
Temporarily lost at sea...
Plan:
World domination! Or something...

:Tezro: :Octane2:

User avatar
jodys
Donor
Donor
Posts: 129
Joined: Tue Feb 06, 2007 1:33 am
Location: Denver, CO

Re: O2 Vice MPEG2 discovery

Unread postby jodys » Sun Feb 07, 2016 9:17 am

It looks like tracing the execution won't be easy

Code: Select all

jodys@mirkwood debug$ pwd
/usr/lib/dmedia/imageconverters/debug
jodys@mirkwood debug$ dwarfdump vicempeg.so
No DWARF information present in vicempeg.so
jodys@mirkwood debug$

but it won't be hard

Code: Select all

jodys@mirkwood debug$ file vicempeg.so
vicempeg.so:    ELF 32-bit MSB mips-2 dynamic lib MIPS - version 1
jodys@mirkwood debug$
:Octane2: :Indy: :O2: :O2: :O3x0: :Indigo2IMP:

User avatar
dexter1
Moderator
Moderator
Posts: 2743
Joined: Thu Feb 20, 2003 6:57 am
Location: Zoetermeer, The Netherlands

Re: O2 Vice MPEG2 discovery

Unread postby dexter1 » Sun Feb 07, 2016 10:21 am

I wasn't expecting a mips2 binary. How about elfdump?
:Crimson: :PI: :Indigo: :O2: :Indy: :Indigo2: :Indigo2IMP:


Return to “SGI: Video”

Who is online

Users browsing this forum: No registered users and 1 guest