The collected works of denver

I recently ran across some conversations regarding this product and thought I would give it a try. It sounded like I could use it for high resolution uncompressed playback. I've been kind of watching for something to do that.

It took me a while to figure out how to get a license. You can now get a permanent, complementary license at:
http://www.sgi.com/support/licensing/courtesy_keys.html

If you try to follow the normal procedure through key-o-matic (support/licensing or mailto:[email protected] ) you hit a dead end because none of the software lists contain shotmaker anymore. There were some posts here earlier this year that sounded like the normal process was still in place back then.


I have now tried shotmaker on several systems: an O2, a couple of Octanes, and an Onyx2, and I always get the same result. When I try to play anything, I get the following message:
"ShotMaker library warning: ShotMaker engine error: can't find a suitable image playback route"

My clip will show up on the left hand side, but it won't, of course, play. All of the clips I've tried can be played with mediaplayer (just not at full speed). I have tried capturing a 640x480 region of the screen. The capture seemed to work ok, but I have the same result when I try to play it back. I've also used smconvert to create clips from file-per-frame sgi files (2K and HD), again with the same result.

I spent some time searching around looking for clues, but the closest I've come is someone else reporting the same symptoms, but with no solution. Something about this message is naggingly familiar, but I can't put my finger on it.

I haven't hooked up any really high speed storage to support hi-res playback yet. I wanted to see if it was going to work at all first. The storage I have used is more than adequate for NTSC though (50+ MB/S).

Here's the hinv from one of the Octanes:
2 195 MHZ IP30 Processors
CPU: MIPS R10000 Processor Chip Revision: 2.7
FPU: MIPS R10010 Floating Point Chip Revision: 0.0
Main memory size: 896 Mbytes
Xbow ASIC: Revision 1.3
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
Secondary unified instruction/data cache size: 1 Mbyte
Integral SCSI controller 0: Version QL1040B (rev. 2), single ended
Disk drive: unit 1 on SCSI controller 0
Disk drive: unit 2 on SCSI controller 0
Integral SCSI controller 1: Version QL1040B (rev. 2), single ended
CDROM: unit 3 on SCSI controller 1
CDROM: unit 4 on SCSI controller 1
Tape drive: unit 5 on SCSI controller 1: DLT
Integral SCSI controller 8: Version Fibre Channel AIC-1160, revision 1
Disk drive: unit 4 on SCSI controller 8
Disk drive: unit 5 on SCSI controller 8
Disk drive: unit 7 on SCSI controller 8
Disk drive: unit 8 on SCSI controller 8
Disk drive: unit 9 on SCSI controller 8
Integral SCSI controller 2: Version Fibre Channel AIC-1160, revision 2
Disk drive: unit 3 on SCSI controller 2
Disk drive: unit 6 on SCSI controller 2
IOC3/IOC4 serial port: tty1
IOC3/IOC4 serial port: tty2
IOC3 parallel port: plp1
Graphics board: MXI
Integral Fast Ethernet: ef0, version 1, pci 2
Iris Audio Processor: version RAD revision 12.0, number 1

Does anyone out there know what's going on with this?

Thanks,

Denver

GeneratriX wrote:

denver wrote: I have now tried shotmaker on several systems: an O2, a couple of Octanes, and an Onyx2, and I always get the same result. When I try to play anything, I get the following message:
"ShotMaker library warning: ShotMaker engine error: can't find a suitable image playback route"

Hi Denver; thanks for sharing, it looks really interesting to me to give it try to shotmaker on non-Onyx platforms...

By the way, do you have noticed this?:

HD I/O (XT-HDIO) Video Subsystem Software (xthd) Users: If you are are user of xthd, you must have at least version 1.2 installed. ShotMaker 1.1.1 is NOT compatible with xthd 1.0 or 1.1. If you are an xthd user but don't yet have version 1.2 installed, you may install it from HD I/O 1.2

I'm not a ShotMaker user, hence I don't know if it is realy related to these error. The full text is on: http://www.sgi.com/products/evaluation/6.5.10_shotmaker_1.1.1/

Yes, I saw that, thanks. I do have all those bits and pieces installed, except for the HD I/O board. But I've read elsewhere that all you really need is the xfsrt.

GeneratriX wrote:

denver wrote:

GeneratriX wrote:

denver wrote: I have now tried shotmaker on several systems: an O2, a couple of Octanes, and an Onyx2, and I always get the same result. When I try to play anything, I get the following message:
"ShotMaker library warning: ShotMaker engine error: can't find a suitable image playback route"

Hi Denver; thanks for sharing, it looks really interesting to me to give it try to shotmaker on non-Onyx platforms...

By the way, do you have noticed this?:

HD I/O (XT-HDIO) Video Subsystem Software (xthd) Users: If you are are user of xthd, you must have at least version 1.2 installed. ShotMaker 1.1.1 is NOT compatible with xthd 1.0 or 1.1. If you are an xthd user but don't yet have version 1.2 installed, you may install it from HD I/O 1.2

I'm not a ShotMaker user, hence I don't know if it is realy related to these error. The full text is on: http://www.sgi.com/products/evaluation/6.5.10_shotmaker_1.1.1/

Yes, I saw that, thanks. I do have all those bits and pieces installed, except for the HD I/O board. But I've read elsewhere that all you really need is the xfsrt.

Oh; I see... I've installed ShotMaker a couple hours ago by very first time on one of my SGI boxes. Tomorrow I'll check with a couple clips to see how it works, or if it works on my setup. We'll see!

Ok, hope yours works. It looks to me as if shotmaker isn't able to access my graphics for output. And since I have no video hardware, at least on the Octane, there's nowhere for it to go during playback. So is there something I have to do to configure my graphics so shotmaker can use it for playback?

GeneratriX wrote:

denver wrote: Ok, hope yours works. It looks to me as if shotmaker isn't able to access my graphics for output. And since I have no video hardware, at least on the Octane, there's nowhere for it to go during playback. So is there something I have to do to configure my graphics so shotmaker can use it for playback?

I've with video, and I got:

"ShotMaker library warning: ShotMaker engine error: Can't find a suitable image playback route"

I've noticed that you can setup the input device from:

ShotMaker>File>Settings>Graphics Screen Recording>Video>Graphics Device>[...]

...On which we have only: "O2 Graphics Screen" as a valid option.

But I can't see any available Tab to setup the output device. In fact: ShotMaker on my O2 does not seems to have any output node for playback, and even what seems an OpenGL viewport on the app remains void... perhaps only Onyx-grade graphic/video options are supported, hence the absence of any valid route to play/decode the images?

Looks as the more logical explanation. But please probe me that I'm wrong and I'll be a lot more happy to have ShotMaker working on my desktop!

This afternoon I tried the Onlyx2 again, and it works - I don't know what was wrong yesterday. So that supports your theory that it can only use IR type graphics. What you describe is exactly the same as what I see on O2 and Octane.

I have an indirect sgi contact that might be of some help. Let's see what I hear back from him. Hopefully there's a way to use the desk machines. After all, I've seen Piranha playing uncompressed HD on an MXI Octane, so that much is technically possible.

GIJoe wrote: any news on this? shotmaker doesn't like to play back here, too. i can't see any mentioning on the manpage regarding onyx-only support. there's a utility "smsetup" that apparently wants to create a framestore. i canceled the setup but maybe it writes out config info that shotmaker depends on for normal operation?

The smsetup utility is a script that sets up a stripe and filesystem optimized for the kind of video you are going to be doing. There's nothing in there that I saw that has anything to do with the graphics hardware.

So far all I've gotten back from sgi is that the graphics hardware shouldn't matter, but he's going to look at the code. He did confirm that the error message you get about not finding a suitable playback route does indicate that it isn't able to use the system's graphics.

Hopefully there will be a positive answer for this soon.

I'm attempting uncompressed capture from a camcorder. The result always has blank spots in the audio. The odd thing is that it's not dropping video frames - it just looses a bit of audio once in a while. If I use a compressed format, it works fine.

While the capture is runnig, everything else pretty much stops: keyboard input, mouse, etc. Mediarecorder is set to stop on any dropped frame. In fact, that's the only way I can get it to stop. I'm using a FC array, so I just pull the FC cable for a bit, and that causes a delay, which stops the capture.

Anybody have any ideas? This is a 175Mhz R10K, with 512MB memory, and a FC card (QLA2200).

Thanks,

Denver

Glock wrote:

denver wrote: I'm using a FC array, so I just pull the FC cable for a bit, and that causes a delay, which stops the capture.

Let me see if I'm reading this right: you stop the recording session, by disconnecting your harddrive???

At least you've won the first price for creativity d00d!

Never ever disconnect a live filesystem. You might (read: will) damage your filesystem, and as a consequence, your filez. The proper order is: close all open files (exit apps), unmount volumes, spindown drives, pray...

* Ask Bluefan how feeble filesystems are, even on plug&play (or unplug and play as you will) systems like Windhoos...

I'm just guessing but... maybe the dropped audio is a direct result of this.

One last question: at the time of unplugging your fibre-channel array, was your cupholder open or shut???

Actually, it's not as bad as it sounds. It's not like pulling the plug on a SCSI drive. I'm not killing the power, all that happens is a momentary loss of sync on the FC connection. That causes a delay in the I/Os, but none are lost. I'm not saying this is a recommended procedure, just that I have no evidence that it caused any probelms here.

Otherwise, I agree about disconnecting a live filesystem - if you don't get it back in a reasonable time, the host can panic. If you loose any cached data, the filesystem gets corrupted.

In the past I've tested devices, HBA's, drivers, etc. Some tests involved introducing errors in the FC connection, to make sure everybody recovers properly. Some things are generally difficult to recover from, others are easier. Momentarily dropping the loop is one of the easier ones.

Thanks,

Denver

zone wrote:

denver wrote: Anybody have any ideas? This is a 175Mhz R10K, with 512MB memory, and a FC card (QLA2200).

My guess is unresolved timing issue with R10k 150/175MHz CPUs in o2.
Think that best what you can do is to look for R10k 195/250 or even better R12k 300/400 CPU upgrade. Which IRIX version you use BTW?

Interesting. I didn't know there were timing issues with some models. But that could explain what's happening, including the way it's behaving during uncompressed capture.

I'm currently running 6.5.25f. Should have said that before.

Thanks

Dr. Dave wrote: When I was messing around with striping Clariion arrays, if I disconnected the primary loop, the automatic failover to the secondary loop didn't happen for what seemed like a minute or so, certainly 30 seconds. One might presume that at a low level the FC-AL protocol is the layer that fights for the connection, and is one addition that regular SCSI doesn't have. So long as the loop can re-establish itself, it can then start queueing/unqueuing the regular SCSI traffic without disrupting the overlying protocols, and should work fine.

Exactly. In fact, this isn't too much different from what happens if you have a hub in there, and connect/disconnect something else. The duration in my case was longer - a couple of seconds, but that's all. When the loop goes down, the ISP waits a while for it to restore before resuming operation. Otherwise it returns a timeout. If anything goes wrong with the current command, it just gets retried. .

zone wrote:

denver wrote: Interesting. I didn't know there were timing issues with some models. But that could explain what's happening, including the way it's behaving during uncompressed capture.

I'm currently running 6.5.25f. Should have said that before.

I stated my guess not an authoritative answer. Regarding timing issue on early R10k o2's you may check sgi related newsgroups.
Also, note that later IRIX versions seems to have somewhat broken video support according to Ian Mapleson, his recomendation is 6.5.15 for video work on o2.

Well, I think your guess was pretty good. I don't have a newer R10000 (or R12000) system at this point, but I do have a 180MHz R5000. Uncompressed capture on that one works quite a bit better, although it is a bit sluggish responding to the "stop" button. But that's not really a problem, at least it does stop.

I've since made a new system disk for that one with 6.5.15. I'm getting very good results going from the camcorder->O2->dvd.

Many thanks,

Denver

zone wrote:

denver wrote: I've since made a new syst
em disk for that one with 6.5.15. I'm getting very good results going from the camcorder->O2->dvd.

Can you tell us more about o2->DVD workflow.

Certainly. I haven't had time to work on this project lately, and I probably don't have the best answers, but I'll explain what I've done so far.

In simple terms, the work goes like this:
1. Capture the camcorder output (svideo) with the O2 using mediarecorder.
2. Do a bit of simple editing: trim the ends of the clip and add a title using moviemaker.
3. Convert the clip to MPEG2 with mencoder (FreeBSD).
4. Create the DVD files using DVDStyler (FreeBSD).
5. Burn the DVD with growisofs (FreeBSD).

I originally thought I was going to need to capture uncompressed because I was going to edit the result. But after doing some experimenting, I don't see a clear advantage. Besides, although I have been able to get the O2 to do uncompressed captures, it's a little unpredictable: sometimes it works fine, sometimes not. Capturing with compression is easier. So I could probably do the capture with dmrecord instead of mediarecorder.

After doing some research, I've been capturing to a QuickTime file, using JPEG-A compression, with YCrCb 422 packing. I usually bump the quality up from 75% to 95%.

I save (Export As) the edited result to an AVI file, using SGI JPEG compression, again with YUV 422 packing.

The mencoder command I use is:
# 4:3
SCALE=720:480
mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=$SCALE,\
harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:\
vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=18:acodec=ac3:\
abitrate=192:aspect=4/3 -ofps 30000/1001 \
-o outfile infile

Once you have the MPEG2 file, there are a number of ways to get that onto a DVD. I've found DVDStyler to be simple and easy to use. It's supposed to also burn the DVD, but I always get an error at that point - I probably don't have the correct permissions on the dvd device. But it does tell you what command it's trying to use, so I just run that as root and that works fine.

So far I've been limiting all my clips to about 30 seconds. I don't want to spend an hour capturing something, then going through all the other work, only to discover that I made a poor option choice during the capture. I have a feeling that once I do start working with clips that are 30 minutes long instead of 30 seconds, there will be a whole new set of challenges.

Thanks,

Denver