February 2006 | Main | April 2006

March 31, 2006

Final Cut Pro 5.1 acknowledges the existence of the Canon XL-H1

No, it doesn't support 24f (Version 6 at NAB, right guys?), but at least the Late Breaking News document acknowledges that the XL-H1 exists, giving some hope that at some point in the future we may get full support. Hizzah!

Posted by at 11:44 AM

March 30, 2006

Go watch TikiBar TV

I'm not one to advocate drinking, but anyone interested in video production should watch some episodes of TikiBar TV. You can subscribe to it in iTunes if that's your bag.

Why the recommendation? It's one of the most beautifully shot and composited video podcasts, plus it's clever and funny. Plus, the folks making it actually went to film school, yet it's not pretentious tripe.

Check out their forums as well, particularly the FAQ forum, to get some insight into their workflow.

Posted by at 9:14 AM

March 29, 2006

Universal Final Cut?

So, Macrumors says Final Cut Studio is universal now. I can't seem to find anything on Apple's site confirming that...

Any bets on whether Final Cut Universal actually works?

Posted by at 2:20 PM

March 28, 2006

Check out the PixelCorps

Initially, I wasn't quite sure what to think about the Pixel Corps, Alex Lindsay's digital post production guild, but having heard him speak more on This Week In Tech, MacBreak, and DL.TV, I'm really getting interested.

The gist is that they're a worldwide group of folks interested in film/video production and post-production. They offer training, real world opportunities, and discounts on software. It seems like they trend almost exclusively towards the technical side of things, giving people the tools and the knowledge of how to use them.

Alex is also a serious video geek - anyone who gets giddy over 4:4:4 dual-link HD-SDI is all right with me.

Anyways, if you're interested in the technology side of things, I highly recommend browsing the PixelCorps website, to see whether it might be a good fit for you.

Posted by at 10:43 AM

March 24, 2006

Writing my own FTP client...

So, Navdeep Bains helped me immensely by updating his FTPKit ftp socket class to support large files (bigger than 2gigs), but I kept running in to problems - resume was broken, queues were broken, etc. Since I didn't have access to the source, it meant going round and round with Navdeep, and while he was incredibly helpful, it just seemed problematic. So, I'm writing my own class. And that's why I'm not posting here. Because I'm stuck in a horrible world of uint64 bugs and reading RFCs...

Posted by at 4:12 PM

March 23, 2006

Getting video framerate through the Quicktime API

This is a topic in which pitfalls abound, but I think I've just about sorted out the various ways to get an accurate idea of the a video file's framerate. I'm using RealBasic for this, but the calls should be pretty generic in any language that talks to quicktime.

If you poke around a bit, you'll find that the Movie.Timescale property is "sometimes" the number you're looking for. In particular, video files generated from Apple applications (FCP, Compressor) seem to have their timescale set to the framerate. However, many other files will have their timescale set to the sample rate of the audio track, or perhaps to something entirely different.

If you can use the timescale, go for it. It's much faster than the alternative. Note that it may come in as an int - so 2997 instead of 29.97.

What I'm doing is testing whether the timescale number makes reasonable sense in the context of video. I figure I'm not likely to have a video with a framerate higher than 60fps, or lower than 10fps. If the timescale result falls somewhere outside those bounds, I fallback to an alternative method.

By using the GetNextInterestingTime Quicktime call, or in Realbasic using NextInterestingVideoTimeMBS (requires MonkeyBread) you can measure the time between frames. NextInterestingVideoTimeMBS will return the current time in the movie and the duration of time between two "interesting times" (which usually equate to frames). The number you're most interested in is the duration. By calling NextInterestingVideoTime a few times, you can be sure that the duration of each frame is the same.

Once you've got your duration number, you can divide your Timescale by the duration, and get the number of frames per second. You can even reset the Timescale to your new value (multiplied by 100) and then use the TimeDuration call to get the length of the movie in seconds.

Seems to work pretty reliably on the videos I've thrown at it. Anybody have better methods?

Posted by at 2:19 PM

March 22, 2006

Realbasic Amazes/Frustrates

One codebase, one button, three windows:

Threewindows-2
Click for a larger image

Read on to find out how ...

Realbasic is an object oriented crossplatform development language that lets you build and distribute binaries for Windows 98/XP, Mac OS X and OS9, as well as Linux with GTK2. It's fast and fairly robust.

The Realbasic IDE is fairly straightforward. If you've used XCode/Interface Builder or any other modern IDE you should come up to speed pretty fast. The integration between the interface design elements and the actual code is much more straightforward than the Xcode approach, and in my mind it makes things a lot simpler.

Realbasic Interface
RealBasic Interface

If you've used any object-oriented language in the past, you'll get familiar pretty quick. The layout of the IDE pretty much forces you to be very object-oriented in your code design. It's been quite a while since I've done any Java work, and my PHP tends to be rather un-OOPy, so it took me a bit of time to wrap my head around the various concepts - methods, properties, events, etc.

One of the most powerful features of Realbasic is the amount of built in capabilities. For example, not only do you get SQL support, but you can built an SQL server into your application for internal use. Graphics (2d and 3d, including vectors) are built in, as is Quicktime support on Mac/Windows, along with decently robust networking support. Plus, although the language is little more abstracted than C, you still get some hardware access if you need it.

You can also build not only GUI apps, but console (command line) apps and daemons.

Additionally, there are lots of very handy classes and plugins out on the net. Most of them are commercial but reasonably priced.

A few downsides - first off, a problem I've run up against is a lack of support for files greater than 2gigabytes. Why such a limitation in this day and age? It just doesn't make sense, and it's causing me no end of trouble.

Second, I find the documentation to be poor. There's plenty of it, but it's scattered around multiple files, and the built in language reference is frustrating. They should really consider replicating the system at php.net, which I think is the most user-friendly and helpful system out there.

Anyways, I highly recommend folks check out RB if you're interested in getting in to crossplatform GUI development. Some folks are doing highly cool things with it.

Posted by at 4:13 PM

March 21, 2006

RealBasic is Kinda Neat

The reason I've fallen off the face of the planet the last few days is that I've been wrapped up in learning RealBasic. Since nobody seems to know what Realbasic is (except Mike of course), I'm going to get together a longer post about the coolness of it. I'll have it up later today.

Edit: OK, got all crazy busy doing some cool code this afternoon. Will tell you about it tomorrow. RB is just too cool!

Posted by at 2:03 PM

March 18, 2006

Not Dead

Sorry, it's spring break, I'm out of town. Nothing of note in the biz anyways, aside from someone mentioning that HDCAM is EOL'd - that can't be true, can it?

Posted by at 6:21 PM

March 14, 2006

Creating video framegrabs from the command line

So, I've been hacking around with different methods for getting stills from video files via the command line. This is part of a larger project I'm working on, but I figured I'd document what I've come up with to hopefully make things easier for folks in the future.

Click the link for more...

So, first off, if you're not working on a Mac OSX / OSX Server platform, your options are pretty limited. You're pretty much guaranteed to end up using something related to ffmpeg, unless you go for commercial software.

In my case, this needs to happen via some interaction with a php script, so the easiest approach is to use the ffmpeg-php extension. This is actually a very cool extension, though it's rather fiddly to get installed right. You can get all sorts of information about a video, and extract whatever information you need.

A few downsides present themselves though. First off, ffmpeg is what we might fairly call "patent encumbered." Because nobody is paying the MPEG-LA for use of the mpeg codecs, ffmpeg is in violation of any number of patents. Now, you're fairly unlikely to be personally harmed for using it, but it's important to be aware of the legality.

Next, and more pressing, ffmpeg is terrible for doing frame grabs. You get lots of control, but it gets slower as a linear function of how far into the video you need to seek. It almost seems like it converts every frame of the video up to and including your target frame. On my 2ghz g5, it can do a grab of the first frame of a video instantly, but grabbing a frame from 10 minutes in can take up to 60 seconds. That's unacceptable. I need to poke in the code a bit more to get a better sense of why that's happening - it happens with both the CVS and stable branch, no matter how I compile it.

As best as I can tell, if you're on a non-Mac platform, that's really the only free way to do it. So let's move on to the Mac options.

First, you can use applescript (via osacript) to make Quicktime do it for you. You'll need QT Pro. This may be a good option for very low volume uses where you can monitor the display. Unfortunately, my experience with applescript and Quicktime is that things often go awry. Further, you're limited to performing one operation at a time, which is tough to do when you're deal with web access. You'd need to create a backend to do batch processing at intervals - no fun!

Next, you can use the QT_Tools software. This is a very lightweight set of applications which make calls into the Quicktime API. If you're looking to learn the Quicktime API, these are actually pretty helpful too. The source is available, but developer support is limited.

Semi-related, you should take a look at the movtoy4m software. It also uses the Quicktime API via the command line to do simple video processing. It's pretty helpful for pulling basic information. It is essentially abandoned at this point.

So that's where I'm at. I think for my solution, I'll end up using the QT_Tools route. I'm somewhat tempted to learn how to write a php extension and just code my own PHP-Quicktime ext. I get the feeling though that this wouldn't be nearly as easy as it seems. Perhaps I'll just make some very stripped down binaries I can call from within PHP.

Anyone have a fantastic option that I haven't thought of?

Posted by at 6:02 PM

Ross sent me an MD Chassis

So yesterday a very bewildered Fedex guy (having navigated through our little snow storm) came to my office saying that he had a big box on a pallet for me. It turns out that it was a spare chassis for a Synergy MD switcher. Which I haven't requested, yet was addressed to me. And I seem to be the only one who finds this odd.

Hmm.

Edit: Ok, apparently it's a replacement chassis so that I can swap our cards around and then take advantage of a software upgrade. They just forgot to let me know...

Weird.

Posted by at 9:56 AM

March 10, 2006

Fantastic HDV Articles

Take a look at these two fantastic articles about using HDV on the set of "24." Really well written stuff...

Posted by at 10:59 AM

March 8, 2006

Focus almost gets it right!

On the third try, I received three FS-4ProHD 80gig Firestore recorders. They're all NTSC too! All three work, but one came with a faulty charger. So, that makes us 2 for 9 I guess. Hrm.

Anyways, they work pretty well as far as I can tell. I'm going to try and do a full review on Friday.

Posted by at 4:52 PM

March 7, 2006

For-A Hanabi

Ok, I've never heard of this company before. That may be my own ignorance though. For-A has announced a portable HD/SD switcher with HDV, DV, SDI and HDSDI. It's called the 2M/E Hanabi and it's supposed to be "affordable". Sub $30k. Take a look at the spec sheet, and be amazed! They're definitely going on my "See at NAB" list.

 Product Img Hvs3800Hs 01

Posted by at 4:44 PM

Thoughts on Avid buying Medea

Meant to blog about this the other day. Avid announced that they purchased Medea. This, combined with Avid's purchase of Pinnacle Systems a year ago, makes me very curious about what Avid's longterm growth plan.

The first point that interested me is that the press release that apparently describes the purchase just talks about some new products that Avid/Medea will be selling. Avid doesn't have any documents that mention that they actually purchased the company (as best as I can tell). Medea links to the press release with the link "Avid Acquires Medea."

So, first off, it seems odd that Avid forgot to mention that they bought the company.

Next, Avid already had a pretty robust line of storage products. I'm not sure what exactly Medea adds to their capabilities - the Medea VideoRaid product isn't a direct competitor to the Apple xRaid - it's sort of in the next tier up, utilizing scsi discs at the expense of... well, expense.

Similarly, I haven't seen much in the way of integration between Pinnacle Systems and Avid.

So, is Avid pulling a Google/Yahoo, buying up companies so that other people can't have them? I'm starting to wonder. It is starkly different from the Apple approach, wherein a company that is purchased essentially ceases to have ever existed. Just... odd...

Posted by at 3:55 PM

March 6, 2006

24 frames of sadness

I find it absolutely astounding that support for 24p/24f HDV video post production is so poor. Final Cut can't do it right, Avid can't do it right, Premiere can't do it right.

I understand that something like Final Cut can't be "turned on a dime" so to speak, but seeing as 24p was the buzzword to have in a product over the last few years, I can't understand why support has been so slow in coming. As best I can tell, neither Canon or JVC do anything particularly unpleasant when they write the signal to tape.

I wanted to take a moment to quickly run through the different options for cutting 24p/24f on a Mac, to try and sum up why they're all terrible. Follow the jump for more fun and depression!

Frowny-1

First up, you can try capturing your video with log and capture. This will fail. But at least you can say you tried. Final Cut doesn't understand the 24fps timebase in any HDV mode.

Next, you can buy a product like LumiereHD or HDVxDV. Lumiere HD will definitely work with the JVC, and rumors tell of support for the Canon. You are recompressing the video to a new format (DVCProHD most likely, though you can use other QT codecs) but otherwise it's pretty straightforward. LumiereHD also gives you the option of going back to tape. It is, however, $180.

HDVxDV is a $100 cheaper, and definitely supports the Canon format, but does not seem to be as robust a product as Lumiere HD. Many folks who are using it are running in to showstopper bugs.

The next option is decidedly free-er but a lot more work. First, you use DVHSCap from the Apple Firewire SDK to ingest the video to M2T files. Then, use MpegStreamclip (a fantastic program) to transcode the video into DVCProHD 1080p24. Then (sometimes at least) use Cinema Tools to conform the file to a 24 or 23.98 timebase. Then modify a FCP sequence to be 1080p24 DVCProHD, drop the file in, and hope it all works. Usually it won't.

Some folks are also hinting that you can use the HDV Apple Intermediate Codec preset in Final Cut Pro. While this will capture the video successfully, you'll be working in a 29.97 timebase. You can use Cinema Tools to reconform your video so that the timing is right, but I still haven't figured a clean way to make the audio match.

Truth be told, all these options are terrible. Recomressing is never a good thing, and going to DVCProHD creates the potential for some pixel-aspect issues as well.

Please, Apple/Avid/Adobe... we beg you. Support these HDV modes!

(the graphic is for the folks who said I needed more... graphics)

Posted by at 10:15 AM

March 2, 2006

Crazy Busy

I'll try for an update tomorrow... a bit crazy busy right now...

Posted by at 4:27 PM

March 1, 2006

Slow Motion Video

There's been a lot of talk on the net lately about the various pros and cons of overcranking with the HVX-200 versus deinterlacing and undercranking the XL-H1. Here's my take on this issue.

One of the coolest features about the HVX-200 is the ability to vary the framerate. You can undercrank down to something like 4fps, or overcrank up to 60fps. This allows for really nice looking slow motion when the 60fps video is played back at 24fps. I always thought that was one of the coolest features of the Varicam, and I was a bit surprised to see it show up in the HVX-200. If you know you're going to be doing a lot of slow motion, that feature is probably a deciding factor in favor of the Panasonic.

Recently, a few folks on the DVInfo forums have been playing with ways to get similar results from the Canon XL-H1. Here's the gist:

Shoot 1080i60
Deinterlace to 1080p60 - you have transcode to the DVCProHD 720p60 present in Compressor, with the fancy frame controls
Conform the 1080p60 to 1080p24 using cinema tools
Drop in a DVCProHD 1080p24 timeline in FCP

Since the Panasonic doesn't have all that much vertical resolution (remember?) one could argue that this method can produce images that are on par with the native progressive images from the Panasonic.

It all seems like a bit of the dogs breakfast though. It's not practical for a real workflow - the time spent in compressor alone will take ages. Moreover, I've been doing some side by side tests and I'm just not convinced that the results look any better than making a speed adjustment to the original HDV clip in Final Cut Pro. Perhaps I'm doing something wrong... more experimentation is required ...

Posted by at 10:40 AM