A H.264/AAC TS file can not be played !

This TS can be correctly played by VLC, MPC-HC, Win7 WMP, and KMPlayer

but NG by QT Player 10.1 (501.29).

First off, the file type presents a problem. Classic (QT 7) based apps do not accept the Transport Stream (TS) file type. And, while QT X v10.1 will play TS files, it expects the file to contain MPEG-2 video muxed with MPEG-1 layered or AC3 audio. Therefore, the first thing I would recommend would be to use a more common QT file format that is compatible with MPEG-4/AAC compressed data like M4V, MP4, or MOV.

Unfortunately, even after I moved the audio and video data to a compatible container, the video still had a playback problem. It would appear that the video includes one or more settings that is/are non-standard for the High Profile/Level 5 encode combination you used for your TS file. Since I could not spot an obvious problem examining the file stats, I decided to use an FFmpeg based app (HandBrake) to recompress the video data to universal settings known to be compatible with all recent Apple apps/devives (QT X, QT 7, GarageBand, iTunes, the QT plug-in component, iPod Touch, iPhone, iPad, TV, etc.) which I use on a regular basis. However, in using "more universal" settings (Main Profile @ Level 3.1) to increase playback compatibility with Apple apps and devices, the quality was reduced and the video lost a bit of its color saturation. At this point, I do not know if this factor would be significant in your work flow since you did not indicate if you are more interested in file quality or file compatibility here.

In any case, here is a link to the resulting file: 22141000.m4v

And here are the video settings used in HandBrake (Note: I also added a secondary AC3 track which is normally used for TV DD5.1 audio when available.):

You can compare these compressions settings against those used in your work flow to try and locate the one(s) causing a problem.

Please kindly indicate how to setup QT player to show debug information or which field in the file is wrong.

Modification/setup to the muxer is possible.

And I look forward to support QT Player natively (without additional cost/components).

Unfortunately, there is no actual "debug" routine that can be "set up." (At least there isn't on the Mac side.) You would normally use the "Inspector" and/or "Properties" windows to look for obvious incompatibilities. However, since this content is MPEG-4/AVC, it is usually better to use a dedicated video utility to examine the file for inconsistancies between Profile/Level standards and the actual encode stats for the file. (As previously mentioned, nothing really obvious caught my eye in your file.) These settings can sometimes be very subtle. For instance, over the weekend, I ran into an MP4 file on the archive.org web site that would not play. Turned out the file used the XviD codec to encode the file using the Advanced Simple Profile but included settings only allowed in the Simple Studio Profile which created a non-standard file. Since Apple players try to strictly adhere to the standards as set forth by the ISO/IEC, the file in question was not playback compatible with QT apps until it was transcoded. Your file appears to have similar problems because the FFmpeg package is somewhat looser when it comes to both the encoding standards and encapsulation of data. As Monk might say, "It is a blessing—and a curse!" The looser standards of FFmpeg as implemented by apps like VLC and HandBrake allow the package to support a wider range of codecs but in doing so, can often create or pass on problems to QT based apps.

QT10_OK.TS is recorded by a device that I have rare control over the encoder and muxer and is supported by QT10.

I took it as the target sample for reference.

This file is encoded differently—using the Main Profile @ Level 4.0 instead of the High Profile @ Level 5.0. File also lacks the "menu" stream included in the original sample file posted. (I.e., not sure if this extraneous track is a problem or not as far as original sample file is concerned.)

Using encoder settings same to 22141000.TS, I create 20130410.MP4 that is OK by QT10.

However, after I remux it to 20130410_remux.ts, QT10 fails to play the resulting ts.

Very interesting. The 20130410.MP4 file may be encoded the same as the 22141000.TS file but the MP4 file contains an additional "Muxing mode" identifier that states "Container profile=High@3.1" which is removed as part of the "20130410_remux.ts" file remux. This may imply that your inability to play the original file may be due, at least in part, to Apple security updates which refuse to allow the targeted High Profile/Level 5.0 combination to be played even though the player appears to have the ability to do so.

Based in these last sample files, recommend you either encode/capture your files using Main Profile @ Level 4.0 settings employed for the "QT10_OK.TS" file if these settings are a user preference option. If not, then use the work flow used to create the MP4 file version that tells the player the file contains High Profile @ Level 3.1 video content. The former approach creates a file that is actually QT comptible while the latter approach "lies" to the player to "get around" the playback problem and is an approach that may or may not work in all possible playback situations.

I remove the "menu" track and QT playback is still NG.

Thanks for the feedback. Probability of helping matters was of such a low order that I did test this myself and so merely mentioned it in passing. However, my normal recommendation is to remove/leave out all extraneous data tracks (menus, alternate languages, subtitles, etc.) if they have no potential for use or are not compatible with your final target device playback.

I have trouble altering the encoder profile/level and keep working on it.

Ability to to control encoding will depend on the specific work flow used.

1) If the original data streams are merely repackaged for local use in a different file form, then encoding is controlled by the service providing that data streams. In this case, the only way to alter the encoding is to transcode the content yourself as I did with the original sample file you posted.

2) In other cases the data may be encoded by the device/software package itself. This process may or may not allow specific manual alterations. You seem to indicate yours does not.

3) In still other cases where the data is transcoded by the work flow, the encoding may be controlled contextually. For instance, the work flow may have a data throughput limitation and be programmed to lower the Profile/Level settings inversely with the increase in encoding dimensions. (I.e., I noticed that the Main Profile @ Level 4.0 QT10_OK file you posted was also the only file encoded in the 1080p mode with a fixed frame rate while all other sample files were encoded as 720p files with variable frame rates. Therefore, if your work flow has an option that controls the resolution of your output, this same option may also control the Profile/Level settings automatically in order to maintain a constant data throughput under the varying work load.)

Could you please indicate which field of 20130410.MP4 that states "Container profile=High@3.1"

and what's the corresponding field in TS ?

Depending on what you really want here, I may or may not be able to help you. Inspection of your files was done using a dedicated media inspection utility—not a utility having the ability to read and modify the embedded data. In comparing the MP4 file, I noted the following:

As you can see in the highlighted text above, the MP4 file contains an added "Muxing mode" file descriptor between the "Internet media type" and the "Codec ID" entries which tells the player that the file contains High Profile @ Level 3.1 encoded video data despite the fact the the file was actually encoded with High Profile @ Level 5.0 data. On the other hand, after you remuxed the same data to the TS file container as seen below, this file descriptor is once again missing and the 720p file becomes non-playable:

In other words, at this point I am merely examining the various characteristics of the files you have provided and compaparring playability to form a hypothesis which might explain why one file is playable and another is not. Since it was your MP4 work flow that added this descriptor to the file, I cannot specifically say what "field" or setting you used to accomplish this.

In the off chance that you might also like to examine these characteristics, I have copied the date for your sample files to separate RTF text files and posted the ZIP file package to the following URL:

YulinHuang.zip

NOTE: Files posted to my personal server are only available for a limited period and will normally be removed within 90 days.

Setting the encoder for Main@4.0 is done.

20130415.TS is the sample clip and QT still NG with it.

I plan to try:

1. add ES_info in PMT for the video stream.

2. make PCR a standalone stream instead of embedded in video PES to save bandwidth.

Not sure what you did to the latest file but TS capable QT based apps seem to see the video data as MPEG-1 (playback ignored by both QT X player and MPEG Streamclip) with either AAC audio (QT X player) or MP2 audio (MPEG Streamclip). I do not understand why you continue to torture yourself by using transport stream (TS) file encapsulization which, at best, is only partially QT compatible when MOV, MP4, and M4V file containers appear to be fully compatible with both QT X and QT 7 based applications, as well as, all latest Apple mobile devices.