I've seen this concern come up over and over again on several forums regarding the lack of camera-generated time code via HDMI capture from the Sony rigs or any camera for that matter, and I think it needs addressing.

Time code was developed as a way to reference frames of video and film back in the anolog days when a system of precise measurement was needed to make the editing process more manageable. These days it's still a very useful tool when recording to tape as a reference for capturing specific scenes from that tape to an NLE and as a pecise way to reference changes when cuts are reviewed by producers and clients. There are of course other technical reasons for the use of time code, but these are engineering issues that I don't fully understand or really feel I need to.

When it comes to direct-to-disk recording no tape is involved and therefore no need of time code as a reference to that footage for capture. It's all been ingested already. Some sort of time code will be added to the footage by whatever software you're using. The parameters of that time code will depend on the software you use, but even Microsoft's Videomaker asigns a time base to the video captured to it from a webcam.

So, why do we feel we need the time code generated by the camera when recording directly to disk and editing digitally? I would say we don't. We don't need it as a capture reference. We don't need it as an editing reference in most of our production workflows, and as a review tool the time code generated by our NLEs is more helpful in that process anyway.

So, what am I missing here? Why in this HDMI-to-disk situation do you think we need the camera generated time code?

Good question - for many workflows you don't need timecode, period. For others, any old timecode will do, for example TC can be added or changed at any stage for reference for client review.

However, there are some traditional applications for timecode that are still relevant in many workflows.

1) Logging. As a general rule, the earlier in the production - post process that good takes and key scenes can be logged the more efficient the process. Camera timecode is one way to do this, but not the only way. To use camera tc, an operator might call out "scene 1 take 4 tape 2 13:44", the 13:44 being the tc at the start of the take. A PA would write it down, at the end of the take the director might say "mark that one NG (no good), or "star that one", or "maybe that one, let's do another, but the 2nd paragraph was pretty good," which the PA would also write in the log.

Obviously, we're up to a 3-person crew already, and probably more, this is a workflow for production with multiple contributors, and it's been used since the early days, and people are using it all the time.

However, with a hard-disk recorder of some sort, each take may be in its own file, and it may make more sense to have whoever is operating the hd recorder do the filenaming and logging of the good takes... and maybe they'll be typing it on the same computer that is hosting the hd recording app... which wouldn't require TC, as the filename would be the reference.

2) If multiple devices are recording the action of a longer event (more than a takes worth), having free-run timecode recorded on all devices is a near-essential tool for efficient post-sync. This could be multiple cameras, or double-system sound, or both. In the world of dv and hdv, that's the most we can usually do.

As we get into higher-end gear, we can do more. The V1 promises jam-sync of timecode, meaning that you can get two or more free-running V1s to have the same TC... at least for a while (we have yet to see how much TC drift there will be over time).

The Canon XL-H1 does not only jam-sync, it does it over standardized protocols and connectors, meaning that you could jam TC to anything in the professional world, including studio decks, high-end hard disk recorders, audio recorders, anything that supports the standards. It will also run with a genlock signal, meaning that each frame on multiple devices will start at precisely the same time and remain synchronized through any length of take, or, come back tomorrow and everything is still synched. This is for larger productions and studios, which will have a master sync generators for all acquisition, recording, and playback devices.

But, back to DV/HDV production, timecode still matters for logging and the post-production syncing of multiple sources because it supports efficient workflows.

Nice response, Seth. I want to stress that this discussion in specifically about capturing via HDMI to hard drive for people reading the thread. That said, I will retort. . .

I can't completely agree with you on the logging point. Actually, you explained why TC isn't needed during the process in your reply. It can all be done on the capture computer. Takes can be marked good or bad with notes depending on the software you're capturing with. You just don't need time code references when you're able to capture to disk unless you're married to a tape-based production style.

As for the syncing of multiple cameras, I can see your point, but given that our topic is HDMI capture and time code, it doesn't apply. If multiple cameras are capturing to HDMI, current technology would require the same number of PCs to do it. Even in a tape-based environment using free-run TC is a challenge when you're using three different camera models from various manufacturers. Some of them have it. Some of them don't. And in that situation you can forget jam-sync. I'd guess most of us small guys use this production model and end up syncing visually.

Blackmagic does have a software called On-air which allows for live switching between two HDMI cards in one computer. It doesn't record both streams, but records the live switch to disk like a live television director would do. It's their answer to genlock, but at this point it only supports two cameras.

Great discussion! Who else wants to kick in?

Nice response, Seth. I want to stress that this discussion in specifically about capturing via HDMI to hard drive for people reading the thread. That said, I will retort. . .

I can't completely agree with you on the logging point. Actually, you explained why TC isn't needed during the process in your reply. It can all be done on the capture computer. Takes can be marked good or bad with notes depending on the software you're capturing with. You just don't need time code references when you're able to capture to disk unless you're married to a tape-based production style.


Oft times, notes are taken during the shoot, so you need cam reference points for that, unless your capture software provides real-time t/c display.

As for the syncing of multiple cameras, I can see your point, but given that our topic is HDMI capture and time code, it doesn't apply. If multiple cameras are capturing to HDMI, current technology would require the same number of PCs to do it. Even in a tape-based environment using free-run TC is a challenge when you're using three different camera models from various manufacturers. Some of them have it. Some of them don't. And in that situation you can forget jam-sync. I'd guess most of us small guys use this production model and end up syncing visually. ?
That might be your particular environment, but there are, and will be more, production groups doing exactly this with multiple computers. TC becomes critical for timely sync of multiple cams in post. Additionally, if you're smart, you're doing tape backup with these cams, and you may need to reference that tape at some point in time, such as HDD failure. While some manufacturers might want you to believe that HDD acquisition is entirely safe, anyone in the industry full-time will tell you that attitude is dangerous, mythical, and fraught with perils.


I understand why you make the arguments that you make, but your position is one of a one-man, one camera, one environment shoot. There are other scenarios, and neither position is entirely valid nor invalid. Leave it to say as well that there are those that have traditionally used T/C for other purposes, and it's a comfort, reference, and standard that is difficult to walk away from, particularly when it's not necessary to lose this aspect, and very beneficial at multiple points to have this information available.

Nicely said, Douglas. I can tell that both you and Seth have done your share of "big money" multicamera shoots and have done film and video for some time. Thanks for sharing that expereince with me and other forum users.

At this point I think it's safe to say that HDMI computer-based capture is at this point in the technology a one camera capture technology suited best for narrative indy shoots and possibly some single camera studio and documentary work. If your particular environment is one of multicamera event shooting it's probably not a good choice. As Seth and Douglas have pointed out, multicamera shoots require an extra level of time code accuracy for efficient syncing.

As for logging I realize it's difficult to throw aside a practice that has been in existance for decades, but computer-based acquisition is a totally new process. We are no longer referencing infomation on a tape. Each individual shot is captured as a separate file and each file can be named with all the information you need to identify it; Sc4-Sh2wide-T2-good.avi (or whatever file format you shoot as). No TC reference is needed, but if we're backing up the shoot with tape, which we certainly should, that reference can be placed in the notes if we feel it's necessary.

HDMI capture is obviously targeted to guys like me; finacially frugal independent content producers that want to spend a little money and get the highest quality image possible. Much of the time this means coming up with a new workflow, shoving traditional models to the side and coming up with a way that works given the money, crew, and technology available to you. Sometimes this means cutting loose those conventions that have been in place for decades. In the case of HDMI capture, that convention is camera generated time code.

Those of us that are married to a tape-based process will certainly attempt to maintain as much of that process as we can when moving to new technologies. I don't have a problem with that. As Douglas said, it's comfortable, and more than that it's reassuring.

All I want is good information for aspiring filmmakers and video artist so they can make good decision about how to spend their money. The time code discussion isn't that unlike discussing other unclear concepts those new to this world might have, like "you can only edit a feature length project on a Mac" or "the HVX200 shoots uncompressed HD." Well, maybe not as misconceived as those, but you get my point.

And, Douglas, as someone who has been in the industry full time for some years I can say that tape and film based acquisition formats are just as fraught with perils as the new hard drive work flow. As you know, film and tape are fragile forms of media!

By all means, everybody, backup your hard drive shoots to tape! We are finally at a time when realtime simultaneous footage backup is possible without a lot of extra cost. How great is that?!

I'm so pleased with this discussion! Great stuff! Who else has a comment?

And, Douglas, as someone who has been in the industry full time for some years I can say that tape and film based acquisition formats are just as fraught with perils as the new hard drive work flow. As you know, film and tape are fragile forms of media!

?

It may be true that tape/film have "perils" but those "perils" have served our industry very, very well and are tried and true over the past 50 years for tape, and much longer for film. If a few frames disappear from a film, they can be hand-recreated digitally. If a bit of tape loses some of its oxide, same story. There are storage methods that are time-proven beyond doubt; HDD can't demonstrate that longevity.
I'm a big fan of non-tape based acquisition such as XDCAM, but HDD-only has many problems still, and it's why some bonding companies will not bond/insure HDD-only projects. I also still like the idea of having a physical "something" that can easily be stored on a shelf, handed to a client, or accessed without plugging in and searching.
Since this thread is no longer about the FX7/V1, I believe it belongs in the General category.

One more log for the fire...

Take the example of DVRack. Serious Magic's stated philosophy in developing the product is to record everything that comes in via firewire, no more, no less.

Now on the face of it this sounds like a good position. Timecode matches between tape and the DVRack recording.

But... why shouldn't DVRack or other hard-drive recording software include a timecode generator capable of free-run and maybe jam sync too? Any pro-level recorder can do this. I guess the question I'm asking is, should a hard-drive recorder emulate tape, or emulate a pro recorder? Or maybe it should have both sets of functionality.

**********
Why did Sony include HDMI out from the V1? I think more people will use it as a quick and easy way to connect an HD tape playback device (V1) to a consumer HDTV than will record out from HDMI. Or maybe there will be a new generation of HDMI-in recorders?

Douglas, all very true about the time-tested reliability of film and tape. hard drive-based recording is going through all the same growing pains the other formats went through when they were first deployed. That's the process all changing technologies have to take. We figure it out. That's what humans do, figure stuff out.

I think the key to a stable hard drive recorder comes down to RAID and fault tolerance. I plan to play with RAID 5 and RAID 6 because of their ability to rebuild lost data if a hard drive fails (1 drive failure tolerance-RAID 5, 2 drive failure tolerance-RAID 6-more expensive). In a single drive or simple striped RAID if one drive fails, you're basically screwed!

Seth, I'd agree that HDMI was meant as an easy way to monitor digitally from the camera to a higher end display. And we need it. Thanks tech guys! It's people like BlackMagic who saw an opportunity to create a capture process which is certainly directed at single camera indy guys like me who what to bypass the HDV compression cheaply. Thanks BlackMagic! Like I said, humans figure stuff out. And who knows, HDMI's future could be to take the place of firewire (HDMI 2.0?), or it could die quietly replaced by something better. Somebody will figure it out.

As for your capture software queston, I'd like it to emulate high end recorders because that is ultimately what the software is. But it is software. With a visionary product team, the right programmers, and enough time and money, software can be whatever they want it to be. Pretty cool. . .

I agree with Douglas that this thread should be moved to a general forum. I started it here because a lot of the V1 threads addressed HDMI capture and TC. I thought it deserved a thread of it's own.

Thanks, guys.

Re: reliability - at the moment I've instigated a system in my workflow that uses a hard disk recorder (more to save on digitising time than anything else). But guess what - I still record to tape and it is more than important to me that the disk timecode and the tape timecode match (I guess that qualifies as another use for TC).

two reasons - the disk stuff get's recycled and is therefore only archival if you archive it back to tape or to another hard disk (reliability not as good as tape). If you have a catastrophic failure on your NLE system you have a tape backup with matching code - easy to fix.

If for some reason your portable hard disk recorder fails in the field you have a tape backup (phew). Sorry to get a little off topic but all this talk of recording only to hard disk was making me nervous.

Thanks for the comment, John.

I think everyone can agree that recording only to hard drive is a bad idea. As I said above, we can now record a realtime simultaneous backup to tape without spending a lot of extra money. Who wouldn't do that?!

Now it is once again my obligation to retort. This is after all "The great HDMI time code debate."

Archiving - When you speak of archiving back to tape I think it depends on what you're archiving whether or not original camera generated TC is necessary. If your archive process includes only completed projects, which is the work flow for most of us little guys, of what use is the original timecode? If it's a project that changes often, say a training video for a client, that's worth keeping on the hard drive (backed up via a RAID mirror or straight drive-to-drive-sync of course) because your editing it every few months. If your workflow involves long periods of time between re-edits, say six months or more, or you hope to someday be able to go back and release a director's cut or remastered version of your dream project, then I can see the importance of matching time codes. But remember that a tape capture wasn't done in the first place so depending on the NLE the process for re-ingesting that tape may be more difficult and time consuming than many may think. If that's what you hope to do, take good TC notes during the shoot.

And let's not forget that this thread started as an HDMI capture from HDV cameras question. The point of which is to bypass the HDV compression to the tape. By all means, still back up to tape, but that tape will be HDV compressed.

Catastrophic failure - This can be avoided with a good NLE machine configuration. RAID! As I said above, RAID 5 and 6 were designed for high fault tolerance. A RAID 0+1 (strip + mirror) can do the same thing with less processor overhead but it will take more and bigger hard drives to achieve high capacity storage. For these configurations to catastrophically fail would mean a whole system meltdown. That's about as likely as a studio fire destroying all your archieve tapes. Sure it can happen, but how likely is it?

Don't you just love forums? The friendly exchange of thoughts and ideas between peers. . . Loving every minute of it!

Thanks again!

Boy, Chad...you have a lot of free time, yeah? ;-)

So, how do you back up your HDCAM master to tape if you don't have an HDCAM deck? How do you deliver it?
How do you recapture it without original T/C with frame-accurate recapture?
How do you sync it after sending to a third party for audio without original T/C, outside of generating new T/C?
RAID's fail. Period. End of story. How likely? Well...Ciprico, for example, suggests that their RAIDs have a life of about 3 years of regular use.
Having a project ONLY on HDD is simply dumb, IMO. As I've mentioned before, some bonding companies won't touch HDD-only projects for good reason. You need to find some print to something device, such as XDCAM HD, HDCAM, D5, or other shelvable storage format. That might even be as simple as sequential data DVD's, but you NEED/MUST have a means of archiving elsewhere from HDD, and likely should archive as fast as possible if your acquisition is HDD-only.
And back to original point, T/C will always hold merit, whether it's computer generated, camera generated, or external device generated.

It's true, Douglas. I'm a little bored right now. It's my slow time and it won't pick up again until February for me, so you're all stuck with my insane and subversive rantings!

Before I go back to my role as dissenter, let me tell you how honored I feel that you, Douglas Spotted Eagle, chimmed in so early is this discussion. I do know who you are and found your book, HDV: What you need to know, a pleasure to read. Thanks for being out there. You still haven't converted me to Vegas, but you came close. . .

Anyway, back to me dissent. . .

Who's talking about HDCAM? I'm talking about lower end HDV rigs with an HDMI out that we can use to capture uncompressed 4:2:2 1080i video, bypassing the HDV compression. A $40000 Sony HDCAM rig to my knowledge doesn't even have an HDMI port. It does have HDSDI, and at that price point it should and those that can afford it should be able to afford HDSDI capture capability and all the computers, decks and other support hardware and software needed for that highend workflow.

I'm not suggesting that we do away with time code. I'm just suggesting that in some workflows, camera generated time code isn't a must have component for completing a high def project.

Yes, RAIDs fail. But the three years of continues use example is pretty good! I'd like to know if anyone has gotten three years of continues use out of a tape. Of course, no one would try it because that's not what tape is for.

Yes, archiving needs to done on shelvable format. A sequencial DVD run isn't a bad idea. It would be time consuming, but would do the job. And as HD codecs get better, archiving the final edit becomes easier. Honesty, after the editing process is complete, I feel archiving to HDV is an acceptable practice. HDV looks good! All we want the extra color space for is compositing and FX work anyway.

All media has a shelf life and it can be significantly shortened when stored poorly. Tapes stretch. CD dye degrades over time. Hard drives are still mechanical devices that can lock after long periods of non-use. So we're screwed in the long term no matter what we prefer.

All that being said, of course, Douglas, you are right. Time code will always be useful and will never leave our workflows completely. The computer generated TC is used by editing software. Jam syncing will always be used in higher end multicamera projects. And when tape is part of the workflow it is down right crucial.

Know, do we need to start another topic to cover the impracticality of capturing uncompressed HD via HDMI for low budget/small productions? It is impractical, or am I wrong there, too?

(I know what you're saying. After all that I don't think it's practical anyway. Yes, I am insane. . .)

Chad

At the end of the day, if all you're looking to deliver media to is DVD for low-number distribution, why worry about 4:2:2 in the first place? I just don't get it.
NO broadcaster will accept HDV as a delivery mechanism. It must be on HDCAM, D5, or HDD. Most won't take HDD yet. So, how do you deliver your 4:2:2-acquired media in any format that makes it worthwhile?
The bottom line is that we've had uncompressed capture capability for years and years for SD, using uncompressed, 4:2:2 output from virtually every DV camcorder made. I challenge you to demonstrate a quality difference from HDMI vs analog component output, vs SDI. Any differences will be miniscule. I find this constant discussion of "how great HDMI capture is for uncompressed HD" to be somewhat humorous, as very few people do it with SD, but now they're going to this workflow for HD? I don't think so.
Back to topic; The lack of timecode, IMO, is the biggest difference of all the above mentioned formats. And arguably the most important difference.
If it's not important to you, that's fine and very understandable. In a higher end workflow where projects are handed off from department to department, T/C is pretty important.
As far as archiving, if all you archive is final media, well....I guess we're working in different industries. And if archiving for only 3 years is important to you, then I *know* we're working in different facets of the industry.

There is a great production divide, in my experience, and timecode is it.

Logging, time code burns, paper edits, preview dubs, edls, client approvals, re-captures ... it is impossible for me to imagine a workflow that doesn't include timecode. In those few instances when I am given an asset that for some reason doesn't have timecode, I immediately dub it to some format that does, and use only the timecoded version even if from a dub ever after. I have worked on insured broadcast productions that _required_ that a timecode identical dub of all elements and an edl be stored off-site from the principal facility -- where every evening long lists of timecoded scenes and instructions were forwarded to men in suits that could pull the plug if necessary.

And yet, it took years before Premiere realized that timecode was important, and in the early days of DV production, when third-party hardware was essential to capturing or displaying DV ... timecode was available on almost no products, and those few that did offer it had to use Quicktime. As recently as three years ago, some major software transferred a timecode that was a few frames different on HDD than it was on tape -- a faux pas beyond my comprehension.

I have no doubt that there are huge segments of the 'production industry', whatever that entails, that don't care about or make use of timecode. I've met working professionals that were clueless as to what 'drop frame numbering' even was -- convinced that DF was dropping frames, not numbers. But in those segments of the industry that have legal departments, broadcasters, corporate approvals ... it is hard to imagine a workflow without timecode, and all the archiving, approval and documentation it backstops.

Cheers,
GB

At the end of the day, if all you're looking to deliver media to is DVD for low-number distribution, why worry about 4:2:2 in the first place? I just don't get it.
NO broadcaster will accept HDV as a delivery mechanism. It must be on HDCAM, D5, or HDD. Most won't take HDD yet. So, how do you deliver your 4:2:2-acquired media in any format that makes it worthwhile?
The bottom line is that we've had uncompressed capture capability for years and years for SD, using uncompressed, 4:2:2 output from virtually every DV camcorder made. I challenge you to demonstrate a quality difference from HDMI vs analog component output, vs SDI. Any differences will be miniscule. I find this constant discussion of "how great HDMI capture is for uncompressed HD" to be somewhat humorous, as very few people do it with SD, but now they're going to this workflow for HD? I don't think so.

That's exactly where I was going with the HDMI capture impracticality thing.
To add to your deliverables point, for a small production to capture uncompressed is a highly complicated process from a computer technology standpoint. Any money you save on the camera and HDMI capture card will be eaten up quickly by huge RAID arrays not to mention the time spent tweaking the computer system during the shoot! The reason uncompressed SD video never took off in most workflows was the expense and weight of equipment and personnel required for a sturdy uncompressed capture platform.

The lack of timecode, IMO, is the biggest difference of all the above mentioned formats. And arguably the most important difference.
If it's not important to you, that's fine and very understandable. In a higher end workflow where projects are handed off from department to department, T/C is pretty important.

That's all I've been saying. If a guy wants to try shooting his short film through his brand new V1 and HDMI and he's going to do all the editing and audio work on his dual core Intel machine in Vegas, let him! If he feels comfortable with that process, who's to say he shouldn't?

I have no doubt that there are huge segments of the 'production industry', whatever that entails, that don't care about or make use of timecode. I've met working professionals that were clueless as to what 'drop frame numbering' even was -- convinced that DF was dropping frames, not numbers. But in those segments of the industry that have legal departments, broadcasters, corporate approvals ... it is hard to imagine a workflow without timecode, and all the archiving, approval and documentation it backstops.

Yep! What else can I say? There are plenty of local television production shops and advertising production departments that give little thought to TC in their workflow, but all the while it's there in the background doing its job without acknowledgement or praise. But for the big boys it's front and center pulling extra duty greasing the wheels of the production process.

Thanks everybody for taking part in this discussion. I hope it has answered many questions about TC and it's use in the production process and whether or not you need it.

I'm done. Time to move on to other topics.

Chad