24p Capture comes to FCP 6.02

[Steve Mullen]

Originally Posted by Matt Devino

Working in an HDV timeline, if you place a title into your timeline you will eventually need to render it, if not right away.

You will render to HDV ONLY if for some odd reason where the graphic is doesn't playback fast enough. You are missing the point that FCP is a RT NLE. Even when you add lots of FX, playback only slows down a bit. There's almost no need to render even with many streams.

And even if you like to wait for renders -- the render to HDV will only be for viewing faster. It has NOTHING to do with export. You will not render to HDV in the final export. You will lose NO quality. All that stuff about errors will never happen.

You seem to think FCP first compresses to HDV and then uncompresses and re-compresses to another codec. It does not. FCP throws away all renders on export and takes the 4:4:4 YUV of each frame -- ignores the Sequence codec -- and compresses it to the export codec.

The only time the HDV codec NEED be used during export is if you write back to HDV tape. And, that makes perfect sense.

PS: And most folks will not be monitoring via HD-SDI. Not when Apple provides a Cinema monitor connection. My laptop outputs DVI which connects via HDMI.

ANYWAY, if you have a AJA/BM card then you obviously will NOT be capturing HDV via FW. You'll connect via HD-SDI and then you'll not capture HDV. Now the HDV is converted to 4:2:2 10-bit INSIDE your VTR. That MAY look better, but I've never seen proof of this.

Frankly, the huge increase in storage (ProRes 422) and the possible need for a RAID (uncompressed) are so negative that I'll gladly accept a quality loss that a few anti-HDV types claim they can see.

PS: when you do CC or use Color the result is not compressed to HDV. It is fed directly to your monitor.

[Matt Devino]

Originally Posted by Steve Mullen

\You are missing the point that FCP is a RT NLE. Even when you add lots of FX, playback only slows down a bit.

Sure it's realtime, but not at 4:4:4. BTW there's no such thing as 4:4:4 YUV, 4:4:4 is by definition RGB. When I was working on the 4:4:4 conform of The Kingdom YUV never entered the equation.

Originally Posted by Steve Mullen

\the render to HDV will only be for viewing faster. It has NOTHING to do with export. You will not render to HDV in the final export. You will lose NO quality.

What are you talking about? Final export to what? Quicktime? Tape? If I got to say an HDCAM tape from my HDV timeline over an SDI card, it doesn't magically re-render everything on the fly to "10-bit 4:4:4 YUV" as you've been saying. It just scales the video to the correct dimensions and puts it on tape. If you're going back to HDV tape sure then it doesn't matter, but what kind of company would accept HDV tape as a delivery format?

Originally Posted by Steve Mullen

\You seem to think FCP first compresses to HDV and then uncompresses and re-compresses to another codec. It does not. FCP throws away all renders on export and takes the 4:4:4 YUV of each frame -- ignores the Sequence codec -- and compresses it to the export codec.

I've never said anything like this. What you just explained in the second sentence of that paragraph is exactly what you are accusing me of saying. If you work in HDV it stays in HDV period, until it is on tape or you output a quicktime movie in a different codec.

Originally Posted by Steve Mullen

\PS: And most folks will not be monitoring via HD-SDI. Not when Apple provides a Cinema monitor connection. My laptop outputs DVI which connects via HDMI.

ANYWAY, if you have a AJA/BM card then you obviously will NOT be capturing HDV via FW. You'll connect via HD-SDI and then you'll not capture HDV. Now the HDV is converted to 4:2:2 10-bit INSIDE your VTR. That MAY look better, but I've never seen proof of this.

Your apple cinema display is not a professional video monitoring tool. If you're doing stuff for YouTube or home movies then fine it's great. I own one too. Sure it's nice and pretty, but it's not even close to par with a professional calibrated tube monitor. I would NEVER analyze video on a cinema display, or any consumer LCD/plasma for that matter.

As for the SDI card, I'll still capture over firewire, it's too much of a pain in the ass to capture HDV over SDI. Capturing through SDI isn't going to gain you a whole lot unless you want to convert to uncompressed on capture. But the only reason to do that is the exact same reason to trancode to ProRes, so you don't have to work in HDV space! And now ProRes exists so there's a high quality codec to work in that takes up next to NO drive space compared to uncompressed. The SDI card is there for monitoring on a pro monitor, and for outputting to a pro deck when you're done

Originally Posted by Steve Mullen

\PS: when you do CC or use Color the result is not compressed to HDV. It is fed directly to your monitor.

If you color correct in FCP and stay in an HDV timeline for finishing then yes it will be rendered HDV. The Color app is a whole other architecture, it only operates in RGB 10-bit or ProRes and nothing else.




I'm done with the flaming. I just hope somebody doesn't think YUV 4:4:4 is something that exists in their FCP system after reading this.



Now to get back on topic, yea, pulldown removal over firewire from a V1U works in 6.0.2

[Steve Mullen]

Originally Posted by Matt Devino

Sure it's realtime, but not at 4:4:4. BTW there's no such thing as 4:4:4 YUV, 4:4:4 is by definition RGB. When I was working on the 4:4:4 conform of The Kingdom YUV never entered the equation.

Finally I realize you do not know what 4:4:4 means. No wonder you think you weren't using it. The meaning of 4:4:4 is that both chroma components are sampled at the same rate as the luma. From the FCP manual:

"4:4:4 Each R, G, and B channel, or each Y´, CB, and CR channel, is sampled at the same rate. Maximum color detail is maintained."

And this from a review of FCP" "However, FCP 4's render engine processes video at 4:4:4:4, which makes sense because FCP 4 offers color-correction tools and compositing operations that make full use of the higher sampling rate."

RGB is inherently equally sampled. So, it IS often called 4:4:4.

But, YUV can also be 4:4:4. It's often called BASEBAND video. In a camera when you convert RGB to YUV -- the result is 4:4:4. Prior to processing or recording the two chroma components are decimated (down-sampled) to 4:2:2.

Likewise, before FCP does any computation on ANY video -- it CHROMA up-samples to 4:4:4 YUV. HDV is up-sampled from 4:2:0 while ProRes is up-sampled from 4:2:2.

Now hopefully you understand why nothing is improved by converting during capture from 4:2:0 to 4:2:2 and then to 4:4:4. In fact, quality may be improved by waiting until a frame needs to be processed where FCP does ONE conversion from 4:2:0 to 4:4:4.

And now that you understand that FCP always computes in 4:4:4 at either 8-bits or 10-bits -- you can hopefully see your other ideas are baseless. They are ideas that editors often pickup from other editors.

For example: Sony makes only one HD tube monitor. It costs $40,000. So like it or not, the vast majority of FCP users will be using either LCD or Plasma displays. Like HDV -- this is "good enough" for most applications.

For example: I never said FCP did anything "magically." Unless you are exporting HDV -- YOU need to do something. You can export to a QT Movie where you specify a codec. You can export to using Compressor where you specify a codec. You can export to DVDSP where you specify a codec.

Or, you can follow the procedure in your AJA/BM manual. This will simply convert every frame in a Timeline back to YUV 4:2:2.

For example: Color automatically creates a 4:2:2 render even when the source is native HDV. If you don't use Color, all computations are done in 4:4:4 YUV. There is NO rendering to HDV!!!

In FCP you almost never render so I don't why you keep talking about it. If you find playback not fast and smooth enough -- ONLY then do you MANUALLY render a small segment. Yes -- this will be to HDV. But, you are only doing this for a smooth PREVIEW. Not a final quality check.

As soon as you pause -- you are looking at 4:4:4.

I'm not flaming you, in fact because of your post I just learned: Because of the new Open Timeline you can use ProRes 422 Sequences. Thus, all PREVIEW renders will be to ProRes 422 - not HDV. Yet you can use native HDV clips freely in the Sequence. RT still works.

[Mark OConnell]

"I think people will be interested to see this:

http://www.flickr.com/photo_zoom.gne...7000334&size=o

This is a frame grab comparing the footage I captured using on the fly conversion to ProResHQ to HDV footage I had on my system that was captured as HDV in 6.0.1"


Wow. The difference in quality between the two parts of the frame is amazing.

[Steve Mullen]

Originally Posted by Mark OConnell

Wow. The difference in quality between the two parts of the frame is amazing.

If HDV really looked that bad:

1) no one would watch it.

2) if the source really looked that bad -- every bit of aliasing and MPEG-2 blocking would be copied to the prores image.

No one claims ProRes can magically remove aliasing and MPEG-2 blocking. That would be an absurd claim. The higher quality media would copy every bit of detail which would include the crap.

So what's going on? The top frame is not pure HDV. It is HDV that was put through Compressor to try and remove pull-down. Who knows what happened to it. It looks like it lost one field.

The bottom frame is HDV-to-ProRes without any additional processing. Bottom-line, Apples and Oranges. Doesn't prove anything.

Hint -- when you saw how bad the output from Compressor was, you should have realized something was wrong with its Output NOT the input.

[Matt Devino]

Hey Steve,
No, really, I opened up the original HDV image as well as that converted image in an HDV timeline, and inverted one of the clips and it produced a white screen, i.e. they matched pixel for pixel (btw originally the only reason I was converting to ProRes was because compressor would crash if I tried to remove the pulldown and compress back to HDV, I had to go to another codec for it to not crash, and cinema tools wouldn't remove pulldown from anything that wasn't intra frame).

Now, I'm not claiming that ProRes magically "fixes" an HDV image, that would be, well, magic. What I'm saying is, at least on my FCP system, in 6.0.1 FCP was doing something on capture that screwed up my HDV image, and it's not doing it now that I've upgraded to 6.0.2. It could have been something wrong with my system, but it may have happened to other people as well, and now 6.0.2 did fix the problem, so I thought people should have been aware of it in case they had the same problem I was having. A regular HDV capture looks the same as a ProRes capture on my 6.0.2 system.

As per our earlier discussion, seems I was wrong about YUV (Y'CbCr)

From wikipedia:

4:4:4 Y'CbCr
Each of the three Y'CbCr components have the same sample rate. This scheme is sometimes used in high-end film scanners and cinematic postproduction. Two links (connections) are normally required to carry this bandwidth: Link A would carry a 4:2:2 signal, Link B a 0:2:2, when combined would make 4:4:4.

4:4:4 R'G'B' (no subsampling)
Note that "4:4:4" may instead be referring to R'G'B' color space, which implicitly does not have any chroma subsampling at all. Formats such as HDCAM SR can record 4:4:4 R'G'B' over dual-link HD-SDI.

The term Y'UV refers to an analog encoding scheme while Y'CbCr refers to a digital encoding scheme. One difference between the two is that the scale factors on the chroma components (U, V, Cb, and Cr) are different. However, the term YUV is often (erroneously) used to refer to Y'CbCr encoding. Hence, terms like "4:2:2 YUV" always refer to 4:2:2 Y'CbCr since there simply is no such thing as 4:x:x in analog encoding (such as YUV).


Still, as far as I know, any NLE or camera that works in 4:4:4 is RGB (i.e. Avid DS Nitris, FCP with a Blackmagic or Kona card). The only tape format of 4:4:4 I know of is HDCAM SR, which I frequently work in, and is RGB. Of course per the information above, it looks like they may use 4:4:4 Y'CbCr in 2k or 4k DI's, which I have no experience with. The only DI work I've done was a 4:4:4 HD DI (RGB) which we did for Bury my Heart at Wounded Knee.

Now, if FCP is sampling everything at 4:4:4 Y'CbCr (YUV) for render, that's a little scary when working in RGB space, every time it renders it samples at 4:4:4 Y'CbCr then back to RGB? I haven't seen anything strange color-wise in a 4:4:4 render but it's still a little weird. Do you know if FCP still acts this way when you select "render everything in RGB" in your timeline options?

Anyway, I suppose that if you work in HDV, and export your entire timeline to say a 10-bit uncompressed quicktime movie, then yes you are right no downfall to working in HDV if all of your renders are being sampled at 4:4:4 YUV and re-rendered at 10-bit uncompressed (although any color effects may look slightly different, maybe better, in the final quicktime output). But if you are simply going to play your timeline out to tape like a D5 or SR, it makes sense to work in the 10-bit space the whole time so you don't need to output a quicktime of your entire timeline before sending out to tape (your renders would be sampled from your timeline's codec at 4:4:4 YUV like you said, then rendered at your timeline's codec) so being in a 10-bit timeline makes sense for this workflow. In the end it truly depends on where the end destination for your project is that determines where you start, and HDV or ProRes are both completely legitimate options depending on what your project calls for.

[Steve Mullen]

Originally Posted by Matt Devino

Now, if FCP is sampling everything at 4:4:4 Y'CbCr (YUV) for render, that's a little scary when working in RGB space, every time it renders it samples at 4:4:4 Y'CbCr then back to RGB? I haven't seen anything strange color-wise in a 4:4:4 render but it's still a little weird. Do you know if FCP still acts this way when you select "render everything in RGB" in your timeline options?

Anyway, I suppose that if you work in HDV, and export your entire timeline to say a 10-bit uncompressed quicktime movie, then yes you are right no downfall to working in HDV if all of your renders are being sampled at 4:4:4 YUV and re-rendered at 10-bit uncompressed (although any color effects may look slightly different, maybe better, in the final quicktime output). But if you are simply going to play your timeline out to tape like a D5 or SR, it makes sense to work in the 10-bit space the whole time so you don't need to output a quicktime of your entire timeline before sending out to tape (your renders would be sampled from your timeline's codec at 4:4:4 YUV like you said, then rendered at your timeline's codec) so being in a 10-bit timeline makes sense for this workflow.

I can't explain what you found with 601, but it sure did look bad. No wonder you were worried. I did pull lots of frame grabs fron 24p for my book and I never saw anything that bad.

---------

I've never even thought of RGB with FCP because -- coming from Media 100 -- I always have tried to avoid working with RGB-based NLEs. I remember the FCP command, but that's it. Can you tell us when you use RGB?

In any case you are correct -- if you worked in 4444 YUV and at the end rendered to RGB the color-space will be re-sampled. Perhaps that's why FCP has the "render in RGB" mode. I assume it forces HDV to be converted not to 4444YUV but to 4444RGB before rendering. In this way there would be no color changes during the final export.

Is there a real problem? Avid Liquid, for example, has some FX that are RGB and some that are YUV. I remember that some Matrox hardware FX are RGB and some YUV. (The RGB FX were processed by the Graphics Processsor while the YUV FX were done by the CPU.) I don't remember any problems, but it points out that it's VERY hard to get details on the insides of our NLEs.

Matt, thanks to you -- I went back to my FCS2 docs and actually read about the new Open Timeline. It works! From now on I can choose ProRes as my Sequence Preset. Makes no difference what's coming in or out.

Unless I render -- everything is RT just like before. But, if I render it will be to ProRes not HDV. Magic -- renders will be in 422 space.

I wonder how many folks know this?

I don't know how I would send a Sequence to HDCAM or D5 or HDCAM SR. If one had an AJA/BM board with HD-SDI -- will they "convert" ProRes to uncompressed OR do you need to drop your Sequence into an uncompressed Sequence?

And, remember I said FCP always ignored renders at export -- now there is really no need. So, does FCP now use ProRes renders?

[James McCrory]

I thought that editing HDV natively was nothing but bad, Bad, BAD? I've read in so many places that everytime you make a cut you are degrading the image, and that if you care about image quality at all, you will NOT edit in HDV, but rather in another format. Now I'm reading here that there is absolutely nothing wrong with editing your film in HDV, and that transcoding to an intermediate codec is not necessary. So which is it?

Here is an excerpt from wikipedia:

"In HDV, splicing always introduces distortion at the splice points, due to the interdependencies between groups of video frames. Any editing of the video, whether it be a complex transition or a simple scene-change, requires a decompression and recompression of the entire HDV frame group... If HDV footage is converted (known as 'Transcoding') to a good intermediate format for editing, these considerations will not necessarily apply, and gradual degradation from generation to generation of edit may be avoided while substantial system performance gains are made."

http://en.wikipedia.org/wiki/HDV


And from Ken Stone's site:

"However, even a simple cut in a native HDV editing system will cause some kind of change to the video. This means that new video has to be generated which taxes your computer's CPU. More complicated things such as color correction, titles, and resizing video frames will cause all of the affected video to be re-generated. Therefore, in many situations, native HDV editing offers little or no advantage because so much new video needs to be created."

http://www.kenstone.net/fcp_homepage/hdvxdv_wright.html

[James McCrory]

I see the conversations have gravitated back to bags and such. What happened? You were all so outspoken on this subject just a moment ago, now no one knows anything?

I have never edited any HD material before so I wanted to thoroughly research a complete workflow before I spent so much as a penny upgrading my editing system. But I keep encountering contradictory information. I'm just trying to get the story straight to avoid wasting money and/or irrevocably destroying my project due to my ignorance of the nature of HD formats. So far I've just been shooting with my V1, and watching my footage on an LCD monitor.

In the meantime, here's another quote from the good people at Cineform, to add fuel to the fire.

"There is no question these new HDV cameras acquire a great picture using MPEG2 compression, but in this analysis we will show that editing using the source (MPEG2) format usually does not result in the highest quality final result... Some proponents of "native" MPEG editing claim HDV editing in its native form can be lossless; this can only be achieved if you don't change anything (including cuts -- which still require rendering using MPEG editing workflows). In practice, editing-session recompression must occur for obtaining an output even in a cuts-only scenario."

http://www.cineform.com/technology/H...tyAnalysis.htm