David Burch
Forum Replies Created
-
BTW, I just checked and both our EX-3s are using firmware version 1.02_0078. The latest firmware update posted on Sony’s website requires at minimum ver. 1.05, so I know that both cameras have old firmware. I’m hoping updating is all it will take.
-
I am experiencing this exact same issue, this time with CS4 and Snow Leopard. Ironically, the buttons work fine when played on an XBox 360 or PS3, but standard DVD players are where the issue shows up. My main menu (which is a motion menu with a moving background) doesn’t show button highlights at all, and my chapter menus (no moving video) have terrible results; most of the highlight is not there, and what is looks awful. I have tried everything that was suggested in a previous post to no avail. I’m about to give up and go back to DVDSP because this project really needs to get done. Any suggestions before I do?
-
I’m having the exact same issue. Thought I’d add that the buttons actually work correctly on both an XBox 360 and PS3, but standard dvd players are where the issue shows up. This is very frustrating.
-
Oh yeah, I wasn’t using smoothcam either. I’m working with footage shot on a Sony EX-1 in the 720p60 HQ format, converted to ProRes 422 (standard). I have three camera sources I am editing together using multiclip, and my lower 3rd graphics are created in motion and rendered to ProRes 4444. As I said in my first post, all this works flawlessly on my older machine. It is only the newer 8-core that is having issues. I tried to keep the settings and workflow as consistent as possible on both machines.
-
I transferred my source files using an eSata drive to both Raids, so essentially I now have 3 copies of the same files. I don’t like having all my source footage on a single Raid-0, as that is asking for data loss.
-
Thanks Kevin. I haven’t tried repairing permissions yet, but I did transfer all my source files to the internal raid on the new machine. The program file I keep on a separate bus-powered Firewire 800 drive, so I can work on my project both at home and at work. Neither machine is set up on a network (other than a standard internet connection). I may call Apple and see if they have any suggestions; I was just hoping somebody on here had run into this in the past and could shed some light first 🙂
-
I seriously doubt that’s the issue, as both computers have the exact same raid setup.
Also, I did a little more troubleshooting since my first post. The problem only seems to show up when the scopes window is open. Again, this is odd as I always have scopes up with my older computer. Also, standard ProRes 422 multiclip tracks (not the 4444 codec and not HQ) are dropping occasionally when the scopes are up, though not as often. Once again, these play flawlessly on my older system. I find if very hard to believe that my new 8-core simply isn’t up to the task, when a nearly 3-year-old 4 core handles it perfectly well.
-
Upon further investigation of the log files, I compared one clip that had successfully completed with another that is still trying to “merge distributed quicktime segments”. I found that the problem file contained this error:
exception = error: FlattenMovieDataToDataRef, status=-2019
I searched the logfile of the clip that finished and did not find any reference to this exception whatsoever. If anybody is savvy in quicktime exceptions and what this could mean to the distributed compression process, this might be helpful information.
-
I should probably add that I am using a 2.66 Ghz quad core Xeon Mac Pro, running Leopard 10.5.8 and using the latest version of FCS 3.0. I have 12 GB of 667 MHz DDR2 FB-DIMM RAM. I am trying to cross-convert these files for editing, using the multiclip feature in FCP.
The reason I want to convert to ProRes 422 first is, again, so I can make use of multiple cores when compressing for DVD. Right now, a 2 hour XDCAM EX timeline takes over 5 hours to export from Final Cut Pro to ProRes 422, and over 15 hours if I go straight out of Final Cut Pro into Compressor (when downscaling to MPEG-2). Of course, distributed encoding does not work if Final Cut Pro is rendering for Compressor, so I wanted to output to ProRes 422 first (keeping all my chapter marks) and send the final clip to Compressor. I generally need to output a reference file anyway for use in Logic when creating the Dolby 5.1 surround mix, so this seemed like a reasonable workflow.
I figured that if I start with ProRes 422 to begin with, the export from Final Cut Pro should take a lot less time (theoretically). Traditionally, my reference file had been an XDCAM EX file, as it take far less time to export the native codec than it does to convert to ProRes 422 (which also puzzles me).
Anyway this is probably much more info than anybody needed to know, but I thought I’d share as much as possible so people could get a good idea of what I am trying to do here 🙂
-
I’m having the same issue, except I’m using a virtual quick cluster to take advantage of my quad core system. I’m trying to convert XDCAM EX 720p60 footage to ProRes 422 (also long clips, in excess of an hour and a half each). I am finding that it is taking longer to use distributed processing because of this than it would take to simply use the local machine with default settings. Does anybody have any work-arounds for this? I would very much like to take advantage of multiple cores, as I generally deal with large amounts of long HD clips, and encoding is by far the biggest bottleneck at this point. Thanks!
Dave