Jeremiah Black
Forum Replies Created
-
No, I didn’t. Audio output is still wonky, and the only way 720p 24 footage plays back is if my decklink settings are set up to play out 1080. Then at least it doesn’t crash. But audio is still scratchy and unlistenable at times. I had to go back to FCP 5.1. And I’m keeping my FCP disks in the desk drawer until it’s resolved in a future update.
-
I just updated to 6.3 drivers after I upgraded to FCP 6, and now my entire FCP system crashes immediately upon opening. The only way to get FCP 6 to work for me is to remove the blackmagic codec from my quicktime folder. Blackmagic now crashes FCP at worst, at best it gives a strobed output that zooms in and out of the picture right before freezing up for eternity.
Looks like the 6.3 drivers were crappy. Good for people with new Intel Pro Macs. Bad for the rest of us. Anyway, I can’t do a lick of work in FCP 6 anymore. Only solution is to re-install FCP 5 or but an intel mac. No support for the rest of us, maybe.
-
“You’re upset? Calling me a liar, say that I’m spreading untruths, putting words in my mouth like “my way is the best way” and you’re upset?”
Actually, I never called anyone a “liar”. I said that the position that there is no loss to recompression, and that that “no loss” can be, and allegedly has been, verified through scopes is a lie. Perhaps I should’ve chosen better words and said “is false” instead of “is a lie”. I’m am sorry for the careless word, as it conveyed a nastiness that I didn’t intend. However, and I mean nothing against your personal character and talents, if you are going to publicly contradict the facts and post incorrect reasoning, then, I’m sorry, this is spreading misinformation. I obviously assume you have ZERO motive for doing so, other than that you sincerly believe you are correct. But, I’m sorry, you are not. The uncompressed workflow is VERY valid, and produces demonstrably verifiable results when the situation arises.
And your attitude is far from angelic. You have repeadly characterized any uncompressed workflow as a waste of time and useless, refusing to acknowledge any dissent. When it was shown that there is, in fact, a use for it, you continued to push your methodology, and push it with arrogance, I might add. You hinted that I was speaking without any experince and called my personal credentials into question. You refused to concede the mathematical truth that recompression into a lossy codec will ALWAYS result in further loss of original data, and you still have yet to concede the situational validity of an uncompressed workflow- despite being contracdicted by (at present) all four other people in this thread.
“Unbelievable. And this is truly the last word I have to say on this subject.”
Yes, I’d say it’s all quite “unbelievable”, indeed. However, I again would like to close with a personal apology for reacting to what I perceived as an arrogant tone in your early writing. I have made many friends on the CC boards over the years, and I am sorry that we got off on a bad foot, and for the part that I played in it.
sincerely,
– jeremiah black, NY, NY
-
“I can tell you that can handle dvcprohd in the manner that walter is suggesting without issue more than 90% of the time- I have the scopes and I can prove it, I can also show you everyplace on a waveform that it will fail. I am not using my eyes, I am using real scopes.
“I did the testing with both of these workflows and see both sides, part of the issue is the difference in the tool set and type of work. I have delivered content both ways- I have only had to change once do to the type of material being posted.”
I apologize to everyone for allowing myself to get so upset over this matter. I was upset and I apologize.
I simply wanted to hear what Gary wrote, and what I endeavored to convey many times which is that (1) there is a difference (2) most of the time it doesn’t matter (3) but sometimes it does, in fact, matter sometimes, and might matter a great deal. (4) compression always means data loss, whether discernable to the eye or not, and scopes will prove it. (5) since it will matter sometimes, it’s a decent habit to just do it uncompressed all the time, unless your client has made it known that they don’t care or they won’t pay for it.
-
“Plan on about 80 mgs a second for the 720p23.98 10bit. so you are there, just BARELY.”
As a test I imported some regular ol DVCPROHD footage into AE and rendered it out at 10 bit uncompressed. Those renders were around 60, so that’s where I got that number. Actually, when I imported the clip into FCP, FCP said the data rate was 56 mb/sec. Do you get 80? Maybe I’m messing something up.
Anyway, my RAID is currently full, but I have two empty SATA drives lying around and a couple a spare slots in a box, so I figured I’d stripe em together for a speed of about 105-110 MB/sec. I just gotta capture like 15 minues, so I figured it’s be doable. Cutting it close though!
Also, the plan was to capture at 8 bit, but render a 10 bit out of after effects- post color grading and compositing in a 16 bit space.
Could you briefly explain any benfits to a 10 bit capture? I assumed 8 bit would be fine.
-
“I was speaking all day yesterday at NAB East in NYC — sorry for the delay.”
Cool. Thanks for getting around to it.
“I would select everything in your final project time line, go to MM and set the project settings to 720p23.98 Uncompressed 10bit -take every thing offline and start the recapture. The BMD card should be able to the project fine.”
Yeah, that’s what I figured. The latest BM drivers even label the preset “Varicam”. I was just concerned that the flagged frames were going to be dropped when going over SDI and avoiding the DVCPROHD codec.
“everyone I know is having issues with 10bit content when using QT 7.1.3 ”
Ouch. Can you elaborate on this?
-
“Decklink 5.7 includes Varicam support with Uncompressed 8bit and MJPEG. ”
I installed the 5.7 drivers and found that they ruined the realtime dvcprohd downconvert. Was all studdery and jumpy. For the online I’ll have an HD monitor, but for the next week I’m using an SD monitor and relying on BM’s downconvert. And like I said, the ugrade the 5.7.2 drivers killed it.
Had to reinstall 5.6.2 drivers. Downconvert back to normal now. But I noticed that the “varicam” setings are all the same in the easy setups in the 5.6.2 as in 5.7.2. So it should still work, yes?
Don’t know why it didn’t work. Maybe cause I’m still in fcp 5.0.4 and not 5.1?
-
One more question:
If I have slo mo that’s 59.94, how do I capture that uncompressed 8 bit SDI? I assume there’s no way to slow it it’s 23.98 upon capture, is there?
thanks,
– JB
-
“The Varicam 720 23.98 preset will produce 8bit Uncompressed media @ 23.98fps. ”
Awesome, thanks. Just wanted to be sure I chose the right one so that the flagged frames were removed.
“Depending on whether your camera was set to 59.94hz or 60hz will depend whether it will capture correctly. ”
I believe it was shot at 59.94. Is this right?
“If unsure – perform a quick test using the 720 59.94hz and 60hz and see which format is captured. ”
please explain that agian. how do I do the test?
“Decklink 5.7 includes Varicam support with Uncompressed 8bit and MJPEG.”
OKay, I’ll install 5.7.2 right now! thanks.
-
“Playing back realtime means that you are rendering but rendering fast enough that each frame is “calculated” in time to playback in the time required (eg 1/24 th of a second or 1/30th of a second etc) so in that case the 8 bit vs 10 bit should not make any difference, because you are not recompressing to DVCPro HD. You are decompressing the file, applying the effect to the decompressed data -which is no uncomprssed – and passing that data out through the board. As long as the board and the effect are able to process at a bit depth higher than 8 bit you will get an output that is higher than 8 bit. Once you need to render to a preview file or output to a file then you are recompressing the DVCProHD, which is a lossy 8 bit codec. This is the reason you may see color shifts between realtime and non-realtime segments in a timeline and also why there is a setting in the preferences to render realtime segments. This is similar to playing back a file and viewing on your HD (CRT) monitor, looks good. If the playback is realtime then your monitor is showing you decompressed footage. Now lay that back to tape in a lossy format, DVCProHD, does not look as good. Because you are introducting another compression pass. ”
VERY interesting. Thanks for that! I guess I should’ve figured that because when you apply a filter 3 things happen, if I’m not mistaken. (1) the file is decompressed (2) the filter is applied, (3) the file is recompressed to whatever codec your timeline is set at. So, in realtime, the footage (1) is decompressed, (2) has the filter applied, but is never RECOMPRESSED because there’s no need if the computer can keep up with processing the filter’s calculations. Fascinating! Of course, I guess the file will be recompressed if you export a quicktime movie in the native codec.
By the way, I render out 10 bit uncompressed out of AE, because I work in a 16bit space there, and rendering out to 8 bit, doesn’t accurately preserve the work. Kind like you said, it looks good, but the render looks different.
“Both workflows make sense to me and I have done both depending on what my final needs were. My preference is to create masters in uncompressed especially if there are lots of graphics involved.”
yup, me, too. I also always go uncompressed in I’m doing heavy color grading “film look” type work. But it doesn’t matter for some jobs.