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:47:59 -0700
- Thread-topic: FCP6 TemporalImageAPI - returning an image different from main input
Title: Re: 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 “output” 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