Re: FCP6 TemporalImageAPI - returning an image different from main input
Re: FCP6 TemporalImageAPI - returning an image different from main input
- Subject: Re: FCP6 TemporalImageAPI - returning an image different from main input
- From: Peter Litwinowicz <email@hidden>
- Date: Wed, 02 May 2007 10:49:24 -0700
- Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input
>
> Hi, Pete,
>
>> Input is input and has it¹s own settings and frame retrieval process. Same
>> for output.
>
> I think this makes sense in the simplest case:
>
> footage -> your filter -> output
>
> But, doesn't this break down as soon as you start adding more filters? Let's
> say you have this:
>
> footage (progressive) -> filter A -> filter B -> output (interlaced)
>
> In this case, it sounds like you would expect filter A to receive progressive
> input and produce interlaced output. But, that means that filter B gets
> interlaced input, which it doesn't expect.
> I think the only reasonable thing to do is to keep all inputs and outputs in
> the same format. The only question is whether you convert the input to output
> format at the beginning, or convert the result of all filters to the output
> format at the end. FCP takes the first approach.
>
> This breaks down with the temporalAPI because we go directly to the footage
> and give you the native format. There are valid reasons for this, but it does
> seem inconsistent.
>
> Am I missing something?
>
> Thanks,
> - Paul
Well, there you are. It does start breaking down. Which is why AE always
provides full frames, just time-sampled at the frame rate of fields, when
appropriate. AE converts EVERYTHING to frames and works from there, and then
60i footage gets processed as 60p... Then these issues go away (with the
problem that it is sometimes almost impossible to identify what was original
interlaed material). Inefficient for a realtime editing app, of course.
Actually, what I would like to do is Filter A to be able to take progressive
input and produce progressive output. Same with filter B. Then the
³output² sequence could resample to fields. The problem is really that
³output² should request 60 fps (suggested as fields, but filter B could
decide to pass progressive back) and let filter B ask for 60 fps, then
filter A gets asked for 60fps. Filter A sees that ³footage² is progressive.
It creates progressive output (at 60fps and not 30fps), which is passed to
filter B (as progressive) which is then passed to the output, which
resamples to fields. Any filter along the way can query what the final
output is and resample to interlaced to pass up the stream, if appropriate.
An idea: let the plugin query the input stream based on the suggested output
stream settings, but not hold tight to that suggestion. In one of my
examples of my previous email, I know that the media is 30p, but my output
is wanted at 60i. It would be great if I could return 60p and let the next
plugin (or FCP for that matter) sample to 60i or not, as needed. That
way, as a plugin (or FCP output sequence ) I could say that I want 60i,
but the plugin could say ³I would rather pass you 60p, because my input is
better handled that way.² Don¹t know if this scales or not. I guess we
should think some more on it.
Pete
_______________________________________________
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