|
|
All the news now and in your digital future
Segue to FCP HD
Posted by PG
|
Re: Segue to FCP HD October 17, 2009 04:29AM |
FCP HD?
The last version of FCP to be labelled HD was 4.5 HD
Do you mean FCP 6 or the latest FCP 7?
Either way there is very little major difference in the basic working and everything can be found in the FCP manuals which are available online [documentation.apple.com] and can also be accessed in the newer version from the help menu - Simply read through working with HDV and HD material.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
The last version of FCP to be labelled HD was 4.5 HD
Do you mean FCP 6 or the latest FCP 7?
Either way there is very little major difference in the basic working and everything can be found in the FCP manuals which are available online [documentation.apple.com] and can also be accessed in the newer version from the help menu - Simply read through working with HDV and HD material.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: Segue to FCP HD October 17, 2009 09:27AM |
Yeah thats NOT what I was saying!
You are mistaken in thinking that your FCP doesn't do HD - all versions of FCP since 4.5HD have handled HD.
However you will see a benefit in upgrading to Final Cut Studio 3 on your Mac and HDV handling is better amongst many other updates so I recommend you do upgrade.
You will not need to necessarily need to learn that much on the editing side it works pretty much the same as 5.14 - as I said all of the information is in the Manual. Learning about HD formats is as easy as searching Google or buying a book on HD video.
You may need to get some sort of additional HD Monitor/TV and possibly HD card as far as I know you still cannot Monitor Live HDV from your Timeline via FireWire via a Deck/Camera connected to a TV as you can with DV.
Tell us what sort of Intel Mac you have. Please be VERY specific with the model, year, RAM, Eternal Hard Disk Storage, additional Monitor (if applicable), any installed Video I/O cards, etc, etc.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
You are mistaken in thinking that your FCP doesn't do HD - all versions of FCP since 4.5HD have handled HD.
However you will see a benefit in upgrading to Final Cut Studio 3 on your Mac and HDV handling is better amongst many other updates so I recommend you do upgrade.
You will not need to necessarily need to learn that much on the editing side it works pretty much the same as 5.14 - as I said all of the information is in the Manual. Learning about HD formats is as easy as searching Google or buying a book on HD video.
You may need to get some sort of additional HD Monitor/TV and possibly HD card as far as I know you still cannot Monitor Live HDV from your Timeline via FireWire via a Deck/Camera connected to a TV as you can with DV.
Tell us what sort of Intel Mac you have. Please be VERY specific with the model, year, RAM, Eternal Hard Disk Storage, additional Monitor (if applicable), any installed Video I/O cards, etc, etc.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: Segue to FCP HD October 17, 2009 09:54AM |
An easy way of doing this is to Open the System Profiler and copy and paste the
Hardware Overview & the The Graphics Overview
The you will need to add any information regarding the HDV Acquisition and what you currently have for Video Playback.
Let us know what you intend the system to be able to handle such as digitise, edit, monitor and output HD video but what formats and what mastering format.
We can then ascertain what you want to get for a basic setup to do this.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
Hardware Overview & the The Graphics Overview
The you will need to add any information regarding the HDV Acquisition and what you currently have for Video Playback.
Let us know what you intend the system to be able to handle such as digitise, edit, monitor and output HD video but what formats and what mastering format.
We can then ascertain what you want to get for a basic setup to do this.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: Segue to FCP HD October 17, 2009 11:31AM |
This is not something you want to do. HDV is a heavily compressed format. So heavily compressed that didging HDV material and then laying it back to HDV tape is basically forbidden. The degradation of the footage from that second compression pass is so great that you'd be significantly damaging your footage by doing that.
|
Re: Segue to FCP HD October 17, 2009 12:08PM |
Yikes. Well, if the client likes it, then ? whatever. But you still need to be aware of where you're damaging your footage.
|
Re: Segue to FCP HD October 17, 2009 12:16PM |
Yeah gotta agree with Jeff here...
I would recommend you supply the Edited HDV footage as clips on an HDD, DVD-ROM or BR-ROM as files linked to an FCP project or EDL rather than re-compressing them back to HDV tape compounding the already bad HDV compression.
Your system is fine for editing HDV considering what you said.
However to be able to monitor the HD video correctly in full HD quality you will need to get a device such as the Blackmagic Intensity card and an HDMI connected a full 1080p (not to be confused with 1080p ready) HD monitor/TV with a native resolution of 1920x1080.
The Sony PVM-14M4U is not suitable unless you only want to monitor SD which is roughly a quarter of the pixel resolution.
Of course you could always monitor the HD video on a second computer monitor hooked up to your Macs graphics card. This will not be an absolutely accurate representation and you might get a few shearing lines as the refresh rates differ but as you are only doing rough edits only and not finishing/grading/online then I don't think it will matter too much.
I wouldn't do any colour correction unless you are prepared to spend a fair bit of money on a decent HD monitor and Video card and then calibrate it. Leave this for the client to do at the finishing/grading/online stage.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
I would recommend you supply the Edited HDV footage as clips on an HDD, DVD-ROM or BR-ROM as files linked to an FCP project or EDL rather than re-compressing them back to HDV tape compounding the already bad HDV compression.
Your system is fine for editing HDV considering what you said.
However to be able to monitor the HD video correctly in full HD quality you will need to get a device such as the Blackmagic Intensity card and an HDMI connected a full 1080p (not to be confused with 1080p ready) HD monitor/TV with a native resolution of 1920x1080.
The Sony PVM-14M4U is not suitable unless you only want to monitor SD which is roughly a quarter of the pixel resolution.
Of course you could always monitor the HD video on a second computer monitor hooked up to your Macs graphics card. This will not be an absolutely accurate representation and you might get a few shearing lines as the refresh rates differ but as you are only doing rough edits only and not finishing/grading/online then I don't think it will matter too much.
I wouldn't do any colour correction unless you are prepared to spend a fair bit of money on a decent HD monitor and Video card and then calibrate it. Leave this for the client to do at the finishing/grading/online stage.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: Segue to FCP HD October 17, 2009 12:23PM |
Quote
HDV does not begin to compare to real HD video
Regulars around here will know that this is one of my major pet peeves.
What the heck is "real HD video?" Technically speaking, anything that, when displayed on a television, results in an image that fits the ATSC specification for 1080i is "real HD video," regardless of where it came from. Once upon a time, the test was "are there visible compression artifacts in this image," but you can't turn on cable or satellite HD without being inundated with visible compression artifacts, so that test is no longer meaningful either.
So we're back to the only two tests that ever mattered: "is this good enough for this job" and "do I like this." If the first answer is yes, then the second answer really doesn't matter very much, though of course we wouldn't be in this business if not for our impulse to maximize that second criterion.
|
Re: Segue to FCP HD October 17, 2009 12:27PM |
It gets re-conformed and re-compressed. That's the nature of the HDV format. I and others have written volumes about this elsewhere on the forum; do a search.
|
Re: Segue to FCP HD October 17, 2009 09:37PM |
If it is possible to go HDV iLink (firewire) to iLink then I would imagine the recorded clip would work from the first available I frame and the Data will be recorded in the same manner as the source resulting in a perfect digital copy - unfortunately I know very little about the transfer of HDV via firewire to HDV and can only guess.
Unless one of the other forum members or moderators have the answer - I would be inclined to contact SONY directly and ask to speak to someone who might know.
If you do this please feed back so we know for future reference.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
Unless one of the other forum members or moderators have the answer - I would be inclined to contact SONY directly and ask to speak to someone who might know.
If you do this please feed back so we know for future reference.
For instant answers to more than one hundred common FCP questions, check out the LAFCPUG FAQ Wiki here : [www.lafcpug.org]
|
Re: Segue to FCP HD October 18, 2009 11:21AM |
So the 15 GOP is the culprit then. But, the 15 GOP structure also gives us excellent quality and manageable video files to work with. Therefore, if I may paraphrase Michael Douglas, "Compression is good!"Quote
Andy
If you do nothing to it, nothing at all not even trimming, then nothing will happen ... it would be a digital copy. Change it in any way at all and it will need recompressing, the GOP structure will be rebuilt and you end up with a generational loss of quality on what is already a heavily compressed format.
Many people have said on many user forums, not just this one, that one can edit in "native HDV", but since editing with the 15 GOP structure results in tearing down the structure, there has to be some re-ordering of the I-frames and the other frames carrying the referenced information.
So is the restoration of the 15 GOP structure constitute degradation? If so then doing any editing in native HDV is a total mistake. ...Because we edit in order to export to some other format for viewing; we're not editing just to look at the program on our FCP monitors
Furthermore, it should then be explained that the HDV format is only an acquisitions format.
The only thing that I know is still true is that the resulting MPEG2 for a 90 minute movie can be as small as 1.5 Gigs, when the self-contained HDV file is about 15 Gigs. And the perceived quality of the DVD is practically as good as the HDV tape. So HDV has its advantages!
|
Re: Segue to FCP HD October 18, 2009 12:44PM |
Quote
since editing with the 15 GOP structure results in tearing down the structure, there has to be some re-ordering of the I-frames and the other frames carrying the referenced information
That is incorrect.
Excuse me for going off on one of my characteristically pedantic lectures. Today we're going to talk about the underlying principles behind MPEG-2.
Once upon a time there was JPEG. Everybody knows how JPEG works: You take a still image ? which is digitally represented as a raster of pixels, so-many wide by so-many high, each pixel being in turn composed of some number of components stored as numbers. JPEG takes that still image and, using Math?, reduces it into a smaller representation that, when decoded, creates a reasonable approximation of the original. That's how JPEG works.
Now. For purposes of this discussion, I'm going to use the word "footage." It's a generic word, but I'm choosing it deliberately, 'cause I'm going to define it very specifically. "Footage," in the context of this pointless rant, is any sequence of still images of the same size, played back at a constant rate. Please not that interlaced video would not meet my idiosyncratic definition of "footage," but that's because I'm trying to keep things as simple as possible here.
Still images can be represented in a computer in a variety of ways, but the most common is 8-bit RGB. That is to say, each pixel in the image is broken down into red, green and blue color components, and each component is a number in the range 0-255, where 0 is pure black and 255 is pure red, green or blue. This isn't the only way to represent a still image. In fact, it's kind of a crappy way for a variety of reasons, but it's by far the most common way.
So let's imagine that we're going to store our "footage" ? see above ? as a sequence of still images represented in just that way: 8-bit RGB. If we pick for example HD resolution of 1920 by 1080 pixels, each frame stored on our computer takes up a hair under six megabytes of disk space. That doesn't sound like a lot in an era when our phones have more than five hundred times that storage capacity, but still. It adds up.
So let us attempt to make our footage smaller, to store it in such a way that it takes up less space. There are some clever things we could do to reduce the amount of space required without actually discarding any information, but those get into more math than I care to deal with on a Sunday so we'll ignore them. Instead, let's accept as an axiom that some reduction in meaningful information is acceptable as a trade-off for smaller data-storage requirements.
What's the most obvious thing to try? You're way ahead of me already: JPEG. Just JPEG-compress each frame. Footage is a sequence of same-sized images played back at a constant rate, and JPEG does an admirable job of compressing images, so let's just go with that.
Ta-da. Our footage is now compressed somewhere on the order of two-to-one. That is, what required 2N bytes of storage before now requires only N bytes. Yippee skippee, our job is done.
(For the more advanced readers out there ? if any ? this is basically what Digital Betacam does. Digibeta doesn't use JPEG compression, obviously, but both JPEG and the Digibeta algorithm are based on the same discrete cosine transform algorithm, so from 10,000 feet, we can say that these approaches are equivalent if not equal.)
Now, let's try editing our footage. Uncompressed footage is, of course, trivial to edit. You just have to have a computer program that says "Play back frames 1-300 of this file, then switch to that file and play back frames 48-202, then switch to yonder other file and play back frames 1-32." Easy. The only real requirement is that the device where your frames are stored ? your framestore, in other words ? can keep up with the demands of its silicon taskmaster.
But what about our compressed footage? Well, it's really pretty much the same. Except instead of saying "play back frames 1-300 of this file," we have to say "read in and decode frames 1-300 of this file." The decoding takes time and effort on the part of the computer, so we have to make sure there's enough time between when each frame needs to be displayed for all the necessary math to be done.
That caveat aside though, editing this compressed footage and playing it back in real time are pretty easy tasks. No big shakes.
But. You knew there would be a "but," didn't you? We only got a compression ratio of about 2:1 out of this scheme. That sounded like a big improvement at the time, but it only served to take the 144 megabytes of storage per second of footage down to 72 megabytes per second. That's still a lot, when you remember that we have to deal with hours of footage in total.
So we need a better compression scheme.
Let's look at our footage a little more closely. It consists of a sequence of same-sized frames played back at a constant frame rate, like we said before. But something that's interesting about our footage is the fact that each frame is largely similar to the frame that preceded it. We don't have a frame of a tree followed by a frame of a cat with a funny caption followed by a frame of porn. What we've got is a few hundred frames of two people standing there, moving a little bit and talking to each other. The frames are all largely similar to each other.
So what if, instead of treating each frame as its own special snowflake, we instead assumed that each frame was going to largely resemble the one that preceded it? What if instead of compressing each frame anew, we compressed the first frame just like we were before, then merely described each subsequent frame in terms of how it differed from the previous frame? If, as we assume, each frame largely resembles the previous one, then the differences between them should be fairly small, and we should be able to get huge compression ratios, on the order of 200:1 or more!
Ah, but there's a little bit of a problem here. Playing back our compressed footage in real time is pretty simple ? not nearly as simple as before, 'cause there's more and more-complex math involved, but still, it's doable. But what happens when we want to seek? In other words, what happens when we don't want to start playing back from frame 1, but rather from frame 60?
In our first iteration, the computer would just read back frame 60's encoded representation from disk, decode it and display it. Easy. But now, when the computer read's back frame 60's representation, it sees "Okay, here are the changes from frame 59." And when it reads frame 59, it sees "Okay, here are the changes from frame 58." And so on, alllllll the way back to frame 2. When we get to frame 2, we see "Okay, here are the changes from frame 1," and then we read in frame 1 which, it turns out, is something we can actually decode.
So then we decode frame 1, make the changes to turn it into frame 2, make the changes to turn it into frame 3, and so on and so on, until finally we get to frame 60, by which point we stop doing anything because the operator who seeked to frame 60 and hit the "play" button has long since gotten fired, gone broke, collapsed into homelessness and substance abuse and died of exposure down by the river.
Clearly this scheme is sub-optimal.
Okay, okay, okay, but wait. What if instead of encoding only the first frame and storing all subsequent frames as differences, we started things over every, I dunno, half-second or so? What if we stored frame 1 as a self-contained compressed image, then wrote down the differences for frames 2 through 11, then started over again with frame 12? Would that be a reasonable compromise?
Yes. Yes, it certainly would. That would still give us good compression ratios ? about 15:1 ? but would allow us to seek around the footage without ruining operators' lives.
But wait a minute. There's a little catch. And to explain it, I have to draw a little picture:
O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 O12 O13
E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E12 E13
D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13
Here we have three snippets of footage. The first snippet ? O1-O13 ? is the original, uncompressed footage. The second ? E1-E13 ? is the encoded footage, with the self-contained frames in boldface. The third ? D1-D13 ? is the decoded footage that results from playing back the encoded sequence.
Frame E2, as we described before, is stored as a list of changes (essentially) between frames O1 and O2. The computer, to play back the encoded footage, decodes frame E1 to get frame D1, then applies the changes from E2 to make D2. And so on. But each time it does this, it's sort of making a copy of a copy; frames D2-D12 drift further and further away from the original frames O2-O12. When we get to frame E13, all that came before is forgotten, and we're back to a self-contained frame again that, when decoded, closely resembles the original.
So the cool thing we did ? storing frames as differences to save space ? introduced the problem of video quality that degrades every half-second, only to pop back into fidelity again. That's not good.
We get around this by remembering that the whole concept of time is an illusion, at least in this case. We've been thinking of this sequence of frames as a moving picture, with some frames coming before and others coming after. That's not right. The truth is, all these frames are written down, and we can read them in any order we choose. We don't have to limit ourselves to looking back; we can also look ahead. And since we have a fully self-contained frame just sitting there ? frame E13 ? there's nothing stopping us from using it as a point of reference for frame E12, just as we used frame E1 as the basis for frame E2.
So once we're all done, we end up with this group of pictures, where each frame in the group either is self-contained, refers to the frame that came before it, or refers both to the frame that came before and the frame that comes after.
Terminology time: The self-contained frames are called "intra-compressed frames," or "I-frames" for short. Frames that refer to the previous frame are called "predicted frames," or "P-frames." Frames that refer both to the previous and the next frame are called "bidirectionally predicted frames," or "bi-predicted frames" for short, or "B-frames" for even-shorter. The whole set, from one I-frame to the next, is called a "group of pictures," or GOP.
And here we have the heart of the matter. Video compression comes in two broad types: I-frame compression, like our first example, which provides easy random access but at the cost of lower compression ratios; and GOP compression, which gives better ratios but makes random access harder. All moving-picture compression schemes fit into one ? and exactly one ? of these two categories. For example:
I-FRAME
Photo JPEG and M-JPEG
DNxHD
ProRes
DV/DVCPRO HD
AVC Intra
GOP
HDV
IMX
XDCAM
AVCHD
Now, we're not quite done. We have just one little bit of business left to deal with, and that's the issue of GOP structure. Earlier we were talking a bit in the abstract, waving our hands about I, B and P frames. In the reality of MPEG-2, the structure of a GOP is quite rigid. It's typically IBBPBBPBBPBBPBB(I), but it varies from vendor to vendor and implementation to implementation. Point being, for a given flavor of MPEG-2, the GOP structure is absolutely fixed.
Let's say you've got two pieces of footage, both in MPEG-2 format, so they're both stored as GOPs. You want to edit them, which means you're going to cut into both of them and splice them together at some arbitrary frame. Say what you end up with looks like this (where bold type means one piece of footage and roman type means the other piece):
BPBBIBBPBBPBBPBBPBBIBBPBBPBPBBIBBPBBPBBPBBPBBIBBPBBPBBPBBPBB
Well that's completely wrong. Because you trimmed frames off the head of your first shot, your GOP doesn't start on an I-frame. And that's just the beginning. From the perspective of MPEG-2, this is complete rubbish. It's not valid at all, and can't be played back. It's just binary noise sprayed across a computer disk.
In order to translate this into proper MPEG-2 video, your computer must fully decode all those frames, then fully re-encode them again from the uncompressed versions it creates in memory. Why? Because what used to be a B-frame must be written out as an I-frame, and what used to be I-frames must become B- or P-frames, and so on all down the line. Every frame of this footage must be re-encoded into another type of frame in order to fit into MPEG-2's GOP structure.
Now, MPEG-2 is really quite good, in terms of visual fidelity to the original footage. It's not perfect, but it's really very good most of the time. But when you push it ? say, forcing it to encode a gushing firehose of data down to a trickle ? it's going to give you mixed results at best. That's why HDV usually looks slightly crap even under the best of circumstances, because it's squeezing a gigabit and a half of data down to 25 megabits. But when you then turn around and tell MPEG-2 to do it twice, well, frankly we're all lucky MPEG-2 doesn't flip us all the finger and piss off down to the bar for a stiff drink or three. Because seriously, we're asking MPEG-2 to do a lot. First it performs a veritable miracle for us by compressing gobs and gobs of frames down to a bitstream weak and thin enough to be smeared over consumer-grade 4mm data tape, and then we say "that's nice, deary, but be a doll and have another go at it?" Come on. That's just mean.
Seriously. Any day now, I expect MPEG-2 to get fed up with the whole mess and for all the world's HDV cameras to start outputting frame after frame of static, punctuated by occasional crayon-drawings of dicks.
Sorry, only registered users may post in this forum.
