Michael Gissing
195
COW Coins
190
DaVinci Coins
3
Solve Coins
Forum Replies Created
-
You can set your render in the HDV sequence to ProRes and convert just the Firestore files to ProRes.
You don’t want to transcode your HDX 900 footage to HDV.
Walter’s method of transcoding to ProRes at the injest for all mixed format shows is the best idea. However, if you are mostly HDV and captured that way, then try the render setting option.
-
Nattress filters has a line drawing plugin if you have the map. I haven’t had reason to use it so I can’t comment on how well it works.
Shane’s suggestion of using Motion is better or getting a graphic artist to do it for you is even better.
-
Pardon my mirth, but what a welcome change to hear of a system defaulting to PAL (the most used system in the world) instead of NTSC.
I am sure that there will be something simple like system preferences to fix it but I don’t know the Kona LHe so I can’t help.
-
[Mitch Deck] “So, the hdcam does the down conversion?”
Yes it does and it is a lot better than FCP’s conversion and in real time. Go hardware for down conversion.
-
I do a simultaneous output to HDCam (via Decklink HD SDI) and use the HDCam SD SDI output to feed a digi beta which I crash record during the edit to tape on the HDCam. I like the HDW downconvert. It is much better than the FCP software version or the Decklink’s downconvert.
The digi beta is set to pick up the matching timecode from the HDCam so both masters are correct for broadcasters. I have heard good things about the Kona downconvert, but I can’t compare it to the HDCam machine. I prefer to do the dual recording as it means the digi is getting a downconvert directly from the HD SDI and not play back from tape which has compression.
-
[Bouke Vahl] “eer, what is unsafe about the original approach?”
There are three problems with your idea. Firstly the timecode needs to be transfered to the camera. This means a either cable from the laptop to the camera or a radio link. A cable is cumbersome and a radio link risky.
Secondly, as you pointed out, every take has common timecode. This is a poor practice.
Thirdly timecode should be synchronous to the video frame. Using a laptop to play a QT file means that there is no way to genlock the playback to make sure the camera is getting LTC that is frame synced. Again this is poor practice and may cause the camera timecode to glitch.
-
I would just make a QT of the music track with a big timecode display window. You can do this by dropping the music into a FCP sequence and putting a timecode window over a slug on the video track. Digital Heaven have a code display plugin (from memory) that gives a big scalable timecode window.
Use the QT file for playback and have the RED shoot the laptop screen just like a timecode slate. Don’t bother transfering LTC to the camera. Let it do its own code generating and just use the visual display as a sync reference. This is much safer than regen on an LTC signal which will not be frame synced to the camera.
Keep it simple.
-
Does the 3 way CC do the same thing? I presume you are referring to peak white information above 100% and not black levels.
-
You can do what you like for youtube. Proper audio post for broadcast is not recommended for those that “really hate” it.
It is just like saying “I really hate editing so can anyone give me tips on how to do it”.
-
If you do that and there is motion in the shot, then you will have a really obvious effect. Much better is if you just delete those two frames and ripple edit.
If there is motion there will be a one frame glitch, not a three frame glitch which is what your solution will create.
There are plugins that correct drop outs by taking previous fields or frames. I am not sure that they will be quicker than manually doing it. Digital Heaven and CHV have such drop out corrector plugins.