2002/07.24 @21:11 (articles, blog, digital video)

video capture: the first steps

beos/hauppauge wintv

Hmm, well that was nice. It’s a wonderful OS, bringing elegance and slickness to the desktop of even ‘slow’ machines, if you can find a selection of hardware with the correct drivers. It can do multiple video and audio streams that even today’s O/S have trouble with, and the default versions even came with Japanese localisations – how about that for a US company ?

Well, not so great, actually. There was an unfinished BT8x8 video capture app. that came with some of the later versions, and if pressed it could cope with PAL and 25fps, but for some reason, despite contacting the author and having quite a few exchanges with him, there was never any move to cope with European audio, particularly NICAM. The stills of Emma from 1999 were grabbed via the Hauppauge WinTV card and this driver, but I could only ever get AM audio decode to give intelligble sound, but AM decoding an FM signal isn’t a recipe for CD quality audio…

Would I have stuck with it otherwise ? Maybe. I never managed to get as far as sorting out an editor for capture footage, and perhaps (given the lifespan of Be) that wasn’t such a bad thing. I’ve still not found a better filing system though, <sniff>…

linux/hauppauge wintv

Hah. What a waste of time.

Ok, that might sound a little harsh, but this was a few years ago – things have now improved to the point where you can get a vi workalike video editor…

The main problem with Linux is the plethora of devices and drivers and other obscure kernel options. Trying out binary releases of Broadcast 2000 nearly drove me dotty, and it was mostly this experience which made be look harder at the *BSD’s in terms of day to day operation. Latency ? Don’t even utter the word (not that Redmond do either, of course…)

After reading about what I needed to do to Windows 98 to ensure a clean capture it’s just as well I didn’t get very far – just sit for a moment and imagine the number of programs that a typical installation will run when it deems fit, and no: killing off cron doesn’t solve them all.

win98/hauppauge wintv

At this point (which was about the same time as I was trying BeOS, and Linux out) I started to discover the main problem with video capture: the size of the data set that is created. I was trying to get the best possible quality, which meant full frame PAL with CD audio sampling. No, stop laughing now – I was new to this. For those that can’t see the joke, try this:

768 x 576 = 442,368 pixels per frame
x 2 = 884,736 because we want at least 16bit colour
x 25 = 22,118,400 because we want nice 25fps motion
 
44,100 x 2 = 88,200 bytes per second for mono 16-bit sound
x2 = 176,400 bytes per second for a full stero stream
 
Total: 22,294,800 bytes per second video stream

Now this wasn’t going to happen with the motherboard and hard drives I had at the time, so I went and had a think and decided that the best method was to get a capture card that could reduce the amount of data I needed to capture.

win98/iomega buzz

This was the next logical step for me – the board was reduced as an end-of-line, and the compression was nice and deterministic (oh, and I understood it). The breakout box provided for the video connections was great – it’s still not around on some much more expensive systems, and yet it’s all so obvious to anyone who likes to plug more than one device into the capture card. The user interface was broken, and the video editing software was, well, excreable. I shan’t rant about it just yet, but if I get a bad day, then you’ll be able to read about just how bad I thought it was (and how Sonic must have bought those same developers for MyDVD).

The interface allowed the selection of frame dimensions (QCIF, CIF, Full frame, etc.) for capture, and it also allowed the compression to be adjusted. Unfortunately, the programmers flipped and decided that everyone would be happy with CIF frames, and changed the compression slider to match: 10k to 200k frame size was the option, except that you had to multiply by 4 to get the correct answer for 768×576 video. Still, the results were good, and the resultant video stream was fairly easy to edit due to the fact that each frame was self-contained, and merely a sequence of JPEG images.

No, the only problem was the audio. Like most PC solutions, the audio was handed off to the sound card for capture – logical and obvious and quite a money and time saver. Unfortunately, also totally rubbish. The delay between the audio and video was slight, but try capturing more than 5 minutes of video, and the drift had become noticable. Changing the video compression made no difference: the two capture clocks just didn’t stay in sync. Time for a new approach, as I didn’t think that I could be the next Peter Jackson[1]

[1] What, you don’t understand ? Ok, Mr Jackson was on a very limited budget for Bad Taste, and only had one camera. A 16mm film camera. A clockwork 16mm film camera. Still not enough ? It only managed to record 30 seconds (I think) of footage at a time, and hence the film has a fast pace due to the frequent cuts required. I don’t really think that I could do many home videos like that before no-one would sit through anything I did.

Especially if they all turned out like Bad Taste…

win98/ati all-in-wonder

Around this time I was also putting a bit more thought into how I was going to present the final movies. Not all of my family have computers, and those that do don’t necessarily have a PC or a Mac – with the Buzz it was fairly obvious: simply use the composite video out connector to dub straight to VHS, and keep copies of the MJPEG AVI’s on CD-R for archival.

I started to get interested in MPEG-1 compression after I bought a VCD adaptor for my Playstation (SCP-1001, now deceased) and imported a few films from Malaysia (Dark City, Michael). The quality was quite remarkable, even if they also seemed to have audio drift issues, so I started thinking about capturing in MPEG-1, which was a more readily viewable playback format than MJPEG. The cards in this area weren’t as cheap, but the AGP version of the All-in-Wonder Pro was out, and a friend built a machine with one in. I got to see what it could do for capture, and I decided it was the way to go.

Because I didn’t have AGP, I also needed a new motherboard, and given that I’d sussed out the amount of data I needed to move for lossless capture, I went for the ABit BE6 as it had the normal IDE interface and then an integrated HighPoint HPT366 controller, which offered ATA-66 performace. Having scoured on-line reviews, particularly Tom’s Hardware Guide, I had decided on IBM drives as giving the best performance for long captures. Then I just bought the fastest CPU I could afford: a PIII 450.

This was good. I could now capture in MPEG-1 realtime full-frame, and I could almost manage sustained uncompressed capture if the hard drive was totally empty (I had one 20GB for programs, and one 40GB for capture) and if I pulled up the task list often enough to kill off all unwanted programs. This took quite some time: I often had to uninstall software if it left too many extra tasks lying around, as the machine was quite apt to tumble and start dropping frames during uncompressed capture sessions.

I wasn’t 100% impressed with the quality of the MPEG-1 files: they certainly weren’t as good as the best I could get with the MJPEG Buzz card, but they did stay in sync for much longer. The other problem was editing the stream, as MPEG is referential in its compression, with any one frame referring to those that came before it for the full picture to be extracted. This makes any sort of off-line editing tricky, as only the I frames (every 12 frames or so) are complete, but there are some tools out there that will do the trick, as well as some that will allow simple cuts only on the I-frames. This would be good enough for my purposes: I was only trying to beat dubbing from the camcorder directly to VHS afterall.

win98/virtualdub/huffyuv

Ahh, VirtualDub… What a program that is. If you have any sort of interesting in how the streams are put together, or if you like the idea of QuickTime Pro but want more codecs and control then go and grab a copy immediately. Using this program rather than the (frankly not very good) ATI built-in capture system I could get much better results with full frame PAL uncompressed captures. The overhead of the software was very low indeed, and apart from the size, the editing ability was much better, with frame accurate cuts possible. The only real drawback now was the Windows 98 2GB AVI file size limit, but even then the answer was fairly close.

HuffyUV is a very, very handy codec indeed – it allows AVI files to be capture in a lossless manner, but manages to cut the amount of information that needs to be spooled to disc in half, resulting in super smooth captures. The best bit was the ability to keep the video and audio clocks in step: the program would trim up the stream as necessary, dropping a frame if required so that the drift was never noticable.

Around this time I also found that the display mode also made quite a difference to the capture frame rate, with the optimum display size vs capture speed being 1024×768 in 16bit colour. More colour was a waste of time (and didn;t alter the capture colour depth anyway) and slowed the system down, and 800×600 was just too painful to contemplate. Dropping down to 256 colours slowed everything down again as the colours had to be matched to a palette rather than simply shoved onto the screen.

Unfortunately, the lack of storage thanks to the stupid 2GB AVI size limit was getting very annoying indeed, as was the general instability of Win98. I was also starting to get interested in MPEG-2 as an alternative to MPEG-2 encoding, as MPEG-2 allows fully interlaced material to be captured and played back still interlaced. This gives much smoother motion on a TV set, and SVCD’s were starting to pop up. Ok, they only had 30 to 40 minutes of video on a CDR, but how many home movies last that long without the viewers wanting to gnaw their own legs off ?

The CPU I had wasn’t good enough to do realtime MPEG-2 fullframe, so I went and found out that in the time I’d been messing around Slot 1 CPU’s had come and almost all gone again. Althons were now the order of the day, and I ended up getting a palty PIII 700 for the sort of money that would have got me over 1GHz of Athlon… Of course I had too much time and money invested in the motherboard to want to change that too, so I did the next best thing and bought another Slot 1 motherboard and gave my wife a decent speed machine for her music work.