Quicktime 7.1 shipped yesterday. Overall, it’s a nice little point release – improved performance, more control over export settings (deinterlacing, hoorah!) and a few other odds and ends.

First off, I’d really like to see FCP5.1.24 ship – or whatever version number they give the “technology demo” they were showing at NAB (and promising to ship that week). If they were very clever it’d be .24 though.

Second off, I’d really love to see Quicktime support HDV natively. Now, I know that Quicktime has always had an uneasy relationship with most things MPEGy in nature. I suspect that more than anything, it’s been an ideological stance on the quicktime team’s part – they believe that muxing all your content together is fundamentally wrong, and have just decided not to support it. I can’t really think of any other reason why, after 15 years, Quicktime can’t internally demux an mpeg transport stream.

In any case, Quicktime as it stands right now, knows nothing of playing back or capturing HDV content stored in a transport stream (which is also the way the content comes down firewire from your camera). This means that you can’t capture HDV in quicktime, nor can you play back the video from a Firestore FS-4ProHD. Which makes me sad.

I’m pretty convinced that this is also the reason FCP has such jenky HDV support for capturing. If you’ve spent time working with it, you’ve noticed that you get an entirely different “Log and Capture” window when using HDV. Also, if you shark the process, you’ll see that they’re making calls in to TSDemuxer and some other components of the FirewireSDK. As best I can tell, the FCP team has had to write a whole separate capture/demux/decode chain in order to support HDV, because Quicktime isn’t handling it for them. It just seems like The Wrong Way ™, and it’s especially obnoxious if you’re trying to write an application which needs to decode HDV. *Cough*

Ok, enough rambling. I’m just so far behind on the blogging – my head has been filled with REALBasic code and end-of-semester nastiness.