So I'm sure you've tried sending screenshots of your n64 to friends, but why do that when you could just stream it to them? It's 2003 now, we can do that.

I don't think anyone was actually doing this in 2003, because the infrastructure just wasn't there. Twitch didn't exist, Justin TV didn't exist. Youtube did not exist. I'm sure some people streamed things to small audiences, but I wasn't out looking for video in 2003 myself. Homestar Runner was doing me just fine.

But, assuming you had the bandwidth and/or hosting, it could be done with basically just consumer hardware. The results aren't even that bad, considering what some livestreams still looked like 5+ years later.

How? Well, basically because Apple really, really wanted streaming video to be a thing, plus a few lesser known tricks that consumer camcorders could pull off. Roll them all together and you've got a surprisingly capable, 20 year old console streaming setup.

---

The prerequisites

Well first of all, you had to be a yuppie or otherwise had access to yuppie levels of consumer trinkets, because you're going to need a lot of them. You also need bandwidth, the thing no one really had like this in 2003. For the sake of this whole post, we're assuming you can push a few dozen Mbit up reliably.

We're also going to pretend that all of your friends are also well off and on reasonably good home lines. The average DSL connection isn't going to hold up for maximum quality here, that'll eat up around 10Mbit.

Other than that, we just need stuff.

The hardware and software

Despite recent technological advances, the N64 was still the peak gaming device to have in 2003.

... Just kidding, but we're using one for demonstration purposes here today. There's also a "Gamecube" (Wii) being used as well but that's not in a photogenic location.

So what we need here is a computer running OSX, with Quicktime Broadcaster installed and as much CPU grunt as we can get. Had this been in 2003, the fastest thing Apple would sell you was either a Power Mac G4 somewhere north of 1 GHz, or a brand new Power Mac G5 if you could get it. The consumer iMac G4 was available between 800 MHz and 1.25 GHz. All of those would also have probably had enough spare juice to run the QTSS at the same time, more on that later.

However, I don't have any of those¹, and they're big. Here's a late 2004 iBook G4. It's running at 1.2 GHz with OSX Tiger 10.4 (2005), and QuickTime Broadcaster 1.5.3 (2009). While not exactly period specific, they should be functionally identical to their in-era versions.

QuickTime Broadcaster is the important piece of the puzzle here. It's like an old, extremely stripped down version of OBS. It takes a single audio and single video input to encode and spit out into an RTSP stream. Not to be confused with RTMP, RTSP is Different and we'll need different software to reproduce it.

Remember what I said about QTSS? That's QuickTime Streaming Server, an RTSP server. This is the role that Twitch plays now, you send them an RTMP stream and they spit it back out for viewers to connect to, just also with a convenient (or awful, depending on who you ask) web video player instead of a local program. In 2003 no general online service exists to do this², so we must run our own. It is possible to run this on the same computer that QuickTime Broadcaster runs on, but my iBook won't run OSX Server, so we're using a separate box.

This in theory is the least important part of the chain as far as being "period specific" goes. I'm using a 2009 Mac Mini running OSX Server 10.6 (snep), but in theory this doesn't even need to be a Mac. Apple's own documentation mentions Darwin Streaming Server, the open(er) source version that should run on any popular OS being a viable option. Alas, that was a step too far for me in this project, so we're using almost period accurate QTSS.

It should also be pointed out that another feature common to sites like Twitch, multiple bitrate options, isn't really a thing here. I could find no info about re-encoding streams with QTSS. We've got one bitrate, and if that's too high for a viewer then tough luck. I know Apple's official live streams had multiple quality options, but it's unclear exactly how they went about producing them. It may have been as "simple" as duplicating the uncompressed output video and ingesting it on multiple systems, each running different encoder settings.

Anyway enough of this old computer nonsense, I know what you all are really here for.

That's right, old camcorders. This is acting as our ADC. Or in other terms, it's the capture card. What we want is a model that can do three things. The first, is accept video input from it's AV jacks. Most models by this era were capable of this, except for the lowest end ones. The second, is that it has a DV port for outputting video, and is happy to spit out the analogue video on it³. Third, it needs to have Sony's Laser Link functionality, which cuts our options down dramatically.

Laser Link is a very inaccurate marketing term for a feature in lots of Sony camcorders that allows them to IR blast the AV signal to a receiver. This was presumably another way to work around the whole "No one has 8mm VCRs but they need to play back the videos they shot on 8mm" problem, and the solution was "well make a box they can leave plugged in but put zero tape circuitry inside it". It's actually pretty neat and works very well. In our case, we simply need a second video output coming from the camera, ideally one that does not add any latency. Laser Link does exactly this, and even saves us a cable kinda sorta. Sony also made consumer-ish boxes that could do media conversion between DV and analogue video, including passing the analogue signal back out, but this is more fun.

I'm also sure someone made DV cameras with docking stations that would enable this as well. Please sound off in the comments and tell me all about them. :-)

So with those things, plus a small mess of cables, we get this. A console streaming setup that was entirely possible back in 2003.

There's one thing I wasn't able to fully verify. DV, the video format, has two audio modes. 16 bit stereo, or 12 bit dual stereo. Normally in 12 bit mode, one set of channels is used for the camera's built in mic and the second is the mic jack. In theory, the camcorder could take the audio from the mic jack and feed that into DV channels 3/4 while the external audio input goes through 1/2. QuickTime Broadcaster even exposes enough audio input options to make this feasible. However, I don't have the correct kind of mic and I wasn't able to get any audio via other inputs, so I'm going to chalk that up as a "maybe not". Which is a shame, because having game streaming with commentary without a like, hardware mixer, would have been sick. Of course you could just forgo the game audio and tell QuickTime Broadcaster to use the laptop mic or audio input, I suppose.

The Setup

Now that we have all of the pieces, the setup is relatively simple.

First, is to run our source into the camera. This camera uses a TRRS breakout, as do most that support our feature set, but we've also got a fiddly S-Video connector available here too.

Of course, the camera will be showing the game and you could play on the flip out screen if you wanted. I honestly think it looks pretty good on it, better than it'd look on a normal LCD.

Then we need to hook it up to the computer. This should Just Work, though if you have a bad firewire cable you can get all kinds of issues. Don't ask me how I know. If you have issues, swap out the cable.

QuickTime Broadcaster has a ton of video options to choose from, some of which were very much not intended for web streaming (Hello DVCPRO50). Surprisingly one of the newest, "MPEG-4", is the one we want. It's unclear if this is MPEG-4 (, the H.263-like standard; part 2) or MPEG-4 (, H.264; part 10), but either way it's what works the best here. This iBook is just capable of cranking out 320x240 at 30fps, if you leave it alone while it works.

Yes I hear you in the back, no we do not have any options for per-field deinterlacing, only per-frame deinterlacing. DV is 480i, and the whole setup does not seem to give a toot about the 240p input signal. I don't like it either, take that up with Apple or whatever.

This would also be a good time to point out that, this version of QuickTime Broadcaster may have had a better encoder than what was available in 2003. Frankly the quality of the video output is greater than I would have expected, even at the (relatively) high bandwidth settings we're using. I've been unable to track down a version from around this era, and I'd love to run the same tests again with it to see if there's any obvious differences.

Once we've got all that set up we need to point it at our QTSS server⁴.

Hey lil guy, you're fast as hell but someone broke your firewire. That's fucked up.

QTSS is built into the OS, you just add it as a service, check a few boxes, and set a login. That's about it.

Mildly annoyingly, the Broadcaster is where you'll see the output destination. In our case, the server's hostname /g4stream.sdp.

So here we have a "close enough" contemporary Windows machine. It's here to run XP, and run Quicktime. I've got to say, QT on Windows sucks shit. Glad that decades old memory was correct.

Assuming we've done everything right, we just put in the URL. Video loads up, and that's it. Job done.

The Results

It's, not terrible. The end to end latency is real, for sure, but it's not any worse than Twitch was 10 years ago. 320x240 isn't great but a G4 just can not push 640x480 without cutting the framerate below half.

Most N64 games don't really touch 30fps anyway, so they look fine enough in terms of smoothness. The encoder does a better job than I would have thought in motion, frankly.

Static text seems to be what trips this up the easiest, the low resolution not helping at all. This isn't quite like modern H.264 where static video will give it enough time to send a phat i-frame over and clean it all up, it just looks like crap forever if the background is too busy. Maybe QT Broadcaster is also heavily biased towards motion, I'm not sure. There's very few knobs to tweak in that regard, more on that later.

Switching to the gamecube, we can really see just how bad static images can hit this encoder.

I keep expecting it to recover but it just, stay fuzzy.

But what about high motion again? Well, we're not getting any of the Gamecube's smoothness through the pipes today, but,

At least for being able to tell what's going on in game, it's doing pretty dang good.

*

So the caveat to all of this is our streaming settings. This is set to "maximum bitrate" at 4000 kbit, which is translating out to somewhere in the neighborhood of 2000-2500 kbit shown bitrate. What happens when we back that down?

Well to start off, we have a bug. This is how things looked with the exact same settings as used in all of the above videos, but after a reboot. OBS can for sure trace it's lineage back to QuickTime Broadcaster, because I've literally changed nothing but something has broken. After giving everything a fiddle and putting it back where it was, we're back to normal.

... Except the audio isn't working. Lovely. Anyway, as you can see everything looks fine and we're in the 2000-3000 neighborhood. Unfortunately the displayed bitrate here seems to be the download speed, as that drop in the end shows not the screen transition but the stream cutting out as I changed settings.

Dropping the "max birate" down to 1500 completely mangles the menu screen, but the replay doesn't look quite as bad. Not awful considering we're staying under 1000 kbit on the download.

1000 max, around 600 shown. Now we're really getting into "15 year old niconico" territory of video quality. I also dropped the audio from 160 to 96k here, but that's being shoved into 160k AAC again for the video and the N64 wasn't very high fidelity to begin with, so it's not super obvious.

500 max, audio to 64, just getting worse. We're fitting the whole stream in around 400k now... but what if you wanted to try pushing this to someone on dial up? Well,

With the max bitrate set to 50, we're still seeing the total average well over 60k, more than any dial up would ever do. I also dropped the frame rate to 8 to try and give it some kind of chance. The audio was set to 16 but obviously was not working here.

It looks like shit and still wouldn't work. Bandwidth is king, surprising no one. But we got to see some pixels along the way.

Summary

It was for sure possible to do all of this in 2003, but the bandwidth requirements would have been a killer for almost everyone. For broadcasting as well as watching. It is, however, very neat to me. Hopefully it was to you as well. I do have a few unanswered questions from all of this:

• How much lower can you go CPU performance wise before 240p30 drops frames? 1 GHz? 800 MHz? I don't see this working on a G4 cube.

• What were the true origins of live streaming? I know people were doing it small scale before even the days of Justin TV, but it's not really something I have expertise in. What hardware did they use? What kind of bandwidth was required? How bad did it look?

• Was it ever even remotely possible to try and push live video over dial up? I'm guessing no, but I'm sure some people tried.

• Does that blasted mic input work or not?

---

1. That's not to say that I don't want all of them, but this whole project has taught me that PowerPC era CPUs were slow as shit and what I really love is how they look. I hate having things I can't use for something, somehow.

2. To my knowledge. I have seen Apple make references to just, hitting up Akamai and using them as your QTSS provider, presumably you probably could do this and it probably cost a not insignficant amount of money to do so. Again, if you or someone you know was exposed to notable online video streaming services before the year 2005, please let us know.

3. Notable exceptions here are Digital8 cameras that don't play back Hi8 tapes, my understanding is that those just have all of the ADC circuitry removed and the one I have on hand that otherwise functions wasn't having it. Earlier Digital8 cameras, such as my TRV310 and 315, also lack this functionality; they'll play back video from the AV jacks but as soon as you plug in the DV it'll switch to DV input. You'll want to read your user's manual and see if they mention a use for something like, recording VHS tapes to your PC. I guess you could do that with all of this too...

4. Yes, Quick Time Streaming Server Server. (Quick Time Streaming Server), the service, (Server), the physical box. I'm sticking to this one.