Mark Hatch
Forum Replies Created
-
Those are good ideas, guys. Thanks for your help.
Mark Hatch
Cosmic Pictures -
The actual raw RED files don’t become corrupt. We used to process those RED files, using REDCine, to ProRes Quicktime files. We would process them directly to the SAN. Those files are the ones that would randomly become corrupt after a day or two. Corrupt, meaning that we get the “bad public movie atom” error and are unable to edit with them. We are now on XSan 2.1.1. We don’t seem to have that problem anymore, but we also don’t use REDCine. We now use RED Rocket and RocketCineX.
I just had this one issue yesterday. So it appears that mostly, we’re much better off now.
Mark Hatch
Cosmic Pictures -
Ben,
Whatever came of this? We’ve had similar problems for a couple of years and we run FCP/CS4/XSAN2.X. I just had this issue come up from After Effects CS4 and now the Quicktime File is corrupt, as mentioned above. Funny thing is that this file was just a small quicktime, h264 file, 640×360 and I was just using it for reference. It worked fine for about 30 minutes, then all of the sudden it died. I like your test idea, but I may have some information that will be helpful for it. We’ve had this problem without ever importing footage into After Effects. We own two RED cameras and shoot lots of footage with them. We used to use RedCine to process the footage to ProRes. We’d then edit for a few days in final cut pro and randomly, some of the footage would start going corrupt. This happened a lot and was very frustrating. We found that if we processed the footage to a local drive and edited from there, that the footage never went corrupt. So, my only guess is that the problem lies with XSan. That may not be true, but it certainly checks out. But it may be the combination of XSan with certain applications. We started using the RED Rocket several months ago and I don’t think we’ve had that issue since then. But as I mentioned, I just had a similar issue with After Effects CS4, XSAN 2.(something) and a lowly quicktime, h264 file. Also, we don’t seem to recall ever having had this issue with XSan 1.
Anyone have any new findings on this?
Mark Hatch
Cosmic Pictures -
I’ve often been wrong on these things, but I’d like to throw in my two cents…
First, I did not know that ProRes(HQ) was only really necessary for 2K and 4K work. That’s interesting. Can anyone confirm that that is true? We do HD work, for broadcast, all of the time and have been using HQ for finishing. The difference between HQ and non-HQ is bit rate, right? So it seems to me that HQ can be helpful with HD footage that is complex and needs those extra bits.
Second, I have to agree with Kevin that ProRes is far superior to DVCProHD, in regard to graphics. Maybe that’s not important to some people. I have worked with both formats for a long time and my experience has been that graphics, especially graphics with alpha channels, look horrible in DVCPro HD. Not to mention that any red colors fall apart almost immediately. I’m guessing that this is due to the 8-bit vs 10-bit color space. If you drop the DVCPro HD footage into a ProRes timeline, or any other 10-bit timeline, and then add those same graphics, with alpha channels, the problem goes away.
Third, what is the data rate of DVCProHD versus ProRes versus ProRes(HQ)?
DVCPro HD: 6-14 MBps (Approximately)
ProRes: 5-18 MBps* (Approximately)
ProRes HQ: 8-27 MBps* (Approximately)
*This doesn’t include prores 60fps in 1080, since DVCPro HD doesn’t do that.
So I guess it depends what you are working on. ProRes over DVCPro HD seems like a no-brainer. Perhaps the HQ data rate is a deal-breaker for some, but the benefits are worth it for us.Lastly, straight from the Apple ProRes White Paper 2007… “For years now, Final Cut Pro editors have relied on HD formats such as DVCPRO-HD and HDV for native, real-time multistream editing. The effciency and image quality of these workflows are excellent for content that originates with and can be finished natively in these formats. But such formats were designed under significant camcorder engineer- ing constraints, so they limit the full quality that can be carried in an HD signal.”
That’s my experience. DVCPro HD is a very good format, but when it comes to graphics and full-raster, it’s a tough sell. I’m sure someone will let me know if I’m wrong. 🙂
Mark Hatch
Cosmic Pictures -
Has anyone at AJA weighed-in on this issue? Seems it’s been narrowed down to a problem with their codecs/software/hardware.
-
That is very interesting. I didn’t even know that the Dumpster program existed. I took raw DVCPRO HD footage and imported it into both FCP and AE CS3. I then exported that footage from AE, unaffected, in the DVCPRO HD codec. I noticed that gamma flag that AE adds and it read 2.2. I then imported that footage from AE into FCP and laid it over the original. There was an obvious shift.
I then changed the gamma in dumpster several times and reimported it into FCP and laid it over the original footage. I never got it to match up very well. At this point, though, I can’t remember if it is correct to apply any color management in AE. Can someone remind me what was determined for that? Do we interpret the footage differently than default in AE CS3?
Thanks.
-
I’m struggling with this and we use DVCPRO HD all of the time. In fact, consider this: The problem is even worse when going back to color. Have you tried that? When we take original DVCPRO HD footage and import it into Color, it works fine. When we take it into AE and render it out DVCPRO HD, then import it into Color, it is way blown out.
See if that happens to you. It doesn’t solve anything, it just gives more insight into what may be wrong.
-
I also would still love to see an answer…
-
Did anyone ever find an answer to this problem? Is FCP just doing things the wrong way?
-
Gary, I am trying to take 720p59.94 QT footage shot at 24p and run it through the FRC to get 23.98 once it removes the duplicate frames. I am losing the audio, however. Did I read your post right? That conversions to 23.98 should keep the audio?