MpegTsMuxTest

A problem raised in gst-devel, by Peter Maersk-Moller, kshitij gupta, and yangsb, reporting that the muxer is not woking "correctly" with h264 audio and aac audio, in the sense that neither VLC nor mplayer is normally playing the file. Discussion see

• http://www.nabble.com/MPEG-2-TS-Muxing-td17485498.html

• http://www.nabble.com/Mpeg-ts-mux---missing-audio-td22617660.html

LinYANG is trying to solve this problem, and here is his result.

First some attempts are made trying to break the problem into parts. In the second thread above, yangsb initiated some analytical tests on the h264parse+aacparse+mpegtsmux bundle, and concluded that h264parse might be the cause. Following his approach, LinYANG tested the bundle over an even wider possibilities of configurations, and found exception to yangsb's conclusion. The detailed result is reported in the following session. Although new evidence shows that the cause is actually irrelevant to the test here, it might be of further interest in verifying the usability when the solution comes out.

As the situation is not clear enough to draw any useful information, Lin then wrote some small programs that parses the ts files. From the parse result, it is clear that the main problem with mpegtsmux is that it is not putting pmt into its output. As a result, players have no way to decide how to treat the streams but to guess randomly, which causes the chaos in playability testing. On the other hand, it has been verified that TS muxes generated with FFmpeg and a commercial muxer Elecard XMux Pro (trail version) are both providing consistent pat and pmt, also playing perfect on all mainstream players.

There is also saying that TS demuxers should get the stream type information from the PES directly instead of from PMT. May be mpegtsmux is not providing the pmt table for the same reason.

Usability Test of mpegtsmux

We are now describing a set of tests conducted on the muxer mpegtsmux working with h264 video stream and aac audio stream. The rationale of the test, posted by yangsb, is to partly replace the pipeline to rule out possibilities of malfunctioning from different parts to identify the error. The naive pipeline is using the h264parse + aacparse + mpegtsmux bundle, so we gradually replace some of them. The original pipeline is here, and here is the script we are using now.

In the script the .ts file is produced in 7 different ways, each of which represented by a 2-letter-string from "ha", "hm", "ma", "mm". "qa", "hq", "qq". The first letter specifies the video source:

• 'h' for h264parse

• 'm' for an mpeg2 video stream
• 'q' for a quicktime video stream demuxed from a .mov file, which is muxed from an h264 stream + aac stream

The second letter specifies the audio source:

• 'a' for aacparse

• 'm' for an mpeg2 audio stream
• 'q' for a quicktime audio stream demuxed from the .mov file as above

Then the two streams are muxed by mpegtsmux.

We define the "mainstream players" to be VLC, mplayer and KMPLAYER (available on Windows, although not so favoured¹). (The main reason for introducing KMPLAYER is that it can play the .ts file from the first pipeline above.)

The results are listed in the following table: (S.B.= scroll bar)

1. In mplayers screen dump we have: "ADecoder Initialize Failed: Cannot find codec for audio format 0x4134504D"
2. In the sense that the movie ends before the scroll bar reaches the end
3. In the sense that the scroll begins at about 2/3 of the whole length
4. The scroll bar is shorter than the playback length; when the thumb reaches the end it just stall there until the playback is finished

5. Except that when playback reaches the end, FAAD shows an error: "Failed to decode frame. <br> error: unable to find ADTS syncword. Trying to resync!"

6. FAAD constantly says: "error: Gain control not yet implemented, trying to resync!" and if you don't drag forward, mplayer would crash at about 1/3 of the movie. If you drag the movie beyond this point then you can reach the end, despite the error from FAAD.
7. The encoding stuck without showing any errors. From top we can see gst-launch is not working.

Conclusion We can see that the situation is in a chaos, as no clear divide can be found on the above chart.

On the other hand, however, FFmpeg and Elecard XMux Pro is making perfectly playable TS streams from the same source. Quite to think.

MpegTsMuxTest (last edited 2009-04-04 00:33:27 by LinYANG)

• Immutable Page

DeleteCache (cached 2009-10-20 19:37:09)

Or try one of these actions: Attachments, CopyPage, Despam, LikePages, Load, LocalSiteMap, MyPages, PackagePages, RenderAsDocbook, Save, SpellCheck, SubscribeUser, SyncPages