Jon:
And if I may ask, how do you autopsy my video files to know my encoding?
I may use a number of differe apps and/or utilities depending on the information gleaned from the player. For instance, in the case of the "alli-jas.mov" file, I started with the QT 7 Pro "Inspector" window.
The "Format:" entry tells me the audio was on of the 16-bit PCM codecs (Stereo L/R sampled @ 48.0 KHz) and the video was encoded non-anamorphically using the H.264 (aka MPEG-4 AVC) codec at 720x480.
NOTE: At this point I began to wonder if the file was really a custom 3:2 file (an aspect ratio not normally used for video but often used by cameras) of if the file was supposed to be an anmorphic 720x480 (640x480) file that had been missencoded—i.e., the latter be a common occurence in some work flows when editing and/or converting NTSC DV or MPEG-2 file content. Based on some video tracking error and and seeing the 320x240 (4:3) encode of the of the same content, it became obvious that this file was encoded at the wrong aspect ratio.
The "Data Size:" entry told me the file should contain at least 1.20 GBs of compressed data for the active audio and video tracks specified in the "Format:" entry while the "Data Rate:" entry indicated a combined total data rate for these two tracks averaging 5827.64 Kbps.
I next decided to open the "Properties" if there were any inactive data tracks about which I should know, check on the distribution of date between active audio and video tracks, as well as, check the individual durations of the various data tracks. Everything still looked normal dispite what I considered a waste of data rate/space for encoding the audio and video. (I.e., there still was still no apparent reason for the limitation on playback.)
Since I remembered the file size had not increased as rapidly as I had expected while monitoring the download, at this point I opened the Finder "Info" window to see how much physical space the file was taking up on my hard drive. To my surprise, the Finder only indicated 77.7 MBs of file space as opposed to the 1.20 MBs of data plus normal file overhead expected. It was obvious that only a fraction of the file data was present in the file. While I did use Atom Inspector and Dumpster to verify the track durations, time scales, and presence of various valid data tables, the data itself was physically absent (as demonstrated by the physical file size) and this was not a case of modified in and out play points preventing QT-based apps from accessing the data.
I also used the MediaInfo utility to check on the Profile and Level used to encode your files, but this had no real bearing on your main playback problem.