MKVToolNix v24.0.0 released

[wbee]

Are you the one who's posted a similar bug...
yes

Thank you very much for your detailed explanation!
it's more likely my player cant play SBR

[Simon88]

I don't know. And honestly, Cook/RealAudio is so old and unused today that I don't really care.
RMVB/RM seems to be REALLY popular in Asia. They have cheap devices that produces excellent video at low bitrates w/o having to pay royalties I guess.

Bit-rate below ~100Kbps defaults to cook and LC-AAC for anything above. Real is moving to HE-AAC for the lower bit-rates, though.

Anyhow, I was hoping to preserve the original RV40/cook onto a MKV container & also add a re-encode of the video as H264/LC-AAC inside the MKV container, and show the original if hardware permits as recencodes degrade video quality.

I didn't know that apparently just by having a "cook" track inside the MKV, playback is negatively affected even on the H264/LC-AAC tracks.

[Mosu]

Back when I implemented support for RealMedia re-muxing cook used to work. That was... oh... hmm... in 2004, it seems. The last time someone actually had contacted my about some RealAudio issue (not AAC) was in 2007, if I'm not mistaken. Also: players refusing to play a whole file just because one kind of track is present are seriously broken -- unless mkvinfo and mkvmerge cannot read such a file either. In which case I would actually investigate the issue.

So please check: "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvinfo" and "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvmerge -> mkv-remuxed-without-cook". If the last step of those actions fail (not if playback fails!) then it might be interesting to look at.

[Simon88]

Back when I implemented support for RealMedia re-muxing cook used to work. That was... oh... hmm... in 2004, it seems. The last time someone actually had contacted my about some RealAudio issue (not AAC) was in 2007, if I'm not mistaken. Also: players refusing to play a whole file just because one kind of track is present are seriously broken -- unless mkvinfo and mkvmerge cannot read such a file either. In which case I would actually investigate the issue.

So please check: "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvinfo" and "rmvb-with-cook -> mkvmerge -> mkv-with-cook -> mkvmerge -> mkv-remuxed-without-cook". If the last step of those actions fail (not if playback fails!) then it might be interesting to look at.
I re-muxed according to your instructions and MPC-HC played it, the RV40 video, fine except there was a slight video studder during playback using VLC and MPC-HC. Changed the splitter to LAV from Haali and video playback works OK without stutter, with cook audio in the MKV container, not OK, no matter using Haali or LAV.

mkvinfo read all the MKVs info without issue.

Finally tried playing RV40/cook using ffplay.exe (ffmpeg) and audio stuttering also occured inside the MKV container. Without cook audio, ffplay.exe played the video ok as well. I believe audio/video may not be interleaved/aligned correctly by mkvmerge. Perhaps, just a one line, code change of some sorts.

I believe the RealMedia container has undergone various changes thru the years, perhaps. Like you, I also think it is a dead/dying format, so I checked wikipedia: http://en.wikipedia.org/wiki/RealNetworks
Surprisingly with the lousy economy, after laying off alot of their employees, they still have more than 1,600 employees left...

If you visit Asian video sites, it is the preferred online format in Asia, they almost exclusively still use RM/RMVB for streaming and downloading, with MKV's used for d/l's of multi-lingual videos, AVI's used less often.

Because of the low-bit rate required, cook is still quite popular and just recently ffmpeg reliably supports RM/RMVB, it is now easily played on ALL platforms without the need of using hacked RealNet dll's.

[Mosu]

Upload a sample file to my FTP server. Maybe I'll take a look at it over the next couple of weeks.

[Simon88]

Upload a sample file to my FTP server. Maybe I'll take a look at it over the next couple of weeks.

Hi Mosu,

I just uploaded two low resolution very recent broadcast/over the air TV captures to your ftp server. I've included MD5 checksums because your ftp server choked a few times during the upload & retransmission/recovery was used. Both use RV40 for video & one has cook, the other has LC-AAC for audio.

HD 1280 x 720p, 3Mbps, RV40 video, 128Kbps LC-AAC audio are the most popular resolutions, though (1GB/45min) too big, I sent you the low resolution varieties.

After a few months, only archived version are available/saved at usually 720x408p, 700Kbps, RV40, video, 64Kbps, cook, audio.

If you convert even the one using LC-AAC to the MKV container, the MKV video has a slight stuttering/not smooth compared with the original RMVB. However, RMVB w/ LC-AAC converted fine using the following command:
ffmpeg -i RMVB_with_LC-AAC_audio.rmvb -vcodec copy -acodec copy RMVB_with_LC-AAC_audio.mkv

However, even ffmpeg does not convert RMVB_with_cook_audio.rmvb to mkv properly.

I've only uploaded the two most popular & current types of RMVB encoded by RealVideo v10/11.

Most development work & source cvs codes, command-line utilities, etc is located at: https://helixcommunity.org/
and only sell their stuff at: http://www.realnetworks.com/

So, HelixCommunity is where everything is at for OpenSource info regarding there SDK, tool, and complete source codes for those tools. The site is hard to navigate, you'd have to poke around to find the good stuff :-)

[redfordxx]

Hi,
I have question about appending in mkvmerge:
When I join two files in mkvmerge, is the junction smooth like there was never a break, or there will be some anomally.

Example:
*.avs with trim(0,10000) --> x264.exe --> *.mkv
will have same result as
*.1.avs with trim(0,4999) --> x264.exe --> *.1.mkv
*.2.avs with trim(5000,10000) --> x264.exe --> *.2.mkv
*.1.mkv append *.2.mkv --> mkvmerge.exe --> *.mkv

Thank you.R.

[Mosu]

It will have almost the same effect, but not really. The difference should not be noticeable though.

[vdcrim]

there will be some anomally?

If the x264 input is VFR, yes. I have noticed that x264 writes the duration of the last frame as '0' if a timecode is supplied. So if you append several VFR videos the timecodes of the final video will be like this:
0
40
80
80 <- start of the second file
120
160
200
200 <- start of the third file
240

A thing to be considered is that mkvextract doesn't include the duration of the last frame when outputing a timecode file (it's often not included in the mkv anyway), so to check this x264 bug you have to append another video and check the timecode as in the example above. Btw I filed a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691) for mkvextract.

[sneaker_ger]

What do you mean with "0"?
The timecodes are starting times, not ending times. So yes, we can't know (only guess) how long the last frame is supposed to be shown from them, but it hardly qualifies as a bug IMHO. :confused:

[Simon88]

Does anyone know if/howto make mkvtoolnix support the saving of iso 639-3 language codes for future use?

The language codes which supports language "dialects". thanx..

[sneaker_ger]

That is probably a limitation of the Matroska format, not of mkvtoolnix.

@vdcrim

Ok, I read bug 233 which implies it may be possible, so ignore my last post.
So what you are saying is that x264 doesn't do it correctly, and what you want from mkvextract is basically a feature request?

[Atak_Snajpera]

@Mosu
Is it possible to get key frame positions from mkv?
Something like this

0
24
48
67
71
95
119
143
167
191
215
239
263
287
311
335
359
383
407
431

[Mosu]

If the x264 input is VFR, yes. I have noticed that x264 writes the duration of the last frame as '0' if a timecode is supplied.

Does x264 explicitely write a BlockGroup with a Duration element set to 0 in such cases? If so then you're correct regarding how mkvmerge will calculate the timecodes.

If, on the other hand, x264 writes no duration for the last frame then mkvmerge will use the track's default duration header field.

[Mosu]

Does anyone know if/howto make mkvtoolnix support the saving of iso 639-3 language codes for future use?

The Matroska format has no header field for that piece of information. Therefore mkvmerge doesn't support it. You could only store in one of the elements suited for free-form text entry, e.g. track titles, tags or even in a text file that is then used as an attachment.

The drawback is that the information will still not be used for track selection in players (apart from the track's title which might be shown by a player).

[Mosu]

@Mosu
Is it possible to get key frame positions from mkv?

Not without parsing the whole file. If you don't have a Matroska parser then parsing mkvinfo's output is always a possibility.

Matroska files may have an index, and most do, but that index is neither mandatory nor does it have to include all key frames of all tracks.

[Mosu]

A thing to be considered is that mkvextract doesn't include the duration of the last frame when outputing a timecode file (it's often not included in the mkv anyway), so to check this x264 bug you have to append another video and check the timecode as in the example above. Btw I filed a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691) for mkvextract.

When appending Matroska files mkvextract is not used, and judging from the original poster's question he didn't plan to extract the tracks before appending.

However, I've just fixed that bug.

[Selur]

Not without parsing the whole file. If you don't have a Matroska parser then parsing mkvinfo's output is always a possibility.
does/can mkvinfo differentiate between I and IDR frames for avc content ?

[Mosu]

Matroska itself doesn't differentiate, and mkvinfo only uses information on the container level. So... no.

[vdcrim]

The timecodes are starting times, not ending times.
Well, they are just timestamps associated to frames. IMHO a timecode of a n frames video should always contain n+1 timestamps. But I don't really need it to be that way, I just wanted to point something that in my opinion is incorrect.

Does x264 explicitely write a BlockGroup with a Duration element set to 0 in such cases?

If, on the other hand, x264 writes no duration for the last frame then mkvmerge will use the track's default duration header field.


It seems the later case is more likely, sorry. I just skipped through the x264 code and the default duration for vfr matroska is indeed 0. I don't know how to check the BlockGroup though.

Edit:
Wouldn't be more appropriate to discard the default duration if it happens to be '0', and use an average FPS or the duration of the previous frame?


When appending Matroska files mkvextract is not used, and judging from the original poster's question he didn't plan to extract the tracks before appending.

I meant that checking the timecode of the file to see if I was right would be worthless as mkvextract doesn't (didn't) include the last timestamp, and that a way to circumvent this would be append another file and check its timecode instead.

[sneaker_ger]

Well, they are just timestamps associated to frames. IMHO a timecode of a n frames video should always contain n+1 timestamps. But I don't really need it to be that way, I just wanted to point something that in my opinion is incorrect.

I hear you, but I didn't think Matroska had this information in the first place. Turns out I was wrong.

[Simon88]

Hi Mosu,

I was testing some MKVs on the recently released ASUS O'Play Media Player ( http://www.asus.com/Multimedia/Digital_Media_Player/ ), which just recently supports HD 720p RMVBs. I had some HD 720p RMVBs that I converted to MKVs which will only play correctly if I used the LAV splitter on my PC.

On this device it also has issues with RMVBs muxed into MKVs (RV40/AAC-LC). I also had to run it thru ffmpeg (not re-encode) first, before the ASUS Media player would play it correctly.

It's not a big issue for me as I can remux to MKV using ffmpeg first, and afterwards use mkvtoolsnix, but I just want to let you know this particular issue and hope it can be fixed one day. thanx..

[Mosu]

Like I've written one or two pages ago RealAudio/RealMedia doesn't really have any priority for me at the moment. Maybe I'll get around to it one day, maybe I won't.

[Lincoln Burrows]

I received this message while creating a Matroska file from one MPV/AC3 and two SUP files demuxed using TSMuxer from the m2ts file decrypted from the original Blu-ray disc:

Warning: Video ended with a shortened group of pictures. Some frames have been dropped. You may want to fix the MPEG2 video stream before attempting to multiplex it.Does it mean the m2ts file is somehow corrupted?

Note: I had to use TSMuxer instead of MakeMKV for the reasons stated here:
http://www.makemkv.com/forum2/viewtopic.php?f=1&t=4353

BTW, despite this warning I mentioned above, I am watching the video with no apparent problems, so I guess it's fine.

[Atak_Snajpera]

@Mosu
I have a feeling that MKVMerge incorrectly splits mkv with VC-1 inside.

http://i.imgur.com/E6DbS.png

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

http://i.imgur.com/Gv1Uc.jpg

BTW. The same happens in FFmpegSource (http://forum.doom9.org/showthread.php?p=1551279#post1551279)
For FFMS2 I found workaround. Trim(detected keyframe-1,...)

[Liisachan]

Mosu:

I have this specific (but quite normal) AVC (x264 r2120) video in MP4 container, which causes "Assertion failed: TimecodeDelay >= int16(0x8000) && TimecodeDelay <= int16(0x7FFF), file lib/libmatroska/src/KaxCluster.cpp, line 280" if muxed with a normal-looking, stereo 48000 Hz Vorbis.ogg (aoTuV), using --timecode-scale -1.
Like:
mkvmerge -o out.mkv x264.mp4 vorbis.ogg --timecode-scale -1

The same command line works just fine if --timecode-scale 20832 is used explicitly (apparently that's what mkvmerge is trying to do for -1, though 1/48000 is 20833 ns).

The problem occurs only with a specific .mp4 file; other .mp4 files creaetd with the same version of x264 so far mux just fine with --timecode-scale -1. Also, if I transmux this.mp4 into tmp.mkv first, tmp.mkv and vorbis.ogg mux just fine as well. On the other hand, this specific AVC.mp4 doesn't mux with other vorbis files either, with --timecode-scale -1.

I'm on Windows (still XP), and the above happens with the current version (5.2.1) of mkvmerge, and also with older versions (tested v2.9.9, 3.0.0, 3.4.0, 4.0.0). With -v -r debug.log, the last message when this happens is:
Vorbis: samples_here at 246276000000 (orig -1 expected 246276000000): 128 (m_previous_samples_sum: 11821376)

The next line would have been:
Vorbis: samples_here at 246278666666 (orig -1 expected 246278666666): 128 (m_previous_samples_sum: 11821504)

I'm not normally using --timecode-scale -1 at all. This happened while I was testing that option out of curiosity.
Do you want me to upload these files in question to somewhere, maybe to your server? It's about 180 MiB.

[Mosu]

Mosu:

I have this specific (but quite normal) AVC (x264 r2120) video in MP4 container, which causes "Assertion failed: TimecodeDelay >= int16(0x8000) && TimecodeDelay <= int16(0x7FFF), file lib/libmatroska/src/KaxCluster.cpp, line 280" if muxed with a normal-looking, stereo 48000 Hz Vorbis.ogg (aoTuV), using --timecode-scale -1.
Like:
mkvmerge -o out.mkv x264.mp4 vorbis.ogg --timecode-scale -1

Yes, please upload at least the MP4 file (my server would be fine). I guess it has something to do with the distance between key frames. Normally mkvmerge can only write a cluster when all frame references are resolved, meaning that for a sequence IBBPBBI... mkvmerge will only start the new cluster after it has seen the second I frame. It will also put everything before that second I frame into the cluster (IBBPBB), even though that is not really necessary.

These are two different things: The decision which frames are ready to be written to a cluster in general, and the decision which of the frames to put into which cluster. The first one cannot be changed, but it is also not the reason for the issue at hand if I guess correctly. However, changing the second reason is kind of a lot of changes. I might decide not to fix the issues.

Anyway, I'd appreciate the upload in order to verify whether or not my assumption is correct.

The same command line works just fine if --timecode-scale 20832 is used explicitly (apparently that's what mkvmerge is trying to do for -1, though 1/48000 is 20833 ns).

Ok, this is strange. Maybe my guess is completely wrong.

BTW, 1/48000 is 20833.333333333, and in order to achieve sample-precision timestamps I decided to err on the side of caution and not only truncate that value to the nearest integer but to subtract 1 from that as well.

[Liisachan]

OK, upping td.mp4 & td.ogg; the actual command-line and output are in TimecodeDelay-assert.txt. ETA a few minutes.

I guess it has something to do with the distance between key frames.
Though my x264 settings are quite conservative in this case (--fps 24000/1001 --keyint 240 --bframes 5 --ref 6). It's 8-bit and CFR too.

Ok, this is strange. Maybe my guess is completely wrong.
mkvmerge is happy with --timecode-scale 1000 or 100 or 10 or even 1 (Docs say the min valid value is 1000, but it accepts and actually handles lower values too). Doesn't look like a simple arithmetic overflow. There might be a glitch in handling -1, something un-auto-magical. Like, the variable size becomes 32- or even 64-bit when you do --timecode-scale with a small value explicitly, but always 16-bit if -1 is given, maybe?

BTW, 1/48000 is 20833.333333333, and in order to achieve sample-precision timestamps I decided to err on the side of caution and not only truncate that value to the nearest integer but to subtract 1 from that as well.
Thought so. That's fine with me :)

[Mosu]

@Liisachan: Thanks for the files. As my time is really limited at the moment I've decided to open a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=707) for it so I don't forget about it.

[Mosu]

@Mosu
I have a feeling that MKVMerge incorrectly splits mkv with VC-1 inside.

Thanks for the test file. At the moment I only have access to my laptop which is not able to play HD video. Therefore I cannot test this properly. I'll try to take a look at it over the weekend.

[Mosu]

Hi Mosu,

I just uploaded two low resolution very recent broadcast/over the air TV captures to your ftp server.

Thanks for the files. As you can probably see in some of the other answers I don't really have the time to look into this. But in order not to forget about it I've created a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=708) for this issue.

[Simon88]

Thanks for the files. As you can probably see in some of the other answers I don't really have the time to look into this. But in order not to forget about it I've created a bug report (https://www.bunkus.org/bugzilla/show_bug.cgi?id=708) for this issue.

Thanks for looking into the RV/cook issues inside MKVs.

btw, earlier today, RealNetworks just sold and licensed most of there "precious" audio/video/streaming patents to Intel for $120 mil... hope Intel will open up / make the format less restrictive.. as Intel intend to use it for streaming on phones, tablets, media players...

[Liisachan]

Thanks, Mosu.

Now I have another question. I'm still doing this x264+vorbis business, and now mkvalidator emits "ERR0C2: The timecode of the Cluster at ... is not incrementing". I didn't get this error before. Is this something I can safely ignore?
The actual internal is like this.

—Cluster (4+3+240028 0x114aa01)
——Timecode (1+1+ 3 0x0114aa08): 85002 <--scale is default
——SimpleBlock (1+2+ 1462 0x0114aa0d): #2A 0:01:25.164000000 ( 162) Xiph lacing
——SimpleBlock (1+2+ 6719 0x0114afc6): #1V [0:01:25.168000000] ( 166) P Frame2042
——SimpleBlock (1+2+ 6319 0x0114ca08): #1V [0:01:25.085000000] ( 83) B 2040D
——SimpleBlock (1+2+ 770 0x0114e2ba): #1V [0:01:25.002000000] ( 0) b 2038D
——SimpleBlock (1+2+ 1569 0x0114e5bf): #1V [0:01:25.043000000] ( 41) b 2039
...
——SimpleBlock (1+1+ 90 0x01185099): #1V [0:01:30.007000000] ( 5005) B 2158D
——SimpleBlock (1+1+ 92 0x011850f5): #1V [0:01:29.923000000] ( 4921) b 2156D
——SimpleBlock (1+1+ 64 0x01185153): #1V [0:01:29.965000000] ( 4963) b 2157
——SimpleBlock (1+1+ 46 0x01185195): #1V [0:01:30.048000000] ( 5046) b 2159
——SimpleBlock (1+2+ 250 0x011851c5): #1V [0:01:30.132000000] ( 5130) P 2161
——SimpleBlock (1+2+ 223 0x011852c2): #2A 0:01:30.152000000 ( 5150) no lacing

—Cluster (4+2+215 0x11853a4)
——Timecode (1+1+ 3 0x011853aa): 90173
——SimpleBlock (1+2+ 207 0x011853af): #2A 0:01:30.173000000 ( 0) no lacing

—Cluster (4+3+61497 0x1185481)
——Timecode (1+1+ 3 0x01185488): 90173 <-- This?!
——SimpleBlock (1+3+ 18860 0x0118548d): #1V [0:01:30.173000000] ( 0) I 2162K
——SimpleBlock (1+2+ 1625 0x01189e3d): #2A 0:01:30.195000000 ( 22) Xiph lacing
——SimpleBlock (1+2+ 1631 0x0118a499): #2A 0:01:30.365000000 ( 192) Xiph lacing
——SimpleBlock (1+2+ 160 0x0118aafb): #1V [0:01:30.424000000] ( 251) P 2168
——SimpleBlock (1+1+ 53 0x0118ab9e): #1V [0:01:30.299000000] ( 126) B 2165D
——SimpleBlock (1+1+ 67 0x0118abd5): #1V [0:01:30.215000000] ( 42) b 2163D
——SimpleBlock (1+1+ 26 0x0118ac1a): #1V [0:01:30.257000000] ( 84) b 2164
——SimpleBlock (1+1+ 22 0x0118ac36): #1V [0:01:30.340000000] ( 167) b 2166
——SimpleBlock (1+1+ 28 0x0118ac4e): #1V [0:01:30.382000000] ( 209) b 2167
——SimpleBlock (1+2+ 1627 0x0118ac6c): #2A 0:01:30.536000000 ( 363) Xiph lacing

Format: <id> (<size of id>+<size of size>+<size of data> 0x<pos>)
#1V = track 1 x264 video; #2A = track 2 vorbis audio; K = Keyframe flag; D = Discardable flag

[Mosu]

Thanks, Mosu.

Now I have another question. I'm still doing this x264+vorbis business, and now mkvalidator emits "ERR0C2: The timecode of the Cluster at ... is not incrementing". I didn't get this error before. Is this something I can safely ignore?

Short answer: yes.

Long answer: Matroska's timecodes are stored as 16bit signed integer numbers in the SimpleBlock and BlockGroup elements. These are relative to the ClusterTimecode element. Their scale is the global TimecodeScale. Now if you're using sample precision then TimecodeScale is pretty low which, in turn, means that those 16 bit signed integer values only account for a limited range of timecodes. For example, at a sampling frequency of 48000 Hz TimecodeScale is probably 20835 (meaning that the value "1" stored in ClusterTimcode would be "20 ns 835 usecs"). 16 bit signed integers = max 32767 (mkvmerge does not use negative relative timecodes) which corresponds to a maximum cluster length of 32767 * 20835 usec = roughly 682.6 msecs.

Now combined with video B frames it's clear that the timecode of cluster n+1 might not always be higher than that of cluster n.

mkvvalidator probably doesn't account for this.

[Liisachan]

Thanks for quick reply. I'll just ignore this error then. Also, mkvalidator emits the same error for some of my old mkv files too; so this was nothing new at all.

The TimecodeScale in above sample is default (1 ms; that's what I meant by "scale is default"), so your long answer may not be applicable in this case, though. I gave up tweaking the timecode scale already, because if I do VLC can't handle subtitle tracks (their bug--nothing to do with mkvtoolinx).
I wanted to use slightly finer scale (0.1 ms), because for example if video is 30-fps, some frames are 33 ms and other frames are 34 ms in MKV, implying about 3% fluctuation or un-smoothness, at least in theory. This 3%-ish may be unnoticeable in reality, but I've been always unsure about it. Using 0.1 ms time-scale "just in case" only increases the file size by a few KiB, so I figured it was a good trade-off even for placebo happiness by thinking "now this is more accurate"... until I tested it on VLC.

[Snowknight26]

mkvmerge outputs an mkv with mangled timestamps when remuxing this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample; eac3to, on the other hand, does not.

[Selur]

startingt with a test.avi file (xvid+mp3)
I created a (xvid+pcm) mkv file by:
1. extract audio as pcm:
mplayer -aid 1 -msglevel statusline=5:all=0 -mc 0 -hardframedrop -vc dummy -nocorrect-pts -aid 1 "G:\Hybrid\test.avi" -vo null -ao pcm:fast:waveheader:file=""""D:\Encoding Temp\test__aid_1__11_22_56_221_01.wav""""
2. mux audio&video to mkv:
mkvmerge --ui-language en -o "D:\Encoding Output\test.mkv" -d 0 --default-track 0:yes --default-duration 0:25fps --aspect-ratio-factor 0:1 --no-chapters --forced-track 0:yes --no-audio --no-subtitles "G:\Hybrid\test.avi" --default-track 0:yes --forced-track 0:no -a 0 --no-video --no-subtitles --no-chapters "D:\Encoding Temp\test__aid_1__11_22_56_221_01.wav"

looking at the file with:
mkvinfo "D:\Encoding Output\test.mkv"
everything looks fine:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 8147739
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4045)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.2.3 + libmatroska v1.3.0
| + Writing application: mkvmerge v5.2.1 ('A Far Off Place') built on Jan 7 201
2 21:56:27
| + Duration: 17.160s (00:00:17.160)
| + Date: Sat Feb 04 10:23:01 2012 UTC
| + Segment UID: 0x98 0xf0 0x5c 0x48 0x26 0x7a 0x36 0x4a 0x96 0x9f 0xce 0x9e 0x2
7 0x24 0x89 0x32
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3165394818
| + Track type: video
| + Forced flag: 1
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MS/VFW/FOURCC
| + CodecPrivate, length 40 (FourCC: XVID, 0x44495658)
| + Default duration: 40.000ms (25.000 fps for a video track)
| + Language: und
| + Video track
| + Pixel width: 640
| + Pixel height: 352
| + Display width: 640
| + Display height: 352
| + A track
| + Track number: 2
| + Track UID: 2416414350
| + Track type: audio
| + Codec ID: A_PCM/FLOAT/IEEE
| + Default duration: 31.250ms (32.000 fps for a video track)
| + Language: und
| + Audio track
| + Sampling frequency: 48000
| + Channels: 2
| + Bit depth: 32
|+ EbmlVoid (size: 1081)
|+ Cluster
and playback is fine also.
Now I wanted to extract the audio again with:
mkvextract tracks "D:\Encoding Output\test.mkv" 1:"D:\Encoding Temp\test2__aid_0__11_23_20_911_01.wav"
but ended up with:
Error: Extraction of track number 1 with the CodecID 'A_PCM/FLOAT/IEEE' is not supported.

-> bug? missing feature? or stupid user?

Cu Selur

[Mosu]

Missing feature.

[Selur]

Okay, thanks for the info. (save me the hassle of looking for a problem on my end :))

[73ChargerFan]

7 0x24 0x89 0x32
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 3165394818
| + Track type: video
.....
.....
| + A track
| + Track number: 2
| + Track UID: 2416414350
| + Track type: audio

??? You're asking to extract the video track as a wav file ???

[Selur]

No th auidio track, since the content is pcm audio, raw pcm or wav seem like a normal choice.

[sneaker_ger]

??? You're asking to extract the video track as a wav file ???

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#mkvmerge_mkvextract_mkvinfo_track_ids

[Mosu]

Hey,

I've released mkvtoolnix v5.3.0. It contains bug fixes all over the board: DTS handling, (E)AC3 detection, invalid memory access with certain broken files and more. mkvmerge's verbose identification mode has been extended with a couple more fields. mkvmerge can treat several separate input files as if they were concatenated into a single large file (e.g. VOBs or MPEG transport streams). The documentation has been updated accordingly.

There were no changes that concern package maintainers.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.3.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.3.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.3.0.7z

All of the Linux binaries that I provide have already been built and are available.

Here's the full ChangeLog since release 5.2.1:


2012-02-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.3.0.

2012-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will parse and apply the audio encoder delay in MP4 files that contain said information in the format that iTunes writes it. Fix for bug 715 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=715).

2012-02-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Implemented support for treating several input files as if they they had been concatenated binarily into a single big input file. Snytax is "mkvmerge -o out.mkv ( in1.ts in2.ts in3.ts )". This feature has already been present since version 5.1.0 but never been mentioned in the ChangeLog. Support for this feature in mmg is still missing.

2012-01-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Blocks with "BlockAdditions" will no longer be muxed as "SimpleBlock" elements discarding the additions but instead as "BlockGroup" elements. This applies to e.g. WAVPACK4 tracks with correction files as the correction data is stored in "BlockAdditions". Fix for bug 713 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=713).
* mkvmerge: bug fix: Fixed some more issues with (E)AC3 being misdtected as AVC elementary streams.

2012-01-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The header editor was sometimes creating two instances of an element if an element was added to the second or one of the later tracks. Fix for bug 711 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=711).
* mkvpropedit, mmg: bug fix: Trying to modify a file located in a path mounted with GVFS SFTP will no longer crash the programs. Instead an error message is output if an error occurs. Fix for bug 710 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=710).

2012-01-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed integer underflows in the read caching code resulting in invalid memory access. Happened in broken or incomplete files only. Fix for bug 709 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=709).

2012-01-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Appending AVI, Matroska or MPEG program stream files with DTS audio tracks will not result in a warning that the appended DTS tracks might not be compatible. Fix for bug 705 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=705).

2012-01-13 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix for the "timecodes_v2" mode: mkvextract will write one more timecode than there are frames in the file. The last timecode written will be the the sum of the last frame's timecode and duration with the "last frame" being the one with the highest timecode. Fix for bug 691 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=691).

2012-01-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed writing into paths on which a drive is mounted on Windows. Fix for bug 701 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=701).
* mkvmerge: enhancement: Identification output for Matroska files: Added the track number header field as "number" to the verbose identification mode.

2012-01-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Identification output for Matroska files: Added a field "content_encoding_algorithms" that contains a comma-separated list of encoding algorithm IDs used for that track. For example, "content_encoding_algorithms:3" would indicate that header removal compression is used.

2012-01-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Identification output for Matroska files: Added several fields to mkvmerge's verbose identification mode for tracks: UID, CodecID, length and content (as a hex dump) of the codec private data.
* mkvmerge: bug fix: Fixed a segmentation fault in the DTS detection code. Fix for bug 698 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=698).

2012-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The track IDs used in the "timecodes_v2" extraction mode are consistent again with the IDs that mkvmerge's identification reports and that mkvextract's "tracks" extraction mode uses. Fix for bugs 689 and 694.

2012-01-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added video pixel dimensions to the output of "--identify-verbose" for Matroska files.

Have fun.

[Selur]

Nice! Thanks!

[b66pak]

thanks a lot...
_

[Chumbo]

Nice big update. :) Thanks a lot.

[Sparktank]

Wonderful! Thanks for the update :D

[73ChargerFan]

http://www.bunkus.org/videotools/mkvtoolnix/faq.html#mkvmerge_mkvextract_mkvinfo_track_ids
I sort of follow that, and have read this thread for years. The documentation does say that track numbers will correspond between mkvinfo & mkvextract for the same release.

In the post I commented on, above mkvinfo has a string "track number: 1" which is labeled video, and later in the same message mkvextract states "cannot extract track number 1 as audio".
So I think his command to mkvextract is incorrect.

I am even more grateful now to sheck for mkvcleaver.

[73ChargerFan]

Thank you Mosu for the update!

[sneaker_ger]

I sort of follow that, and have read this thread for years. The documentation does say that track numbers will correspond between mkvinfo & mkvextract for the same release.

In the post I commented on, above mkvinfo has a string "track number: 1" which is labeled video, and later in the same message mkvextract states "cannot extract track number 1 as audio".
So I think his command to mkvextract is incorrect.

No. In mkvinfo you only see the "TrackNumber", while mkvextract is using the "Track ID". The former is hard-coded into the file, the latter is made up by mkvmerge and mkvextract. They do not necessarily correspond, but for older mkvtoolnix versions they did.

"cannot extract track number 1 as audio" actually means "cannot extract track with TrackID 1 as audio". Maybe that should be changed to avoid confusion.