FCP Native HDV editing: the good, the bad and the ugly

[Stephen L. Noe]

@ Tim D. How about renaming the thread header to "FCP Native HDV editing: the good, the bad and the ugly".

As Andy said, uncompressing the timeline for delivery is nothing new but may be new to FCP users since the recent (welcome) update.

S.Noe

[Simon Reilly]

Originally Posted by Nigel Cooper

I will be doing tests. I have been told by a codec guru that if there are any cross-disolve type renders or other complex graphics that have been rendered out in HDV there could be blockies and artifacts, whereas a bump to uncompressed 8-bit timeline re-renders them in that format i.e. not HDV hence no blockies etc.

I have been searching this forum and others seeking a answer .
Here is my senario,
Shot 720 30p on HD 100 , droped it in a HDV timeline [FCP 5.2], approx 7 minutes, lots of filters and time remapping , colour correction.
Export to compressor , using best Quality DVD 90minutes 16 x 9 , import to DVD studio pro.Burn.
What I notice while viewing on a NTSC monitor and a NTSC projector, the image is lighter, also blacks where I changed the contrast , becomes blocky as talked about in this thread.
Does anybody have any suggestions as to how to reslole these issues, it would be so nice to have a finished product that is a mirror image of the piece I see being played in my timeline.
thanks

[Jiri Bakala]

Originally Posted by Shaun Wilson

Well I dunno what things are like in FCPland, but when Avid gets around to releasing 720p25 support my workflow will be something like this:

-Capture HDV
-Change project to SD & transcode media to DV or 15:1 (probably DV, space is cheap these days)
-Edit offline with SD footage for speed's sake
-Change back to HD project, relink sequence to HDV media
-Use DNxHD to render anything while mastering
-Mixdown to a DNxHD master

I'd be curious to hear what workflows people use for HDV (especially with HDV under Avid but under any NLE would be interesting)

Shaun,
I don't think that you are gaining anything by transcoding to DV. Editing in HDV is equally fast - I didn't notice any delays other than the need to render some effects, such as superimposed titles. The method I used was to edit as far as you can in native HDV and when the picture is locked and you are ready for colour correction, titles and other final stuff, transcode to the highest DNxHD codec and finish in that.
My problem was getting to SD DVD directly from the HD timeline. I could do it but the picture didn't look good with washed out colours and raised blacks. I had to take the HD timeline, "Export to HDV Device" and then use the HDV tape, downconvert it via the deck to DV, recapture the master in DV and geti it to DVD the usual way (QR REF).

[Simon Reilly]

Originally Posted by Jiri Bakala

Shaun,
I don't think that you are gaining anything by transcoding to DV. Editing in HDV is equally fast - I didn't notice any delays other than the need to render some effects, such as superimposed titles. The method I used was to edit as far as you can in native HDV and when the picture is locked and you are ready for colour correction, titles and other final stuff, transcode to the highest DNxHD codec and finish in that.
My problem was getting to SD DVD directly from the HD timeline. I could do it but the picture didn't look good with washed out colours and raised blacks. I had to take the HD timeline, "Export to HDV Device" and then use the HDV tape, downconvert it via the deck to DV, recapture the master in DV and geti it to DVD the usual way (QR REF).

Thanks Shuan,
Sorry but when yoy say "downconvert via the deck" is this possible to do using the HD 100 and if so , how would I go about it .
thanks

[Nate Weaver]

Originally Posted by Nigel Cooper

I will be doing tests. I have been told by a codec guru that if there are any cross-disolve type renders or other complex graphics that have been rendered out in HDV there could be blockies and artifacts, whereas a bump to uncompressed 8-bit timeline re-renders them in that format i.e. not HDV hence no blockies etc.

Your guy has the right intention, but what you're doing is unnecessary.

As long as you render to another format (uncompressed, MPEG-2 for DVD, etc), FCP always goes back to the original media and makes that timeline step redundant.

[Jiri Bakala]

Originally Posted by Simon Reilly

Thanks Shuan,
Sorry but when yoy say "downconvert via the deck" is this possible to do using the HD 100 and if so , how would I go about it .
thanks

I don't think the camera can do that... maybe Nate or some else can confirm this?

[Daniel Weber]

If you don't mind I will jump in with my FCP experience since I have been editing HDV for over a year now.

I am shooting with a Sony Z1 so my footage is 1080i60, but the theory should remain the same.

Most of my end use is SD DVD, but I edit everything native HDV and export a Quicktime movie with the original settings of my project. I then load this quicktime file into compressor and make a DVCProHD 720p60 version. I do this because I use a lot of H.264 for web and iPod delivery. This file seems to be a good master to then do compressions from either for DVD, web, whatever. Maybe I am adding an extra layer of compression, but my DVD's look pretty damn good.

I can then take my DVCProHD files and output to DVCProHD tape if need for an HD master. I could also go uncompressed HD if I wanted to make an HDCAM master.

Does this make sense?

Dan Weber

[Antony Michael Wilson]

Down-converting and Avid:

You can't down-convert via firewire using the camera or the BRHD50 (like you can with the Sony HDV devices). The camera can downconvert via component SD (or composite) analogue but you'll lose control and TC. If you want to capture in SD for offline (for example) you can ingest via component, unbalanced analogue audio and RS422 for control and TC. This is the method I use for Avid offline.

Btw, I agree with Jiri that the HDV transcode to DV is somewhat superfluous on a fast system. Furthermore - for long-form projects - it's usually more efficient to capture compressed SD for offline and then decompose a duped sequence and conform as HDV. You can then set renders and imports (Media Creation settings) for your online HDV timeline to DNx to ensure all processing happens at optimum quality. If you happen to have Symphony Nitris, you can use uncompressed HD instead. This method keeps the quality high, minimises storage requirements and eliminates lengthy transcodes.

[Ben Chace]

Hey fellas,

Very interesting to read this whole back and forth. I haven't yet tried any edits with the new FCP.. so I have nothing to add but one more question:

I've just gotten the DR-HD100 - and am awaiting the QT wrapper for 720p24 HDV recording... thinking I will finally have the streamlined HD 24p workflow I have been dreaming about since I got my HD100 a little over a year ago.

After reading all your varying assertions about the loss of quality in Native editing - I've got some basic questions which I was hoping you all might chime in on. They are:

When FCP (or perhaps in my future situation the DR-HD100) converts the MPEG2 stream into a quicktime clip - which we then use in the edit - is the resultant QT file still an MPEG2 stream? Or is it creating a reference file that refers to part of a companion m2t? Or something like that?
What happens to the GOP structure? And in this transition from mpeg2 stream to 720p24 HDV QT File is there any loss of quality?

When you convert to uncompressed HD what happens to the GOP structure?

Also, when people talk about "uppressing" to a codec with 4:2:2 color space for color correction - do they simply mean compressing HDV to dvcproHD (for example) or can this be done for via output of uncompressed HD? And what are the pros/cons of this process regarding image quality/resolution and original GOP structure?

I'm sorry - thats actually a ton of questions... any input would be greatly appreciated.. as I am in the early stages of planning a feature intended for filmout and I want to be rocksolid on the workflow from shoot to edit to output.. before I begin scheduling, budgeting, breaking down the script, equipment needs etc..

thanks for any input.

[Ben Chace]

oh yeah.. sorry

so (after re-reading my last somewhat confusing post) my basic question was - would there be any downside to recording 720p24 with the QT wrapper (on my DR-HD100) - assuming that these files will be my master footage, rather than a pure .m2t - if thats not what these files represent?

thanks.

[Nigel Cooper]

Originally Posted by Daniel Weber

Most of my end use is SD DVD, but I edit everything native HDV and export a Quicktime movie with the original settings of my project. I then load this quicktime file into compressor and make a DVCProHD 720p60 version. I do this because I use a lot of H.264 for web and iPod delivery. This file seems to be a good master to then do compressions from either for DVD, web, whatever. Maybe I am adding an extra layer of compression, but my DVD's look pretty damn good.

Dan Weber

Daniel, what you say makes sense, but I would not do it. Working in DVCPROHD is only any good if you are importing DVCPROHD footage to start with. So why convert from one heavily compressed codec to a different format, but still a compressed codec? You'd be better off leaving the DVCPROHD part out of it and either bumping to an uncompressed 8-bit (not 10-bit as that is a bit twitchy and is far from perfect right now) timeline and going from there, or go from HDV straight to Compressor

[Nate Weaver]

Originally Posted by Ben Chace

When FCP (or perhaps in my future situation the DR-HD100) converts the MPEG2 stream into a quicktime clip - which we then use in the edit - is the resultant QT file still an MPEG2 stream? Or is it creating a reference file that refers to part of a companion m2t? Or something like that?
What happens to the GOP structure? And in this transition from mpeg2 stream to 720p24 HDV QT File is there any loss of quality?

When using the "native" method in FCP to bring in HDV, the muxed stream is demuxed to it's constituent m2v and mp3(?) audio streams. These streams become tracks in a Quicktime file. The process also creates "hints" I believe for the Quicktime MPEG decoder that allow Quicktime to handle the file quicker.

The Quicktime file is still MPEG2, and it hasn't been trancoded to anything else...that is, the picture data is still untouched. It's just a different vehicle for the same data, same GOP structure.

Originally Posted by Ben Chace

When you convert to uncompressed HD what happens to the GOP structure?

Well...uncompressed video doesn't have a GOP structure. Each frame lives alone. So each MPEG frame is decompressed to a frame buffer, then written out to the uncompressed structure where it lives alone.

Originally Posted by Ben Chace

Also, when people talk about "uppressing" to a codec with 4:2:2 color space for color correction - do they simply mean compressing HDV to dvcproHD (for example) or can this be done for via output of uncompressed HD? And what are the pros/cons of this process regarding image quality/resolution and original GOP structure?

Boy, you're sure worried about those GOPs.

The above methods of outputting your final to uncompressed do away with the need to go to an intermediate step. Pros and cons? Going to uncompressed needs lots of disk space, and a fast drive if you expect to be able to play the resulting file in real time.

I have to say, this is an awful lot of talk about a simple aspect of how FCP works. What seems like voodoo or hearsay in this thread is kind of common knowledge amongst the FCP post houses here in Los Angeles...with all the questions and discussion, it seems much more complicated than it is!

[Mark Silva]

we never go back to HDV and seldom ever back to Tape for that matter in HD editing.

But if I did we would:

shoot in HDV with the HD100u-A

capture and edit in HDV.

export and uncompressed 10-bit quicktime for output later to HDCAM.


pure and simple and no need for complications.
I've looked at this kind of thing closely and have never seen anything ugly.

It really is not all that complicated as Nate has said.

[Ben Chace]

Nate and Mark others,

thanks for your comments/clarifications... much appreciated.

the nice thing about his forum (and this camera too, it seems) is that it works for both experts and intermediates - with regard the technical aspect. Thank you for clearing up my questions/confusions re: HDV format and the editing process

I myself am not incredibly tech-oriented.. and actually the process of figuring out a feasible hd24p workflow during the last year has forced me to learn a bit more of the technical side of file management - which has in turn made me a more efficient shooter and editor.

Big props to the forum members who take the time to explain these issues, to the less technically proficient. I hope in some way it has been beneficial to you work through your explanations of our various questions. It has certainly been a big help to me... when in many cases, JVC and Apple didn't really have much to offer in the way of support/answers.

[Steve Mullen]

Originally Posted by Nate Weaver

I have to say, this is an awful lot of talk about a simple aspect of how FCP works. What seems like voodoo or hearsay in this thread is kind of common knowledge amongst the FCP post houses here in Los Angeles...with all the questions and discussion, it seems much more complicated than it is!

Perhaps the problem stems from the fact that Avid does reuse renders and the fact that from the days of Hi8 and DV there was an obsession with bumping to something better.

I'll kill if I read one more time about the "fragile" nature of HDV. It's data in a file and no more fragile than your income tax data files. It gets decoded once in FCP. The uncompressed result of ANY FX is recompressed once during export to HDV, DVD, DV, HDCAM, DVCPRO HD, etc. There is one decompress and one compress.

If you waste the money to go to uncompressed there will be -- one decompress and one compress.

And, if I remember right -- FCP decodes HDV to 4:4:4 not 4:2:2. And, you can ask for all computations to be done in 16-bit (or maybe that's Liquid) or FPP. Then the bit-depth is ONLY determined by the export codec. So choose a 10-bit codec.