dropped and repeated video frames in Pro Tools but not QuickTime?!?

[hociman]

Hello,

I have a very perplexing problem that I wanted to share, in hopes that maybe someone has encountered this and can explain what is (not) going on.

I received a .mov file (H.264) with a window burn. The timecode is drop-frame. The first frame of video is 00:59:40:00. I converted this file to the DV codec. When I place the file on the Pro Tools timeline, this is what happens.

At 00:59:40:10 on the Pro Tools timeline, the QuickTime movie window burn is 00:59:40:09.

At 00:59:41:20 on the Pro Tools timeline, the QuickTime movie window
burn again matches the timeline timecode address.

At 00:59:42:00 on the Pro Tools timeline, the QuickTime movie window
burn is 00:59:41:29.

At 00:59:43:10 on the Pro Tools timeline, the QuickTime movie window
burn again matches the timeline timecode address.

At 00:59:43:20 on the Pro Tools timeline, the QuickTime movie window
burn is 00:59:43:19.

At 00:59:45:00 on the Pro Tools timeline, the QuickTime movie window
burn again matches the timeline timecode address.

The only conclusion I can draw is that this is a 10-40-10-40 etc. cadence.

The same thing happens if I use the original H.264 file. It is also observed if I am looking at the Mojo SDI output, looking at the QuickTime movie window (Apple+9), or if I set the video track to frames and set its size to fit to window and zoom in far enough to see each frame on the video track.

The more perplexing thing is that if I view either the H.264 file or the DV file with the QuickTime Player, and nudge through frame-by-frame, this phenomenon does not occur! The same is true if I spot the file in Final Cut Pro and nudge through frame-by-frame.

I have tried this with Pro Tools v7.4cs8 and QuickTime versions 7.3.1, 7.4.5, and 7.5.5. I get the same results every time. I also get these results with Pro Tools v7.4.2cs2 and QuickTime v7.3.1. So it does not not appear to be an OS issue.

If anyone has insight as to what is (not) going on here, I would appreciate it.

Thanks for reading!

[smurfyou]

Was it spotted right to the frame line? Not that it would matter in this case. I've never noticed this. Will try if I get a chance.

[jahtao]

Last week, on one project, Pro Tools was only showing me every other frame.

Turns out my video disk was very full, I just had to empty the trash. Problem sorted.

[hociman]

Originally Posted by smurfyou

Was it spotted right to the frame line?

Yes.

[jozzafunk]

We were getting a problem using QT Pro to compress from DV25 ( I think ) to .h264 for FTP. Im not sure of the mechanics but it was resulting in an extra frame being added. The solution to this was to use FCP compressor which compressed the frame accurately. I'm not sure if this is related to your problem.

This problem reminds me of a known issue with compressed files coming from FCP into protools - I'm sorry I can't remember the solution but I think if you search a site like FCP for Indies / SF FCP user forum it has the answers.

[hociman]

Here's an interesting update. We have a Final Cut Studio setup, so I asked an assistant to dump the picture to a Digi Beta, and then we would load that back into Pro Tools via Mojo SDI capture. Well, it turns out that the same thing I was observing on playback of a converted file in Pro Tools was being printed to tape! Only it was even more funky than the file conversion. Very strange. We have asked for a digi beta from the source, so hopefully this problem will be resolved by getting that tape.

Thanks for the responses. I'll post back when I know what happens with the tape we receive.

[soundboy]

I have seen this problem! My solution was to have them re-output the pic. They were DV25 QTs generated by an Avid(I don't know what model).

[jacobfarron]

I have the exact same problem with 4 of 6 reels for a mow i'm working on at the moment. i'm losing a half frame or so towards the end of the project. but the omf still lines up on the 2 pop. only the burn in the QT window is off.

[hociman]

Originally Posted by soundboy

I have seen this problem! My solution was to have them re-output the pic. They were DV25 QTs generated by an Avid(I don't know what model).

I have no idea of knowing what their NLE is, and I might have to go through too many people to find out. The tape they sent, while sufficient for the session, had no window burn. Oh well, the more important thing is that the session went off without a hitch.

[soundboy]

Mine had a window burn, and I could actually find where it skipped frames. I pointed it out to the post supe, and said "I cant verify sinc until I see the final output."
C.Y.A.

[nlc201]

Dumb question, just had to ask as it's happened to me before:

You've verified that the actual playback frame rate in PT (shown in fps to the left on the video track under the name box) and the timeline frame rate settings in the session setup window are 29.97? If the 29.97 reading on the video track itself is in red then you have a problem and PT does not believe the video to be the same frame rate as the session.


I've had similar issues in PT when a video that is "supposed" to be at 29.97 is inadvertently delivered / re-exported at 30 fps. Even with the PT timeline at 29.97, the frame boundaries of the video are placed at timing locations relative to what PT believes the video is supposed to be playing back at. This can lead to some very kooky readings looking at the burn-in timecode on screen.

[smurfyou]

I haven't been able to recreate the problem.

Originally Posted by nlc201

I've had similar issues in PT when a video that is "supposed" to be at 29.97 is inadvertently delivered / re-exported at 30 fps. Even with the PT timeline at 29.97, the frame boundaries of the video are placed at timing locations relative to what PT believes the video is supposed to be playing back at. This can lead to some very kooky readings looking at the burn-in timecode on screen.

Thats a good point. I've been delivered video that was 30fps 640x480. I was told it was "TV Quality".....

[soundboy]

I always check the frame rate on import, check with the editor, and if I have further questions, check it in QT Pro. I'm a stickler about sinc. And if it's coming from FCP, I'm doubly careful.

[hociman]

Both QuickTime and Pro Tools claimed that the video was 29.97 FPS, and neither one threw up a red flag in this regard.

[Jfriah]

JUST went through this yesterday/today on a project.
My edit suite showed the same symptoms when I had to switch a 29.97df session to the true 23.976 picture (picture was late coming in to us and I was working to a 29.97 DVD rip--best I could do at the time because of tight timelines---imagine that?).

Had to go change all my scene splits/automation to now match 23.976 when I imported the picture and changed the session frame rate. Then I was wondering why I'd go frame by frame to find the cuts and went 00 01 02 02 03 04 05 06 06 07 etc...

Took the session to two other rooms to check with other editors; they were not having problems. One figured it was a result of using the improper version of QuickTime for the OS. But we switched out all that and it still happened.

Couldn't figure it out, but it WAS an H.264 video-----which we have had nothing but problems with / sluggggggggish Pro Tools performance. We pretty much run exclusively in DV or MJpeg-A now with great performance. That solved my problem and got me back to frame-by-frame increments and not having to wait (seriously) a second or more after every mouse click for the program to respond.

H.264 LOOKS great, but...

[Jfriah]

And, yes, I am very anal about sync (even though, in the end...everything airs in HD now and...well...we all know what the end result is there for the home viewer...), and often do the "check the first minute" time code burn, check the QuickTime information itself, etc.

If we don't...who will?

[minister]

Originally Posted by Jfriah

Couldn't figure it out, but it WAS an H.264 video-----which we have had nothing but problems with / sluggggggggish Pro Tools performance. We pretty much run exclusively in DV or MJpeg-A now with great performance. That solved my problem and got me back to frame-by-frame increments and not having to wait (seriously) a second or more after every mouse click for the program to respond.

H.264 LOOKS great, but...

What you are experiencing here is the difference between an Intra-Frame Codec and an Inter-Frame one. H264 is an Inter-Frame codec. In other words, it relies on preceding and forthcoming frames in order to present a "frame". It is effiecient space-wise because creates a "keyframe" and then it "looks" for differences (changes from frame to frame) and encodes those to a frame and then greatly compresses the similarities. Upon playback, the system must decode the keyframe and all the successive frames referring to it in order to present a "frame". Sometimes you can get around this by "keyframing" every frame.....

MJPEG and DV are Intra-Frame codecs where each frame is encoded as it's own still image and there is no extra interpolation demand upon the cpu in playback. It just presents one image after the other. Less compression, easier playback and genlockable.

[Jfriah]

thumbsup

THANKS for the explanation, Tom! That's great info.

[Marbarbaar]

Originally Posted by Jfriah

thumbsup

THANKS for the explanation, Tom! That's great info.

Great info indeed.

Maybe H264 is my problem too. Sometimes the QT video screen goes black and never returns. Sometimes it even freezes everything but playback (which plays fine). Until the last event is played, after which everything responds again.

odd......


So, when I convert this h264 QT to another format like avi pal or another QT codec, will all frames be 1:1 to the original?