site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Hi Kristian, - Paul On Jun 19, 2008, at 7:49 AM, Kristian Harms wrote: Hi List, Steve, others, Best regards, Kristian Harms, software developer, Vizrt Norway I'm seeing something weird in both FCP and FCE. I am working on a filter plugin that changes over time, so I'm getting the clip- relative frame number and the clip duration in order to calculate the fraction "done": timingAPI = [_apiManager apiForProtocol:@protocol(FxTimingAPI)]; effectTime = [timingAPI inputTimeForFilter:self fromTimelineTime:renderInfo.frame]; effectDuration = [timingAPI durationOfInputToFilter:self]; I also included a couple of test lines: testStart = [timingAPI startTimeForEffect:self]; testDuration = [timingAPI durationForEffect:self]; Everything behaves correctly in most cases, but I've run into one case where I get very unexpected numbers. Here's what I'm doing: 1. Launch FCE/FCP with a new project. 2. Drag a clip onto the timeline so it starts at about the 01:00:00;08 second mark. 3. Move the playhead so it's a few frames into the clip. 4. Click once on the clip so it's selected. 5. Locate my plugin in the list and drag it onto the clip. I have a breakpoint set in -renderOutput:withInput:withInfo: which gets hit at this time. I see: renderInfo.frame = 6 effectTime = 6 effectDuration = 300 testStart = 240 testDuration = 300 This is what I expect. I continue execution then switch back to FC. If I double-click on the clip, my plugin breakpoint gets hit once again, this time with the following values: renderInfo.frame = 1806 effectTime = 1806 effectDuration = 3901 testStart = 0 testDuration = 3091 Any ideas if I'm doing something wrong, if it's a FC bug or what? steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/kha%40vizrt.com This email sent to kha@vizrt.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... I'm unaware of any circumstances under which the TimingAPI is unreliable. Your best bet would be to file a detailed bug at bugreport.apple.com, so that I can see exactly what you're seeing. Could you also include your project settings? Under normal circumstances, we should be asking you to render at sequence size, not at whatever size the canvas window happens to be... I'm seeing something similar to what Steve is reporting, in the FxPlug generator that I'm working on. It also changes over time, based on the length of the effect, which therefore is of fairly high importance. In my -renderOutput:withInfo: method, I find that I cannot fully rely on the duration obtained from the timingAPI's - durationForEffect: method. In many cases it does give the correct result, e.g. 250 frames, but very often it also reports the duration as being exactly 3000 frames. This seems to happen in most cases when FCP is getting a frame for the Canvas preview area, i.e. for scrubbing, where the parameters for the rendering is often different from that of the actual rendering. We could try hacking around this based on the reduced dimensions of the requested image (but that's not very good, since some users will have the Canvas window large, yielding requests for full-size images when scrubbing) or based on the field order of the requested image being progressive (again not very good, as projects that actually -are- progressive would yield false positives). I've also tried using the -inPointOfTimelineForEffect: and - outPointOfTimelineForEffect: methods fot the timingAPI. The difference between these two doesn't seem to be fully reliable either, but in my testing today this number seems to be correct exactly in the cases where -durationForEffect: is not, and vice versa. Therefore this seems to be my best bet at the moment, although testing in Motion remains to be done. The reason I'm so troubled by inaccurate effect lengths even when scrubbing is that we store the effect length in an internal datastructure the first time we see it after it seems to have changed, and use this stored number to determine how a custom parameter is presented to the user. Perhaps it has been thought that incorrect effect lengths are innocuous in the scrubbing case, but clearly for us it's not. Taken together with Steve's observations from a few weeks ago, it does seem that the timingAPI is somewhat unreliable. Would anyone care to comment on my proposed workarounds or recommend another course of action? Steve Christensen skrev: This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com