MKVToolNix v24.0.0 released [Archive] - Page 76 (2025)

Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers > MKVToolNix v24.0.0 released

PDA

View Full Version : MKVToolNix v24.0.0 released

Pages :123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475[76]7778798081828384858687888990919293949596979899100101102103104105

Mosu

10th November 2015, 11:42

Hmmm sounds somewhat useful, though I highly doubt a lot of people would actually use it. But I'm willing to implement it in the future. If you want something like that then please open an issue on Github (https://github.com/mbunkus/mkvtoolnix/issues/) for it; otherwise I'll likely forget about it again. Thanks.

ndjamena

12th November 2015, 03:39

I'm currently attempting to write in the chapter names for the extended editions of The Lord of the Rings...

Is there a good reason the focus keeps returning to ChapterTimeStart when I press enter to move to the next chapter?

I'd rather it stayed where I left it.

Mosu

12th November 2015, 09:07

Different people prefer different workflows.

Often you generate a lot of chapters first (or import them from a DVD) and adjust all their timestamps or names in one go (sounds like what you're trying to do). On the other hand other people prefer to generate chapters once and then they want to tweak each entry (requiring to change both the timestamp and the name, then go to the next chapter entry, rinse & repeat).

The GUI supports both workflows. It defaults to supporting the second kind of workflow: when you press enter you move from the timestamp field to the name field. If the focus is already on the name field then the next chapter entry is selected and that entry's timestamp field is focussed.

However, in this mode you can also press Shift-Return. This causes the GUI to select the next chapter entry no matter where the focus currently is and to keep the focus in the same field.

And that's your answer. Either press Return twice or Shift-Return once; both will result in what you want to achieve.

ndjamena

12th November 2015, 09:29

How long do we have to wait for a pre with the VC-1 fix?

mariner

12th November 2015, 09:35

No, it isn't. It must be in a container, e. g. WAV.
Thanks again, Mosu.

Mosu

12th November 2015, 09:53

How long do we have to wait for a pre with the VC-1 fix?

FYI: I often find your style of asking questions to be a bit offensive. For example, I read this question as you thinking I have some kind of obligation to provide pre-builds in a timely manner. That's probably not what you think, but it can come across this way. If you had just asked "Can you please provide a pre-build with the VC-1 fix?" it would have gone over much better.

Here are your pre-builds 1002 and 1003 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/).

ndjamena

12th November 2015, 10:07

I think you got it the wrong way around.

I was asking how long I had to wait... and that's exactly what I meant. NOT KNOWING is annoying.

"Can you please provide a pre-build" is asking you to do something, like you have some kind of obligation.

You're inserting sarcasm in what I'm saying that doesn't exist. (Try timidity and helplessness instead.)

Mosu

12th November 2015, 10:16

Fair enough, but for the record: asking someone to do something is, to me, the most normal thing on earth. The person is under no obligation to heed the request, therefore there's no pressure (e.g. if I had no time to create one I would simply say so without feeling bad about not having fulfilled the request). And such a question shows your actual desire (you want to have such a build). I wasn't even aware there was a need for such a build; so asking for how long it will take for the build to materialize seems like skipping steps (first communicate the fact that there is such a need).

My whole point was: communication is complicated, especially if it's only text without body language to accompany it, and I wanted to let you know how your question seemed _to me_. Like I said I didn't really think you meant it the way it was received, and it's good to know that it indeed wasn't.

Boulder

12th November 2015, 11:01

English is probably not ndjamena's mother tongue so the sentence may sound a bit harsh. "How long do we have to wait" does have a negative tone but it's understandable in that case.

Anyway, "please" is a very useful word no matter what you ask for :)

beastbg8

13th November 2015, 01:45

I finally updated it some days ago and i must say: I'm not a big fan of the new GUI. I liked the older one better.

Mosu

13th November 2015, 08:58

What exactly don't you like? Are you missing certain features? Do features not use the way you want them to? Do you have a beef with the layout? Do you not understand how to do certain things?

The new GUI can do everything the old GUI can do, but it does things differently. I'd like to help you, but you'll have to be specific with your complaints. I cannot do anything with "I prefer blue over red".

nada2k

13th November 2015, 19:47

In the past I saved some .mmg settings files. Is it correct that the new MKVToolNix GUI can not open these anymore?

In the job cue some menu items are available over the "Job queue" menu on top and some over the right-click context menu. Some are exclusive to each menu, some appear in both. Is there a setting to make both menus show the same, combined content?

Mosu

13th November 2015, 19:56

In the past I saved some .mmg settings files. Is it correct that the new MKVToolNix GUI can not open these anymore?

That's correct. The new GUI uses a different storage format with different keys and values.

In the job cue some menu items are available over the "Job queue" menu on top and some over the right-click context menu. Some are exclusive to each menu, some appear in both. Is there a setting to make both menus show the same, combined content?

There are no duplicates, even if some of the options look similar. The options in the menu on the top are the ones that operate on the whole queue. The ones in the context menu operate on the ones that are selected when you open the context menu.

For example, the context menu option "Remove jobs" removes then ones that are currently selected whereas the main menu option "Remove completed jobs" removes all jobs that have been completed regardless of their current selection status.

Another example: "Start pending jobs" from the main job queue menu sets all jobs to "start automatically" that are currently in state "start manually". Whether or not they're selected doesn't matter. On the other hand the context menu option "Start jobs automatically" sets the status of all selected jobs to "start automatically" no matter what their current status is (which means that you can use this option to re-enable particular jobs that have already been completed).

It's easy enough to remember: do you want to manipulate the currently selected job(s)? Then use the context menu. Otherwise you'll find the corresponding option in the main job queue menu.

See also this related wiki article (https://github.com/mbunkus/mkvtoolnix/wiki/The-job-queue,-statuses-and-their-actions) about "The job queue, statuses and their actions".

magsoud

15th November 2015, 08:40

MKVtoolnix not show about This errors and warnings (Show in image):
Please Fix This!

LeMoi

15th November 2015, 11:54

Some dialogs need (at least French) translation, like overwriting confirmation, for example.

EDIT : never mind, looks it's been fixed in latest version

bin_ch

15th November 2015, 12:58

I love the new GUI. Particularly for it showing the properties on the right side as a single scrollable widget. With the old mmg, I had to switch between tabs to set different options. I am just wondering is it possible to assign all the properties options with access keys (the underlined letters)? That would make jumping betweeen options even faster. Currently, access keys are only available for the top three options (Mux this track, Track name, Language).

Also, I sorta miss the "Copy to clipboard" button. Currently in the new GUI, one wants to copy the command line options has to go to Merge menu --> Show command line --> Copy to clipboard. I can understand it may not deserve a dedicated button in the main window because it's not very frequently used for normal users. But I personally often use it. What do you think about adding an entry under Merge menu (say, above/below "Show command line", like in mmg)?

Thank you.

Mosu

15th November 2015, 16:48

I love the new GUI. Particularly for it showing the properties on the right side as a single scrollable widget. With the old mmg, I had to switch between tabs to set different options. I am just wondering is it possible to assign all the properties options with access keys (the underlined letters)? That would make jumping betweeen options even faster. Currently, access keys are only available for the top three options (Mux this track, Track name, Language).

Unfortunately assigning more hotkeys isn't as easy as one might hope. The whole "merge" tab dialog is a single form, and Qt's Creator tool doesn't really allow me to re-use the same hotkeys on different tabs. Some are silently changed whenever I make a change, and I don't want to have to fight the Qt Creator each time I edit the form.

Additionally there are so many options that selecting distinct hotkeys for all of them isn't even possible.

Also, I sorta miss the "Copy to clipboard" button. Currently in the new GUI, one wants to copy the command line options has to go to Merge menu --> Show command line --> Copy to clipboard. I can understand it may not deserve a dedicated button in the main window because it's not very frequently used for normal users. But I personally often use it. What do you think about adding an entry under Merge menu (say, above/below "Show command line", like in mmg)?

Nothing, to be honest. That would only move it one layer up and not improve your situation much. And you're right, copying to the clipboard is something that few people do regularly.

You seem to be a keyboard user. Why don't you memorize the hotkeys you need to press for copying to the clipboard? After doing it a couple of times pressing them should become somewhat automatic. For the English version it's Alt+M, h, Alt+O, Alt+C. You can even use Alt+H in the second step, so you don't even have to take your finger off Alt. Basically: Press and hold Alt, then hit m h o c in sequence. Release Alt.

bin_ch

16th November 2015, 13:03

Unfortunately assigning more hotkeys isn't as easy as one might hope. The whole "merge" tab dialog is a single form, and Qt's Creator tool doesn't really allow me to re-use the same hotkeys on different tabs. Some are silently changed whenever I make a change, and I don't want to have to fight the Qt Creator each time I edit the form.

Additionally there are so many options that selecting distinct hotkeys for all of them isn't even possible.
I see, didn't know the technical details.

Nothing, to be honest. That would only move it one layer up and not improve your situation much. And you're right, copying to the clipboard is something that few people do regularly.

You seem to be a keyboard user. Why don't you memorize the hotkeys you need to press for copying to the clipboard? After doing it a couple of times pressing them should become somewhat automatic. For the English version it's Alt+M, h, Alt+O, Alt+C. You can even use Alt+H in the second step, so you don't even have to take your finger off Alt. Basically: Press and hold Alt, then hit m h o c in sequence. Release Alt.
True. After imagining the workflow now I completely agree, three keystrokes indeed isn't too much different than five.

Thanks for the reply, and the new GUI.

dansrfe

17th November 2015, 01:11

It would be great to select/deselect by en-masse highlighting in the tracks, chapters, tags, and attachments section. For example to deselect a long list of subtitle streams.

foxyshadis

17th November 2015, 03:54

It would be great to select/deselect by en-masse highlighting in the tracks, chapters, tags, and attachments section. For example to deselect a long list of subtitle streams.

All the usual text selection shortcuts work, along with the context (right-click) selection options. Maybe a shortcut and option for invert selection would be useful? Or perhaps being able to sort by the track headings, making it easy to use shift to select the right things.

dansrfe

17th November 2015, 08:13

All the usual text selection shortcuts work, along with the context (right-click) selection options. Maybe a shortcut and option for invert selection would be useful? Or perhaps being able to sort by the track headings, making it easy to use shift to select the right things.

Right, the right-click menu as is applied actions to the entire set of tracks, regardless of the subset of tracks which have been highlighted. The space-bar shortcut working with with a subset highlight would be nice as well.

Mosu

17th November 2015, 08:56

dansfre: use the right-click menu to select e.g. all subtitle tracks, then use the "mux this track" drop down on the right to toggle the state for all of the selected ones.

You're right about the space key only toggling the one track that's currently focussed. This should work on all selected tracks, and I'll fix it accordingly.

See also this short introduction video (https://www.youtube.com/watch?v=QET-MifgJLM) for selecting and changing multiple tracks at once.

Mosu

17th November 2015, 09:23

Oh wait, space isn't supposed to toggle all, that's what Enter/Return is there for. Space is supposed to work on the current one only.

LeMoi

23rd November 2015, 00:39

I have 698 MB MKV file muxed with mkvmerge 7.9.0 5 months ago. I want to replace two audio tracks (LC-AAC 6ch, each one is 104 MB) with tow other ones with the exact same bitrate (160 kbps, both tracks have exactly the same size as the ones I want to replace).
When I mux the file with latest MKVToolnix, the result file is 707 MB!! And if I just remux the original file without unchecking or adding any track, the file is 704 MB!!
Is there a reason why the new version adds those MB?

Mosu

23rd November 2015, 09:48

There are a couple of potential reasons, e.g. differences in how cues were created, or maybe the original muxer packed frames together in an illegal way (which mkvmerge doesn't). But that's all guesswork. Can you please create four files with mkvinfo and upload those to my FTP server (https://github.com/mbunkus/mkvtoolnix/wiki/FTP-server) so that I can analyze them? I'll need:

mkvinfo -v -v --redirect-output original-vv.txt original.mkv
mkvinfo -s --redirect-output original-s.txt original.mkv
mkvinfo -v -v --redirect-output remux-vv.txt remux.mkv
mkvinfo -s --redirect-output remux-s.txt remux.mkv

original.mkv is the orignal file you're trying to remux/change audio tracks in, and remux.mkv is the file after remuxing without changing anything (no audio tracks removed/added).

Thanks.

LeMoi

23rd November 2015, 17:47

Remuxing with 8.3.0 resulted in a 698 MB file too. I'll upload the files on your server so that you can analyze them

Mosu

23rd November 2015, 23:22

Your original file uses content compression (zlib compression) for the VobSub tracks; your remuxed file doesn't. Hence the bigger files.

LeMoi

23rd November 2015, 23:26

I dind't change any setting, shouldn't zlib compression be enabled by default?

Mosu

23rd November 2015, 23:30

Depends on your settings in the GUI ("Preferences" → "Merging" → "Disable additional lossless compression for all track types"). That setting is off by default (https://github.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/util/settings.cpp#L151), meaning that in a new installation the GUI will leave the setting on its default causing mkvmerge to use zlib compression for VobSub tracks.

The command-line mkvmerge uses zlib compression by default, too.

LeMoi

23rd November 2015, 23:46

So since I began using the new GUI, all the files I muxed didn't have this (zlib) compression, since I didn't change that default setting? And if I remux a file in which tracks have this compression, if I don't enable it in settings, i'll lose this compression?
Can't you make the GUI keep the compression of tracks in files when you remux them?

sneaker_ger

23rd November 2015, 23:59

You did change the defaults, that checkbox is not ticked by default. If the box is not ticked all idx/sub and pgs tracks will be compressed using zlib regardless of the source file. If the box is ticked all idx/sub and pgs tracks will be uncompressed regardless of the source file.

LeMoi

24th November 2015, 00:16

Thanks for the explanation, I just wanted to be able to keep track settings when I remux a file regardless of the default options, I wanted these options to concern new muxings only.
I don't remember unchecking this option, but maybe I did some weeks ago not knowing what it means!

Mosu

24th November 2015, 08:43

You misunderstood me.

If that option is [ ] unchecked then mkvmerge WILL use zlib compression. The default for new installations is to leave the option [ ] unchecked. Therefore a new installation WILL use zlib compression.

The option exists for people whose players DON'T support zlib compression. Those people can [✓] check the option and then mkvmerge will NOT use zlib compression.

So if the option is [✓] checked for you then you've enabled it manually sometime in the past.

LeMoi

24th November 2015, 23:57

That's why I understood.
I don't really remember, but maybe i checked this box some years ago when video compression was not compatible with some software or hardware players. But as far as I remember, i was still using subtitles compression, maybe when I updated to the new GUI, it also disabled the compression for every type of tracks. That could explain why my subs tracks are bigger then they used to be some weeks ago when I was still using the old GUI ^^

ndjamena

27th November 2015, 23:57

I'm currently looking at working on fixing MediaInfo's handling of seek heads at the very ends of files, but I no longer have any examples to work with.

Is there any way of doctoring a file with that configuration or am I stuck playing around with MKVPropEdit until something works out?

sneaker_ger

28th November 2015, 00:04

mkvmerge --clusters-in-meta-seek?

Mosu

28th November 2015, 10:09

Is there any way of doctoring a file with that configuration or am I stuck playing around with MKVPropEdit until something works out?

This is actually pretty easy to achieve if you know how. First create a Matroska file; content doesn't really matter, e.g. a single track will suffice, but don't add any attachments.

Next take a look at it with mkvinfo. You should notice an EbmlVoid element located directly behing the seek head. For example this is how a file I've just created looks:

…
+ Segment, size 3970442
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4029)
|+ Segment information
…

Now all you have to do is use mkvpropedit to add a new attachment that'll fit into that void. Use any small text file, a couple of bytes will suffice. Just don't use anything too close to the void's size as there are some more elements like attachment name and attachment MIME type that'll be added as well.

The result is that the attachments will be written into that void. Then mkvpropedit tries to add a pointer to the attachments element into the existing seek head, but it'll find that it cannot do that as there's no space behind the seek head anymore (that's now occupied by the attachments themselves). Therefore mkvpropedit will create secondary seek head at the end.

TL;DR:

[0 mosu@sweet-chili ~/prog/video/data] ls -l x.txt
-rw-r--r-- 1 mosu vj 1420 Feb 24 2015 x.txt
[0 mosu@sweet-chili ~/prog/video/data] mkvmerge -o v.mkv v.avi > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvpropedit v.mkv --add-attachment x.txt > /dev/null
[0 mosu@sweet-chili ~/prog/video/data] mkvinfo -v -v v.mkv | sed -e '1,8d' -e '15q'
+ Segment, size 3970521 at 40
|+ Seek head at 52
| + Seek entry at 57
| + Seek ID: 0x11 0x4d 0x9b 0x74 (KaxSeekHead) at 60
| + Seek position: 3970440 at 67
|+ EbmlVoid (size: 37) at 73
|+ Attachments at 119

ndjamena

28th November 2015, 11:40

That did it. MediaInfo is now incapable of reading the tags and presumably the cues as well.

Should I assume I need to be capable of reading header elements sandwiched between clusters? There aren't any actual rules as to where anything can go is there?

Things go where ever, and MediaInfo has to read anything a pointer points to?

Mosu

28th November 2015, 11:57

The rules players have to follow are pretty simple:

Start reading from the start until you find the first cluster
For each seek head found so far read any other seek head it points to
For each level 1 element found by one of the two steps above read and process those level 1 elements

Now the player is ready to start playing.

Following seek heads that way is only required once, meaning that if there's a seek head A at the start pointing to a seek head B somewhere else and if that seek head B points to yet another seek head C then you only have to process seek heads A and B but not C anymore. mkvmerge does support following an arbitrarily long chain of seek heads but that's purely optional, and none of my tools (nor any other tools I know of) produces a chain of seek heads longer than two.

Mosu

28th November 2015, 11:59

Should I assume I need to be capable of reading header elements sandwiched between clusters?

In case my answer above wasn't clear: only if a seek head points to an element sandwiched between clusters. Level 1 elements must be found if they're either located before the first cluster or if they're reachable by a seek head that's located before the first cluster.

You don't have to scan the whole file from start to finish.

ndjamena

28th November 2015, 12:36

Sorry, I'm looking at the source code and the assumptions it makes. It follows one pointer, once. The pointer with the lowest value that's higher than the current position in the file, then it reads to the end of the file.

I'm guessing every time it reaches either a cluster or an end of file it needs to look at all the available seeks, check them against where it's already been, and if it finds somewhere it hasn't been, go there and repeat until there's no seeks left.

THEN, start reading the clusters. Now I'm just wondering what's supposed to happen if it comes across a non-cluster element it hasn't parsed before within the clusters. I know the specs say you can put tags there at least.

Mosu

28th November 2015, 12:44

Such elements can be ignored if they're not pointed to with seek heads.

Boulder

28th November 2015, 16:17

When appending Matroska files, the job output sometimes starts to show things like these after the first part is muxed:

#GUI#progress -12%
#GUI#progress -11%
#GUI#progress -10%
#GUI#progress -9%
#GUI#progress -8%

Mosu

28th November 2015, 16:50

Interesting. I cannot reproduce that at the moment. Can you please tell me more about your mux settings? What kind of files are involved, what's appended to where? Ideally you could send me a mux setting file or the corresponding job queue file (https://github.com/mbunkus/mkvtoolnix/wiki/mtxcfg-file-format-and-the-jobQueue). I'd also like to know how big the files in question are exactly.

Mosu

28th November 2015, 22:02

Hey,

The next release of MKVToolNix is available: v8.6.0. Like the previous couple of releases this one focuses on bug fixes primarily. However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.

There's also an important change breaking backwards compatibility: text files created by the tools (e.g. chapters extracted with mkvextract or redirected output of any of the tools) won't start with a byte order mark (BOM) anymore, even if they're encoded in one of the UTF-* encodings. Back in the day people believed that text files would be encoded primarily in UTF in the future and that distinguishing between those formats automatically with a byte order mark seemed sensible.

Reality has shown that things turned out differently: text files are overwhelmingly encoded in UTF-8 if they originate on Linux/Unix/Mac OS and in Windows' local encoding otherwise. Writing byte order marks isn't recommended anymore anyway.

This is an experimental change in so far as I'm willing to reverse it if enough people speak out for keeping the BOMs. So if you have legitimate concerns about this then please drop me a line.

An important change for package maintainers is that gcc 4.8.0 or newer/clang 3.4 or newer is now required for compilation due to the (header-only) library used for generating the JSON output. This concerns CentOS 6 and Debian 7 "wheezy" for which I don't offer binaries anymore as a consequence.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since the previous release:

2015-11-28 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.0.
* all: change: none of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes anymore.

2015-11-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Matroska reader bug fix: the info about which packetizer is used was output twice for each HEVC track. Fixes #1522 (https://github.com/mbunkus/mkvtoolnix/issues/1522).
* MKVToolNix GUI: bug fix: implemented a workaround for a bug in Qt which caused the GUI not to start anymore due to failing to detect a stale lock file if the GUI had crashed before on a computer with a host name that included non-ASCII characters. See https://bugreports.qt.io/browse/QTBUG-49640

2015-11-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: a track's number of bits per audio sample wasn't output in verbose identification mode even if it was present in the file.
* mkvmerge: enhancement: if no seek head is found before the first cluster when reading Matroska files then mkvmerge will attempt a deeper scan of all elements in the file in order to find track headers, attachments, chapters and tags located at the end of the file. See #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513) for the rationale.

2015-11-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor bug fix: the "status" description wasn't adjusting its height properly resulting in its text being cut off. Fixes #1517 (https://github.com/mbunkus/mkvtoolnix/issues/1517).
* MKVToolNix GUI: bug fix: the program changes its working directory to the user's profile/home directory on startup allowing the removal of its installation folder even if a program started by the GUI (e.g. a web browser) is still running. Fixes #1518 (https://github.com/mbunkus/mkvtoolnix/issues/1518).
* ebml_validator: bug fix: elements with an unknown size weren't handled correctly.
* build system: fixed building and linking against libEBML and libMatroska if they're installed in a non-standard location.
* mkvpropedit, MKVToolNix GUI's chapter and header editors: the tools were unable to update elements in files without a seek head present. Fixes #1516 (https://github.com/mbunkus/mkvtoolnix/issues/1516).

2015-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues causing mkvmerge to write invalid data when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1498 (https://github.com/mbunkus/mkvtoolnix/issues/1498).
* all: MKVToolNix now requires gcc 4.8.0 or later or clang 3.4 or later for compilation.

2015-11-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the options for linking to the next/previous segment UID were wrong. Fixes #1511 (https://github.com/mbunkus/mkvtoolnix/issues/1511).

2015-11-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added JSON as an output format for file type identification. It can be activated with "--identification-format json --identify yourfile.ext" (or their short counterparts "-F json -i yourfile.ext").

2015-11-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the VC-1 handlig code was duplicating the first sequence headers with each mux. Fixes #1503 (https://github.com/mbunkus/mkvtoolnix/issues/1503).

2015-11-08 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: configure was checking for and using libintl if --without-gettext was used. Fixes #1501 (https://github.com/mbunkus/mkvtoolnix/issues/1501).

Have fun.

filler56789

29th November 2015, 01:23

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links,
all that I get is a page reload :confused:

Sparktank

29th November 2015, 01:35

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links,
all that I get is a page reload :confused:

Try disabling AdBlock and/or other plugins that block content on the site.

I got that at first but when I disabled AdBlock, it gave me the download right away.

---horizontal-line---

Thanks for the updates. :)

It's time I use the new GUI. I've been waiting out a few versions.

filler56789

29th November 2015, 01:41

@Sparktank: I don't have AdBlock, and FossHub is on the white list of my NoScript since ages ago.

Fortunately Videohelp does not use too much AJAX faggotry :cool:

P.S.: @Mosu: :thanks: again.

rsotome

29th November 2015, 04:43

Is anyone else having this problem with the new 8.6.0 build?

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

Mosu

29th November 2015, 08:13

Currently it's impossible to download the Windows builds from the FossHub site,
whenever I click on the links, all that I get is a page reload :confused:

I can download just fine with Chrome & Edge, however, Firefox shows the same reloads you're seeing. And this is Firefox without any addon affecting JavaScript or ads. I'll contact the FossHub staff; they're usually pretty fast in their reaction.

Edit: seems to me that after clicking on a download link again that page reload does trigger the regular download even on Firefox. Maybe that'll work for you, too.

vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.

MKVToolNix v24.0.0 released [Archive]  - Page 76 (2025)
Top Articles
Latest Posts
Recommended Articles
Article information

Author: Saturnina Altenwerth DVM

Last Updated:

Views: 5393

Rating: 4.3 / 5 (44 voted)

Reviews: 83% of readers found this page helpful

Author information

Name: Saturnina Altenwerth DVM

Birthday: 1992-08-21

Address: Apt. 237 662 Haag Mills, East Verenaport, MO 57071-5493

Phone: +331850833384

Job: District Real-Estate Architect

Hobby: Skateboarding, Taxidermy, Air sports, Painting, Knife making, Letterboxing, Inline skating

Introduction: My name is Saturnina Altenwerth DVM, I am a witty, perfect, combative, beautiful, determined, fancy, determined person who loves writing and wants to share my knowledge and understanding with you.