HDCAM or DVCPRO-HD

[Dirk DeJonghe]

Jon,

 

I feel DoP's should be intererested in the way a proper DI is performed.

 

No longer spending time in the telecine suite but having a proper 10bit Log scanned digital file format on a high end grading system such as Baselight.

No more wear and tear on the negative.

Put any frame from any part next to any other frame from any part and copy/paste parameters.

Why 10bit log files are much more intelligent than linear video type files.

Film and video (SD/HD) deliverables from a single grading session.

Uncompressed files with lots of reserve in the shadows and highlights.

Placing the blacks and whites exactly where you want them.

Many more reasons than I can think of.

[Walter Graff]

I'd go wiht HDCAM. Both formats are 8 bit to tape but HDCAM has a larger framesize to work with and while it is color sampling ratio of 3:1:1, that is misleading as the sampling frequency is higher so it's 3:1:1 is not less than DVCpros 4:2:2. HDCAM would be my choice for best options with the master.

[Stuart Brereton]

Shadow for real-time direct to disk transfers on my RaveHD as 10bit log DPX sequences (SD and HD).

Just the transfer to the clients hard disk takes some time (filecopy from server to hard disk).

 

Phil,

 

BBC resources TK in Bristol offers the same workflow at a reasonable rate. I would have thought that just about any major TK facility would be able to transfer direct to disk. The problem, of course, is that the disk in question is their raid array, rather than your Firewire, so you still incur transfer charges.

[Phil Rhodes]

They can, they just won't.

 

I've long considered offering for sale some sort of device for making this easy for the facility, with scheduled offload, etc.

 

P

[Stuart Brereton]

They can, they just won't.

 

Is this really the case? I'm not the most IT savvy person, but I would have thought that any TK facility is goingto be a lot happier transferring to their own tried and tested disk array, rather than some unknown quantity firewire drive that could have any number of problems with it, all of which will cause the customer to come back and complain that 'there's something wrong with my footage'.

[Phil Rhodes]

Very few of them are patched up to do that sort of transfer. Even if there's a clipster in the building, the likelihood of it being connected to the telecine bay is, in my experience, slight.

 

They'd have to change cables around. If they have enough work that they don't need to pull two BNCs and a device control cable, they won't.

 

P

[Dirk DeJonghe]

The problem with customer portable disks is that they are SLOOOOW. I can transfer 30 minutes of uncompressed HD in real time to my raidsystem, it could even be dual-link HD-SDI.

There is no way a portable disk can record say 250 MB per second in a reliable steady stream.

After the real-time recording it then takes about all night to transfer 30 minutes to the customers disk. This would become a problem if more than one hour per day needs to be copied. Also, I like to have an NTFS or Linux partition, not HPS+ or FAT32 (limited to 21000 files per directory).

On an LTO-3 I get easily 80 MB per second read/write when hooked up to the local SCSI controller.

[Jon Rosenbloom]

Ok, I did a little reading on 10 bit log frame files ... It wasn't so scary. Maybe it can have this application: We had a "little problem" on a recent shoot. The film stock used for one sequence was mishandled - which is a whole story on its own - resulting in strobing in the footage. I estimate when the editing is done the sequence will run about 90 seconds. We have the key codes, and the bad negative is all on the same flat. It seems we could do one of these ten bit log frame scans on just our select takes and even out the strobing in a relatively painless, and not too expensive fashion. The alternative is to correct it frame by frame in Final Cut in DVCPRO-HD resolution and color-space.

 

Thanks.

[Dirk DeJonghe]

There is a plug-in for Shake called Furnace that has two different deflicker algorithms. A really good compositor can also build one from scratch.

I once had a problem with an HMI fixture on the left hand back wall of the set. Actors in front of the wall were lit by tungsten and the right hand part of the wall was lit with HMI without flicker. It was all solved in compositing with scanned frames and then recorded back to film. Insurance paid for it.

Reshoot was not possible, actors were no longer available.

[Michael Most]

They can, they just won't.

 

I've long considered offering for sale some sort of device for making this easy for the facility, with scheduled offload, etc.

 

They can't if the requested file format is a Quicktime file with an Apple specific codec, like DVCProHD or ProRes - the two that seem to be the most oft requested. Other than that, many US facilities - including the one in which I work - can and do perform direct to DPX or uncompressed Quicktime file transfers all the time, using RaveHD, Clipster, or other devices. And yes, these have to be copied to a client drive because I don't know of any Firewire drive that can sustain the 150MB/sec or so that's required to reliably record 10 bit uncompressed HD (more like 200+ if it's recorded as single frame DPX files).

 

Write software that can reliably virtualize a VTR on a Mac, complete with RS422 control that works with a standard edit controller and simulates a tape preroll and I'll buy one. But to this point, nobody's done that.

[Phil Rhodes]

What d'you mean by "simulate tape preroll" - pretend to be a VTR to the point of actually emitting timecode as if we're prerolling? It's not non-doable, but is it really necessary?

 

My inclination would simply be to record the lot, assuming it's a couple of seconds preroll, and treat it as handles.

 

P

[Michael Most]

What d'you mean by "simulate tape preroll" - pretend to be a VTR to the point of actually emitting timecode as if we're prerolling? It's not non-doable, but is it really necessary?

 

My inclination would simply be to record the lot, assuming it's a couple of seconds preroll, and treat it as handles.

 

It needs to fully emulate a VTR (and work in NTSC, PAL, and various HD formats) so that time code can be added under editor control. Sometimes the time code is sent with the video in the form of pre-inserted VITC (for SD) or VANC (for HD), but it's often the case that the code is added in the VTR itself by striping the starting time code (say, hour 1) and assemble editing from there. That allows for new edits each time there is a new shot, necessary when you're doing daily transfers with sync sound. In the case of a Quicktime type recorder, it has to be smart enough to remember the last outpoint, but also to be able to change it. In the case of file based recorders (i.e., Rave HD, which records DPX sequences) this is not an issue because each frame (i.e., each file) has a time code attached via both the header and the file name itself, so if you need to overrecord previous material, it writes new files with the original names that replace the old ones (see how much easier everything is when you don't use wrapped movie files?). It also needs to play well with other devices, like other VTR's. This is necessary in part because backup tapes are often requested, but also because it is fairly common practice to create multiple formats simultaneously, i.e., HD and SD for viewing copies. This is usually done by dragging a DVCam as a second recorder. If you're using an editing controller (a DaVinci TLC is probably the most common in a telecine situation) it expects each transport to park, roll, sync, and report its position over RS422.

 

You seem to be assuming that time code is always originating in the telecine suite and traveling with the material. That is not the case. The VTR's themselves are often the source of the time code, and this is necessary for multiformat transfers. That's why devices such as RaveHD and Clipster fill this need so well. The only device I know of that ever did this while writing wrapped movie files was the Avid Media Station (and Symphony, although very few facilities used that capability). As I recall (it's been quite a while) what they did was create a 24 hour long virtual tape device for every edit, so that any time code you enter on the edit controller would be a valid in point. It would then simulate a preroll based on that in point. This worked reasonably well, although the hardware at the time was pretty primitive by today's standards.

[Phil Rhodes]

It's clearly possible to emulate a striped tape and support inserting onto it, it just struck me as a fairly crazy way to approach the situation when there's easier ways all round. You wouldn't really want to end up with one half-hour DPX sequence/Quicktime/whatever per virtual VT - would you? I'd rather have a bin full of individual clips, which would be easier to import and log. Ending up with overlapping timecode ranges on those clips (regardless of whether they're wrapped or not) might be a problem; the solution is to maintain an internal database of what frames you've written, and invalidate anything that gets rewritten. Relying on a filesystem to do that is a zero-dev-time approach, sure!

 

Part of what I was thinking this ought to have would be the ability to sit on downtime and create DVCPROHD/DV/whatever offline files as a software operation, but that would depend on your sensitivity to whatever time delay that incurred. Particularly relevant for DVCPROHD as it seems to be a popular offline format and it's currently complicated to create.

 

That said I think we're getting away from what I intended the core functionality of the thing to be, which is as a way of delivering online material as data from setups which aren't currently oriented to doing that. I can't see that there would be any reason to use something like this for dailies, unless you were taking a scan-everything approach and creating your online elements at that stage, which would presumably make your dailies a bit spendy.

[Michael Most]

It's clearly possible to emulate a striped tape and support inserting onto it, it just struck me as a fairly crazy way to approach the situation when there's easier ways all round. You wouldn't really want to end up with one half-hour DPX sequence/Quicktime/whatever per virtual VT - would you? I'd rather have a bin full of individual clips, which would be easier to import and log.

 

That sounds like the view of a user, not a supplier. In a telecine operation, efficiency is key and accuracy is required, and that's why virtually all telecine facilities use TLCs to control the coordination of telecine and recording transports. It's the only real way to ensure that the transfer is controlled, and therefore metadata that is supplied is accurate - a must in the professional end of the business.

 

Part of what I was thinking this ought to have would be the ability to sit on downtime and create DVCPROHD/DV/whatever offline files as a software operation, but that would depend on your sensitivity to whatever time delay that incurred. Particularly relevant for DVCPROHD as it seems to be a popular offline format and it's currently complicated to create.

 

That is the approach taken by Drastic Technologies, which can spin off a transcode operation when recording of a clip is complete. And that can work reasonably well if it's implemented correctly.

 

That said I think we're getting away from what I intended the core functionality of the thing to be, which is as a way of delivering online material as data from setups which aren't currently oriented to doing that. I can't see that there would be any reason to use something like this for dailies, unless you were taking a scan-everything approach and creating your online elements at that stage, which would presumably make your dailies a bit spendy.

 

But that is exactly what is done in the US, for essentially every television program and for most features as well, at least insofar as creating an element for dailies that is later used for previews (not for the DI, in most cases). It's not scans, of course, it's HD telecine transfers, but you get the idea.

[Phil Rhodes]

That sounds like the view of a user, not a supplier. In a telecine operation, efficiency is key and accuracy is required, and that's why virtually all telecine facilities use TLCs to control the coordination of telecine and recording transports. It's the only real way to ensure that the transfer is controlled, and therefore metadata that is supplied is accurate - a must in the professional end of the business.

 

Regardless of how accurate your timecode is (regardless of source), it's still just a bin full of tagged images. My question was whether you wanted one half hour sequence or individual takes binned individually.

 

But really my interest is not so much in the VT emulation side of it. That's fairly textbook. What I'm interested in is what else it could do in order to make this something more than just what you've been doing for the last thirty years, only on hard disks. There are a number of things this could do which I suspect haven't ocurred to most tape-oriented people simply because their thinking is bound by what a VTR is capable of. Yes it can be made to do everything a VTR can do. Obviously it can. That's not particularly useful other than allowing people to conform HD on desktop computers, which is the last thing the post houses will want to facilitate.

 

It is in any case never quite going to be a VTR; if you want to lay this stuff off onto firewire or E-SATA disks, it's going to be tied up nights doing that, or however you want to schedule it. It's an age old compromise. What's interesting is where else it could go.

 

P

[Michael Most]

There are a number of things this could do which I suspect haven't ocurred to most tape-oriented people simply because their thinking is bound by what a VTR is capable of.

 

I'm not a "tape oriented" person. However, a telecine is, by definition, a linear transfer device. And time code and other metadata are what post production is based on. Telecines are not going to change - hell, we're probably seeing the last generation of them right now. So the ones that are used will continue to be used, and the installations they are in will continue to be operated the same way, because it's established, convenient, and efficient. So if you want to create a device for that market, you need to look at what's being done, how it's being done, and accommodate that rather than tell people to change what they already do quite well. Even the MTI Control Dailies system, which takes a rather nonlinear approach to dailies creation (at least to the point of separating ingest and combining of picture and sound) still has to read, track, and correlate time code and keycode in order to allow a relationship between the resulting tapes or files and the original material.