[Mark Curry]

This doesn’t make sense to me. I know that browsers, players, etc interpret video differently (i.e. you cannot control these factors), but this is something else.

A low data rate, simple, spatially compressed QuickTime file should play back any current, out-of-the-box or well-maintaned Mac fine (with the usual caveats: no other applications running, standard QuickTime codec, etc.). In other words, if I have a SD 75% Photo-JPEG QuickTime playing back in ‘kiosk’ mode (i.e. no other apps running, networking disabled, Energy Saver set to max performance, etc.) on a current Mac (with RAM upgraded) the playback should be without stutters. I’ve certainly run this scenario many times in public exhibition for months on end. This is not heavy lifting for existing Mac graphics cards.

[Mark Curry]

Hi Justin,

Yes, you’re asssumption is correct – direct computer monitor and yes, the file is fine; it is playback that the issue.

I am excited to hear about you’re experience with this bump (accurate characterization) as I can’t find anyone else with this issue. Would you be able to take a look at the footage if I provide a link?

I do think it is weird however that all transcodes (including low data rate NTSC 29.97 PhotoJPEG, DV stream, etc) and the SD downconvert via the camera’s analog outputs all exhibit this bump. Also, how is one supposed to distribute this? I can’t expect all playback to be dependent on an Aja or Blackmagic device. I need to be able to output this thing in a way that can be distributed.

Next, I’m booked with post houses that have Kona gear and I’ll also try capture to ProRes via firewire from the camera.

[Mark Curry]

Yes, it does seem to be a performance playback issue except for the fact that the issue persists through transcoding to low-data rate Quicktimes (dv stream, photo-jpeg, h264).

However, my next step is test on a better rig: Mac Pro, internal SATA RAID, 2nd 23″ monitor in order to eliminate this playback performance troubleshooting candidate.

Also, I’m going to try doing a hardware downconvert via the camera. As round-tripping to HDV via the camera is fine, perhaps downconversion via the camera will also be fine.

[Mark Curry]

Just had a new idea. As our final output is letterbox SD (.h264), how about we try doing a hardware downconvert via the camera. As round-tripping to HDV via the camera is fine, perhaps downconversion via the camera will also be fine. It is quite possible that the camera conforms the footage properly (in a way that the software doesn’t). I believe this camera’s (JVC GY-HD200U) downconverts to DV? This DV file we would then transcode to h264. In light of the stuttering issue, this extra DV compression is acceptable if the result doesn’t have this issue.

[Mark Curry]

Tried:
– External Macally Firewire 400 7200rpm drive (not Oxford bridge)
– Internal aluminum iMac SATA2 drive
– G-Tech G-RAID Mini

I can’t vouch for the G-RAID as it was a quick test on an unfamiliar system. However, I will test more carefully on a Mac Pro internal SATA RAID.

[Mark Curry]

Yes the PNG’s are sequential. However, I will need to edit out sections: specifically, editing out 24 frames every 48 frames beginning approx 1/3 into the sequence.

[Mark Curry]

hmm, sucks huh. I definitely want less suckage in this project. I’m convinced. um … see you over at the After Effects forum?

[Mark Curry]

Thanks Jeremy. Yes, After Effects is really the better and more fitting application for this project. However, I’m much more confident in FCP. This project only has 1 simple zoom into the center of the image with 2 keyframes at start and end – with “ease in” and “ease out” bezier curves. My understanding is that such simple motion graphics wouldn’t really reveal After Effects superior motion graphics abilities. Thoughts?

If I go with FCP, I will paste and nest to reduce compression. Perhaps, I will push myself to run this through After Effects.

[Mark Curry]

I expect that I do want an RGB codec (source is RGB and Mac Mini QT playback to LCD is RGB via DVI). I expect my source PNG’s are 8-bit … Is there loss if I have an 8-bit workflow? Should I instead be better served working within Apple’s 10-bit Uncompressed codec (or is this overkill)?

I’m going through an initial 10 MP timeline (identical to the resolution of my source images) and producing a single lossless QT movie from this in order to better apply a progressive zoom within my 0.8 MP (1024×768) timeline. Basically, this will allow me to easily keyframe this zoom. I suppose I could alternately drop in my 10 MP PNG’s into a 1024×768 timeline, remove attributes on all 2500 frames, nest the 2500 frames then apply a progressive zoom to that nested item. It just seems prone to issues where a self-contained QT isn’t. (I do need a quality zoom without interpolation (afforded by 10 MP footage within a 0.8 MP/1024×768 timeline)

[Mark Curry]

How is it lossy if I’m using a lossless workflow with minimal RGB<>YCbCr color shifts?