View Full Version : HD is twitching... twitching... twitching...


George Strother
October 11th, 2006, 04:14 PM
Frames are sticking/stuttering/skipping on playback. 720p30, HDV or Apple Intermediate codec and DV 60i anamorphic. DV anamorphic scenes captured from HD100 or PD150 all have drop/skip frames. Skips occur in FCP or QT playback. Skips are embeded in QT exports too.

DV files shot with HD100 or PD150, captured with either play fine.

For test footage I shot traffic on the freeway. The skips show as all of the vehicles jumping forward about 1 frame. Skip/stutter/stuck frames happen repeatedly in about the same location on clips, but not the same frame. Frame by frame advancing shows all frames are there, none missing. Each vehicle moves an equal distance as each frame is advanced.

I have tested files on a 185 MBps 1.8TB RAID and a 200GB SATA drive, both capture and playback.

"Report drop frames on playback" is active and does not report on these frames. Problem does not occur on D1 video or standard 4:3 DV shot or captured with either camera.

I have tried every tip I have found on the web and a few I made up -
Render audio, render all, insert slug on V1 and A1/2, delete viewer, 50% canvas, close all other timelines, close all other FCP windows, close all other apps, delete all audio, delete empty audio tracks, delete empty video tracks.

Anyone found the real cause of this problem?

System setup:
OSX 10.4.8, Final Cut 5.1.2, QT 7.1.3
PowerMac G5 DP 2.0, 4 GB ram, 4 matched 1GB sticks
ATI Radeon X800 XT, 256 MB ram
160 & 200 GB internal SATA drives
AJA Kona LS capture card
ATTO UL3D, latest drivers and firmware
Huge Media Vault DualMax 1.8 TB RAID
Dell 30, Gateway 2185W dual monitors or 2 Phillips 21 CRTs

Nate Weaver
October 11th, 2006, 04:36 PM
Sounds like errors in the stream that cause behavior problems in some stiuations, but not in others. In other words, partially corrupt data from tape.

I'd clean the heads and stick to one type of tape for the time being.

William Hohauser
October 11th, 2006, 04:49 PM
Try DVHSCap and MPEGStramclip or HDVxDV. See if the m2t streams are captured that way also.

George Strother
October 11th, 2006, 06:25 PM
Sounds like errors in the stream that cause behavior problems in some stiuations, but not in others. In other words, partially corrupt data from tape.

I'd clean the heads and stick to one type of tape for the time being.

First tape into the cam was a head cleaner, then it has pulled 4 tapes, all the same. Something in my G5 setup seems more likely. I'd say maybe firewire output, but DV works fine on firewire from this cam.

Component playback of the same scenes to the Gateway 2185W looks smooth.

I've also tried three different firewire cables, two brands, no change.

I've now noticed these skip/jerk things in the footage from the demo camera I tried, also. Those clips came from the demo cam on Sony HD tape. Not very noticable in some shots, more so in others. So I tried the traffic shots to see if it was repeatable. It's very repeatable. I've seen them in FCP 5.0.4, 5.1 and 5.1.2

George Strother
October 11th, 2006, 07:07 PM
Try DVHSCap and MPEGStramclip or HDVxDV. See if the m2t streams are captured that way also.

Couldn't locate DVHSCap on the Apple Developer site, but I installed FireWireSDK22 and used VirtualDVHS, apparently an update version. I hope.

In MPEGStreamclip, the M2T files stick and skip like the HDV or Apple Intermediate versions, but more often. Also, not always on the same frame on each pass, just in the same areas.

Nate Weaver
October 11th, 2006, 07:27 PM
Ok, so now we know one of two things. Either:

1-The stream is corrupt

or

2-Something is corrupting the stream as it comes into the computer

FYI, VLC uses it's own MPEG2 decompressor, not the FCP/Quicktime MPEG2 libraries. Given the history myself and others have had with the camera, my bet is on #1.

George Strother
October 12th, 2006, 10:10 AM
Ok, so now we know one of two things. Either:

1-The stream is corrupt

or

2-Something is corrupting the stream as it comes into the computer

FYI, VLC uses it's own MPEG2 decompressor, not the FCP/Quicktime MPEG2 libraries. Given the history myself and others have had with the camera, my bet is on #1.

Failed to mention earlier, I cleaned the heads and recaptured the material twice yesterday. And the newest test were shot after yesterdays head cleanings. It didn't make any change.

I pulled up some test footage from an HVX200, m2t files form the P2 card stored on a firewire drive. Those twitch too and I now realize they did on the factory graphics card and Phillips 21" crts. At the time I attributed the playback glitch to the old, slow graphics card.

I'm also seeing the same problem with DV files I checked today.

Currently running TechTool Pro 4 on all of my system. When the G5 is available again, I'll test some older DV from the firewire archives.

Firewire problem? Other hardware problem? Voodoo curse?

Nate Weaver
October 12th, 2006, 11:18 AM
Yeah, I'm starting to think you have a PCI bus problem now maybe.

The next real troubleshooting step would be to digitize your footage somewhere else and see if it happens on a second computer...I'm guessing it won't.

Nathan Apffel
October 18th, 2006, 06:47 PM
Just tested footage from my JVC and George's, stuttering comes up on my new intel based G5 aswell. We went to both tape, and exertnal DTE drive.... We tested the footage on Dual 3.0 intel G-5 at the apple store aswell! Looks like a disease could be spreading or is it spread already? Could be quicktime itself!

Nathan Apffel
October 18th, 2006, 06:53 PM
/Users/nateapffel/Desktop/Untitled Project 1-Sequence 4-MPEG-4 300Kbps.mp4




Here is a test clip that show the problem, look at the white truck as it is about to leave the fraaammmmeee....stutter