Does anybody know if there would be a way to pipe an MPEG1 AV videoconferencing stream from the web to the MPEG Media System Card in the old 5 & 6xx/6xxx boxen as if it were coming from a VCD playing in the unit's CD-ROM drive?

Between decompression in hardware on that card, the output being piped straight across the interconnect cable to the Philips Chipset on the Video Slot Card and then straight from there to the pixels onscreen and to the RCA speaker jacks without ever bogging down the CPU, the system bus or even hitting the VRAM buffer seems like it would be half of a slick lowend videoconferencing rig. Would using a serial based webcam and a 10baseT ComSlot card keep the i/o channels from stepping on each other's toes for videoconferencing using something like CU-SeeMe?

It'd be nice to keep some of these old systems out of landfills and put them to good use. The card supposedly works on the 68k 630 etc. as long as they are not DOS compatible revs, but I haven't verified that yet, other than mine DOES NOT appear to work in my LC630-DOS MLBs. That would be interesting to determine, but for now this is probably more of a Road Apple PPC kinda deal.

It certainly has the possibility to be done, but what I have learned through experience is that sometimes we search for practical answers.

Why am I rambling so much? do my sentences make sense?
Did I allways ramble this much?

quote:

---

Does anybody know if there would be a way to pipe an MPEG1 AV videoconferencing stream from the web to the MPEG
Media System Card in the old 5 & 6xx/6xxx boxen as if it were coming from a VCD playing in the unit's CD-ROM drive?

---

Quadra 840av, prettymuchmaxedout8xcd drive,3 monitors 15" & 14" & 14" os 8.1
, 12 meg ram, 500 meg hard drive
Performa400(asleepintheattick)

I think this one is more of a software issue, so I'm basically clueless.

Videoconferencing would let you avoid IM.

G4From128k

quote:

---

I think you would need to trick the System into mounting the stream as if it were a VCD. Perhaps you could hack a browser or internet app to dump the incoming stream into a FIFO buffer that is accessible to the MPEG Media System Card. The pseudodriver for the streaming media would make it look like a faked drive to the OS. The pseudodriver would handle the flow of incoming stream packets from the net and requests for file blocks out to the MPEG Media System Card.

---

That's kinda what I was thinking :rolleyes: maybe writing it to a RAM disk would make it easy to emulate SCSI i/o?

Dunno, I don't know much of anything about programming, but the coprocessing setup looks promising from the hardware angle.

Does the old serial camera from Connectix support output of an MPEG1 stream to CU-SeeMe? If that feed is compressed in hardware before hitting the serial port and the Mac can handle the sound input from the microphone port without bogging down and still juggle the various i/o channels to and from a DSL modem via a ComSlot card, it just might work on ancient hardware. Lowend VideoConferencing would be a lot of fun, you can't get hardware much less expensive than 630's and Road Apple PPC's.

quote:

---

Videoconferencing would let you avoid IM.

---

Obstinacy has worked just fine so far!

jt ™.
Trash Hauler: call sign: eight-ball
C.O. AC-130H SpecOps 68kMLAAF

quote:

---

That's kinda what I was thinking :rolleyes: maybe writing it to a RAM disk would make it easy to emulate SCSI i/o?

---

The only nasty bit is fooling the file system into letting one application (the streamer) write to the RAM disk file while the other application (the VCD player) reads from it. A third bit'o code would need to keep things tidy by deleting streamed data that had been read (unless one had a RAM disk the size of the entire stored stream).

quote:

---

Dunno, I don't know much of anything about programming, but the coprocessing setup looks promising from the hardware angle.

---

I agree.

quote:

---

Does the old serial camera from Connectix support output of an MPEG1 stream to CU-SeeMe?

---

Dunno, but many newer digital cameras have a "movie" mode that I suspect creates MPEG files and saves them to the memory card (e.g. compact flash). So perhaps one could create a brass board hack that acts like a two-ported memory card -- it plugs into both the camera and a SCSI memory card reader at the same time.

quote:

---

Lowend VideoConferencing would be a lot of fun, you can't get hardware much less expensive than 630's and Road Apple PPC's.

---

Maybe the BrickOven 6-Pack would have enough distributed CPU omph to do compression and decompression on both the video and audio streams??

G4From128k

by Day: Mild-Mannered Engineer and Trapeze(tm) Artist
by Night: Colonel of Truth, Justice, and the Macintosh Way
Reserve Officer in 68kMLA Cantankerous Coot Contingent

quote:

---

quote:

---

That's kinda what I was thinking :rolleyes: maybe writing it to a RAM disk would make it easy to emulate SCSI i/o?

---

The only nasty bit is fooling the file system into letting one application (the streamer) write to the RAM disk file while the other application (the VCD player) reads from it. A third bit'o code would need to keep things tidy by deleting streamed data that had been read (unless one had a RAM disk the size of the entire stored stream).

---

Three strikes! I'm out!

quote:

---

quote:

---

Dunno, I don't know much of anything about programming, but the coprocessing setup looks promising from the hardware angle.

---

I agree.

---

Good, maybe I'm not too far over the top on THIS one!

quote:

---

. . . many newer digital cameras have a "movie" mode that I suspect creates MPEG files and saves them to the memory card (e.g. compact flash). So perhaps one could create a brass board hack that acts like a two-ported memory card -- it plugs into both the camera and a SCSI memory card reader at the same time.

---

I'd like to keep it out of the hardware realm if at all possible, but I guess a USB VidCam/microphone rig that outputs MPEG1 and a do-it-yourself Basic Stamp kinda deal with one of the inexpensive USB->8 bit controller IC's would make a decent backup plan, but modern hardware would be easier and probably more efficient except for hack/bragging rights.

quote:

---

Maybe the BrickOven 6-Pack would have enough distributed CPU omph to do compression and decompression on both the video and audio streams??

---

That'd be fun! But the idea was to tie togeter different stock bits-n-pieces with an elegant software hack that'd allow novices to turn potential dumpster ballast into usable teleconferencing workstations for little or no money!

jt ™.
Trash Hauler: call sign: eight-ball
C.O. AC-130H SpecOps 68kMLAAF

It does sound like an icky data-line plumbing task, is the camera itself doing the MPEG encoding?

quote:

---

I'm thinking that you're not going to be able to do this type of thing in software *and* bypass the CPU.

It does sound like an icky data-line plumbing task, is the camera itself doing the MPEG encoding?

---

Edited by - Trash80toG-4 on 25 Feb 2003 08:37:29

1) I'm a bit confused (no news there ). It seems to me that you want to route the MPEG output of the serial camera out to the network for transmission to the recipient (not to the MPEG card). The MPEG card would handle the video stream from the remote party. Most of the time, you don't need to see yourself talking (OK, maybe during a setup process -- there might be a switch that routes your own serial camera output to your own MPEG card).

2) I wonder is *nix could help? Seems like the whole notion of "pipes" is exactly what you need. The key is to the pipe the output of the serial port to an appropriate networking port that sends the streaming MPEG data out to the recipient. On the receive side, one would pipe the incoming video stream from the network to the MPEG card. Probably the hardest nut to crack is the required *nix support for the MPEG card (software! BLEH!). I'd bet that if you can get *nix to work, that you could hack down the kernal to some minimalist distro of *nix that ONLY does the video conferencing.

G4From128k

quote:

---

A couple of thoughts:

1) I'm a bit confused (no news there ). It seems to me that you want to route the MPEG output of the serial camera out to the network for transmission to the recipient (not to the MPEG card). The MPEG card would handle the video stream from the remote party. Most of the time, you don't need to see yourself talking (OK, maybe during a setup process -- there might be a switch that routes your own serial camera output to your own MPEG card).

2) I wonder is *nix could help? Seems like the whole notion of "pipes" is exactly what you need. The key is to the pipe the output of the serial port to an appropriate networking port that sends the streaming MPEG data out to the recipient. On the receive side, one would pipe the incoming video stream from the network to the MPEG card. Probably the hardest nut to crack is the required *nix support for the MPEG card (software! BLEH!). I'd bet that if you can get *nix to work, that you could hack down the kernal to some minimalist distro of *nix that ONLY does the video conferencing.

---

http://pure-mac.com/intphone.html

The 68k Cu-SeeMe stuff might provide the software for doing what you want to do.

Enjoy,

G4From128k

if we could then have somewhat of a 5400 or something with this PCi card and the apple vid cam...

or with the Personal Media Centre that I wanted to do... to a G3AIO.... I'd probably want that WebCam, the PCI phone card, a TV/FM tuner, use the onboard 10BT ethernet and then have a PCI slot available for something more fun like maybe one of apple's PC cards.... (or not) this way it truly becomes a way to integrate so many different types of media and such..... (yadda yadda bladda)

68k Macintosh Liberation Army Forums

© 2001-2003 68kMLA