Michael Gissing
Forum Replies Created
-
[Erik N] “If the only way to achieve my goal is to log and capture in HDV and render in prores then I will go that way.”
The transcoding is the same and it uses less drive space than going to ProRes on capture.
That said, there are some that don’t like editing in HDV. I am recapturing and onlining documentaries and I have not found issues working with the HDV in via firewire and ProRes render workflow.
-
As Dave said, you are doing the right thing by getting it right in CC. However, I have used that same workflow and found that after render, the broadcast safe is letting spikes of luma through which looked safe on the scopes before render. That was true for me using uncompressed so it is not a compressed codec issue.
The RGB limiter so far has proven to be reliably clipping after render. That said, I am ordering my new Macpro soon so that I can get into Color where proper clipping can be trusted.
-
I used to capture from a Canon H1 via HD SDI uncompressed using firewire control. The camera had to be set to downconvert to DV via firewire and then machine control worked in a custom setup.
That said, transcoding to DVCPro100HD via component inputs is not a good workflow compared to straight ingest as HDV and setting render to ProRes. You don’t want the double hit of component conversion and transcoding to Pro100. Messy workflow and technically more of a drop than HDV in and ProRes render.
I am happily doing that with a 2.5 G5. Personally, I can’t see any point in considering DVCPro 100HD unless it is also your camera format. I don’t see a role for it in HDV particularly since ProRes.
-
Check the motion tab to make sure the text is positioned on whole integers, ie; not with decimal points.
Obviously you are rendering the shots with supers and looking on an external monitor.
-
They turned up without spares?? That’s stupid optimism, not pro service.
-
[Steven Gonzales] “Considering this technical requirement, it was really an amazing engineering feat to add color, and only shift the scan frequency by 1 part in 1000.”
When coloUr was added to PAL they didn’t have to shift frequency. There was a slight net like pattern on the image on old b&w teles. Perhaps they should have shifted the FM subcarrier frequency instead of the frame rate. I always understood the solution was far from good engineering actually. My father was a microwave developer and made links for broadcast and he would always say it was lazy engineering to shift.
I have often wondered why the problem in NTSC wasn’t fixed when timecode was being developed.
-
[Dave LaRonde] “Until NTSC video abandons 29.97 and goes with 30 fps (fat chance of that happening), it’s the best we’ve got.”
Every day I bless the PAL format that I work with. When I have to work in NTSC rates I think back to that fateful day when a tech thought of the idea of shifting the frame rate off 30 rather than fix the problem with color and 60 Hz. I wonder if anyone knows his name and if his offspring are still living.
-
As I just said in another post about the broadcast limiter, I prefer the RGB limiter which actually stays legal after render. Don’t know why the broadcast safe doesn’t but it is best avoided in critical QC environments.
-
My 2 cents. You are better of with a Kona or Decklink interface to capture beta SP. That will give you proper machine control and any timecode rate you want, plus a proper monitor output.
-
FCP Vers5.?? I suggest an upgrade if you want to have less grief with HDV.