MKVToolNix v24.0.0 released

[Mosu]

So my real should've been: why did you make mkvmerge ignore the decimals? Does this serve any practical purpose worth the increased jitter?

Would you care to elaborate on "why did you make mkvmerge ignore the decimals"?

Matroska files have a maximum resolution of 1ns. The specs know a concept of a "timecode scaling" parameter. This parameter determines the effective resolution of timecodes in a Matroska file. That parameter is simply used as a factor by the reading program in order to scale to nanosecond resolution. The default value in the specs is 1,000,000 (American notation) resulting in an effective resolution of 1ms.

Why does this parameter exist in the first place? Because it's a trade-off between saving space and higher precision. Remember that all integer numbers (timecodes are integers) are stored in variable-length encoding.

Now to mkvmerge. Internally mkvmerge calculates all timecodes and durations in nanosecond precision. When outputting a file mkvmerge has to decide upon the timecode scaling factor. In general this defaults to 1,000,000 as well -- unless you create an audio-only file. In that case the timecode scaling parameter will be calculated to allow sample-precision for the file.

What happens if there's no DefaultDuration or BlockDuration element? Duration of N-1?

During extraction? I don't know from the top of my head.

What do rational numbers have to do with this, if timecodes aren't stored/extracted as rationals? :confused:

They are extracted as floating point numbers. However, if a floating point number's decimal places are 0 (as in 40.000000) then the decimal places are not written to the timecode file.

[sneaker_ger]

Would you care to elaborate on "why did you make mkvmerge ignore the decimals"?

Your answer covers my question completely, thx.

[Mosu]

You're quite welcome :)

[sneaker_ger]

Don't rejoice too quickly as a new question just popped my mind:
How can the audio track's timecodes have decimals, if TimecodeScale is 1000000 and a segment element, not a track element? (Like in a file with both video and audio)

[Mosu]

In audio tracks several frames are put into a single Matroska element (either a BlockGroup or a SimpleBlock; the difference does not matter for the sake of this discussion). This is called "lacing" in Matroska terms. That single Matroska element has a timecode that is indeed scaled with TimecodeScale. However, there's only a single timecode stored in the file for the whole BlockGroup/SimpleBlock (that's the whole reason for lacing frames: saving space, especially with codecs that use ultra small packet sizes like TrueHD for which single frames often have fewer than 100 bytes).

The timecodes of the second and all following frames in a lace are again calculated from the track's DefaultDuration element. For N frames in a single block programs use the following simple formula: timecode for frame N = BlockTimecode + (N - 1) * DefaultDuration As the DefaultDuration element itself is stored with nanosecond precision you end up with timecodes that are not divisible by TimecodeScale for audio tracks.

[sneaker_ger]

Thx.
That also explains why every 8th timecode does not have decimals, i.e. it's the start of a block. I never gave it much thought and assumed the timecodes would just add up to x.000000 in that location, which is obviously nonsense.

[KoD]

Hi, the test binary http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-5.7.0-build20120711-453-setup.exe also fails to display anything in the mkvmerge GUI, when trying to mux a small file, like the one here:
http://wikisend.com/download/415420/6_Channel_ID.flac

The result of the merge process is an empty window, with no log, and no progress bar, but with an "everything went fine" message.

[Mosu]

I will not fix that, I guess. <rant>Simply because the effort needed in order to re-write that particular part of mmg yet again (and this time it won't be a "small" time investment like roughly 20 hours). It all started with Jon asking for my help 'cause mmg wouldn't run that well on Mac OS as it did on Windows and Linux. Now everything's got a whole lot more complicated...</rant>

Anyway. I have a good idea why it happens, why it only happens with trivially short muxing cycles, and that there's no easy fix. So... I'll leave it like this for the time being.

[Atak_Snajpera]

are we far from support .opus audio format in matroska?

[Mosu]

As far as any other codec that hasn't been implemented yet. However, I will most likely work on that one day. No ETA, as usual.

[mastrboy]

are we far from support .opus audio format in matroska?

Opus does not seem to be a part of the matroska specification: http://matroska.org/technical/specs/codecid/index.html

So what good does it to add support in a muxer for it?
I might be misunderstanding something though...

Btw, i too would like to see more Opus support, and not just for the mkv container.

[Kurtnoise]

https://wiki.xiph.org/MatroskaOpus

[SeeMoreDigital]

I actually tried muxing an Opus audio file with MKVmerge GUI on Sunday. Needless to say it did not work :o

But even with Matroska container support, we still need software player splitter and decoder support to test Opus more fully ;)

[Kurtnoise]

With ffmpeg, you should be able to mux opus stream to matroska...

[Mosu]

As A_ACM? Well, that's completely unspecified by the specs, and it wouldn't solve some of the problems mentioned in the wiki page like seeking & preroll.

[Kurtnoise]

As A_OPUS but yeah, seeking problems remain for the moment...

[Mosu]

Well, that's even worse because it isn't even specified yet.

[SeeMoreDigital]

Well, that's even worse because it isn't even specified yet.

Well.... It may be of "no interest to you" what-so ever. But AVI-Mux GUI (v1.17.8.3 Dated 16 Feb 2010) is able to place Opus audio streams within the Matroska (.MKA) container ;)

EDIT: And the new version of MediaInfo (v0.7.59) can read their contents.

[Mosu]

It's nice that they all implement something like that but don't contact any of the Matroska devs regarding making the framing official ~~ I am definitely interested, just a bit disappointed.

[gonwk]

Hi folks,

I am combining Video form one source with the Audio form another source. The 2 MKV files are identical with the exception that video lengths are about 19.960 Seconds different and that causes my Audio to be off ... here is the info

Video 1 duration is 01:29:37.040
Video 2 duration is 01:29:57.000

I have tried the following with no luck ...
I used MKVMerge and put in -14000 ms Audio Delay ... and that works for about 20 minutes then Audio/Video sync problem again.

I saw something about Video Stretch ... but can't figure out how to use it.

Q1: Can someone tell me how to use the Video Stretch Function?

Q2: Is there a Better and Easier way of mixing the Good Video from one file with Good Audio of the other file?

Thanks!

G!:)

[DragonQ]

Sorry if this has been asked before but are there any plans to support LATM AAC? Does the MKV container even allow this?

[Mosu]

As far as I understood LATM is simply a different container/streaming format for AAC to be packaged in. So there's no specific requirements for Matroska -- only mkvmerge would have to be able to read that format. But no, there are no plans whatsoever.

[nevcairiel]

LATM also has the advantage that it carries an additional header for decoder configuration information, which allows mid-stream decoder re-configuration (change number of channels, and the like), which Matroska with raw AAC would not allow. (ADTS-AAC has the same feature as well)

[Mosu]

I see. Well no, that is not supported in Matroska.

[Mosu]

Hey,

I've released v5.8.0. It adds a couple of new features and fixes a few bugs; most prominently mmg not displaying mkvmerge's last couple of messages.

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.8.0.tar.bz2

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

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

Here's the ChangeLog since v5.7.0:

2012-09-02 Moritz Bunkus <moritz@bunkus.org>
* Released v5.8.0.
* Build system: dropped support for gcc 4.6.0.
* mkvpropedit: new feature: Added support for adding, deleting and replacing attachments.

2012-09-01 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: chapter editor: Added support for the edition flags "hidden", "default" and "ordered" as well as the chapter values "segment UID" and "segment edition UID". Implements ticket #736 (https://www.bunkus.org/trac/ticket/736).

2012-08-30 Moritz Bunkus <moritz@bunkus.org>
* documentation: Added a Basque translation of mmg's guide by Xabier Aramendi (see AUTHORS).
* all: bug fix: Fixed a buffer overflow in the Base64 decoder routine.

2012-08-19 Moritz Bunkus <moritz@bunkus.org>
* source: Various fixes for building with g++ 4.7.x and clang 3.1.

2012-08-08 Moritz Bunkus <moritz@bunkus.org>
* Build system: Boost's "bind" library is not required anymore. The C++11 features from "functional" are used instead.

2012-08-07 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG transport streams whose timecodes wrap around/overflow are handled correctly. Fixes #777 (https://www.bunkus.org/trac/ticket/777).

2012-08-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MP2/MP3 audio tracks in MPEG program streams that contained garbage at the start of the very first packet caused mkvmerge to use uninitialized/random values for certain parameters (sample rate, number of channels, and therefore also during timecode calculation).

2012-08-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading ALAC (Apple Lossless Audio Codec) from CAF (CoreAudio), MP4 and Matroska files. Implements #753 (https://www.bunkus.org/trac/ticket/753).

2012-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will remove stuffing bytes from MPEG-1/-2 video streams that are used to keep the bit rate above certain levels (the 0 bytes between slices and the following start code). Implements #734 (https://www.bunkus.org/trac/ticket/734).

2012-08-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed audio/video synchronisation when reading MPEG program streams with MPEG-1/2 video with respect to B frames. Fixes #579 (https://www.bunkus.org/trac/ticket/579).
* mkvmerge: enhancement: SRT files can have spaces in their timecode line's arrow (e.g. "-- >").

2012-07-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: VC1: mkvmerge will now only mark frames as I frames if a sequence header precedes them directly. Fixes #755 (https://www.bunkus.org/trac/ticket/755).

2012-07-30 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: Added a Basque translation by Xabier Aramendi (see AUTHORS).

2012-07-20 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The programs do not try to create directories with empty names anymore. This happened if the output file name for e.g. mkvmerge or mkvextract was only a file name without a directory component. With Boost v1.50.0 the call to "boost::filesystem::create_directory()" would result in an error if the name was empty (it didn't in earlier versions of Boost).

2012-07-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed mmg not reading the very last line of mkvmerge's output. The result was that messages like "the cues are being written" did not show up in mmg and that the progress bar was not filled completely. Fixes #774 (https://www.bunkus.org/trac/ticket/774).


Have fun.

[b66pak]

thanks a lot...
_

[Liisachan]

Thanks as always, Mosu :)
In case this isn't intentional... you forgot to post in the Matroska mailing list. I always got an email titled like "MKVToolNix v1.2.3 released", which I didn't this time.

[Isochroma]

Windows XP SP2 32-bit, MKVMerge GUI 5.8.0:

Trying to append "03 03_disorganisation.m4a" to "02 02_strength_of_movements.m4a" causes MKVMergeGUI to throw an error: "Assertion failed!".

Same happens if they are muxed individually to MKV and attempted merge.

Same also happens if they are muxed to MKV, extracted using MKVExtract to AAC and then appended.

After dismissing that dialog it just totally crashes out and process self-terminates.

It works fine to merge most of the other M4A parts by appendation.

I can also merge the files OK with the older MKVMerge 1.8.1, so it's a code regression since then.

Here are the files: MKVMerge GUI M4A Append Crash Source Files.rar (http://www.sendspace.com/file/nruiba)

[Mosu]

Thanks as always, Mosu :)
In case this isn't intentional... you forgot to post in the Matroska mailing list. I always got an email titled like "MKVToolNix v1.2.3 released", which I didn't this time.

Thanks for noticing. I totally forgot about that.

[Keiyakusha]

Hi Mosu! Thanks for the new version! I want to ask something about mkvmerge and official cleaning/validation tools. Maybe its not very follows this topic, but somehow I feel that you may know the answers.

Some people say TimecodeScale in matroska is mandatory but mkclean removes it. This makes "optimized" files incompatible with some matroska parsers/splitters/players. Is it normal to work around this issue or this is mkclean bug?
Then on every file muxed by mkvmerge validator reports that there is 5000+ bytes of void data and mkclean (probably) removes it. What is that? Oo
Also if I'll make mkv with 2 (or more?) video streams, validator reports a lot of things like "First Block for video track #2 in Cluster at 40801376 is not a keyframe". What is that? It expects that both streams will have keyframes at the same places? I have no idea how can I achieve that without reading frametype information from 1st stream and then manually overriding frametype decisions by creating lookup list of frames that I pass to encoder Oo

Finally, just curious, why you made header editor as separate window? To me it seems that having it as one more tab, just like chapter editor will be more consistent...

[Mosu]

Some people say TimecodeScale in matroska is mandatory but mkclean removes it. This makes "optimized" files incompatible with some matroska parsers/splitters/players. Is it normal to work around this issue or this is mkclean bug?

It is mandatory. However, in Matroska elements can also have default values in the specs. If an element's value equals its default value then it doesn't have to be written to the file. Turning this argument around means that a reader must assume that the element equals its default value if it isn't present in the file.

TimecodeScale (http://www.matroska.org/technical/specs/index.html) has a default value of 1.000.000 which is also the standard value that most muxers use resulting in ms precision for timecodes. That's why mkclean can safely remove it.

If software doesn't support this situation then it is buggy/doesn't implement the Matroska specs properly.

See also one of my FAQ entries (https://www.bunkus.org/answers/?qa=5/does-language-english-show-output-file-even-though-selected).

So what mkclean does is 100% spec compliant.

Then on every file muxed by mkvmerge validator reports that there is 5000+ bytes of void data and mkclean (probably) removes it. What is that? Oo

Void elements are placeholders that can be overwritten with other values. Readers must simply skip such values.

mkvmerge uses them after certain important elements during muxing, especially after the track headers. This is done because mkvmerge sometimes has to change and re-write the track headers during muxing because new information is available that wasn't available when muxing started. There are basically two approaches for dealing with it: 1. use two-pass muxing (after the first pass it is known how much space muxing will really need for such elements) or 2. create small void elements at the start of the muxing that can be overwritten/adjusted during muxing. mkvmerge choses 2. for two important reasons: implementing two-pass muxing is pretty time consuming to code, and enforcing two-pass muxing is very annoying to the user (it takes twice as long, obviously).

100% spec compliant. Wastes only ~5 KB of space.

Also if I'll make mkv with 2 (or more?) video streams, validator reports a lot of things like "First Block for video track #2 in Cluster at 40801376 is not a keyframe". What is that? It expects that both streams will have keyframes at the same places?

More or less, yes. This is just a question of how easy it is to seek in such files. As a user you will never, ever, ever notice a difference. Simply ignore this warning. It's also not a spec violation -- simply a matter of being only 99.9% optimal instead of 100%.

I have no idea how can I achieve that without reading frametype information from 1st stream and then manually overriding frametype decisions by creating lookup list of frames that I pass to encoder Oo

Well... From the programmer's view: simply start a new cluster before each and every video key frame. I refuse to do that because it wastes space for no gain at all. From the user's view: you cannot, at least not with mkvmerge.

Finally, just curious, why you made header editor as separate window? To me it seems that having it as one more tab, just like chapter editor will be more consistent...

Implementing the chapter editor as a separate tab was the wrong decision. It confused users to assume that the chapters they see there are actually taken into account during muxing. As a matter of fact the chapter editor is more of a separate application. That's why I decided against such a design for the header editor.

That I don't split up the chapter editor tab into a separate window today is simply a matter of not wanting to waste more time on wxWidgets programming than absolutely necessary.

[Keiyakusha]

More or less, yes. This is just a question of how easy it is to seek in such files. As a user you will never, ever, ever notice a difference. Simply ignore this warning. It's also not a spec violation -- simply a matter of being only 99.9% optimal instead of 100%
I see. Well I asked about this mainly because I encountered problems with such files. One of the video streams was having troubles with seeking. After seeking it just freezes for some time. In my case 1st stream was freezing and 2nd one with a lot higher amount of keyframes was playing alright. Interesting thing its that running the file through mkclean was fixing the seeking problem. However I wasn't able to replicate this issue today, so I removed this information from my initial question. Will check more about that.

About TimecodeScale, I see. I was guessing things are like that. The software I was dealing with will be fixed to support this default timescale value.

Thanks for your answers. Everything is perfectly clear now!

[Mosu]

I have seen it. I will take a look at it when I find the time and motivation (probably not before the weekend).

[cyberbeing]

From seeking + subtitle perspective, would it be possible to add a switch to mkvmerge to prioritize creating clusters based on subtitle start times which overlap a keyframe, on the subtitle start time instead of the keyframe?

It appears that Haali's GDSMux does this, but mkvmerge doesn't. The difference being that with a MKV created with GDSMux, you can seek to a chapter on a keyframe when paused, and subtitles with start times in very close proximity to that keyframe will be displayed. With a MKV created with mkvmerge, no subtitles will be displayed at all, even after resuming play, since the subtitle which overlaps this keyframe was placed in the previous cluster and never loaded since the splitter seeks directly to said keyframe cluster (which happens to be a chapter). I've noticed that disabling the meta-seek element in mkvmerge may resolve the issue, but that doesn't seem like an optimal solution.

[Mosu]

I won't add such a switch, sorry. There are several reasons (time, technical reasons, and there are better/proper solutions to this problem that solve other issues as well). No, I don't want to spend half an hour explaning this in detail at the moment. Sorry.

[cyberbeing]

I won't add such a switch, sorry.
No problem, what I suggested never really sounded optimal in the first place.

There are several reasons (time, technical reasons, and there are better/proper solutions to this problem that solve other issues as well). No, I don't want to spend half an hour explaning this in detail at the moment. Sorry.

Hmm... Well when you have a chance, I'd be curious and interested in hearing about what the better/proper solutions are for future reference.

Everybody seems to always blame the subtitle renderer for this issue, but as far as I can tell it's actually a MKV specific muxer/splitter issue?
None the less, if there is anything which we could do in xy-VSFilter to resolve this, we're open to suggestions.

[Mosu]

The proper way would be to add subtitle entries to the index (Matroska terms: the cues). This can already be enforced with mkvmerge for each track (option "--cues" (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.cues)). However, in order to provide a real benefit to splitters/players such cues would have to store not only the frame's start time but also its duration. That is currently not possible with Matroska specs.

There are also other related issues with the cues that don't relate to subtitles but to things like pre-roll. For example, Opus has such problems (see http://wiki.xiph.org/MatroskaOpus). This would not be solved by such an "duration-in-cues" field mentioned above, though.

So when we extend the Matroska specs regarding cues I'd like that extension to cover both use cases.

[Liisachan]

@Mosu - Questions (Muxing)

1) When a timecode file is used (with a VFR-as-CFR moive), what's the default value of Video track's DefaultDuration ? Is that value important in any way? Mkvmerge seems to write a rather random value for it. Since it's VFR, DefaultDuration should be meaningless anyway, I suppose.
2) --default-duration seems to be just ignored even if specified. On MMG, the "FPS" option is not disabled even after a timecode file is specified, but apparently this "FPS" setting doesn't change anything.

@cyberbeing
Just FYI I often set a chapter point about 3 video-frame after the intended chapter point (keyframe). That way, I don't have to hear the partial audio (not beautiful) from before the keyframe, which would be otherwise decoded (if the audio packet straddles the keyframe in question, timing-wise). And after the chapter jump, the video is decoded from the targeted keyframe anyway, because the player first has to decode the keyframe before it can decode the chaptered bvop.

Also, you might want to tweak the subtitle start time to see if it helps. For example, if the chapter point frame is t=1000, and the previous frame is t=950, then the sub-start=1000 is unsafe. You can edit the subtitles so that, for example, the sub-start will be 990 (basically, this change has no bad effects: relative timing--or rendering--doesn't change as long as it's after the previous frame, t=950). Then, the probability that the sub in question is shown right at t=1000 will increase.

But admittedly, controlling softsubs is very difficult. We may have to use several workarounds.

[sneaker_ger]

@Mosu - Questions (Muxing)

1) When a timecode file is used (with a VFR-as-CFR moive), what's the default value of Video track's DefaultDuration ? Is that value important in any way? Mkvmerge seems to write a rather random value for it.

Look here (http://forum.doom9.org/showpost.php?p=1563861&postcount=1436) for an explanation on how this is set with timecode file input.
That value is not important for video tracks, though, since each frame has its own timecode anyways. Some programs might choose to make use of that info in one way or another, but I haven't really seen it being put to use. (Because of the rounding, LAV/madVR for example uses the bitstream info instead of container info)

2) --default-duration seems to be just ignored even if specified. On MMG, the "FPS" option is not disabled even after a timecode file is specified, but apparently this "FPS" setting doesn't change anything.

If you specify a timecode file, the "FPS" field is ignored. If you don't set a timecode file, "FPS" controls all the timecodes and the defaultduration header element.
If you open a mkv file in mmg, the "FPS" field is always empty, which just means that it will copy whatever value has been used in the source file (both timecodes and header element). It does not mean that the element has not been set. If you want to check the element use mkvinfo or the header editor.

[Mosu]

@Mosu - Questions (Muxing)

sneaker_ger has answered both questions very well (and correctly) already. I only have this link to add to the first question: Why is the FPS/frame rate wrong? (https://www.bunkus.org/answers/?qa=205/why-is-the-fps-frame-rate-wrong) It's from my FAQ and explains a bit more about what DefaultDuration really is and how readers are supposed to interpret it.

[cyberbeing]

Just FYI I often set a chapter point about 3 video-frame after the intended chapter point (keyframe).
This would work only in cases when the desired start time of the subtitle is the keyframe, or else the subtitle will likely end up in the previous MKV cluster and never get decoded on seek.

Also, you might want to tweak the subtitle start time to see if it helps. For example, if the chapter point frame is t=1000, and the previous frame is t=950, then the sub-start=1000 is unsafe. You can edit the subtitles so that, for example, the sub-start will be 990 (basically, this change has no bad effects: relative timing--or rendering--doesn't change as long as it's after the previous frame, t=950). Then, the probability that the sub in question is shown right at t=1000 will increase.
Similar as above, this usually won't work when the chapter point is a keyframe. If you set the sub-start time to 990, it will often end up in cluster prior to the one containing the keyframe/chapter. If the chapter point is _not_ a keyframe this method you mention will usually work.

But admittedly, controlling softsubs is very difficult. We may have to use several workarounds.

It is difficult. There are little workarounds like what you mentioned, but what we really need is a solution which allows subtitles which overlap multiple clusters to be displayed, even if you seek near the end of a line. This issue doesn't occur with external softsubs at all, since VSFilter pre-loads the entire script. Theoretically I could imagine a hackish solution involving MKV attachments and a splitter modification to allow VSFilter to pre-load the entire attached script as if it were external, but that would be completely non-standard and conflict with the MKV spec's support of embedded subtitles (bad idea).

I'm hopeful something like the "duration-in-cues" which Mosu mentioned will turn into a proper solution, but it sounds like it would require an overhaul of MKV splitters to actually support it. Luckily (or not) we do now have the Opus codec which requires a decoding 'pre-roll' (the need to decode audio frames prior to the one seeked to for proper decoding) which will require a splitter overhaul anyway. If the MKV spec extension for Opus can be extended to support subtitle start/end times as well, that will be excellent.

[Liisachan]

@sneaker_ger
@Mosu
Thanks a lot, and I'm sorry I asked the essentially same question that was already asked. The FAQ page is so informative. Let me add another nitpick, though. The FAQ says that the Matroska specifications do not know about a concept called "FPS", which is not entirely true: "FPS" is explicitly defined in the Tag specifications. But that's not the point, I know~ :P

Well, I kind of suggested this: it would be more user-friendly if a control in MMG was disabled when not available. For example, it would be ideal if the [Start muxing] button was grayed until the Output file name is specified. In the ideal world, the FPS list would be disabled when the Timecodes editbox is non-empty. But that's only idealism. I'm not complaining here.

@cyberbeing
I can see your point. That said, you can at least make it a keyframe if a frame is chaptered, using a qpfile if it's x264. Also, you can try a workaround like this, if subtitles are text-based like SSA/ASS.

; Example 1
Dialogue: 0,0:00:10.00,0:00:15.00,...,,A keyframe at 00:11.23 is bad?!

; Example 2 (Workaround)
Dialogue: 0,0:00:10.00,0:00:11.23,...,,A keyframe at 00:11.23 is bad?!
Dialogue: 0,0:00:11.23,0:00:15.00,...,,A keyframe at 00:11.23 is bad?!

Conversion from Example 1 to Example 2 could be done trivially with a simple program, using a keyframe list, before muxing. I'm not saying your problem is trivial; I'm simply offering a possible workaround.

Edit: fixed example 2

[Keiyakusha]

if by some chance Mosu will mess with GUI to make something grayed out, maybe its good idea to disable language selection for chapters, since it does nothing anyway. However I wouldn't mind if it will actually override language set for chapters, will be very handy :P

[Mosu]

You can count on me spending as little time as possible implementing changes to mmg ;)

[cyberbeing]

I'm not saying your problem is trivial; I'm simply offering a possible workaround.
This is another known workaround, but it becomes impractical whenever dealing with animated effects.

The main reason I brought back up this years old issue, is not because I was looking for a solution for myself, as it only affects me indirectly. It has more to do with how the majority of people have mistakenly come to believe this is a VSFilter bug, when it's actually a MKV limitation. It's all just part of my process of looking into and sorting issues which can be fixed by xy-VSFilter from issues caused by other factors which are outside our control. When I find time, I'll add an entry for this on the xy-VSFilter Troubleshooting FAQ. It was a happy coincidence that there may now actually be a proper solution in planning as a side-effect addition of needing to support the Opus codec.

[Mosu]

Opus has nothing to do with this solution (or the planning of it). Both issues have different solutions as far as I know. The subtitle problem (and the solution for it regarding Matroska) has also been known for years; the question is whether or not we will get around to adding elements for it.

[cyberbeing]

Technically it's completely different, but if adding new elements never occurs, couldn't you re-purpose whatever is implemented for Opus as a partial solution acting as a subtitle pre-roll?

[Mosu]

My guess is the solution for Opus will require new elements as well.

[cyberbeing]

My question was if any new Opus pre-roll elements could theoretically be re-purposed for adding a subtitle pre-roll, without adding new subtitle-specific elements?

[Mosu]

No idea, I haven't thought through what's required for Opus. Maybe, maybe not.