SGI: Hardware

Managed to find someone with a no-longer-needed Apple iSight FW camera for sale, so I picked up the iSight for testing under IRIX.

For the record the test platform is a Tezro running IRIX 6.5.30. The 'DM10' is actually a generic PCI firewire board with a Texas Instruments TSB43AB23 chip, the hinv shows "PCI Adapter ID (vendor 0x104c, device 0x8024)". The DM10 software is the later 1.1 revision . While I got away with hot-plugging (and hot-unplugging) the iSight without any adverse effects, there have other mentions of system crashes while attaching or removing firewire devices with IRIX running. The safe bet is to do either with your system shut down.

Connected the iSight to one of the ports on the pseudo-DM10 in my Tezro. Without any additional action on my part the following appeared in the syslog (the Oxford IDE device listed is a pre-existing 2GB CompactFlash card in an MicroTech FW CameraMate CF card reader):
I ran an hinv -vm and it appeared there... as well as in the output of fwprobe:
Firewire/DM10 video devices don't use any of the classic IRIX video tools (e.g. Media Recorder, videod, et al), instead they use DM10 specific ML video libraries.

The iSight didn't initially appear in an "mlquery", so after a little rtfm quality time I followed the advice found in the DM10 Release Notes and stopped and restarted the mldaemon:
Then ran "mlquery" to get the iSight's ML device name:

So far so good, so I tried the iidc_vidtogfx sample program ( additional background and installation instructions are in this post ) and got: Not too promising, but since 'sampling' seemed to be the rub, I took a look inside iidc_vidtogfx.c for clues and found: Using 411 sampling I was able to successfully display a live video feed from the iSight: Unless you specify otherwise, the iidc_vidtogfx display window auto-closes after approximately 30 seconds. If you want the iidc window to remain open , there's a note inside iidc_vidtogfx.c that defines the command line switches. Adding " -c 0 " (that's a zero) to your command line string will cause the vidtogfx window to remain open indefinitely.

The sample program code for the DM10 also includes iidc_vidtomem. That works in a similar fashion. Using the same 441 sample value (and specifying an output path) I was able to successfully write raw output from the iSight to a file: If you save the output with a .ppm extension IRIX will open a single frame for viewing. There are a number of input and output options discussed inside iidc_vidtomem.c that might prove useful with a little more investigation.

recondas wrote: Connected the iSight to one of the ports on the pseudo-DM10 in my Tezro.

Another small step for Man ! Congratulations

I remember that neko got almost to that point but his iSight would not work. Maybe this means that the supported Canopus ADVC device could one day be persuaded to function ?

Super news, thank you !

What model and revision isight is it? (IIRC there are 3 revisions, /A, /B, and /C)

Man, you beat me to it (on a business trip this week).

hamei wrote: Super news, thank you !

You're welcome. Be interesting to see what other IIDC or AV/C fw vid devices can be make to work. Having someone with real programming skills take a look at the iidc/avc_vidtogfx and iidc/adc_vidtomem source code samples will be the next hurdle.

guardian452 wrote: What model and revision isight is it? (IIRC there are 3 revisions, /A, /B, and /C)

Good question - but if google got it right it might not make a difference as far as the DM10 is concerned. The MacRumors iSight wiki and this post in Apple's support forums suggest the revision letter only appeared on the packaging to designate which mounts originally shipped with the iSight. An examination of the iSight I have seems to superficially bear that out, no model/revision appears on the iSight (I don't have the original packaging).

ClassicHasClass wrote: Man, you beat me to it (on a business trip this week).

Couldn't have done it without you - the discussion in your Fuel thread moved fw vid to the top of my one-of-these-days list. If you consider similar tests with your Canopus ADVC-300 and Orange Micro iBOT, it would move this thread beyond the single-lucky-combination-of-hardware stage.

hamei would have me filleted if I didn't try the Canopus.

Okay, I couldn't let recondas show me up. For the final(?) hinv of my Fuel, see separate thread; this is 6.5.30 using the DM10 1.1 beta driver. To make this simple, I restarted the machine after connecting a new FW device so I didn't have to dork around with mldaemon -- more about hot swapping at the end. First, to establish reproducibility, bog standard FireWire iSight, normally connected to my G5:



So far so good. Next, the Orange Micro iBOT FireWire camera. This works fine with QuickTime, but TenFourFox's internal support doesn't like it and gives a scrambled image.



But it works fine here, as the image proves:


Now, for hamei, a Canopus ADVC-300 FireWire video deck, but for this we will need avc_vidtogfx instead:



Notice that periodically avc_vidtogfx and the device get out of sync and you have to do it again. The input basically works otherwise, but ... well ...


I tried playing around with glOrtho() in the source but I couldn't get it to flip vertically, and I don't know if avc_vidtomem has the same problem. I'm not very good with OpenGL programming though. It just seems to glDrawPixels() right into the window with no intervening texture or anything like that.

I mentioned hot swapping. It doesn't work. In fact, it seemed to hose the FireWire driver so bad that I had to hard-power-down the machine (the console was spammed with tons of FireWire errors about bad or missing targets and the kernel just sat there emitting errors forever until I hit the hard reset). Resetting mldaemon only worked the very first time for me (no devices seen and plugging one in). It wouldn't work for other devices after that.

TAKE THAT, RECONDAS!

* Incidentally, love and (if you are an attractive person with no Y chromosome) kisses if you can identify the (16-bit!) computer that generated the video signal for the ADVC-300.

ClassicHasClass wrote: * Incidentally, love and (if you are an attractive person with no Y chromosome) kisses if you can identify the (16-bit!) computer that generated the video signal for the ADVC-300.

Hands off but some kind of MSX...?

R.

ClassicHasClass wrote: Perhaps it's useable like this in the Southern Hemisphere.

I'll send it to my Mom - right after WW II she and a friend started a little newspaper. Linotype is upside-down and mirror image. She can still read that faster than I can read frontwards ... it used to piss me off when I was little.

Pretty nifty accomplishment, Classic. I was taking notes on how they cooked squid down in Mongkok but looks like we'll have to pass on the fillet session this time

PymbleSoftware wrote: Hands off but some kind of MSX...?

Nope, though you're right about the VDP (9918A)! Hint: the CPU is a Texas Instruments 9995.

hamei wrote: I'll send it to my Mom

Word to your Mom!

GL h4xx0r5, is there an easy way to flip glDrawPixels other than by labouriously turning the buffer around in memory? There must be a simple transform I can apply or something rather than expensively doing that in software. (This could really use MDMX. I'd just AltiVec it on PPC.)

it's a Tomy Tutor, although I have never actually seen one.

Close! You are very, very close! It's the Tutor's older brother, the Pyuuta: http://www.floodgap.com/retrobits/tomy/pyuuta/

ClassicHasClass wrote: GL h4xx0r5, is there an easy way to flip glDrawPixels other than by labouriously turning the buffer around in memory?

glPixelZoom(1.0f, -1.0f)
You will also need to start drawing the image at a different y position, use glRasterPos to do that.

ClassicHasClass wrote: So far so good. Next, the Orange Micro iBOT FireWire camera..... it works fine here, as the image proves... TAKE THAT, RECONDAS!

Nicely done ClassicHasClass, I'll gladly take it (and add it to the IP35 Hardware Aggregator)

In reference to the avc_vidtogfx producing an inverted display, ClassicHasClass wrote: Perhaps it's useable like this in the Southern Hemisphere.

If we can get to the point of capturing a video stream to a useful format with avc_vidtomem, GMplayer has an option under the 'Video' tab in the Preferences Panel to "Flip image upside down'.

ClassicHasClass wrote: Notice that periodically avc_vidtogfx and the device get out of sync and you have to do it again.

Does the Canopus ADVC-300 output a compressed or uncompressed video stream? Probably unrelated, but if you haven't already seen it/tried it, there's a note in the avc program folder that mentions devices that deliver compressed video to the avc_vidtoxxx programs need 411 sampling, and those that deliver uncompressed video need 422 sampling.

The README file in /usr/share/src/dmedia/video/avc wrote: Note that most AVC devices use DV compression, which limits the sampling to 411 compressed DV. 422 is only available for AVC devices that support uncompressed video.

If you'd like another opportunity to beat me to the firewire punch, about a decade ago the fcc mandated that cable HDTV set top boxes include a firewire video-out port (the set top box here has two 1394-out ports, but it's about 25 feet farther than the FW cable length spec).

Comcast even offers STB Firewire Drivers for Windows , and the AVS Forums have a multi-page topic on the same subject . The Win references obviously aren't useful to us, but there's a brief mention on the Comcast page

Comcast wrote: If you simply want to capture a Firewire stream..... then all you need is the AV/C Tuner device."

Life with IRIX is rarely that simple, but it at least opens the possibility of another test source for the DM10 and the avc versions of the sample programs.

ShadeOfBlue wrote:

ClassicHasClass wrote: GL h4xx0r5, is there an easy way to flip glDrawPixels other than by labouriously turning the buffer around in memory?

glPixelZoom(1.0f, -1.0f)
You will also need to start drawing the image at a different y position, use glRasterPos to do that.

It's already there, I think. I played with a few different iterations and all I got was a black screen. When it goes to blit the bits, it starts at the bottom and works back, but setting it to 0.0 didn't fix it, unless I'm totally wrong somewhere. I don't have the Fuel on right now, but I'll check the source code when I'm in front of it again (later this week).

recondas wrote: devices that deliver compressed video to the avc_vidtoxxx programs need 411 sampling, and those that deliver uncompressed video need 422 sampling.

I didn't check to see what it was selecting. I'll also check that and report back.

But, I don't have cable or satellite or even Netflix, just an antenna and a big stack of DVDs, so I'll have to defer the DVR testing to someone else. I am, after all, a big Luddite.

ClassicHasClass wrote: It's already there, I think. I played with a few different iterations and all I got was a black screen. When it goes to blit the bits, it starts at the bottom and works back, but setting it to 0.0 didn't fix it, unless I'm totally wrong somewhere.

Try setting the starting y offset to the height of the image you're drawing

Cable HDTV set top box connected via firewire Shows up as an AV/C device, but didn't appear in an mlquery (possibly because I tried this with the cable box powered but not running). The SGI gear is a bridge too far from the incoming cable terminus, so the cable box was tried without a cable connection. Apparently the cable box net boots, because without the cable attached, it hangs with "booting" displayed in the LED panel.

Since not having the cable box booted and running may or may not be the reason that it didn't appear in an mlquery, has anybody else got a firewire equipped system and a (more) conveniently located cable set top box they could test?

If the files produced with the avc_vidtomem program are in mpeg-transport stream format , Mplayer may be able to play them (and if necessary, invert them). ClassicHasClass, if you have the opportunity could you try an avc_vidtomem capture from your Canopus AVDC 100?

ClassicHasClass wrote: I mentioned hot swapping. It doesn't work. In fact, it seemed to hose the FireWire driver so bad that I had to hard-power-down the machine (the console was spammed with tons of FireWire errors about bad or missing targets and the kernel just sat there emitting errors forever until I hit the hard reset). Resetting mldaemon only worked the very first time for me (no devices seen and plugging one in). It wouldn't work for other devices after that.

It's probably lurking right around the corner, but so far (knock on wood) that hasn't happened with the Tezro. No obvious reaction from the system when I hot-disconnect a video device from the DM10. When I hot-plug a new device "Scanning FireWire bus" appears on the console and in the syslog. Here's the entries produced when I hot-unplugged the iSight and hot-plugged the cable set top box: Perhaps attributable to differences in the Fuel-Tezro PCI bus topology?

Yes, I'll see what I can get out of it (though I'll probably test the output on the G5 since I have my media tools there). Note, for pedantry's sake, that it's an ADVC-300 -- not that this should make much difference, but the -300 has a TBC and I don't believe the -100 does.

Also, I found my Pyro A/V Link and I'll give that a spin as well. I suspect the problem reported by the original tester was that it does not have a TBC. This isn't a big deal for computer output; it *is* a problem for people using dodgy sources like consumer VHS decks.

As Duke Nukem once observed, I'm back .

First, let's get the agony of defeat out of the way -- the ADS Pyro A/V Link appears to be a non-starter. This unit works fine with my G5, by the way, except for the aforementioned lack of a TBC. It has a bad habit of dropping on and off the FireWire bus, particularly when switching it from digital to analogue. The Mac doesn't care, but mlquery loses track, and starting and stopping mldaemon doesn't bring it back. After some devious timing, I managed to bring the whole system up with it in analogue mode connected to the Tomy.



Unfortunately, that's about as much victory as I got:


... after which avc_vidtogfx just locks up. After killing it, I tried using some other samplings with no joy:



I consider the Pyro A/V Link thus a lost cause unless anyone has any other ideas. But it works great with the Mac!

Having thus dispensed with the bad news, here's the good news and the better news. The good news was that Mr. Blue was half-right and I was half-right. He was right about the GL flipping, but I was right that it was already in the source code. In a duh! moment, I just took the glPixelZoom out and reoriented the glDrawPixels:



Et voila, with the ADVC-300:


And the best news of all. On a brainwave, based on recondas' prior post, I dumped avc_vidtomem to an .mts file. And guess what can play it?


Yes, laydeeez, the MTS file is fully playable by Irix itself. There is no audio; I wasn't able to get that to work yet. But the video files it generates appear to be completely compatible. No screen flipping was needed for avc_vidtomem; that's unmodified.

I'm pretty pleased about this! Still can't get hot swapping to work, though even pushing my luck it didn't crash today.

Nicely done CHC!

Updated the Fuel (IP35) Hardware Aggregator to change the status of firewire video from questionable/not-working to functioning-with-the-right-device.