media may be damaged error in QuickTime player 10

But, only in QuickTime player 10 version gives 'The document ... could not be opened. This media may be damaged'.

I tried lot to find out the reason for this error, but not able to fix. My file has two tracks: One track is 1920x1080 resolution H264 video track and another track is MPEG4 AAC-LC with 48K sampling rate and 64K bit rate.

Why this error is coming only in QuickTime player 10 and but all other players are playing (including QuickTime 7)

QT X may reject non-standard encodes. I.e., user settings and codec features should be compatible with the standards as specified by the Joint Video Team (JVT) for the profile and level used. Such standards are often ignored by proprietary and/or third-party encoders or players. Unfortunately, you have provided little info in the way of specific settings used for your files. (E.g., specific Profile, Level, video data rate, frame rate, etc.) However, based on what you did include, is your audio content mono or stereo? I ask because a mono AAC-LC track should be compatible with a 64 Kbps data rate @ 48.0 KHz but a stereo audio track of 64 Kbps would be expected to have a minimum sampling rate of 16.0 KHz and a maximum sampling rate of 44.1 KHz.

Not sure that your issue is this simplistic but it gives you some idea as to how user settings/options can affect the encoding of data for certain players but not others.

Please help to figure out why QuickTime 10 gives this error.

Can you provide a sample file for examination? This might be easier that a lengthy Q&A regarding specific encode settings like...

1. Is your video data rate greater than 62.5 Kbps?
2. Is your frame rate greater than 64 fps?
3. Is your bit depth greater than 8?
4. Are you using 4:2:2 or 4:4:4 chroma formats?
5. Are you using Flexible Macroblock Ordering (FMO)?
6. Are you using Arbitrary Slice Ordering (ASO)?
7. Etc., etc., etc.

Also, in re-reading your initial paragraph, it was unclear if by "MP4 container sources" you are referring to the encoding of data or the creation of a custom MP4 container. My previous, as well as, the above response was in regard to the encoding of data. However, Apple is also constantly issuing "security" updates that may trap on what it may consider questionable container characteristics which it may interpret as a damaged file.

In any case, was wondering if you can post a non-critical "sample" file having your previously described issue for download and testing/examination on my system to see if anything obvious about the file and/or its contents stands out.

Hi,

This is the same sender. Initially, I sent from different Id wrongly.

Below are the links to download my 2 MP4 files. one recorded with 48Khz and another with 44.1Khz

https://app.box.com/s/m9a8elw6grx6eb7eyf2j
https://app.box.com/s/974wtv4tuax2pw8b4ttn

Actually, I use the H264 and AAC encoders from third party and I use my own MP4 container. I encode and get the H264 and AAC streams using my third party library and then I take care of creating MP4 container.

Please help me to find out what is wrong in the about MP4 file to get the 'media may be damaged' error.

Hi Jon,

Additional information, if I create the MP4 file without audio then it is playing properly in QuickTime 10 also. Video configuration is same as in the previously attached file. I get the error if I create with video and audio tracks.

This is the same sender. Initially, I sent from different Id wrongly.

Below are the links to download my 2 MP4 files. one recorded with 48Khz and another with 44.1Khz

https://app.box.com/s/m9a8elw6grx6eb7eyf2j

https://app.box.com/s/974wtv4tuax2pw8b4ttn

Actually, I use the H264 and AAC encoders from third party and I use my own MP4 container. I encode and get the H264 and AAC streams using my third party library and then I take care of creating MP4 container.

Please help me to find out what is wrong in the about MP4 file to get the 'media may be damaged' error.

Additional information, if I create the MP4 file without audio then it is playing properly in QuickTime 10 also. Video configuration is same as in the previously attached file. I get the error if I create with video and audio tracks.

Based on both the files provided and the added information comment, as well as, my own observation that QL also did not totally like your files, I tried a little experiment. Basically, I simply copied the data from each of your provided files to new MP4 file containers and tried playing them in the QT X player under Mavericks. Both of the new files played without problem in the QT X player and now play the audio in QL (which didn't previously play).

Here are links to the new files which have a "-A" added to the original file name for differentiation purposes:

http://downloads.walker4.me/Temporary_files/File_AAC4_H264_44_1Khz_64Kbps-A.mp4

http://downloads.walker4.me/Temporary_files/File_AAC4_H264_48Khz_64Kbps-A.mp4

You can download the linked content for testing on your various systems and media apps as desired. (NOTE: Will leave file links active for at least 30 days but will eventually delete the files to reclaim the storage space on my personal server.)

Conclusions:

Based on my results, it appears the problem is in your MP4 "muxing" workflow. Unchanged audio and video data is compatible with both QT X and QL playback on Mac systems as is. However, there is something about your final MP4 file containers that the AVFoundation structure embedded in the Mavericks OS doesn't like. To make the files Mavericks compatible (i.e., QT X v10.3 compatible), I simply opened them up individually in MPEG Streamclip and saved the data to a new MP4 file container. Other media apps like VLC may be able to do the same thing, but I did not try them as this app was already open and available when I made the test. You can either change your "muxing" workflow or "re-mux" your current files for final distribution.

Hi Jon,

Thank you very much for your experiments and in the information. I would like to correct my MP4 "muxing" workflow. But, I could not exactly identify which part in my file is not compatible with the QT10.

1. Since, QT 10 gives the generic error message "media may be damaged" and there is not detail error logs, I could not find out the exact issue in my Muxing workflow. Is there any tool can give with more logs for this error condition with quicktime 10 ?

2. I compared with my file and the file you have uploaded and found that only 'edts' atom is additionally available in the file you have sent apart from the timescale for the entire movie. But, as per the MP4 standard, 'edts' atom is optional. By any change, 'edts' is necessary for the file that I have sent.

1. Since, QT 10 gives the generic error message "media may be damaged" and there is not detail error logs, I could not find out the exact issue in my Muxing workflow. Is there any tool can give with more logs for this error condition with quicktime 10 ?

I use Dumpster (an old "Developer" app or the newer Atom Inspector app) along with an older version of MediaInfo for most examinations.

2. I compared with my file and the file you have uploaded and found that only 'edts' atom is additionally available in the file you have sent apart from the timescale for the entire movie. But, as per the MP4 standard, 'edts' atom is optional. By any change, 'edts' is necessary for the file that I have sent.

I believe the 'edits' atom was added as a result of a discrepancy between the stated audio track duration and the actual duration of the audio data track. Your container indicates the audio duration is 6930 ms while the actual data duration appears to be 6933.436 ms and the 'edits' adjustment appears to tack on an additional 3 ms duration so that the next ms (6934) completely encloses the audio data actually contained in the audio track and provides a valid End of Track (EOT) marker beyond the end of the audio data. Not an Apple QT technician so I am only guessing that this discrepancy is what was triggering the "file damaged" message and by re-wrapping the the data to a new file, the software was smart enough to write the correction as a "logical" edit entry to the new MP4 file. And, of course only the Apple QT media players would bother to check for and use this edit information under normal circumstances as many QT users have previously complained when making "logical" edits to MOV files instead of making "physical" edits to their content.