Log in

View Full Version : MKVToolNix v24.0.0 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 [81] 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

Perenista
11th March 2016, 20:12
I was looking into my uploaded Matroska files to Google Drive and discovered that one of them had playback issues, meaning that the entire video was fine, but at 4:18 the player freezes and no sound can be heard, then you can see macroblocks after 4:22 (that means it was skipped, and no one can see what goes between 4:18-22). At 18:00 the same thing happens for a few seconds. I downloaded the original file and noticed the same issue using MPC-HC, with a difference that MPC skips from 4 to 18 minutes.

Here's the thing:

1) The Blu-ray decrypted to my HDD looks fine in both these moments (if you look into the original authoring);

2) I used MakeMKV, plus MKVToolnix to edit the thing.

3) The MKVToolnix version was old, from the time Mosu didn't change how it looked like. It was used to split the files, since Google Drive allows only 15 GB for free users.

I don't remember if in those scenes the defect was already there.

However, using THE LAST MKVTOOLNIX version to do the same thing, the entire movie is fine.

My theory is that either it was a bug from this old MKVToolnix version or Google itself damaged the original file. As you can see from here:
https://productforums.google.com/forum/#!topic/youtube/lwJmU45tARI

There were reports of truncated files with shorter lengths in the past. What I never heard was that Google could modify the digital fingerprint of a video you upload there. As we all know, Youtube doesn't keep the original files, only the reencoded ones, while Google Drive gives us BOTH.

I mean, if I upload a 10 GB matroska, the original 10 GB file (unaltered) remains in their servers and when we try to watch, only the reencoded version (with smaller size and lossy) is available for streaming. In my case, I only noticed the problem because 50 minutes were remaining in file 2 and it stopped at 4 minutes.

(File 1 has 62 minutes and file 2 the remaining 50).

So I need to ask you if there's a possibility that ancient MKVToolnix versions could have done this, or perhaps the file-hash was altered and Google itself damaged those parts. Or maybe MakeMKV didn't create a MKV properly, even though this was an untouched/decrypted Blu-ray in my Hard Drive.

I need to know if there has been a similar case in the past, of course corrected in future versions, because I am relying on GD to store my backups. I would not like to find out that in the future some video I don't have a copy is damaged.

Another possibility is that the file itself was somehow damaged in my Hard Drive prior to uploading to Google Drive. I don't know how is that possible since my 1 TB Hard Drive is new and doesn't present any signs of defect, using a software like HDTune Pro to evaluate its health.

P.S. The video only had a DTS-HD MA 5.1 (plus DTS 5.1) track, and an english PGS track (subtitles). Video codec was AVC, High@L4.1 (codec ID: V_MPEG4/ISO/AVC).

Mosu
11th March 2016, 20:15
I've never heard of such a case before.

hubblec4
11th March 2016, 23:46
Hi Mosu

The "h264/MVC (right eye) stream" of a 3D Bluray is not handled by your GUI. Any plans to add MVC support?

sneaker_ger
11th March 2016, 23:49
https://github.com/mbunkus/mkvtoolnix/issues/1106

kuchikirukia
18th March 2016, 16:10
What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

MGarret
18th March 2016, 18:01
What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

I just want to know what I'm talking about when I put in a feature request to mpv.

With "previous/next segment UID" you don't need to make chapter file at all. You can use header editor (or use splitting feature and check "link files" option) to manually add Segment UID of the next/previous file to use as a segment. Players (splitter?) that support this feature should scan mkv's from the same folder to check for their Segment UID's.

I just checked this in recent VLC and it works.

kuchikirukia
18th March 2016, 19:04
Well, apparently wm4 can't understand the difference and he threw a rather big hissy fit about it. So apparently mpv won't be fully supporting mkv.

hubblec4
18th March 2016, 19:35
What's the difference between mkv segment linking specified in ordered chapters and the "previous/next segment UID" function of MKVToolNix?
mpv works with ordered chapters but it ignores linking the other way.
MPC-HC works great either way.
I don't want to install VLC to check, but I hear it has problems with the previous/next, too. Only one of them will work.

I just want to know what I'm talking about when I put in a feature request to mpv.

Segment linking is in my opinion not the best choice.
Ordered chapters are better. You can enter the "file(segment)-uid" easy at ChapterSegementUID.

For an automatic generation of such a xml-ordered chapter file you can use my chapterEditor->Matroska Menu.

kuchikirukia
18th March 2016, 20:00
Is there a way to do ordered chapters that will automatically enter the segment length? Because ordered chapters are nicer, but episode lengths aren't exactly identical so it becomes a major hassle to write them. If the series has an OP and ED at its very beginning and end you can mux a season in a minute with linked segments. To write chapters you need to fetch the UID for the episode and manually enter its length every time.

sneaker_ger
18th March 2016, 20:04
To write chapters you need to fetch the UID for the episode and manually enter its length every time.
You shouldn't need to fetch the UID of the episode. No segment UID given means "use current segment".

kuchikirukia
18th March 2016, 20:35
You shouldn't need to fetch the UID of the episode. No segment UID given means "use current segment".

Ah, true, I was thinking of the fact you need it to come back to that segment.
But you still need to manually enter the length and then save the chapter to the mkv, when with segment linking you can reuse the same mkvmerge input window and they'll all mux with the same setting. It ensures no stupid timing errors will be made. Missing a fraction of a second at the end of an episode can be missing something very important.
I strive to "me-proof" my workflows.

nevcairiel
18th March 2016, 21:18
So apparently mpv won't be fully supporting mkv.

No player on this planet "fully" supports mkv, it has way too many stupid/silly features that noone uses for nothing useful. :p

hubblec4
19th March 2016, 01:50
Is there a way to do ordered chapters that will automatically enter the segment length?
This feature is on my todo list. Segment UID and the lenght of the segment(mkv file) will be entered.

Because ordered chapters are nicer, but episode lengths aren't exactly identical so it becomes a major hassle to write them. If the series has an OP and ED at its very beginning and end you can mux a season in a minute with linked segments. To write chapters you need to fetch the UID for the episode and manually enter its length every time.

Therefor I wrote the Matroska Menu Editor.
Creating an ordered chapter xml (and a tags.xml) with all episodes and there linkings is done in less a minute.

hubblec4
19th March 2016, 01:53
No player on this planet "fully" supports mkv, it has way too many stupid/silly features that noone uses for nothing useful. :p

The player is the second one, and the first one is the splitter.
You're our man could change that. Your splitter is the only one where mkv works best.

kuchikirukia
19th March 2016, 01:58
This feature is on my todo list. Segment UID and the lenght of the segment(mkv file) will be entered.

oooooooooh, nice.

hubblec4
24th March 2016, 11:48
Hi Mosu
There are updates on DVDMenuXtractor (https://github.com/Matroska-Org/dvdmenuxtractor). Is robUx4 back and work again on the DMX?

Mosu
24th March 2016, 15:29
No idea, to be honest. He's working for VideoLan now, and he is doing work on the Matroska specs, especially in combination with IETF's CELLAR (https://datatracker.ietf.org/wg/cellar/charter/) working group. What his plans for DVDMenuXtractor are I cannot say; you should probably contact him directly.

hubblec4
24th March 2016, 18:08
Thanks for this info. I will try it to contact him.

Perenista
26th March 2016, 05:42
I've never heard of such a case before.Found a second file corrupted today, this time a MKV with 2 GB instead of more than 10 GB. This is no doubt a server issue from Google. And it was indeed a surprise for me, I thought anything uploaded there would be safe from this kind of problem. This is very odd, because the file was 100% OK when uploaded there (I am positive - others still are, from the same disc and several other contents), and all of sudden, this happens. Other people in the past reported the same thing.

How is it possible that a video file sitting in a Google server can become corrupted? If a Hard Drive fails, don't they have measures to prevent this from happening? If I knew this was going to happen, I would have generated hash values for all files prior to uploading them.

I don't even remember the last time this happened in my Hard Drive. If it happened, it must have happened with a very old Hard Drive, years ago, and the Hard Drive was already gone by the time that happened.

Nowadays I thought it was impossible for this kind of issue to ever happen. Guess I was mistaken and we can't even trust a company like Google with our data.

And I here thinking this was MKVToolnix's fault...

hubblec4
26th March 2016, 12:00
mmh..
I have the same issue with same mkv's stored on my extern HDD's.
On the first HDD I have stored Futurama episodes.
On another HDD(5) there are lot of movies.
Both HDD's were at the same time connected to my PC.
2 Years later I check the movies on HDD(5) and the last movies (in different folders) play Futurama video without sound.

Thats so strange that I thougt it is an HDD-issue.

Boulder
26th March 2016, 12:05
I've learnt that my computer needs to have the write caching enabled for external drives, otherwise it'll corrupt data randomly, it seems to concern large files such as movies. I always use mkvalidator on files I've processed to make sure that the transferred file is OK in the beginning, and then use Teracopy to copy (and verify) to the final location.

Mosu
26th March 2016, 15:26
Hey,

here's another release of MKVToolNix. There were tons of bug fixes all over the place. The most important one is probably in the HEVC handler which won't drop certain SEI NALUs anymore. This was a regression introduced in v8.7.0.

A change a lot of users of Windows and Mac OS will hopefully welcome is that mkvinfo launches with its GUI by default now unless the option "--no-gui" is given. Users of these two OSes often start mkvinfo by clicking on the executable instead of using start menu entries making adding the parameter "--gui" somewhat difficult. The behavior for other OSes has not been changed.

One of the new features is mkvmerge's capability to generate chapters automatically whenever a new file is appended. Additionally it can also generate chapters in fixed intervals. This can be turned on in the GUI, of course.

There's one change for package maintainers: a Korean translation of the programs and the man pages has been added.

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).

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's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since the previous release:

2016-03-26 Moritz Bunkus <moritz@bunkus.org>
* Released v9.0.0 "Power to progress".

2016-03-25 Mike <kona8lend@gmail.com>
* build system: implemented support for explicit pre-compiled headers for Linux and Mac OS.

2016-03-25 Moritz Bunkus <moritz@bunkus.org>
* Installer: fixed support for silent installation and uninstallation.

2016-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two more issues in the conversion of teletext subtitles to SRT subtitles: 1. Packets belonging to pages that don't contain subtitles were used as valid end points for subtitles causing entries to become very short (e.g. 40ms). 2. Sometimes the timestamps of wrong packets were used as entry's start and end points causing start timestamps and durations that were slightly off. Second part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: MP4/QuickTime reader: audio tracks with the FourCC 'lpcm' are muxed as A_PCM/INT/LIT instead of A_QUICKTIME.
* mkvmerge: bug fix: MP4/QuickTime reader: audio tracks can contain two instances of certain header fields (channel count, bits/sample & channel, sample rate) in the STSD atom: one instance in the version 0 header and one in the version 2 header parts. So far mkvmerge has used those from the version 0 header only and ignored the ones from the version 2 header. This has been changed to match the behavior of other players and MP4 readers like ffmpeg. If the STSD atom contains a version 2 structure then the fields from it will be used. Otherwise the fields from the version 0 part will be used. Fixes #1633 (https://github.com/mbunkus/mkvtoolnix/issues/1633).

2016-03-21 Moritz Bunkus <moritz@bunkus.org>
* all: new feature: added a new translation of both the programs and the man pages to Korean by Potato (see AUTHORS).
* MKVToolNix GUI: chapter editor enhancement: added a button next to the 'segment UID' controls that enable the user to select a Matroska file. The GUI reads that file's segment UID and enters its value into the input field.

2016-03-20 Moritz Bunkus <moritz@bunkus.org>
* build system: added an option to configure »--without-qt-pkg-config«. Normally configure uses pkg-config for detecting Qt and setting QT_CFLAGS and QT_LIBS. With this option configure won't use pkg-config and rely on the user having set both variables before running configure. This enables using Qt on systems where no pkg-config files are generated (e.g. Qt 5.6.0 on MacOS with frameworks enabled).

2016-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: change: on Windows and Mac OS mkvinfo will now launch the GUI by default unless the option »--no-gui« (or »-G«) has been given. This is due to the fact that on both OS users often use portable versions respectively disk images and launch the executable directly and not via start menu entries. In those situations adding command line options for launching the GUI is unnecessarily difficult.

2016-03-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues in the conversion of teletext subtitles to SRT subtitles: 1. Consecutive teletext packets with the same content are now merged into a single entry instead of resulting in multiple entries. 2. The calculation of a packet's duration was wrong in certain situations. Part of the fix for #1623 (https://github.com/mbunkus/mkvtoolnix/issues/1623).

2016-03-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: the playlist items are sorted by their position within the playlist by default.
* MKVToolNix GUI: merge tool (playlist selection dialog) enhancement: double-clicking on a playlist will select and add that playlist.

2016-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added the number of bits per sample to the verbose/JSON identification output for FLAC files.

2016-03-11 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: fixed the duplication of VPS, SPS, PPS and SEI NALUs when extracting h.265/HEVC tracks. See #1076 (https://github.com/mbunkus/mkvtoolnix/issues/1076) and #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).
* mkvmerge: bug fix: reverted the patch by Vladimír Pilný that made the h.265/HEVC not store SEI NALUs with the frames during muxing. It was supposed to prevent having the SEI NALUs present twice when extracting HEVC due to some SEI information also being stored in the codec private data, but it dropped a lot of other SEI NALUs irrevocably. Fixes #1621 (https://github.com/mbunkus/mkvtoolnix/issues/1621).

2016-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the --sub-charset option is now ignored for text subtitle files that start with a byte-order mark (BOM) bringing the behavior in line with the documentation. Fixes #1620 (https://github.com/mbunkus/mkvtoolnix/issues/1620).

2016-03-07 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: new feature: implemented the extraction of Big Endian PCM (codec ID A_PCM/INT/BIG) to WAV files. The content will be byte-swapped into Little Endian PCM in the process.
* mkvmerge: enhancement: Big Endian PCM tracks will now be byte-swapped into Little Endian PCM, and the codec ID A_PCM/INT/LIT will be used. This was done due to a lot of players not supporting Big Endian PCM inside Matroska.

2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586 (https://github.com/mbunkus/mkvtoolnix/issues/1586).

2016-02-28 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: job queue enhancement: completed jobs will now be removed from the queue automatically on exit if the job has been added more than 14 days ago in order not to let the queue grow arbitrarily large. This feature can be turned off and the number of days can be adjusted in the preferences.

2016-02-27 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, MKVToolNix GUI's header editor: bug fix: fixed the handling of files where the last level 1 element has an unknown size. The programs will now either fix this element to have a known size or abort the process with an appropriate error message but without modifying the file. Fixes #1601 (https://github.com/mbunkus/mkvtoolnix/issues/1601).

2016-02-25 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: when extracting chapters in the simple format the user can use the new option »--simple-language …« for selecting the chapter names that are output. Normally the first chapter name found in each atom is used. With this option mkvextract looks for a chapter name whose language matches the specified one. Implements the feature enhancement part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).
* mkvextract: several issues regarding the extraction of chapters in the simple format have been fixed: if multiple names with different languages were present then an entry had been written for each name; the total number of entries written was wrong; the wrong entries were written. The new code only writes the first name found from the top-most chapter atoms of all editions. Chapters flagged as hidden or as not enabled are not extracted at all. Fixes the bug part of #1610 (https://github.com/mbunkus/mkvtoolnix/issues/1610).

2016-02-24 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new chapter editor feature: added an option to multiply all chapter timecodes by a factor to the "additional modifications" dialog. Implements #1609 (https://github.com/mbunkus/mkvtoolnix/issues/1609).

Have fun :)

73ChargerFan
26th March 2016, 19:57
Cool, I tried auto chapter creation to combine a bunch of 3 minute "sing alongs" from an HD-DVD and it worked great. After the file was created, I used Edit Chapters existing MKV to change the chapter names.

Thank you very much!

hubblec4
26th March 2016, 21:29
Hi Mosu

I should you remember to my feature request after new versions.

Now seems a good time, cause you have change a bit the mkvinfo.exe. (I know its a little and not the "output info")

But could you now implement a output of the Duration in nano-sec?

This is a part of an info text

|+ Segment information size 131
| + Timecode scale: 1000000 size 7
| + Muxing application: libebml v1.3.3 + libmatroska v1.4.4 size 38
| + Writing application: mkvmerge v8.8.0 ('Wind at my back') 32bit size 44
| + Duration: 2763.744s (00:46:03.744) size 7
| + Date: Tue Mar 01 19:27:08 2016 UTC size 11
| + Segment UID: 0x98 0x7e 0xe4 0x54 0x5a 0xdf 0x74 0x96 0xa6 0xa2 0xc4 0xb1 0x44 0xd1 0x54 0xd9 size 19

How you calculate this duration? Is in the info output enaugh information to calculate the duration by my self?

Mosu
26th March 2016, 21:39
No, I'm sorry. As I've said before changing the existing format is a recipe for breaking other people's tools.

If you need the file duration in a higher resolution then use mkvmerge's JSON (or verbose) identification mode. It includes the segment duration in nanoseconds.

Neither mkvinfo nor mkvmerge calculates the duration; it's a header field in the file whose value is output.

mkvmerge calculates the duration and sets the header field during muxing, of course. It's the difference between the highest sum of a frame's timestamp and its duration in the segment minus the lowest timestamp of all frames in the segment. Note that the header field itself is based on the segment's timestamp scaling value. This means that with standard settings (timestamp scaling at 1000000) its resolution is milliseconds even if mkvmerge's JSON identification mode always outputs nanoseconds.

SeeMoreDigital
26th March 2016, 22:02
Thanks for the new version :)

Sparktank
26th March 2016, 23:14
:thanks: Appreciate the A_PCM/INT/BIG conversion to A_PCM/INT/LIT on the fly.

hubblec4
27th March 2016, 00:25
No, I'm sorry. ...

If you need the file duration in a higher resolution then use mkvmerge's JSON (or verbose) identification mode. It includes the segment duration in nanoseconds.
...

Perfect, I will have a look.

Fullmetal Encoder
27th March 2016, 00:31
2016-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, MKVToolNix GUI: new feature: added switches (»--generate-chapters« and »--generate-chapter-name-template«) and their corresponding UI items for generating chapters while muxing. Two modes are currently supported: »when-appending« which creates one chapter at the beginning and an additional one each time a file is appended and »interval:…« which generates chapters in fixed intervals. Implements mkvmerge's and the GUI's part of #1586.


Thank you very much for seriously considering and implementing this. I think it's a huge leap forward in giving users practical access to one of Mastroska's most powerful features. And, as always, thanks for all your continued work on this terrific software.

filler56789
27th March 2016, 01:12
1) @Mosu: many :thanks: for the new version.

2)
mmh..
I have the same issue with same mkv's stored on my extern HDD's.
On the first HDD I have stored Futurama episodes.
On another HDD(5) there are lot of movies.
Both HDD's were at the same time connected to my PC.
2 Years later I check the movies on HDD(5) and the last movies (in different folders) play Futurama video without sound.

Thats so strange that I thougt it is an HDD-issue.
&&
I've learnt that my computer needs to have the write caching enabled for external drives, otherwise it'll corrupt data randomly, it seems to concern large files such as movies. I always use mkvalidator on files I've processed to make sure that the transferred file is OK in the beginning, and then use Teracopy to copy (and verify) to the final location.

Yes... FWIW:

http://forum.videohelp.com/threads/367509-Files-corrupted-when-copying-to-external-usb3-hdd

isidroco
27th March 2016, 06:34
mmh.. I have the same issue with same mkv's stored on my extern HDD's.....

Unfortunately, it happens that some bytes are changed. Now I always generate a MD5 checksum list of all files (with total commander) before making a backup. Then test backup's MD5 to exclude corruption. Sometimes a couple of bytes per Tb become corrupted, even with internal HDs. Usually SATA cables to blame.

PS: Thanks for this new version!

hubblec4
27th March 2016, 10:41
Thanks for this info to copying mkv's to an external HDD.
I have used "SuperCopier" for copy data over usb2/usb3 (I know the Win7 bug). I should use this software (or Teracopy -but its not 100% freeware) in future for all copys.

Mosu
27th March 2016, 10:45
Guys, this is a thread about MKVToolNix, not one about fighting with your OS or your hardware. Can we please drop the topic of USB drives and the associated file corruption? Thanks.

hubblec4
27th March 2016, 11:12
Hi Mosu

I have tried the identification with JSON and it seems to me the duration in nanosec is not really good calculated.
Only 0-digits fill the rest of nanosecs.


.....
"container": {
"properties": {
"container_type": 17,
"duration": 2763136000000,
"is_providing_timecodes": true,
"segment_uid": "bca9e279b82f5fba9f315cfd3655add8"
},
"recognized": true,
"supported": true,
"type": "Matroska"
...

Groucho2004
27th March 2016, 11:14
I suppose it's by design that the new mkvmerge switch "--generate-chapters interval:xxx" only supports chapter marks at intervals >= 300 seconds?

Mosu
27th March 2016, 11:16
Hi Mosu

I have tried the identification with JSON and it seems to me the duration in nanosec is not really good calculated.
Only 0-digits fill the rest of nanosecs.

Please re-read what I've written above (http://forum.doom9.org/showthread.php?p=1762154#post1762154). The header field's resolution is determined by the file's timestamp scaling.

Mosu
27th March 2016, 11:19
I suppose it's by design that the new mkvmerge switch "--generate-chapters interval:xxx" only supports chapter marks at intervals >= 300 seconds?

No, you can use any duration. I've just given 10s a try, and it works just fine:

[0 mosu@sweet-chili (master) ~/prog/video/data] mkvmerge -o v.mkv v.avi --generate-chapters interval:10s
mkvmerge v9.0.0 ('Power to progress') 64bit
'v.avi': Using the demultiplexer for the format 'AVI'.
'v.avi' track 0: Using the output module for the format 'AVC/h.264 (unframed)'.
'v.avi' track 1: Using the output module for the format 'AAC'.
Using the track with the ID 0 from the file 'v.avi' as the reference for chapter generation.
The file 'v.mkv' has been opened for writing.
'v.avi' track 0: Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 640/352.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@sweet-chili (master) ~/prog/video/data] mkvextract chapters v.mkv
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionUID>15387469689991544545</EditionUID>
<ChapterAtom>
<ChapterUID>5188743258543738188</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1343074347162551858</ChapterUID>
<ChapterTimeStart>00:00:10.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>12827577923699787492</ChapterUID>
<ChapterTimeStart>00:00:20.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14365894815514065430</ChapterUID>
<ChapterTimeStart>00:00:30.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>15150422538290076290</ChapterUID>
<ChapterTimeStart>00:00:40.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14737049900229639724</ChapterUID>
<ChapterTimeStart>00:00:50.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 06</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>17067655115020329310</ChapterUID>
<ChapterTimeStart>00:01:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 07</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>273832462594112675</ChapterUID>
<ChapterTimeStart>00:01:10.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 08</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
</EditionEntry>
</Chapters>

hubblec4
27th March 2016, 11:24
Please re-read what I've written above (http://forum.doom9.org/showthread.php?p=1762154#post1762154). The header field's resolution is determined by the file's timestamp scaling.

Ok sorry, its not possible to get nanosec precision, cause is the timestamp scaling is limited to millisec.

Can I extract the FPS and the frames info with mkvmerge or info.exe?

Mosu
27th March 2016, 11:27
No. A Matroska file doesn't have a number of frames per second, it only has distinctly timestamped frames. See this FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Wrong-frame-rate-displayed). The video track's default duration field (output by both mkvmerge and mkvinfo) is only an approximation as it is scaled by timestamp scaling, too.

hubblec4
27th March 2016, 11:34
OK. Than the spec should updated there :-)
Is this possible?

Mosu
27th March 2016, 11:44
You're welcome to work on this and suggest appropriate specs. The places to talk about spec changes are the Matroska-devel (https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel) and the IETF CELLAR (https://datatracker.ietf.org/wg/cellar/documents/) working group.

Groucho2004
27th March 2016, 12:35
No, you can use any duration. I've just given 10s a try, and it works just fine
I tried this:
mkvmerge --output "test.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:300s
MediaInfo correctly reports the chapters:
Menu
Count : 109
Count of stream of this kind : 1
Kind of stream : Menu
Kind of stream : Menu
Stream identifier : 0
Chapters_Pos_Begin : 90
Chapters_Pos_End : 109
00:00:00.000 : en:Chapter 01
00:05:00.000 : en:Chapter 02
00:10:00.000 : en:Chapter 03
00:15:00.000 : en:Chapter 04
00:20:00.000 : en:Chapter 05
00:25:00.000 : en:Chapter 06
00:30:00.000 : en:Chapter 07
00:35:00.000 : en:Chapter 08
00:40:00.000 : en:Chapter 09
00:45:00.000 : en:Chapter 10
00:50:00.000 : en:Chapter 11
00:55:00.000 : en:Chapter 12
01:00:00.000 : en:Chapter 13
01:05:00.000 : en:Chapter 14
01:10:00.000 : en:Chapter 15
01:15:00.000 : en:Chapter 16
01:20:00.000 : en:Chapter 17
01:25:00.000 : en:Chapter 18
01:30:00.000 : en:Chapter 19

If I change "interval" to "250s", there are no chapter marks visible in mpc-hc and there is no "Menu" section present in the MediaInfo export.

Mosu
27th March 2016, 12:48
I just tried 250s (with the GUI on Windows this time); works just fine here, too. I highly suspect an error on your part (e.g. you've opened the wrong file in the player, or you actually didn't mux and only added the job to the queue or something like that).

Groucho2004
27th March 2016, 13:13
I highly suspect an error on your part (e.g. you've opened the wrong file in the player, or you actually didn't mux and only added the job to the queue or something like that).
It would have been sufficient to say that you can't reproduce this behaviour. Accusing me of being an idiot/noob is not necessary, I have been using mkvmerge for many years.

Never used the gui but just for the fun of it just tried it. Same result.

Until now I have been using a tool I wrote that parses the streams and generates a chapter file for import into mkvmerge. I was hoping that the new option would eliminate that step.

So, just ignore my posts, I'll stick with my current method.

Mosu
27th March 2016, 13:43
I'm sorry you feel put down, but I wasn't calling you names, nor a noob, and I definitely didn't intend to. There have been countless times where users have reported supposed problems and it turned out they were making some kind of error when checking the result. Hell, I do it often enough myself, especially when I'm debugging code (e.g. I'm outputting the wrong variables leading me to think there is a bug when there actually isn't). To err is fundamentally human. It's not a character defect.

Typical issues that users including myself have made in the past: playing the wrong file instead of the one mkvmerge has just created (wrong file name, wrong directory…); not actually having run mkvmerge after changing some options; not looking at mkvmerge's output and not seeing that an error message was output (e.g. trying to write to a file which is still open in a player and locked by it). Making any of these errors says nothing at all about a person's proficiency. One can do a task correctly a hundred times only to make an error the next time. Does that make him an idiot? Far from it.

Now back to mkvmerge not creating chapters. Can you please take the command line you've written above and run the following modifications of it:

mkvmerge --output "test-300.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:300s
mkvmerge --output "test-250.mkv" --language 0:eng --compression 0:none --default-duration 0:24000/1001p ( "test.264" ) --language 0:eng ( "test.m4a" ) --track-order 0:0,1:0 --generate-chapters interval:250s
mkvextract chapters test-300.mkv
mkvextract chapters test-250.mkv

What is the output of the two mkvextract commands?

Groucho2004
27th March 2016, 15:40
Sorry, I guess I over-reacted a bit. Before I report something like this I always double- or triple-check the results to be sure that it's not a silly user error as you mentioned.

I ran your command lines and "test-300" outputs what was to be expected:
<?xml version="1.0"?>
<!-- <!DOCTYPE Chapters SYSTEM "matroskachapters.dtd"> -->
<Chapters>
<EditionEntry>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<EditionUID>15240921881376772994</EditionUID>
<ChapterAtom>
<ChapterUID>6755968388673756333</ChapterUID>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 01</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10765774132084890519</ChapterUID>
<ChapterTimeStart>00:05:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 02</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>15181808861288630163</ChapterUID>
<ChapterTimeStart>00:10:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 03</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11211224267078624444</ChapterUID>
<ChapterTimeStart>00:15:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 04</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>12772237345159149743</ChapterUID>
<ChapterTimeStart>00:20:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 05</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>6027843348120838316</ChapterUID>
<ChapterTimeStart>00:25:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 06</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>8309850999047443333</ChapterUID>
<ChapterTimeStart>00:30:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 07</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>7090206436313069997</ChapterUID>
<ChapterTimeStart>00:35:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 08</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10302068659269412522</ChapterUID>
<ChapterTimeStart>00:40:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 09</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>6516520102347956407</ChapterUID>
<ChapterTimeStart>00:45:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 10</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>17909294277027573424</ChapterUID>
<ChapterTimeStart>00:50:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 11</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>10533455910740190633</ChapterUID>
<ChapterTimeStart>00:55:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 12</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>8062765570784066221</ChapterUID>
<ChapterTimeStart>01:00:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 13</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14454955690992927150</ChapterUID>
<ChapterTimeStart>01:05:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 14</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>9588557843478759354</ChapterUID>
<ChapterTimeStart>01:10:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 15</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>3736210551441426074</ChapterUID>
<ChapterTimeStart>01:15:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 16</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>11616954146485479823</ChapterUID>
<ChapterTimeStart>01:20:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 17</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>14130439254598456491</ChapterUID>
<ChapterTimeStart>01:25:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 18</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
<ChapterAtom>
<ChapterUID>1388229754696499842</ChapterUID>
<ChapterTimeStart>01:30:00.000000000</ChapterTimeStart>
<ChapterDisplay>
<ChapterString>Chapter 19</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
</ChapterAtom>
</EditionEntry>
</Chapters>


"test-250" outputs nothing.

I'll try it with different streams later to see if the same happens.

Mosu
27th March 2016, 15:51
Huh… Very strange. I honestly have no idea yet why no chapters are generated for you. As I said I cannot reproduce it at the moment; I've even tried the very same command line I've posted (the 250s one) with the same file types. Maybe it depends on the actual files in question.

Mosu
27th March 2016, 16:29
Hah, I can reproduce it now. It seems that it's a question of the number of chapters that are created whether or not it breaks. So far I had only tried 250s with a 45min movie, but when I use 25s no chapters are present in the output file. I'll investigate. Thanks for pointing it out.

Mosu
27th March 2016, 17:03
The issue with the chapter generation should be fixed in pre-builds 01163 and higher (https://mkvtoolnix.download/windows/pre/).

manolito
27th March 2016, 17:11
Until now I have been using a tool I wrote that parses the streams and generates a chapter file for import into mkvmerge. I was hoping that the new option would eliminate that step.


Since I am stuck with version 0.7.80 (I'm still using XP), would you consider publishing your tool?

So far I have been using a software called MKV Chapterizer for this task, but it is not always reliable.


Cheers
manolito