[Allan White]

You might look at Foundry’s Storm app – looks like a good tool at the top of the chain for .r3d trimming, metadata managing, and decent 1-light grading before exporting to your editor.

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

You need to compress 1,000 hours of video? Epic! My take:

Compressor will do what Jeff describes, play with short clips until you get the overlay correct.

It’s also not the most efficient encoder out there. I’d look at investing in Episode Pro from Telestream – it’ll do the overlays, has very powerful workflow/processing abilities, and (I think – jump in here Cow ppl) will encode more efficiently than Compressor (utilizing more cores & RAM).

Adobe Media Encoder on my new 8-core Mac Pro encodes H.264 more than twice as fast than MPEG Streamclip with the x264 encoder (which didn’t use all the cores). Very impressive.

For the amount of footy you have, you might also consider a hardware encoder like the Matrox MAX or ElGato USB dongle. If encoding takes a 2:1 ratio, you’re looking at 83 days to encode that material.

Hope you don’t mind not using your comp(s) in that season… What on earth generated this much footage?

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

Any insight into this issue in FCP 6? Your wisdom appreciated.

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

I would think you’d be able to preserve them as markers in the clip. Not sure how it works in Premiere, though I do something similar with CatDV which has a verbatim logger for transcriptions.

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

Why try to have 2000 hours of anything online? It’s just overkill.

We have 30 years of tapes in our vault, so we scan it all in with Live Capture (also from Squarebox) and save the previews as H.264. Same goes for file-based media – copy to a 1TB bare drive (2-bay eSata Dock), which gets backed up to a mirror disk.

2000 hours of MPEG-4 fits in a MUCH smaller spot. Use that to make basic edit decisions, then relink/recapture at online res for final edits (to, of course, a SAN of some sort. Great recs here from Z).

You would save tens of thousands of dollars – with minimal impact on production – with this approach.

Of course, if money is no object, enjoy a 200TB SAN if you can! =)

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

Hi Shane, a few thoughts and then I’ll leave it be. What I think is true is this: some workflows are more dependent on reel metadata than others.

At some point in the last year or so, our workflow crossed a threshold from tape- and physical-media-based to a much larger percentage of file-based media. While we still have a vault full of video (30 years’ worth), here’s a few scenarios that don’t work with the ones you mentioned:

• All media is brought in, copied to a media drive, renamed, metadata added in CatDV, then cloned to a mirror drive.
• Cards are brought in, downloaded, then wiped. It’s sent back out for shooting. We don’t need to care about what card or drive it came in on; once the media is downloaded and backed up, the capture media is ready for reuse. This is the same workflow I use for my photography work.
• Same with DVDs, hard drives (we’re getting a ton of volunteer-shot video, of every flavor). I don’t want to fish for a DVD somewhere, I want the video in the format I converted it to.
• Crazy, but true: we’re getting usable iPhone footage now. No reel info there, either! =)

Another fundamental problem I’d think stamping generic reel info (say, “live”) is that if there are any overlapping timecode regions, edit apps will get confused. They’d all have to have unique, non-overlapping timecodes (right?) to avoid confusing the reconnect stage.

My point is that FCP being tied to reel information is anachronistic (not surprising, given its ancient heritage). What I am going to change is what I do in CatDV (my “pre-edit” tool) – either assigning unique reels to new clips (ugh) or creating new timecodes for a logical group (say, a single day’s shoot) that don’t overlap (hours 1-8, etc.). Since Reel info gets baked into the clip, it should be a trivial step in the pre-edit that will prevent hassles downstream.

Thanks again for your insights. I’d be interested to hear more about your workflow ideas on your blog.

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

Not really a bug…it is information FCP needs to track footage. Just add it and you are good to go. Should be something you have anyway, to help YOU track the footage too. Without reel information, how do you know where a shot came from?

“Reel” is an antiquated concept moving forward. File-based cams can create clips that don’t have a tape “reel”. DVD rips (yes, we must sometimes…), motion graphics or specially graded/VFX clips, and live-captured events (say, from an EVS or ghetto cam capture) often don’t have reel information. Nor do they need to.

It should just trim the clip. A unique filename alone should be sufficient. Other systems do (right? PPro, Vegas, etc.).

BTW, if there’s a tape involved, you betcha we make sure it has reel info. 😉

Big fan of the Little Frog blog BTW, appreciate your contributions.

[Allan White]

I have racked my brains for a long time regarding the Media Manager. I’ve never heard that missing reel metadata was the cause of it failing to trim. Still a huge bug in my opinion – but thank you, Shane, for an easy solution!

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

Terry, I may have misunderstood – are you saying you’re getting CPU’s pegged on playback of H.264? That doesn’t surprise me, if so – I’ve seen that on older machines.

H.264 is very efficient, in the size vs. quality arena; that’s one reason it’s become so popular. It does require a lot of horsepower to play back, though. iOS devices have hardware decoding, so it’s very efficient there. Older CPUs won’t.

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server

[Allan White]

A couple of thoughts, Terry:

• x264 is highly optimized for Intel (x86) chips. It will suck on PPC, if it runs at all. =P
• You want full CPU utilization when encoding. A G4 won’t cut it, or will mightily struggle; you need a modern Intel chip for H.264 encoding to make sense at all. By “faster”, I mean faster encodes, which is of paramount importance when ingesting 10 hrs. of footage.
• Scaling it to 320×240 (which I often do, btw) also incurs a cost of scaling the video. In some cases, not scaling is actually faster, yielding less overhead. Any other opinions on that? I do it both ways (less valuable footy gets scaled, and encoded as low as 400kbps)
• I’ve been playing around with getting a Matrox MAX card (a fast, hardware H.264 encoder) to work with CatDV; should in theory. That would be a great addition to a PCI-X machine like your G5 for this use.
• @ Bryson – you might try having an MP4 will keyframes set to “all”; not sure if that adds much benefit. I shudder at how much space P-JPG would take for the amount of footy I have… but I can see why it would help. I get “frame-accurate” when it hits Final Cut, so I don’t worry about that too much in the “pre-edit” stage (where CDV gets used most in my shop).

– Allan White, Video Producer, Luis Palau Assoc.

Quad 3Ghz Mac Pro, 10GB RAM, X1900 GPU, XSAN, CatDV Server