Re: filter plugin getting unexpected frame numbers
Re: filter plugin getting unexpected frame numbers
- Subject: Re: filter plugin getting unexpected frame numbers
- From: Kristian Harms <email@hidden>
- Date: Thu, 19 Jun 2008 13:49:37 +0200
Hi List, Steve, others,
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?
Best regards,
Kristian Harms,
software developer,
Vizrt Norway
Steve Christensen skrev:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden