|
|
All the news now and in your digital future
HD Log & Capture Questions
Posted by Haskin
|
Re: HD Log & Capture Questions March 05, 2009 08:45PM |
Quote
Capture your native hd codec for quality. Meaning the exact form you filmed in and don't worry about saving gigs hard drives are cheap.
I disagree completely with that advice. There are tangible issues that Editors who are experienced with HDV (which is your "native hd codec" I am assuming - Clay is correct..."MiniDV" is not a codec...that's a tape format) can tell you both good and bad stories about working in Long GOP format...mostly bad. As mentioned, a straightforward edit would be OK to go with HDV, but if you have any serious compositing / graphics / color treatment to be implemented, the HDV codec doesn't hold up as well as ProRes so I suggest capturing in ProRes (around 1.03 GB per minute of captured 1080i footage) and keep your entire project in ProRes all the way through. HDV gives you much smaller file sizes (190 MB per minute of 1080i footage) but is much more processor-intensive. FCP and the main graphics compositing apps like ProRes much better (in my experience)
When life gives you dilemmas...make dilemmanade.
|
Re: HD Log & Capture Questions March 07, 2009 11:14PM |
I agree with Joey - I feel a lot a safer with prores - HOWEVER - a major drag that I have not found a way around is the fact that you don't get a proper log and capture window when using the HDV-to-ProRes capture preset -- it seems like you can only capture your footage as one ginormous block (a la "capture now"
. Am I missing something? Enlighten me, Joey!
. Am I missing something? Enlighten me, Joey!
|
Re: HD Log & Capture Questions March 08, 2009 09:13AM |
I'm gonna differ with Joey a little here. Our whole HDV workflow is built around log-and-capturing HDV from tape over Firewire, then assembling the HDV footage in a ProRes 422 1920x1080 timeline.
There are a couple notable advantages. First, as mentioned above, HDV capture files are a lot smaller. That matters if you're short on storage, but otherwise not so much. But the far bigger factor is that capturing HDV lets you log-and-capture as normal, and ? this is the most important part ? batch re-capture later if you need to get your media files back off tape. With this workflow, you have the option of archiving only your timeline and any graphics or other non-tape-based media files, while keeping your footage on tape. Yes, there's always the possibility that a tape sitting on the shelf can degrade over time, making some of your footage unrecoverable, but hard drives fail too, and far more frequently, so I think this method is safer overall.
Now, as for this "quality" thing people are talking about. As Clay mentioned, HDV is already massively stomped on by the camera; it's a very heavily compressed format. But that doesn't mean it inherently sucks. HDV footage can look quite good, especially if your workflow involves shooting HDV for eventual delivery in SD. One you down-rez to SD, HDV can end up looking amazing.
The trick, though, is to make sure you never make your HDV source material look any worse than it does straight off the camera. That's one of two reasons why it's bad to edit native HDV: native HDV editing involves applying a second compression pass to your footage, which degrades it in ways you don't have to be a broadcast engineer to spot.
The other reason editing native HDV is not a great idea is workflow; the computer has to do a lot of math even to play back HDV in real time, much less to edit it, so you end up waiting a lot.
Fortunately both these problems can be solved by editing your native HDV media files into a ProRes 422 1920x1080 timeline. Assuming your system has the storage bandwidth to play back two streams of ProRes 422 HD in real time, you'll be able to drop your HDV media into a ProRes timeline and cut it in real time at what Apple calls "preview quality." That means your system will automatically show you a lower-resolution version of your footage while you're editing. (Not that much lower, either; I think it's quarter-res, so it's effectively 960x540 or something like that. Still more pixels than SD.) As soon as you render, Final Cut will decode the HDV media, scale it up to 1920x1080 from HDV's native 1440x1080 non-square-pixel format, then apply any effects or color-corrections or whatever you might have put on the shots, and finally write the media to your render cache in ProRes format. Since ProRes is a "transparent" codec ? it's generally agreed to be visually indistinguishable from uncompressed 10-bit ? you can do all that without degrading your footage at all. And the best part? Your system can do all that faster than it can do the same thing to HDV media, because ProRes is so much less computationally intensive.
If this sounds like a complicated workflow, it's really not. The use of intermediate formats for editing is as old as the hills. Think about it: If you shoot on film, you're not going to edit your show with a razor blade and scotch tape. You're going to transfer your film to video and edit that, and only when you're done are you going to apply those edits you made offline to the film negative. In fact, these days you might not even do that; you might well scan the parts of your negative you used in your final cut and make a digital intermediate before printing the finished show out to film again, or making an HDCAM master, or delivering it digitally, or whatever. Intermediate-format workflows are pretty standard. It's just that many editors have never encountered them before, because the DV, DVCAM, DVCPRO and DVCPRO HD formats ? which, trivia time, are all basically the same ? were designed to let editors skip the intermediate. Other formats like HDV, XDCAM and AVCHD, and even Red, all depend on an intermediate-format workflow.
Hell, even shooting HDCAM SR means you'll use an intermediate workflow. The only way to get footage onto or off of an SR tape is through SDI, which means you're going to have to create some intermediate format when you edit it. These days, that intermediate format is usually uncompressed, ProRes or DNxHD, but from a workflow perspective, it's still an intermediate format. The only difference, workflow-wise, is that if your source media is SR, you convert to your intermediate format in real time when you digitize. With HDV, you essentially copy your source media off the tape bit-for-bit when you capture it, then convert to your intermediate format later, when you render your Final Cut timeline. Same principle, slightly different execution.
(Which I guess is my characteristically long-winded way of saying "This is how all the cool kids do it, so you should totally give in to the peer pressure."
There are a couple notable advantages. First, as mentioned above, HDV capture files are a lot smaller. That matters if you're short on storage, but otherwise not so much. But the far bigger factor is that capturing HDV lets you log-and-capture as normal, and ? this is the most important part ? batch re-capture later if you need to get your media files back off tape. With this workflow, you have the option of archiving only your timeline and any graphics or other non-tape-based media files, while keeping your footage on tape. Yes, there's always the possibility that a tape sitting on the shelf can degrade over time, making some of your footage unrecoverable, but hard drives fail too, and far more frequently, so I think this method is safer overall.
Now, as for this "quality" thing people are talking about. As Clay mentioned, HDV is already massively stomped on by the camera; it's a very heavily compressed format. But that doesn't mean it inherently sucks. HDV footage can look quite good, especially if your workflow involves shooting HDV for eventual delivery in SD. One you down-rez to SD, HDV can end up looking amazing.
The trick, though, is to make sure you never make your HDV source material look any worse than it does straight off the camera. That's one of two reasons why it's bad to edit native HDV: native HDV editing involves applying a second compression pass to your footage, which degrades it in ways you don't have to be a broadcast engineer to spot.
The other reason editing native HDV is not a great idea is workflow; the computer has to do a lot of math even to play back HDV in real time, much less to edit it, so you end up waiting a lot.
Fortunately both these problems can be solved by editing your native HDV media files into a ProRes 422 1920x1080 timeline. Assuming your system has the storage bandwidth to play back two streams of ProRes 422 HD in real time, you'll be able to drop your HDV media into a ProRes timeline and cut it in real time at what Apple calls "preview quality." That means your system will automatically show you a lower-resolution version of your footage while you're editing. (Not that much lower, either; I think it's quarter-res, so it's effectively 960x540 or something like that. Still more pixels than SD.) As soon as you render, Final Cut will decode the HDV media, scale it up to 1920x1080 from HDV's native 1440x1080 non-square-pixel format, then apply any effects or color-corrections or whatever you might have put on the shots, and finally write the media to your render cache in ProRes format. Since ProRes is a "transparent" codec ? it's generally agreed to be visually indistinguishable from uncompressed 10-bit ? you can do all that without degrading your footage at all. And the best part? Your system can do all that faster than it can do the same thing to HDV media, because ProRes is so much less computationally intensive.
If this sounds like a complicated workflow, it's really not. The use of intermediate formats for editing is as old as the hills. Think about it: If you shoot on film, you're not going to edit your show with a razor blade and scotch tape. You're going to transfer your film to video and edit that, and only when you're done are you going to apply those edits you made offline to the film negative. In fact, these days you might not even do that; you might well scan the parts of your negative you used in your final cut and make a digital intermediate before printing the finished show out to film again, or making an HDCAM master, or delivering it digitally, or whatever. Intermediate-format workflows are pretty standard. It's just that many editors have never encountered them before, because the DV, DVCAM, DVCPRO and DVCPRO HD formats ? which, trivia time, are all basically the same ? were designed to let editors skip the intermediate. Other formats like HDV, XDCAM and AVCHD, and even Red, all depend on an intermediate-format workflow.
Hell, even shooting HDCAM SR means you'll use an intermediate workflow. The only way to get footage onto or off of an SR tape is through SDI, which means you're going to have to create some intermediate format when you edit it. These days, that intermediate format is usually uncompressed, ProRes or DNxHD, but from a workflow perspective, it's still an intermediate format. The only difference, workflow-wise, is that if your source media is SR, you convert to your intermediate format in real time when you digitize. With HDV, you essentially copy your source media off the tape bit-for-bit when you capture it, then convert to your intermediate format later, when you render your Final Cut timeline. Same principle, slightly different execution.
(Which I guess is my characteristically long-winded way of saying "This is how all the cool kids do it, so you should totally give in to the peer pressure."
|
Re: HD Log & Capture Questions March 09, 2009 04:02AM |
Jeff, is there any difference when it comes to CPU usage when you do the offline edits in an HDV timeline with render set to ProRes and editing in a ProRes timeline?
>Also, what is the best way to get clips off of a DVD?
Mpeg Streamclip.
[www.squared5.com]
www.strypesinpost.com
>Also, what is the best way to get clips off of a DVD?
Mpeg Streamclip.
[www.squared5.com]
www.strypesinpost.com
|
Re: HD Log & Capture Questions March 09, 2009 05:43AM |
Yeah, there is. Just scrubbing an HDV timeline is a computationally intensive task, because the system has to decode whole GOPs to show individual frames.
The only advantage to editing HDV with ProRes rendering, in my experience, is if you're going out to an HD tape format over SDI. If both of those things are true, you can leave your timeline HDV, render only your dissolves and effects and stuff, then edit to tape in real time, letting your Kona board handle the 1440x1080-to-1920x1080 upres for you in real time.
But if you're adding any graphics at all, like chyrons, you might be unhappy with HDV's native 1440x1080 raster, which means you need to set your timeline to 1920x1080 anyway, and once you do that, you might as well just switch over to ProRes.
Our HDV-originated projects here mix camera footage with archival footage and graphics, and the archival footage and graphics are all ProRes 422 anyway. So it's a lot better for us just to assemble shows in a ProRes timeline, letting the system render all the camera footage via auto-render during a break or something.
I did a ton of workflow experiments using the "keep it HDV 1440x1080, but tell Final Cut to use ProRes for rendering" thing last spring, and for the kind of projects we do here, I just found it to be too clever by half. Assembling HDV into ProRes and letting FCP render works better in our situation.
The only advantage to editing HDV with ProRes rendering, in my experience, is if you're going out to an HD tape format over SDI. If both of those things are true, you can leave your timeline HDV, render only your dissolves and effects and stuff, then edit to tape in real time, letting your Kona board handle the 1440x1080-to-1920x1080 upres for you in real time.
But if you're adding any graphics at all, like chyrons, you might be unhappy with HDV's native 1440x1080 raster, which means you need to set your timeline to 1920x1080 anyway, and once you do that, you might as well just switch over to ProRes.
Our HDV-originated projects here mix camera footage with archival footage and graphics, and the archival footage and graphics are all ProRes 422 anyway. So it's a lot better for us just to assemble shows in a ProRes timeline, letting the system render all the camera footage via auto-render during a break or something.
I did a ton of workflow experiments using the "keep it HDV 1440x1080, but tell Final Cut to use ProRes for rendering" thing last spring, and for the kind of projects we do here, I just found it to be too clever by half. Assembling HDV into ProRes and letting FCP render works better in our situation.
|
Re: HD Log & Capture Questions March 09, 2009 06:15AM |
Interesting. My workflow for XDCAM EX was to do offline cuts native so most of the footage do not need to render. During CC, I'll swap the sequence codec to ProRes HQ (as almost everything needs a render anyway) and render everything out ProRes HQ. That worked out pretty alright.
I was thinking that having a long GOP codec on a ProRes timeline will still require the processor to decode the source long GOP footage on the fly, and render it to the sequence codec at quarter resolution (a compromise quarter resolution was made for ProRes if i recall). Hence editing native would be simpler since FCP doesn't have to do anything else after the decoding. But I haven't ran it against the activity monitor, so it could be moot.
www.strypesinpost.com
I was thinking that having a long GOP codec on a ProRes timeline will still require the processor to decode the source long GOP footage on the fly, and render it to the sequence codec at quarter resolution (a compromise quarter resolution was made for ProRes if i recall). Hence editing native would be simpler since FCP doesn't have to do anything else after the decoding. But I haven't ran it against the activity monitor, so it could be moot.
www.strypesinpost.com
Sorry, only registered users may post in this forum.
