More strange QT behavior...

[Kelly M. Pieklo]

Had a curious situation brought to my attention today:

Session start at 00:00:00:00, OMF (from FCP) imported, starts at 01:00:00:00. Imported 23.98 QT (also from FCP) and ref audio to the timeline, spotted to 01:00:00:00. Upon examination, QT and ref audio are spotted 31.5 subframes later than the FFOA from the OMF - OMF is spot on, QT and ref audio around 1/4 frame off.

Furthermore, I can slip/grid/spot the ref audio to OMF start, but QT will only move in relative 1 frame increments - ie., if I nudge the QT 1 frame early, it's actually ending up at 59:59:23 + 31.5 subframes, and I cannot get the QT to line up with a beginning frame edge. Slip mode doesn't help the situation.

I've found the workaround to be starting the session at 01:00:00:00, and importing OMF, then importing the QT/ref audio to the session start - everything lines up perfectly. But why wouldn't I be able to slip the FF of the QT to a frame boundary in the PT timeline?

Clearly, FCP's handling of 23.976 OMF exports is flawed, or so I have read (thanks Minister), but is there a problem with the exports of the QTs? NTSC, DVCPro codec.

Danka.

[Kelly M. Pieklo]

So I've been able to recreate this with a completely different 23.976 OMF 2.0 and QT, both coming from FCP.

I can clarify a bit here too, in case anyone is interested:

I started out by creating a 23.976 session and set the session start TC at 00:00:00:00. I then imported the 23.976 OMF, which starts at 01:00:00:00, into the already created session. NOTE: Digitranslator is reading the OMF as a 24fps session. Instead of the FFOA being at 01:00:00:00, it instead rests at 59:56:09. When session TC is changed to 24, FFOA changes to 01:00:00:00, which makes sense.

So yes, the 23.976 OMFs coming from FCP are either being coded wrong on the export, or decoded wrongly on the import. Where is the problem, and why is it happening?

I have also found that, as stated above, if I then import a 23.976 QT and spot it directly to 01:00:00:00, it actually rests 31.5 subframes later than the FFOA from the OMF, and I cannot line it up to the frame edge, even in slip mode.

One workaround I've found, and it's usually the way I work, is to directly open the OMF instead of importing the OMF data into a previously created session. The OMF still imports as a 24 session, but changing the TC rate to the correct rate of 23.976 at that point keeps the OMF audio butted up to 01:00:00:00. Additionally, importing the QT to this OMF-created session works flawlessly, with the FFOV from the QT lining up to the 1st frame edge at 01:00:00:00.

Creating a 23.976 session and importing the 23.976 QT into the session sans OMF works fine also - I can spot to 01:00:00:00 and be frame edge accurate.

So...a few questions, perhaps for Tech:

1. Is there any info on the FCP to PT OMF issue at the 23.976 frame rate?
2. Why would a QT not be able to snap to a frame edge in the video track? I've never had this problem before. Anybody else?
3. I'm counting 28 colons in this post. Is that a record?

Interested? I'll be sending an 23.976 OMF back to FCP and will post the results.

: That's 29.

[admix]

2. Why would a QT not be able to snap to a frame edge in the video track? I've never had this problem before. Anybody else?

I have also seen QTs that wouldn't line up to a frame edge. I can't recall frame rates or session specifics, but i've noticed it several times. Being overly anal about that stuff, it's generally caused me to import the offender into FCP on another machine, render it out, and PLAY it into my PT session through MOJO.

I've not been happy with PT/MOJO's ability to play out QT's. I've experimented with pretty much every codec, with some showing improvement (notably DV25), but to my eye, it still looks "stuttery". I may need to consider the "second machine for video playback" option, but I do love everything living together in one box. Conundrum.

Overall not a lot of help, sorry, but you're not alone.

[paranerd]

Bringing this one back from the past!

I've been tolerating the quarter to third frame off issue from DV25s for a while, but I had time to look into it and I couldn't find a reason for it. It's a little irritating. Has anyone figured out why DV25 Quicktimes movs won't snap to frame? From my experience, h264s will always snap correctly.

[rhumphries]

Is the frame rate indicator on the Quicktime track in red? I think I have only seen the video offset from the frame edge when the Quicktime is not being recognized as the same frame rate as the session. i.e. the Quicktime is at 30 and the session is at 29.97.

-Richard

[paranerd]

Yes, it is in red saying 30fps while my session is in 29.97DF. However, Quicktime Player says the DV25 is in 29.97.

This issue will even happen when I convert an H264 to DV25 in Quicktime Player 7 with my frame rate export setting at "current." The H264 will always snap correctly in Pro Tools, while the exported DV25 won't.

[rhumphries]

Yes. I've seen that too. I couldn't get protools to recognize some Quicktimes as 29.97 when I used Quicktime Pro. When I used mpegstremclip to convert the movie to 29.97, PT would recognize it as 29.97. I don't know why.

You could also click the 'video pull down' button in the session setup window. that will make it playback at 29.97 and it will sit on the frame boundaries again.

-R

[paranerd]

Originally Posted by rhumphries

Yes. I've seen that too. I couldn't get protools to recognize some Quicktimes as 29.97 when I used Quicktime Pro. When I used mpegstremclip to convert the movie to 29.97, PT would recognize it as 29.97. I don't know why.

You could also click the 'video pull down' button in the session setup window. that will make it playback at 29.97 and it will sit on the frame boundaries again.

-R

I'll try converting with mpegsteamclip next time to see if that solves the issue. Thanks for the tip!