-
AVID Editor Needs to Transfer Media (Not Timeline) to FCP for Tweaks
Hi All,
New to this forum (just a few people over here); have spent more time over at Compression over the years.
I’m an AVID editor (10+ years experience) that needs to (quickly) take a :30 ad created on an OS 9.x MC and import it to FCP 4.5 (< 2 days experience) for further changes (OK, the reason is financial). I just want the composited piece as a single clip, not the AVID timeline (if I do more of this, the "Duck" will roost here) and its linked MediaFiles. I normally create QT "masters" of AVID projects as archival backups using the Meridian QT codec and thought that might be the cleanest way to get the piece exported to FCP. I don't have any outboard gear to go from Component (or any analog source) to my G5 - just an empty Firewire port at the moment. As a digression (one of my favorite modes), I've used Apple Compressor recently to encode Meridian Compressed QT files generated by the AVID, to MPEG-2 to become DVD's via Toast or DVDSP but have had some issues (somewhat resolved) trying to get the gamma level to match that of a DVD burned directly out of the AVID via S-Video to a stand-alone DVD recorder. So part of my question has to do with trying to insure that whatever codec I use to get into FCP won't produce gamma issues as well. I've used Compressor to generate two different encodes of the AVID generated Meridian Compressed QT file; one using MJPEGA at full Quality and the other at 8-bit Uncompressed, both preserving the AVID's frame size, 720x486. This project will most likely output back to BetaCam SP for local air; my assumption is that I'll want this FCP edit to export out as a Meridian codec QT again to go back onto the AVID for final transfer onto BetaSP tape. I imported the two Compressed files into FCP and I also imported the original AVID Meridian QT file. I've created three different FCP sequences using settings appropriate for each clip's codec. Each sequence plays OK without further rendering although FCP complains sometimes about dropping frames playing the Meridian codec sequence (the Meridian codec was never designed as an authoring codec, just quick, accurate transport). In theory, if I'm going back to the AVID, I thought that keeping the edited clip in it's native codec might keep things cleaner but I didn't expect that FCP (or any MAC) could play a Meridian codec QT file real-time -- but a G5 D2 does impress! But here's the rub - the Meridian codec and the 8-bit Uncompressed sequences have a "gamma shift" problem but the MJPEGA sequence does not. The "shift" I'm seeing is that when playing, the computer screen shows a darker picture than when paused. This is true whether I'm playing the clip in the Viewer or the Sequence in the Canvas. The paused state of the 8-bit and Meridian codec sequences matches the brightness of the MJPEGA sequence. I don't have an analog-Firewire converter so I can't look at the output on a broadcast monitor so perhaps the problem is only on the computer screen?? I've been also working on a couple of 24 P Advanced projects digitized from a rented DSR-45 but I don't see any difference on the screen from pause to play in those projects. And I don't see the shift, as I said, using MJPEGA, BUT, I don't know that this codec is producing an accurate gamma either; its sequence just doesn't "shift". I have been aware of and have played with the RGB vs. YUV settings for the sequences of each codec - another "bad" thing about using the Meridian codec sequence is that FCP doesn't allow for anything but RGB rendering using that codec (which seems odd as the AVID Meridian board uses 16-235 values instead of the older ADVB 0-255 - perhaps I am confusing YUV v. RGB with black/white values?). So what's wrong with full quality MJPEGA (aside from colors being slightly washed out)? I'm not sure anything is but I thought I'd ask. Aside from wasted drive space, I initially thought that 8-bit Uncompressed was the way to transfer a clip from an AVID to FCP but not if the gamma gets messed up. thanks, ren
-
13 Replies
-
Have you tried exporting using the Animation (Lossless) codec? Generally that is the preferred codec to move Quicktimes from one format to another or one NLE to another.
Walter Biscardi, Jr.
Creative Genius, Biscardi Creative Media
https://www.biscardicreative.comNow in Production, “The Rough Cut,” https://www.theroughcutmovie.com
“I reject your reality and substitute my own!” – Adam Savage, Mythbusters
-
Personally I’d avoid the Animation codec and use Motion JPEG @ 100% quality. The Animation CODEC is 8bit RGB, and makes massive files. Motion JPEG is YUV 4:2:2.
-
[Daniel_l] “Personally I’d avoid the Animation codec and use Motion JPEG @ 100% quality”
Except that in his original post, he said MJPEG is giving him Gamma Shifts. That’s why I suggested Animation.
Walter Biscardi, Jr.
Creative Genius, Biscardi Creative Media
https://www.biscardicreative.comNow in Production, “The Rough Cut,” https://www.theroughcutmovie.com
“I reject your reality and substitute my own!” – Adam Savage, Mythbusters
-
While I believe I’ve gone both ways with Meridian-encoded files ( FCP <-> MC ) without problems, another method that works well has been using Blackmagic’s codec as an “intermediate” filetype. https://www.blackmagic-design.com/site/techsupport.htm
-
“…But here’s the rub – the Meridian codec and the 8-bit Uncompressed sequences have a “gamma shift” problem but the MJPEGA sequence does not”
I read that as ‘there was no shift happening with MJPEG’
I’d rather a slight gamma change (if there is in fact any change) than go from YUV->RGB->YUV.
I’d expect some (possibly perceived) visual changes in the display of interlaced video on a progressive display when switching between motion and paused viewing.
Proof of the pudding………
-
Thanks all. I’ll give the Blackmagic codec a try. The Meridian is nice because the G4 based AVID takes forever to export any other codec, but if it causes problems with the rest of the process…
After more experimenting and reading, it seems possible that what I may be seeing on my computer screen is an artifact of RT FCP playback of non-DV clips due to the lack of hardware support and not anything that will end up in the edited file for export. I’m getting the impression (I REALLY need to take a crash course) that FCP is dependent on PCI cards and other hardware to provide extra horsepower for RT playback of anything more challanging than 720×480 DV.
I hooked up my stand-alone DVD recorder to act as a Firewire to S-Video output for my broadcast monitor and quickly learned that when the FCP Output Video says “NTSC DV (720×480)”, it doesn’t mean “FCP will RT playback 720×486 sized video through a 720×480 Firewire converter.” I need hardware
. When I cropped my Meridian QT file to 480 while encoding it to either DV or DVCPRO 50 codec and imported it, FCP acted like everything was fine, AND, I couldn’t see any difference on the broadcast monitor between the 8-bit sequence (I could only view stills of this sequence on the broadcast monitor) and the DV sequence. So I’m assuming that the limiting factor in this project is the quality of the original Meridian QT export from the AVID, originally encoded at 2:1 compression.
ren
-
[Ren Hinks] “I’m getting the impression (I REALLY need to take a crash course) that FCP is dependent on PCI cards and other hardware to provide extra horsepower for RT playback of anything more challanging than 720×480 DV. “
The reason you aren’t seeing a difference between DV and 8-bit because you’re using the Firewire as your output to the broadcast monitor. Firewire outputs DV, DV50, and DV100 only. Nothing else. So the 8-bit is essentially being converted to DV as you play it back- hense you don’t get RT playback, only 1 frame when paused (BTW, hit option-P for close-to RT preview). Hopefully that makes sense. You see, Final Cut has no problems working with uncompressed 486 material whatsoever. But without a card, there’s no way to actually view 486 material. You’re trying to force uncompressed 486 footage down the throat of the Firewire bus which only accepts DV 480 footage.
If you stick with the Apple 8-bit codec (or Blackmagic), and you have YUV rendering on, you won’t have to worry. As long as you don’t convert the colorspace, it’s 100% lossless. Just make sure the sequence settings match the media. You’ll know it matches when there’s no colored bar on the timeline. But if you still don’t trust it and you need to see what it really looks from Final Cut, you gotta get a card.
-
[Ren Hinks] “I’m getting the impression (I REALLY need to take a crash course) that FCP is dependent on PCI cards and other hardware to provide extra horsepower for RT playback of anything more challanging than 720×480 DV. “
Nope, actually the opposite is true. The G5 is the engine that drives most of the realtime functionality of FCP. You can work in full uncompressed video space without the need for any PCI cards by using the AJA Io which is an external I/O device.
The only format that requires a PCI card is uncompressed HD.
[Ren Hinks] “I hooked up my stand-alone DVD recorder to act as a Firewire to S-Video output for my broadcast monitor and quickly learned that when the FCP Output Video says “NTSC DV (720×480)”, it doesn’t mean “FCP will RT playback 720×486 sized video through a 720×480 Firewire converter.” I need hardware . “
DV is 720×480 so why would you expect FCP to output a 720×486 signal from this? Even with any PCI card you will need to render 720×480 footage into a 720×486 timline if that’s what you want to output.
[Ren Hinks] “When I cropped my Meridian QT file to 480 while encoding it to either DV or DVCPRO 50 codec and imported it, FCP acted like everything was fine, AND, I couldn’t see any difference on the broadcast monitor between the 8-bit sequence (I could only view stills of this sequence on the broadcast monitor) and the DV sequence. So I’m assuming that the limiting factor in this project is the quality of the original Meridian QT export from the AVID, originally encoded at 2:1 compression. “
You encoded your footage into the DV codec so you compressed your footage. Of course it will look like DV. If you want to remain in the uncompressed world, export your footage in the Apple 8bit or 10bit codec and then connect to an AJA Io for playback. If you have at least FW 800 drive, all playback will be realtime.
Uncompressed does not play back via Firewire directly out of FCP, you need to have an Io box.
Walter Biscardi, Jr.
Creative Genius, Biscardi Creative Media
https://www.biscardicreative.comNow in Production, “The Rough Cut,” https://www.theroughcutmovie.com
“I reject your reality and substitute my own!” – Adam Savage, Mythbusters
-
[Ren Hinks] “I hooked up my stand-alone DVD recorder to act as a Firewire to S-Video output for my broadcast monitor and quickly learned that when the FCP Output Video says “NTSC DV (720×480)”, it doesn’t mean “FCP will RT playback 720×486 sized video through a 720×480 Firewire converter.” I need hardware . “
One more thing I forgot to mention, a stand-alone DVD Recorder adds compression to the image you see on your broadcast monitor. I have a Phliips model and the recorder is always running the footage through an MPEG-2 compression cycle before it gets to the monitor so if you really want to see the quality of your footage, you need to take the DVD Recorder out of the loop and get your image directly from FCP to your monitor.
Walter Biscardi, Jr.
Creative Genius, Biscardi Creative Media
https://www.biscardicreative.comNow in Production, “The Rough Cut,” https://www.theroughcutmovie.com
“I reject your reality and substitute my own!” – Adam Savage, Mythbusters
-
[Sean ONeil] “The reason you aren’t seeing a difference between DV and 8-bit because you’re using the Firewire as your output to the broadcast monitor. Firewire outputs DV, DV50, and DV100 only. Nothing else. So the 8-bit is essentially being converted to DV as you play it back- hence you don’t get RT playback, only 1 frame when paused (BTW, hit option-P for close-to RT preview).”
[Walter Biscardi] “recorder is always running the footage through an MPEG-2 compression cycle before it gets to the monitor “
First of all let me thank you for the feedback – its extremely helpful – I’ve got three DV 24 PA projects mid-stream that have to get finished pronto and a re-edit of an ad walked in the door yesterday, all with April something deadlines. 480 versus 486 output is something this AVID editor never had to think about before – everything was 486 mindset except for export to DVD.
The reason I thought there was little difference between 2:1 Meridian compressed footage transcoded to DV or to 8-bit was that even though I could only look at stills of the 8-bit sequence, it seemed to look no different than stills of the DV sequence. However, there could be BIG differences in running playback seen through a card or IO hooked to a broadcast monitor – I thought looking at things through the DVD recorder to act as a Firewire bridge was a kludge but I didn’t even think about the MPEG-2 conversion it would apply to its output – thanks Walter.
Perhaps the two sequences looked identical because of the MPEG-2 compression being applied to the image but my initial reasoning had more to do with data rate comparisons of the original Meridian 2:1 Compressed file, the DV and the 8-Bit file – since one can’t improve on an image when transcoding, I reasoned that since the datarate of the Compressed Meridian was very close to the datarate of the DV transcode, that the original file’s resolution was the limiting factor. There is some proprietary encoding of AVID’s native codecs so that may not be a completely accurate assessment.
[Sean ONeil] “If you stick with the Apple 8-bit codec (or Blackmagic), and you have YUV rendering on, you won’t have to worry. As long as you don’t convert the colorspace, it’s 100% lossless.”
So to cut to the chase, now that I know I have the re-edit job of a :30 originating from a BetaCamSP edit master, I encoded it to the AVID here using 1:1 Uncompressed instead of 2:1 as I did the night before and then dumped that out to the G5 as a Meridian Uncompressed QT.
I have to go through the interim stage of using one of the Meridian codecs for export because the AVID is running on OS 9.0.4 and Quicktime 4.1.2 (the owner refuses to put any money into upgrading it, hense my migration to FCP) and has no 8-bit export option, only M-JPEG. I tried to D/L the Blackmagic 8-bit codec but the web site only has codecs for Windows systems and Mac OS 10.x; nothing for OS 9.x (even though there is a OS 9 logo in the codec D/L sidebar – I emailed Blackmagic about this).
On the G5, I transcoded the Meridian Uncompressed QT to an 8-bit and file size and datarates were almost equal. Using the 8-bit encode derived in this manner makes more sense to me and although I’m still not able to monitor the sequence on a broadcast monitor, the picture looks much better on the computer screen in FCP. FWIW, FCP is not happy trying to play a sequence based on the Meridian Uncompressed codec, hence the transcode to 8-bit for FCP use.
Someone in this thread earlier mentioned using MJPEGA for transport but I think I read that it is lossy, even at 100% – is there any reason to use that versus 8-bit?
[Walter Biscardi] “The G5 is the engine that drives most of the realtime functionality of FCP. You can work in full uncompressed video space without the need for any PCI cards by using the AJA Io which is an external I/O device.”
From the Blackmagic Web site:
DeckLink cards feature:Realtime effects in Final Cut Pro. Cross Dissolve, Dip to Color, Sepia, Desaturate, Brightness Contrast, Proc Amp, Tint, Gamma Correction and 3-Way color Corrector. RT Extreme support in Final Cut Pro
Reply to this Discussion! Login or Sign Up