Confirmed - 720p25 support in FCP 5.1.2

Cees Mutsaers said:
When I asked why they didn't change it he said that apple was QT based.
Click to expand...
This is such a silly response. We KNOW FCP is QT based. That doesn't stop it working with AVIs or JPGs or TIFFs or TGAs or WAVs or any other of a host of different file formats, none of which are Quicktime. MXF is just another file wrapper.

We're not asking them to rewrite the entire application, fer cryin' out loud. Just add one more file type to the list, that's all.
 
This is ridiculous. No 720p 50 support? Do they have a contract with imagine products?

Seriously, if others can do it, why can't Apple do it on their OWN application? Its just insane.
 
Anders Holck said:
You really think 720p50 is the most usefull format? 90% of what I do on it is either 1080/25p or 720/25pn. The rest is 720/25pn at overcrank or undercrank.
Click to expand...

It's not the most useful format full stop but if you want sound + 50 fps in the same file its the only option right ?
Saying that I would probably use 720/25pn at overcrank or undercrank the most also.
-matt
 
Steve Shovlar said:
http://ibc.mikkowilson.com/photos/Day3Gallery/pages/IMG_3929.htm

You can see from this screen grab that there is no 720P50 support.
Click to expand...

Those are easy setups, which also need support for the timebase for editing.
If you look closely you can see that there is no DVCPRO HD 1080/25p either, and I use that every day in FCP 5.1.1. But they chose to include both 1080/60i, 1080/30p and 1080/24Pa...

What I'm trying to say is that 720/50p footage might be possible to import, but cannot be edited in an 50 fps sequence as there is no 50fps framerate in the sequence settings dialog.
 
Last edited:
eliotbaring said:
With the lack of 720 50p why would you want to shoot 720 over 1080p?
Click to expand...

Vari frame rates under/overcranking is the main reason for using 720p as their is no vari frame rates in 1080.
-matt
 
Barry_Green said:
This is such a silly response. We KNOW FCP is QT based. That doesn't stop it working with AVIs or JPGs or TIFFs or TGAs or WAVs or any other of a host of different file formats, none of which are Quicktime. MXF is just another file wrapper.
Click to expand...

Actually, when you use something like Filp4Mac to import WMV files, it's rewrapping it into QT. JPEG, TIFF, WAV, all are technically re-wrapped in QT wrappers. It's nothing new.

The problem is the time it takes to rewrap MXF files, that's all, from my understanding. If there is more to the issue, I'm unaware of it.

And I have a theory.

I got a glimps of Lepord and some technical explination of things at Apple in NYC a few weeks ago. Lepord will use a totally new graphics engine. My guess is that Apple is waiting to impliment native MXF (which, like AVI and everythign else, would be a seemless and "blink of an eye" rewrap like it does for WMV) with the new graphics engine.

The ONLY porblem with wrapping it in a QT wrapper is the time it takes. From what I understand, that's the ONLY QT issue. Right?

Barry, if it re-wrapped seemlessly and quickly like it does WMV with the Filp4Mac product, would that solve the problem? Casue all we're talking about is time, right? Or am I missing something?

And don't be suprised if Telestream or someone like them comes out with a product like Filp4Mac, but for MXF. Would't surprise me a bit.

But, this is all speculation.
 
BenB said:
Barry, if it re-wrapped seemlessly and quickly like it does WMV with the Filp4Mac product, would that solve the problem? Casue all we're talking about is time, right? Or am I missing something?
Click to expand...
Mostly. I was thinking about this last night, that they could maybe even make an on-the-fly interpreter, an intermediate class object that receives QT commands from FCP, translates them into how to seek into the MXF file, and returns the data in a QT-compatible mode for FCP. That's all that really needs to be done.

Well, that plus supporting things like chaining the pieces of split clips together, etc.
 
Barry_Green said:
Mostly. I was thinking about this last night, that they could maybe even make an on-the-fly interpreter, an intermediate class object that receives QT commands from FCP, translates them into how to seek into the MXF file, and returns the data in a QT-compatible mode for FCP. That's all that really needs to be done.
Click to expand...

The only catch is that this would certainly require more processor overhead. Either they support MXF directly or do what they're planning on doing (which is probably the next best thing to direct support).

For me the only issue is the need to duplicate media which is just a waste of drive space.
 
You must log in or register to reply here.
Back
Top