View Full Version : mkvtoolnix 4.1.1 released
MADAJ
12th May 2009, 21:17
Hi, I am running Win XP SP3 (English)
http://www.zshare.net/download/59931524d49ddde4/ the log
thanks
Thanks, that helped. I'll fix this until the weekend.
Keiyakusha
13th May 2009, 01:23
Mosu
Little bugreport:
If I Start mkvmerge GUI -> Start Header Editor -> Change/add/delete some UID -> save file -- then I can't change/add/delete any UID again and I must restart Header editor.
Little suggestion:
Maybe it will be good to have a small button for generating random UID if we want to change/add one.
EDIT: now, after few UID editings in one file, I have this error:
http://www.petaimg.com/u447/11013.05.png
Mosu
Little bugreport:
If I Start mkvmerge GUI -> Start Header Editor -> Change/add/delete some UID -> save file -- then I can't change/add/delete any UID again and I must restart Header editor.
That was a known error in v2.7.0. Please upgrade to v2.8.0.
Little suggestion:
Maybe it will be good to have a small button for generating random UID if we want to change/add one.
Good idea.
EDIT: now, after few UID editings in one file, I have this error:
http://www.petaimg.com/u447/11013.05.png
If you enter invalid data (e.g. if you enter text instead of a number for a header field that expects a number) then you get this message. For UIDs there are actually more rules:
1. An UID must be 128 bits long. The input field shows hex digits (0-9, A-F). Each hex digit represents 8 bits, therefore you have to enter exactly 16 hex digits.
2. I'm not quite sure about the formats that are recognized, but I think you can either prefix hex digits with "0x" or leave it; you can use spaces between hex digit pairs, but not between single digits -- but I may be wrong there; it could be that I've already made the parser less strict.
TheFluff
13th May 2009, 12:50
I found a "bug" the other day while experimenting with a semi-automated split-and-merge script I was writing, although I guess it's less a bug than it is a "don't do that".
Anyway, if you try to use mkvmerge to split at timecode 00:00:00.000, it will happily accept the timecode and sure enough it'll generate two splitted files. The first one turns out to be about 10kB and can't be read by mkvmerge (says "failed to read the headers"). It does appear to contain _something_ but I'm not man enough to figure out what.
Keiyakusha
13th May 2009, 14:58
That was a known error in v2.7.0. Please upgrade to v2.8.0.
Oops, you right. I reinstalled the latest 2.8.0 and it works fine. First time I installed it to the MeGui/tools directory, but some files was not replaced.
If you enter invalid data (e.g. if you enter text instead of a number for a header field that expects a number) then you get this message. For UIDs there are actually more rules:
Well, maybe I made some typo when entering UDI and not noticed this.
Sorry about that. Next time I will recheck a few times more before posting.
I found a "bug" the other day while experimenting with a semi-automated split-and-merge script I was writing, although I guess it's less a bug than it is a "don't do that".
Anyway, if you try to use mkvmerge to split at timecode 00:00:00.000, it will happily accept the timecode and sure enough it'll generate two splitted files. The first one turns out to be about 10kB and can't be read by mkvmerge (says "failed to read the headers"). It does appear to contain _something_ but I'm not man enough to figure out what.
Interesting :) Maybe I'll add a check that prevents mkvmerge from writing empty files; the easiest solution would be to make sure at least one frame is written to a file before starting a new one.
Oops, you right. I reinstalled the latest 2.8.0 and it works fine. First time I installed it to the MeGui/tools directory, but some files was not replaced.
Ok :)
Well, maybe I made some typo when entering UDI and not noticed this.
Sorry about that. Next time I will recheck a few times more before posting.
No problem at all; I know that the error message is very generic and not helpful if the user doesn't know all the details of the Matroska header structure. I will likely improve the error messages in the future.
hi, when I import a video source, I get this message.
http://img11.imageshack.us/img11/8864/imagekar.jpg
This problem should be fixed in builds 128 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/
Snowknight26
14th May 2009, 03:13
When you add a file twice and you remove the second file, the Remove all button stays disabled.
When you add a file twice and you remove the second file, the Remove all button stays disabled.
This problem should be fixed in builds 129 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/
MADAJ
14th May 2009, 22:50
This problem should be fixed in builds 128 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/
thanks a lot :D
Snowknight26
17th May 2009, 05:44
Any word on FLAC parsing showing 100% twice or is that a non-issue?
I don't consider that important, therefore I will or will not fix it. It is only a visual glitch.
vwpassion
17th May 2009, 23:49
I noticed Vobsubs get compressed when muxing them into the mkv, does image quality get degraded as well, or how does the compression work?
Extra track compression inside Matroska files is done with lossless compressors. The available choices are zlib (the algorithm behind "gzip"; good compromise between speed and compression ratio), bzlib (the algorithm behind "bzip2"; slow but very good compression ratio) and lzo v1 or v2 (very fast but poorer compression ratio). Of those three only the zlib algorithm is widely supported by playback applications; therefore mkvmerge/mmg default to zlib.
vwpassion
18th May 2009, 10:51
Great, thanks.
Hey,
I've released mkvtoolnix v2.9.0. New features include support for chapters in MP4 files, a translation to Chinese Traditional and support for MPEG-1/-2 video in AVI files. Improvements were made to the MPEG program stream and VobSub handling code. Fixed bugs include several segfaults, crashes in the header editor and mmg always reporting that adding files has failed with a return code of 1 on certain Windows systems. Audio/video synchronization for the native MPEG-4 storage mode has been fixed.
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-2.9.0.tar.bz2
...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.9.0-setup.exe
The binaries I provide myself have all been built and uploaded already.
Here's the full ChangeLog since release 2.8.0:
------------------------------------------------------------
2009-05-22 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.0.
2009-05-17 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation to Traditional Chinese by Dean Lee (see AUTHORS).
* mkvmerge: bug fix: mkvmerge was not handling dropped frames well when converting from VfW-mode MPEG-4 part 2 to native mode MPEG-4 part 2 (with '--engage native_mpeg4'). This resulted in timecodes being to low which in turn resulted in the loss of audio/video synchronization. Fix for bug 236.
2009-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The modes 'chapters', 'cuesheet' and 'tags' did not honor the '--redirect-output' option and where always writing to the standard output.
* mkvmerge: new feature: Added a hack ('vobsub_subpic_stop_cmds') that causes mkvmerge to add 'stop display' commands to VobSub subtitle packets that do not have a duration field. Patch by Todd Schmuland (see AUTHORS).
2009-05-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Changed how mmg sets the output file name automatically if the option is enabled. If the user adds more than one file then the output file name is set each time a file is added and not only when the first one is unless the user has changed the output file name manually. Fix for bug 229.
2009-05-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Improved support for QuickTime audio tracks with version 2 of the STSD sound descriptor.
* mmg: bug fix: The "remove all" button was sometimes disabled even though there were still files left to be removed.
* mkvmerge: enhancement: The MPEG program stream reader will now detect invalid padding packets and skip only to the next 2048 byte packet boundary instead of skipping several good packets. Patch by Todd Schmuland (see AUTHORS).
* mmg: enhancement: The "no chapters" checkbox can now be used for QuickTime/MP4 files and OGM files as well.
* mkvmerge: enhancement: The OGM reader will only print the warning that no chapter charset has been set by the user if the title or the chapter information contained in the OGM file is actually used and not overwritten with '--title ...' or '--no-chapters'.
2009-05-13 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The VobSub extraction was made more compatible with most applications. Fix for bug 245. Patch by Todd Schmuland (see AUTHORS).
* mkvmerge: bug fix: Fixed support for Windows systems that use code pages that are not supported by the iconv library (e.g. code page 720). mkvmerge was exiting with warnings causing mmg to report that file identification had failed. Fix for bug 376.
2009-05-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for handling MPEG-1/-2 video in AVI files. Fix for bug 388.
2009-05-11 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Global variables are deconstructed in a pre-defined way no longer causing segfaults when the programs are about to exit.
* mkvmerge: enhancement: Implemented small speedups for some common memory operation (affects e.g. the MPEG program stream parser).
* mkvmerge: bug fix: Fixed potential and actual segmentation faults occuring when appending VC-1 video tracks, Dirac video tracks and DTS audio tracks.
2009-05-10 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The header and chapter editors will no longer crash the application if the user wants to open a file that's locked by another process and show an error message instead.
* mkvmerge: enhancement: Invalid VobSub packets whose internal SPU length field differs from its actual length are patched so that the SPU length field matches the actual length. This fixes playback issues with several players and filters. Fix for bug 383.
* mkvmerge: new feature: Added support for reading chapters from MP4 files. Fix for bug 385.
------------------------------------------------------------
Have fun.
b66pak
22nd May 2009, 18:25
thanks...
_
Liisachan
22nd May 2009, 22:06
Fixed support for Windows systems that use code pages that are not supported by the iconv library (e.g. code page 720).
Is that even possible? I mean CP720 is an OEM CP (MS-DOS) for Arabic, not "ANSI" CP (Windows). If the default Windows language for non-Unicode is Arabic, ANSI-to-Unicode conversion is from CP1256 isn't it?
And what exactly do you mean "fixed"? Does mkvtoolnix have its own conversion table for CP720 now? Well, all you need for that is, at worst, a 256-member array of uint16_t so it's cheap, but it was a tedious work to type that manually, wasn't it :) ?
Thanks again for your hard work anyway~
Is that even possible? I mean CP720 is an OEM CP (MS-DOS) for Arabic, not "ANSI" CP (Windows). If the default Windows language for non-Unicode is Arabic, ANSI-to-Unicode conversion is from CP1256 isn't it?
My tools use both the normal code page returned by GetACP() and the OEM code page returned by GetOEMCP(). The former is used for everything displayed in GUIs while the latter is the default for everything output to the console (e.g. mkvmerge's and mkvinfo's output) unless overridden with "--output-charset".
The problem was that the tools output a warning if the iconv library cannot be initialized for a specific code page. The tools derive iconv's name for a code page like this: The string "CP" followed by the number returned by GetACP() and GetOEMCP(). For code page 720 (which is the one returned by GetOEMCP() in this case) iconv doesn't know a code page named "CP720" even though it does know one called "MS-ARAB". I don't know if "MS-ARAB" is identical to "CP720"; I've solved the issue differently.
And what exactly do you mean "fixed"? Does mkvtoolnix have its own conversion table for CP720 now? Well, all you need for that is, at worst, a 256-member array of uint16_t so it's cheap, but it was a tedious work to type that manually, wasn't it :) ?
No :) My tools now use a two-tiered strategy for charset conversion: First, try iconv. If that doesn't work use Windows' own MultiByteToWideChar() and WideCharToMultiByte() functions. On non-Windows systems only iconv is used even though similar functions like the ones Windows provides are available (mbstowcs() etc). However, I've never heard of iconv not working correctly or not providing all neccessary tables on non-Windows systems, so there's no need to change this at the moment.
buzzqw
23rd May 2009, 07:18
thanks Mosu!
(suggestions: edit title of thread AND change link in first post! these link to 2.0.0!)
BHH
Any word on when we will be able to mux .sup files to MKV? This is probably the only feature that is missing in my list of how awesome mkv is. ;)
It will be ready when it's ready. I don't have an ETA.
Liisachan
23rd May 2009, 23:16
Thank you for the explanation about OEM CP, Mosu. That makes sense and calling Windows API when iconv doesn't work is a good idea~
Not sure if it is a bug... maybe it is a feature :)
Right, so if I have several AAC files and I want to merge them into one mkv/mka, I have found the following:
if all files are not checked as SBR/AAC+ then all is OK
if all files are checked as SBR/AAC+ then muxing fails with error
if first file is checked and the rest is not, it still fails
if first file is unchecked and the rest are, it works :)
I'm not certain if that particular AAC is SBR or not, it seems to work as normal in mkv with the option unchecked. All the fragments are from the same AAC so should have same parameters.
As well, have you changed anything about append/delay logic for at least AAC files in the 2.9.0 version? It seems I have got a bit different result in 2.9.0 version compared to one of the latest builds of 2.8.0 (it terms of audio/video sync).
Not sure if it is a bug... maybe it is a feature :)
Right, so if I have several AAC files and I want to merge them into one mkv/mka, I have found the following:
if all files are not checked as SBR/AAC+ then all is OK
if all files are checked as SBR/AAC+ then muxing fails with error
if first file is checked and the rest is not, it still fails
if first file is unchecked and the rest are, it works :)
Cute :) Can you please upload the first 5 MB of each file to my FTP server? Also please save the mmg settings to a settings file ("File" -> "Save settings") and upload that file as well.
As well, have you changed anything about append/delay logic for at least AAC files in the 2.9.0 version? It seems I have got a bit different result in 2.9.0 version compared to one of the latest builds of 2.8.0 (it terms of audio/video sync).
I don't recall any changes to the A/V muxing code.
It is done. (i.e. uploaded to your ftp).
Regarding potential muxing problems -- it is not A/V sync per se, it is just in two very similar cases with the same four fragments of AAC I got different result in terms of audio/video sync in the muxed file. In the first case it was a draft xvid copy (again four fragments) as a video track, in the second one it was mp4 h264. First copy was done several days ago with 2.8.0 build, the second one was made yesterday. There could be several reason why a/v is different now, so I'll try to recreate both cases and compare.
Right, there's something strange between two different files.
However it is proven not to be related to the version change. I'll dig deeper and try to find out what could be wrong.
As for another feature, it seems older installer (2.8.0-132) performed successfully and offered to launch 2.8.0 :) All is nice but a minor detail -- it didn't overwrite any of the files in the main folder so inplace updowngrade didn't work it seems :P
I cannot reproduce your problem with mkvmerge failing if all tracks are marked as being SBR. In fact I cannot get it to fail no matter what combination I use. Sorry, cannot help you at the moment.
rack04
26th May 2009, 22:04
Does mkvtoolnix accept Sony wave64 audio streams?
frank
28th May 2009, 10:36
I use MKVextractGUI 1.6.4.1 to extract and save the chapterfile (OGM).
But the last working version for MKVextractGUI is MKVtoolnix v2.6.0
:(
Something was changed with the mkv parameters.
Any solution?
System: Win XP SP3
mkvextractGUI is not one of my programs and I don't support it. Maybe someone else knows a solution. I will also not change mkvextract to work around problems in the GUI.
clavelm
28th May 2009, 15:33
* mkvmerge: new feature: Added support for reading chapters from MP4 files. Fix for bug 385.
Lot's of :thanks: for that feature, I'm remuxing all mp4 to mkv, and for mp4 with chapters, I had to demux it to ogm chapter with yamb, then add it to the mux.
It's going to be so much faster !!
mark0077
28th May 2009, 21:14
Hi all,
I have recently started using makemkv to convert all of my TV Show's (originally dvd's) to mkv files. I notice when playing these mkv files that the aspect ratio is wrong on very many of these files. I have two questions for you mkv experts.
1) Is makemkv known for this behaviour
2) When I remux using mkvtoolnix, the output file also plays at the incorrect aspect ratio (16:9 playing with black bars top and bottom but original disks don't show this).
Thanks guys, bit confused and annoyed now because many of my old star trek tng disks got damaged overtime and my hdd copies are now deleted since I converted to mkv. I hope theres a way to get them all back to the right aspect ratio. I am using mpc-hc and media player to playback files with haalis matroska splitter.
rack04
28th May 2009, 21:28
Hi all,
I have recently started using makemkv to convert all of my TV Show's (originally dvd's) to mkv files. I notice when playing these mkv files that the aspect ratio is wrong on very many of these files. I have two questions for you mkv experts.
1) Is makemkv known for this behaviour
2) When I remux using mkvtoolnix, the output file also plays at the incorrect aspect ratio (16:9 playing with black bars top and bottom but original disks don't show this).
Thanks guys, bit confused and annoyed now because many of my old star trek tng disks got damaged overtime and my hdd copies are now deleted since I converted to mkv. I hope theres a way to get them all back to the right aspect ratio. I am using mpc-hc and media player to playback files with haalis matroska splitter.
I wonder if the header editor will allow you to change the aspect ratio. That would be the first place I would look.
mark0077
28th May 2009, 21:33
I wonder if the header editor will allow you to change the aspect ratio. That would be the first place I would look.
See I remuxed with aspect ratio 16:9 (it was set to "Resolution" 1024 x 576) but this didn't seem to have any effect. The new file played at the same incorrect AR. Any help would be great. I have a massive list of episodes that play all squashed... Damn you makemkv lol
rack04
28th May 2009, 21:40
See I remuxed with aspect ratio 16:9 (it was set to "Resolution" 1024 x 576) but this didn't seem to have any effect. The new file played at the same incorrect AR. Any help would be great. I have a massive list of episodes that play all squashed... Damn you makemkv lol
What is the correct resolution?
mark0077
28th May 2009, 21:52
Well I tried setting it to 720 * 576 because ffdshow osd output shows the original disk as
Original DVD Reports
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 64/45, DAR: 16/9
Converted to mkv with makemkv Reports
Input: Resolution: 720 x 576, SAR: 64/45, DAR 16/9
Output: SAR: 256/135, DAR: 64/27
mkvtoolnix Reports
Resolution: 1024 X 768
so to get 1024 x 576 makemkv must have multiplied the SAR by the resolution. I assume this is correct but... maybe not for DVDs. I know lots of (if not most) DVD's have both some sort of badly written aspect ratio flags and interlaced flags.
Maybe makemkv doesn't correct this as I know most video renderers do this correction automatically on DVD's without us noticing so maybe in my situation the renderer isn't recognizing a DVD and hence not doing the correction for me.
Note: I am not using ffdshow for any AR changes, resizing etc, just passing through to see OSD.
rack04
28th May 2009, 21:55
Well I tried setting it to 720 * 576 because ffdshow osd output shows the original disk as
Resolution: 720 x 576, SAR: 64/45, DAR 16/9
so to get 1024 x 576 makemkv must have multiplied the SAR by the resolution. I assume this is correct but... maybe not for DVDs. I know lots of (if not most) DVD's have both some sort of badly written aspect ratio flags and interlaced flags.
Maybe makemkv doesn't correct this as I know most video renderers do this correction automatically on DVD's without us noticing so maybe in my situation the renderer isn't recognizing a DVD and hence not doing the correction for me.
Is the video format AVC? If so does the stream contain VUI parameters? Can you post a sample?
Inspector.Gadget
28th May 2009, 21:57
1024x576 is the correct frame size for 16:9 PAL discs. They are stored on DVD as 720x576 and stretched on playback to display as 1024x576. Since this information is generally coded into the video stream itself, a remuxing app like MakeMKV shouldn't screw up the display size. When importing MPEG-2 video or a MakeMKV-created MKV containing it into mkvmerge, don't set any display size flags. If the display isn't correct in the resulting MKV, demux the video stream with MKVExtract and verify that there isn't some problem particular to it rather than the container.
Just a short note from myself. First, this is not a "makemkv" support thread. Please keep it on topic (the mkvtoolnix package consisting of mmg, mkvmerge, mkvinfo and mkvextract). Thanks.
Second, mkvmerge only (!) extracts the aspect ratio if the source file is not a Matroska file that already has display width/height set (e.g. if you mux from AVI or MP4 files or if you mux from a Matroska file that does NOT contain display width/height fields). This is intentional; the idea is to respect the user's wishes. If the source contains display width/height then the user wanted them set and mkvmerge should not change this automatically unless stated otherwise.
Third, yes, you can use the header editor to change/add the values for display width/height without having to remux.
mark0077
28th May 2009, 22:03
Is the video format AVC? If so does the stream contain VUI parameters? Can you post a sample?
Its just mpeg2 and some stereo audio. Its my first time attempting to convert some of my content to mkv (mostly to have tv show episodes appear correctly in xbmc) but I would have thought the conversion processes wouldn't do this.
Any suggestions would be fantastic. I agree, makemkv shouldn't have and probably didn't touch the original mpeg2, as converting entire DVD's took a very short amount of time.. I just wonder "who's" fault was it to have all of these episodes now playing at the incorrect AR. Ill try to see what the values of the flags are in the mpeg2 stream... if thats not too difficult :P
mkvinfo says
Pixel width: 720
Pixel height: 576
Display height: 576
Display width: 1024
which looks right. Ill try the header editor to see what changes "fix" the problem.
EDIT: Looks like a bug in ffdshow, using its internal decoders the problem happens, using mpc-hc decoder it doesn't. Thanks all, some excellent tools you have here.
Snowknight26
29th May 2009, 06:36
I recently remuxed an MP4 file to MKV but I noticed that whenever I played it, switching audio tracks would cause the video to stutter. As I was cutting a sample of that newly created MKV file, I noticed that mkvmerge gave me hundreds of these warnings:
Warning: 'G:\source.mkv' track 3: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 256ms in order not to lose any data. This may throw audio/video synchronization off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>.
The ms seemed to vary between 224ms and 256ms. I'm thinking its a bug considering what the message says, but I don't know what I files (cut if anything) I should be uploading for analysis. MP4 source? MKV remux? split MKV sample?
The MP4 file, but don't expect a quick fix, please.
TheFluff
29th May 2009, 20:16
Here's a really bizarre bug (not sure if it's in mkvmerge or in something else) that I've been seeing for some time.
If you mux an ASS or SSA subtitles file to MKV with the subtitle lines not ordered by start time, and use VSFilter to render it when playing the MKV file, you get at least two bizarre effects.
1) Overlapping lines that not in start time order in the input file get a lot brighter and the alpha masking seems to break in one way or another.
2) If you use animated effects, lines that are not ordered by start time in the input file get rendered several orders of magnitude slower than they otherwise do.
These problems appear regardless of what splitter you use; I tried both Haali's splitter (latest version) and MPC-HC builtin one (Gabest's?). They only appear when the subtitle file is muxed into an MKV; they do not appear when you use the file in any other way (such as hardsubbing it on the video using VSFilter in Avisynth, or letting it autoload an external subtitles file).
Both issues magically go away if you use a subtitle editor to order lines by start time before muxing. Which is absolutely bizarre, because I know mkvmerge does the EXACT SAME THING when you mux; I even used a hex editor to confirm this (the lines ARE ordered by start time in the MKV file; of course with a marker that notes the line's original position in the input file).
I made a small example demonstrating bizarre effect #1 mentioned above, in case you need it. Can be found at http://www.mod16.org/testfiles/subtitlebork/
The question is, is this a bug in VSFilter? If so, why does it happen? It should get the lines in the correct order regardless of whether the input is sorted or not, and it doesn't happen when using an external file. Does the splitter hand it the lines differently? If so, why does it break with two different splitters? Or is it a bug in the way the subtitles are muxed to mkv?
Both issues magically go away if you use a subtitle editor to order lines by start time before muxing. Which is absolutely bizarre, because I know mkvmerge does the EXACT SAME THING when you mux; I even used a hex editor to confirm this (the lines ARE ordered by start time in the MKV file; of course with a marker that notes the line's original position in the input file).
The difference is that those markers are used by the splitters to reconstruct the original order of the entries. This may pose a problem for the splitters of filters, I don't know.
Or is it a bug in the way the subtitles are muxed to mkv?
No. Muxing has always worked this way since subtitle support was introduced back in... Oh I don't know... 2004 or so.
I made a small example demonstrating bizarre effect #1 mentioned above, in case you need it.
Thanks, but no thanks. I have no interest in debugging such problems in programs I have no control over.
TheFluff
29th May 2009, 21:33
No. Muxing has always worked this way since subtitle support was introduced back in... Oh I don't know... 2004 or so.
This bug has existed for as long as I can remember; the first time I actually remember observing it was in 2007 but it has probably been around for even longer than that. Just sayin'.
Well, then it's obviously the demuxer's or filter's fault. Back when we implemented subtitle support we specified the way subtitles are stored ("we" as in "the Matroska team"). mkvmerge and other muxers that handle subtitles (e.g. AVI Mux GUI) work according to specs. If the playback applications cannot handle this flawlessly then in all honesty this is not our ( = the muxer application's) fault.
Demuxers and filters are not bug-free. Just sayin'.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.