MKVToolNix v24.0.0 released

[Simon88]

How did you verify the stripping did not work?

Some tools (like this one (http://forum.doom9.org/showthread.php?t=152419)) allow SAR changing after encoding, though results may vary.

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

[Shapierian]

I've noticed that since MKVToolNix 6.0, output no longer seems to playback with the Android 4.2 JellyBean stagefright framework. (e.g. Android Gallery). This seems close to the switch to matroska v4 and libmatroska 1.4.0, but that switch happened with MKVToolNix 5.9, which works fine with Android 4.2. Does anyone have any insights on this? Is it possible to turn off the Matroska v4 features to see if that helps with compatibility?

[Fullmetal Encoder]

Mosu,

Thanks a lot for the Blu-ray mpls and chapter functionality! This is tremendously powerful for me since it gives me direct access to Blu-ray extras and chapters which I've never had before.

I also wanted to ask about how time codes are determined for chapter start times when appending files.

If I mux, say, 5 VOBs to 5 separate MKVs and save an empty chapter to each output file with a chapter time of 0 and then append them all together again in the GUI, a single chapter file is attached to the output with adjusted time codes. Obviously this is being calculated from the play time or duration of each video segment being appended but exactly how does mkvmerge GUI get that information and how is the calculation being done? The result in the output file is perfectly precise.

I have searched the forums and looked through the source code but haven't been able to discover it.

[sneaker_ger]

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

This does not necessarily mean it is still present. You should see from the value of "Original display aspect ratio" whether that is just coded width / height or the original SAR coded into the bitstream.

[Kurtnoise]

Hi Mosu,

Subtitles text tracks from mp4 don't seem to be parsed anymore with the current mkvtoolnix package...Here is a sample file (http://kurtnoise.free.fr/samples/Sopranos.mp4) (h264 + aac + tx3g + chapters) to debug.

[Overdrive80]

Hi Mosu, could be possible a minor implement feature as insert button "up" & "down" in attachment tab?? For example, for creating cover arts (http://matroska.org/technical/cover_art/index.html) is necessary put image files at the top of the attached. Maybe as that:


http://s6.postimg.org/x0idr6wht/Sin_t_tulo_2.png (http://postimage.org/)

[hubblec4]

Hi Mosu, could be possible a minor implement feature as insert button "up" & "down" in attachment tab?? For example, for creating cover arts (http://matroska.org/technical/cover_art/index.html) is necessary put image files at the top of the attached. Maybe as that:



what a kind of splitter and/or player is required to get this feature?

[Bigmango]

header removal compression has been turned off by default in both mkvmerge and mmg.



How can I enable header removal compression now?

You say the option was turned off.... but I can't seem to find any way to enable it. Is this option now gone?

Is there a way to mux all my files with header removal compression with version 6+, or should I go back to using version 5.8?

[Chumbo]

How can I enable header removal compression now?

You say the option was turned off.... but I can't seem to find any way to enable it. Is this option now gone?

Is there a way to mux all my files with header removal compression with version 6+, or should I go back to using version 5.8?
You may be referring to the Compression option on the Extra Options tab.

[Bigmango]

You may be referring to the Compression option on the Extra Options tab.

Header removal compression is not in the compression options in the extra options tab in version 6.1...

I may be blind, but the option seems to be gone? :confused:

Furthermore, how can I make mkvmerge behave like prior to version 6 (enabling Header removal compression by default) ? (the option you are referring to is not there anymore in the extra options tab, but even if it was, I would have to select it manually for each ID in each file.... this is too complicated, I want it to be applied by default as it was prior to version 6).

[Chetwood]

And why is that? To save a few MB on a GB file?

[Mosu]

Mosu, when loading a bluray playlist file into mkvmerge, the chapters it creates are ALL named "Chapter 0". I guess the correct would be "Chapter 1", "Chapter 2", etc.

Please file a bug report (https://trac.bunkus.org/) for this. I'm incredibly busy at the moment and will most likely forget about it otherwise. Thanks.

[Mosu]

I'm wondering if there was a way for mkvtoonix to tell me where approximately (in minutes:second) in the video is that particular XXXXX position located.... so that I can simply cut the offending portion using an editor.... thanx...

In case I haven't mentioned it yet: I've added that information (both the last timecode correctly read before such a resync and the first one afterwards) to mkvmerge's output. The latest pre-build (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) should contain said code.

[Mosu]

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

Edit: that should work. How do you know it didn't work?

[Mosu]

I've noticed that since MKVToolNix 6.0, output no longer seems to playback with the Android 4.2 JellyBean stagefright framework. (e.g. Android Gallery). This seems close to the switch to matroska v4 and libmatroska 1.4.0, but that switch happened with MKVToolNix 5.9, which works fine with Android 4.2. Does anyone have any insights on this? Is it possible to turn off the Matroska v4 features to see if that helps with compatibility?

Why don't you read this fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590) that I've written specifically for this issue and that has been linked about 21 times now in this thread? And please read it carefully and completely as it mentions several solutions.

[Mosu]

I also wanted to ask about how time codes are determined for chapter start times when appending files.

When you append two files (let's call them A and B) and B contains chapters then all of their timecodes are adjusted by the total duration of A. The total duration of A is the difference between the highest timecode+duration for a block minus the lowest timecode of any block in the file.

[Mosu]

Subtitles text tracks from mp4 don't seem to be parsed anymore with the current mkvtoolnix package...Here is a sample file (http://kurtnoise.free.fr/samples/Sopranos.mp4) (h264 + aac + tx3g + chapters) to debug.

mkvmerge has never supported tx3g subtitles. I have taken a look at that specification in the past and decided not to spend any time on it any time soon either.

[Mosu]

Hi Mosu, could be possible a minor implement feature as insert button "up" & "down" in attachment tab?? For example, for creating cover arts (http://matroska.org/technical/cover_art/index.html) is necessary put image files at the top of the attached.

No, sorry, because I refuse to implement workarounds in my software for idiotic implementations of other software. I'm not Mr. Fix-Other-People's-Mistakes.

To elaborate on this. Attachments are supposed to be identified by two different pieces of information:

A unique ID (called "file UID" in mkvinfo's output). mkvmerge automatically assigns that ID when attaching files and keeps it when remuxing them. This could be used from inside the file in order to refer to an attachment unambiguously. Currently that is not really used.
The attachment file name. This is supposed to be used by external applications if they need a specific feature, especially things like front/back covers.


The position inside the attachment list does not factor into it one tiny bit.

[Mosu]

How can I enable header removal compression now?

It's more or less gone now (not really gone, but you cannot enable it at the moment). That was a time/effort tradeoff I made when I reversed the decision to enable it by default. If enough people actually want to use that feature then I'll spend the time necessary to make it selectable from the command line (and from mmg) again, but so far you're the only one asking for it.

I also suspect that you're confusing what you want to do. The default prior to v6 was to have header removal compression enabled. The option present in mmg was to disable header removal compression again because having it enabled caused a lot of devices a lot of pain. So if you want your files to be as compatible as possible with regard to this feature v6 and newer already do what you want to achieve.

[Simon88]

Edit: that should work. How do you know it didn't work?

I use MediaInfo and it shows TWO values, one "Display aspect ratio" and the other one "Original display aspect ratio"......

as "sneaker_ger" pointed out - "This does not necessarily mean it is still present. You should see from the value of "Original display aspect ratio" whether that is just coded width / height or the original SAR coded into the bitstream."

However, I often use MediaInfo, BOTH the GUI version for a quick check and the CLI version for batch processing. I usually go by the container AR, but in the past my batch scripts were getting confused when there were two values.

Even some STB MediaPlayers gets "confused" and use the "Original display aspect ratio" rather than the container AR, requiring manually adjusting the AR using the remote during playback?

Can you make it so that "--engage remove_bitstream_ar_info" will ALSO remove the "Original display aspect ratio" info/value more completely so that programs like MediaInfo cannot detect it or make the value mirror that of the "Display aspect ratio"?

[Mosu]

That is exactly what the option is supposed to do in the first place. You should ask the MediaInfo author whether or not that piece of information is always reported for AVC/h.264 -- even if the ar_info_present flag in the SPS is not present.

One thing you can do is let mkvmerge output some debugging information:

mkvmerge --redirect-output output.txt --debug avc_sps -o dummy.mkv your_file_that_was_created_with_remove_bitstream_ar_info.mkv

Then paste the resulting messages e.g. on pastebin.com or upload the output.txt somewhere.

What this is doing is simply remuxing the file you've created with "--engage remove_bitstream_ar_info" while dumping the parsed AVC SPS structures mkvmerge handles.

[Simon88]

That is exactly what the option is supposed to do in the first place. You should ask the MediaInfo author whether or not that piece of information is always reported for AVC/h.264 -- even if the ar_info_present flag in the SPS is not present.

One thing you can do is let mkvmerge output some debugging information:

mkvmerge --redirect-output output.txt --debug avc_sps -o dummy.mkv your_file_that_was_created_with_remove_bitstream_ar_info.mkv

Then paste the resulting messages e.g. on pastebin.com or upload the output.txt somewhere.

What this is doing is simply remuxing the file you've created with "--engage remove_bitstream_ar_info" while dumping the parsed AVC SPS structures mkvmerge handles.

I couldn't find a file w/ bad AR. So, I issued the following two commands on a known good video file that is 960x540p (which has a 1:1 PAR / 16:9)... I want to make it 4:3, so I issued the following two commands:

"mkvmerge.exe" -o "your_file_that_was_created_with_remove_bitstream_ar_info.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--aspect-ratio" "0:4/3" "--default-track" "1:yes" "--forced-track" "1:no" "-a" "1" "-d" "0" "-S" "-T" "--no-global-tags" "--no-chapters" "(" "dummy.mkv" ")" "--track-order" "0:0,0:1" "--engage" "remove_bitstream_ar_info"

"mkvmerge.exe" --redirect-output output.txt --debug avc_sps -o dummy.mkv your_file_that_was_created_with_remove_bitstream_ar_info.mkv

The output of "output.txt" is:
mkvmerge v6.1.0 ('Old Devil') built on Mar 2 2013 14:32:37
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv': Using the demultiplexer for the format 'Matroska'.
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv' track 0: Using the output module for the format 'AVC/h.264'.
'your_file_that_was_created_with_remove_bitstream_ar_info.mkv' track 1: Using the output module for the format 'AC3'.
The file 'dummy.mkv' has been opened for writing.
Progress: 0%
Progress: 8%
Progress: 26%
Progress: 44%
Progress: 59%
Progress: 71%
Progress: 91%
Progress: 100%

The cue entries (the index) are being written...
Muxing took 3 seconds.


MediaInfo shows:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 40mn 53s
Bit rate : 1 068 Kbps
Width : 960 pixels
Height : 540 pixels
Display aspect ratio : 4:3
Original display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.082
Stream size : 306 MiB (87%)
Writing library : x264 core 114 r1924 08d04a4
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1068 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
In the resulting file, MediaInfo still shows the "Original display aspect ratio".... It appears MediaInfo gets he value from the track header.... I searched the web and found this info:

http://sourceforge.net/p/mediainfo/discussion/297610/thread/5c5de6d2

Can you also reset or mirror (w/ the container AR) the video track header info associated w/ the AR when the "--engage remove_bitstream_ar_info is used?

thanx...

[Mosu]

Ah I know what's happening. In case of remuxing from Matroska to Matroska the code path that actually adjusts or removes the AR info (depending on whether or not "--engage remove_bitstream_ar_info" is in effect) is never called. The same is true when remuxing from MP4 to Matroska. In all other cases (from raw h.264, from MPEG-PS or TS, from AVIs...) it is called.

I might get around to changing that some day. But don't ask me for an ETA.

[Simon88]

Ah I know what's happening. In case of remuxing from Matroska to Matroska the code path that actually adjusts or removes the AR info (depending on whether or not "--engage remove_bitstream_ar_info" is in effect) is never called. The same is true when remuxing from MP4 to Matroska. In all other cases (from raw h.264, from MPEG-PS or TS, from AVIs...) it is called.

I might get around to changing that some day. But don't ask me for an ETA.

Great that you now know what the issue is and that it only affects MP4s & MKVs muxed into MKVs... :D Thanks...

[sneaker_ger]

Ah I know what's happening. In case of remuxing from Matroska to Matroska the code path that actually adjusts or removes the AR info (depending on whether or not "--engage remove_bitstream_ar_info" is in effect) is never called. The same is true when remuxing from MP4 to Matroska. In all other cases (from raw h.264, from MPEG-PS or TS, from AVIs...) it is called.

I might get around to changing that some day. But don't ask me for an ETA.

Yes, I think we already talked about that in this thread some months/years ago.

Anyway, MediaInfo might still display "Original Display Aspect Ratio" even if the bitstream info has been completely removed by mkvmerge, so that's nothing that can be further improved from the mkvmerge side (aside from it also working with non-ES input). MediaInfo showing that info does not necessarily mean the info is still present.

Btw, I think the mkvmerge doc on compression might need some update.

[nautilus7]

Please file a bug report (https://trac.bunkus.org/) for this. I'm incredibly busy at the moment and will most likely forget about it otherwise. Thanks.

Done!

[Fullmetal Encoder]

When you append two files (let's call them A and B) and B contains chapters then all of their timecodes are adjusted by the total duration of A. The total duration of A is the difference between the highest timecode+duration for a block minus the lowest timecode of any block in the file.

You're obviously quite busy so thanks for responding.

With regards to the timecode and duration in the files being appended, where does that information come from? Was it read from the VOBs by the MPEG program stream reader when the VOBs were muxed into MKVs? What elements are being pulled from the stream to get those infos? When muxing, are VOBs treated any differently in this regard than any other MPEG stream?

If I examine the fist VOB with MediaInfo it exactly reports the same duration given by mkvmerge GUI to the first chapter when it's muxed and appended with the second MKV. However, if I use MediaInfo to get the duration of each VOB separately and then add those durations I get a number that's different from that of the single appended MKV. From the testing I've done, what mkvmerge is doing is perfectly correct vis a vis the chapter seek points and file segment durations. This is why it seemed that mkvmerge was doing something different than just adding the separate file durations.

I am asking about this because a while back I'd expressed interest in mkvmerge being able to "see" the "chapters" in DVD files like it can currently with Blu-ray mpls. I believe I can code a solution for this. Other tools like MakeMKV are not placing the chapter points correctly and if I'm going to try to solve this I want to do it properly.

[Mosu]

With regards to the timecode and duration in the files being appended, where does that information come from? Was it read from the VOBs by the MPEG program stream reader when the VOBs were muxed into MKVs?

Not as such. The timecode adjustment code (which also applies to the timecodes of appended tracks, not just of appended chapters) is located in mkvmerge's output chain. It simply knows which blocks were read from the previous file and tracks the lowest timecode and highest timecode+duration, and that is independent of the source file format. So it's not some... header value or something like that read from a source file, it's really the maximum difference between the block timecodes in an input file.

However, if I use MediaInfo to get the duration of each VOB separately and then add those durations I get a number that's different from that of the single appended MKV.

I'm pretty sure that MediaInfo does not take care of a) frame reordering due to B frames and b) maybe not of frame durations. For example, if you have a (pretty short) MPEG-2 video sequence of the usual IPBB with timecodes 0, 120, 40, 80 then the duration of that short sequence would be 160 (lowest timecode is obviously 0; duration of each is 40, so highest timecode+duration would be 120+40; 120+40 - 0 = 160 total duration). I'm simply not sure how MediaInfo calculates the duration, but it might just use the 80 (as it's the very last frame), or it might even be more intelligent and add the frame's duration of 40 ending up with 120 -- which would still be wrong.

I also don't know how MediaInfo handles streams of different lengths. What if there's an audio track in addition to the video track and the audio track still has packets for timecode 150 with a duration of 32ms?

You should ask MediaInfo's author for further information if you really want to know the answers.

I am asking about this because a while back I'd expressed interest in mkvmerge being able to "see" the "chapters" in DVD files like it can currently with Blu-ray mpls. I believe I can code a solution for this. Other tools like MakeMKV are not placing the chapter points correctly and if I'm going to try to solve this I want to do it properly.

If I'm not mistaken then the chapter information is stored in one of the IFO files. So far mkvmerge doesn't have an IFO parser on board, though it would be nice to have one -- similar to how the MPEG transport stream reader is looking for CHPL files and parsing them in addition to the M2TS or MPLS files you've asked mkvmerge to process.

[SeeMoreDigital]

Hi Mosu,

I'm currently performing some tests with .dff and .dsf (DSD) (http://en.wikipedia.org/wiki/Direct_Stream_Digital) audio streams. Is there official Matroska container support for these types of files?

[Mosu]

Never heard of them, so: no.

[Fullmetal Encoder]

For example, if you have a (pretty short) MPEG-2 video sequence of the usual IPBB with timecodes 0, 120, 40, 80 then the duration of that short sequence would be 160 (lowest timecode is obviously 0; duration of each is 40, so highest timecode+duration would be 120+40; 120+40 - 0 = 160 total duration).

Ok, that's very interesting. So the duration is something that the code just calculates from seeing the difference between the timecodes. And the timecodes are pulled from the stream by the MPEG-PS reader? I'm interested in where in the MPEG data and code it's pulling this.

You should ask MediaInfo's author for further information if you really want to know the answers.

It's ok, it's no longer relevant. There were just two possibilities. Either there was some generally accepted method of getting the play length of an MPEG clip and mkvmerge (along with MediaInfo, Windows OS, etc.) was implementing that, in which case I wouldn't probably need to delve into the mkvmerge code, or mkvmerge is doing it's own thing entirely. The latter appears to be the case.

The big thing that mkvmerge does differently is that it's setting the chapter points by the actual video segment duration via the timecodes. I think aside from maybe some DVD authoring tools mkvmerge is the only program that does this. As far as I know, the video segment can only begin with an I-frame (without corruption). Mkvmerge has no knowledge of IFOs and there's nothing else to go by to tell it how to adjust chapter start times when appending so it looks directly at the real video duration (which would make sense anyway). So when our two hypothetical mkvs are appended the output file has chapter start times that land directly on the I-frames that were at the beginning of the individual segments. I think other tools that attempt to pull chapter "points" from DVDs are only looking at the IFOs.

If I'm not mistaken then the chapter information is stored in one of the IFO files.

Well, yes and no. When human beings think of chapters they think of them as 'parts of a show' they can jump to that are at certain time points in the playback of the video. The problem is that the DVD structures and files have no such concept of a chapter. The "chapters" in an IFO are really just tables of pointers to byte offsets within the VOBs. Of course, it's up to the user which of those video segments have enough meaning to be considered chapters in the file they want to mux to mkv. If a user wants to create chapters in some generic video file they have to manually decide where each chapter point should land. However, in a DVD all the chapter "points" are already chosen for us but to get them properly you have combine the information in the IFOs with the video frame data. I don't think there are any non-professional tools that do this, which doesn't surprise me. While the above method may be perfectly correct it's also a PITA to implement.

So far mkvmerge doesn't have an IFO parser on board, though it would be nice to have one --

Yes, I am almost completely finished with this as far as video title sets are concerned. Although I do have the idea to go beyond that. I still need to do a little more work to include the parts of title table pointers but mostly everything regarding the program chains and cell byte offsets is complete and that's the main meat of it.

I have also completed code for pulling subtitles from DVDs. It can scan through VOBs and pull together all of the sub-picture PES streams just as VobSub would for a .sub file as well as look into the IFO for a video title set to get the original DVD color palette and convert to RGB as VobSub would. As far as I can tell the subpic PES streams and the DVD palette infos should be all your vobsub packetizer needs from a DVD source. Most of the content of a VobSub .idx file is to allow the user to customize different attributes of the subtitles which is irrelevant to us since we're only concerned with extracting the subtitles as they are in the DVD source. Let me know if any other information may be needed.

Honestly though I have not been able to integrate any of this into the mkvtoolnix code as it's just too complex and over my head for me to do that at this point. Especially the memory management. What I am doing is creating stand alone programs that show that the code does what it's supposed to do. Would you be willing to check out the code when it's all finished to see how easily or how difficult it may be to integrate? I am trying to make everything as modular as I can and to keep it simple in case any redesigning needs to be done to make it more compatible/portable.

[Atak_Snajpera]

mosu any breakthrough regarding opus stream in matroska?

[SeeMoreDigital]

mosu any breakthrough regarding opus stream in matroska?Experimental support was added to MKVToolNix v6.0.0... It seems to work okay ;)

[Mosu]

Well, Opus is bitchy to implement properly. No, no major breakthrough so far. Read the recent discussion (http://article.gmane.org/gmane.comp.multimedia.matroska.devel/4617) for more details.

[sneaker_ger]

While we're at new formats: is H.265 support in the works?

[Mosu]

No, not really. I'd love to have support for it, obviously I'd be the one doing the implementation, but I don't have access to specs, nor do I have a lot of time on my hand right now. So unless someone else steps forward and provides some needed knowledge... For example, someone mentioned something about needing to distinguish between BLA/CRA, and I have no clue whatsoever what he referred to.

[superhil]

Dear Mosu,
I have 6.1 AAC file that I want to mux with the video.
When I add it (using mmg.exe v6.1.0) it doesn't appear in the menu.

But, if I downconvert it to 5.1 AAC, everything is fine

Do you know what's the problem?

------------------------
edit:
I just tried also with 7.1 AAC
I face the same problem

[Mosu]

No, I don't know what the problem is.

[superhil]

have you tried muxing 6.1/7.1 AAC audio?
I don't know whether it's bug or not

thank you for your fast reply

[Mosu]

I don't know how many channels my AAC files have. I only mux them, I don't listen to them.

[superhil]

may I give you sample file?
thank you :-)

[Mosu]

Sure, but I don't have much time at the moment. Don't expect an answer for a week or two (might be sooner, but I simply cannot plan ahead when I'll have time and motivation to work on MKVToolNix at the moment). Upload to my FTP server, please (see signature).

[superhil]

Sure, but I don't have much time at the moment. Don't expect an answer for a week or two (might be sooner, but I simply cannot plan ahead when I'll have time and motivation to work on MKVToolNix at the moment). Upload to my FTP server, please (see signature).

I've uploaded the file with name "audio-sample-SuperHil.m4a"
Just take your time :-D

Thank you

[Mosu]

The audio track in your file contains an invalid number of channels inside the AAC configuration data. To be more specific:

An MP4/M4A file with AAC contains an ESDS atom. That atom's content is usually 2 or 5 bytes long and tells the AAC decoder about the most important properties: the profile, the sampling frequency, the number of channels, the output sampling frequency in case of SBR/HE. In your case the ESDS contains 14 bytes (why so many? no clue, to be hones), but the first two are 0x11 0x80. The number of channels is stored in the second bytes in the lower seven bits, which is... 0. mkvmerge then discards the track because 0 channels would be invalid in Matroska.

However, the MP4 container itself does also contain a "number of channels" header element. That one is set correctly. I'll change mkvmerge to use the channel number indicated by MP4 for AAC in such a case.

ffmpeg compiled with debugging options agrees that the container value is fine but the ESDS data says "0 channels".

Not sure if this is solely an issue in mkvmerge. Meaning... I'd be interested to know why there are 14 bytes instead of 2 or 5. I'd also be interested to know if those extra 12 bytes are actually something official that does contain the channel number in some way.

[nevcairiel]

channel_config == 0 is valid in the aac header, it usually means that a GA ("General Audio") block and PCE (program configuration element) is following the data which contains the channel configuration.
If you have the AAC spec at hand, its tables 1.13 for the generic setup data, and tables 4.1 for the "General Audio" info (following the setup data), and 4.2 for the PCE

[Mosu]

Ah, that sheds some light on it, thanks. Looks like this blog post (http://spectralhole.blogspot.com/2010/08/aac-bistream-flaws-part-1-channel-model.html) explains the situation quite well.

[Mosu]

Hmm, is there ANY documentation about AOTSpecificConfig anywhere apart from ISO 14496-3 (which I don't have)?

[Guest]

@Mosu

Check your PM.

[superhil]

Honestly,,I don't understand about the detail.. :-D
But thank you very much for your explanation..

Finally, i decided to convert it to 5.1 audio, since my speaker is only 5.1.

[superhil]

Does it mean that the problem is with Nero AAC Encoder?
The original file is 7 channels (6.1) .wav audio and then i converted it to AAC (.m4a)

BTW, I have MediaInfo installed in my PC, it tells correctly about the total number of channels from that .m4a file.