Log in

View Full Version : MKVToolNix v99.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

Perenista
11th June 2020, 23:11
Read:
https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Appending-&-splitting-FLAC-audio-tracks-not-supportedI have noticed after writing this post that my 2 uploads somehow have stuttering issues not solved after hours. They are both online at Youtube, but I am already checking the whole thing again just to confirm if this is only Youtube's doing or if they became this way after I combined them:

The 1st video has almost 12 hours (Youtube limits to 12 hours or 128 GB). This I believe has 60-70 GB:
LINK REMOVED. A NEW ONE IS BEING SENT RIGHT NOW, AND I ALREADY CONFIRMED IT'S OK. THIS ISSUE WAS FIXED BY FOLLOWING THESE TIPS (https://forum.doom9.org/showthread.php?t=170249&page=12)

The 2nd video has 3 hours and more or less 22 GB:
LINK REMOVED. A NEW ONE IS BEING SENT RIGHT NOW, AND I ALREADY CONFIRMED IT'S OK. THIS ISSUE WAS FIXED BY FOLLOWING THESE TIPS (https://forum.doom9.org/showthread.php?t=170249&page=12)

*****************
(Update: problem solved, I changed the audio to W64 and now the newer MKVtoolnix versions handle it just fine. Youtube is also showing the full video without issues: https://www.youtube.com/watch?v=I-hAea-eYz8 - no more stuttering, probably caused by the old audio track). For the moment I gave up the idea of reencoding the video (in H.265 it would still be as much as good as it is now), which would in my calculations be reduced to 50% of its current size, because it would take too much time in my 2014 PC.
*****************

I recorded this content (Metal Gear Solid PS1 game) using an old software many will know... called FRAPS (which is crap and for years no one uses anymore).

Unfortunately I didn't use OBS at the time so the files end up being very big and reencoding the whole thing isn't something I am willing to do at this point (if it's done then the resulted file would have to be 98% similar in terms of PQ). But in this case I suspected before you posted this had nothing to do with the video, since in the past I remember having a similar problem:

https://forum.doom9.org/showthread.php?p=1786481#post1786481

In this case the total filesize is 95 GB and almost 15 hours. I had to split into 15 GB parts because that's the Google Drive free account max disk space, I use multiple accounts for backup. That's why I splitted back then. When I wanted to watch the whole thing I just had to append.

Mosu
12th June 2020, 18:43
Would be possible to have an abort job in the Multiplexer window too, without having to switch to Job output one?

I don't want any controls working on the current job in the multiplexer window as it's completely intransparent which job they would actually work on. There might be something else entirely muxing currently, that has nothing to do with what's shown in the multiplexer tool at that moment.

That plus a switch in preferences to remove or not the muxed file if a job is aborted.

You mean the incomplete output file(s)? Hmm… that I would consider. Please open a feature request for it over on Gitlab (https://gitlab.com/mbunkus/mkvtoolnix/-/issues); makes it harder to forget about it again :) Thanks.

Liisachan
12th June 2020, 19:44
@foxyshadis
@lvqcl
Thanks for the great info. I tried --no-md5-sum and it works perfectly (though a WARNING is shown when encoding). If the correct MD5s are desired, I guess one can still append/split FLAC.mkv by
1 demuxing FLAC
2 decoding it to WAV (*)
3 remuxing it with the original MKV while disabling FLAC track(s)
4 MKVToolNix can append/split this
5 replace the audio in the resulted file(s) with FLAC, by demuxing WAV, compressing, and remuxing.
(*) or transcode it to WavPack so Step 5 will be unnecessary

@Mosu
Something very minor, not practicaly important: When the "second" is not integer in DateUTC, Header Editor's behavior is slightly inconsistent, e.g. the same time 01:23:45.9 may be shown as 01:23:45 or 01:23:46 depending on the year:
Original Date 2000-12-31 01:23:45.9 -> Header Editor shows 01:23:46
Original Date 2001-12-31 01:23:45.9 -> Header Editor shows 01:23:45
Header Editor doesn't refuse to write a "bad" Date not expressible as EBML, when it is specified by the user.
New Date 2293-04-11 23:47:16 -> Header Editor writes x = 0x7FFFFFFFCD0D2800 correctly.
New Date 2293-04-11 23:47:17 -> Header Editor overflows: 0x8000000008A7F200 = x + 10^9 is written (=1708-09-22 00:12:43.290448384). If Matroska lives long, eventually the year 2293 problem will occur...

Nejiro
16th June 2020, 18:47
When I use the program I sometimes get error or warning messages but when I click to go and see them it doesn't show me anywhere, where can I find them?
Thanks

Boulder
16th June 2020, 18:49
Sometimes I have replace audio and subs from external sources. There is where real fun starts. :p

You just have to follow the proper naming scheme to make your batch muxing work :) Bulk Rename Utility is something I also use quite a lot with mkvmerge related things.

Mosu
16th June 2020, 20:20
When I use the program I sometimes get error or warning messages but when I click to go and see them it doesn't show me anywhere, where can I find them?

The "job output" tool (last icon in the job selector on the left) contains the output of the currently running job. It's split into three panes: the regular output on the top, the warnings on the bottom left and errors on the bottom right.

For past jobs you can go to the "job queue" tool, right-click on the job that contains warnings/errors and select "view output" from the context menu. This will open a new tab in the "job output" tool and switch to that new tab. That tab will only contain the output/warnings/errors generated by that one job.

Nejiro
16th June 2020, 22:03
Thank you so much

tormento
17th June 2020, 10:58
I have tried to mux some HEVC video to Matroska and I've found the orientation is lost, i.e. a vertical video on mobile becomes horizontal.

Is there any manual setting we can use to set back the original rotation or any tweak you can introduce?

Thanks.

hubblec4
17th June 2020, 11:57
Is there any manual setting we can use to set back the original rotation or any tweak you can introduce?


You can/must use a Tag to rotate the movie. The official ProjectionPoseRoll element is not supported in the players today.

tormento
17th June 2020, 14:28
You can/must use a Tag to rotate the movie. The official ProjectionPoseRoll element is not supported in the players today.
Which tag allows me to do it? Where can I set it in MKV GUI?

I have looked at HEVC file with MediaInfo and there is a Video TAG, such as

Rotation : 90°

Isn't possible to have MKV GUI to automatically recognize Rotation and set the correct tag?

Perenista
17th June 2020, 18:38
Using the delay for audio tracks usually works everywhere? Sometimes I introduce a negative delay for some audio tracks. Other times I put a positive one, also for subtitles. I know we can edit both cases and avoid using the delay field from MKVToolnix, but I think this will imply a reencode at least for audio.

What I find odd is that I once uploaded a video excerpt to Vimeo and the delay was ignored. The same video sent to Dailymotion worked as intended. And for both services I uploaded the same file.

sneaker_ger
17th June 2020, 19:31
Using the delay for audio tracks usually works everywhere?
Most often it works. But not always (as you found out). If you want to be sure you have to take the extra steps to pre-pend silence outside MKVToolNix. (Negative audio delays usually work because mkvmerge does delete audio frames, then).

Other times I put a positive one, also for subtitles.
Subtitle delays should always work, at least with text subtitles.

I know we can edit both cases and avoid using the delay field from MKVToolnix, but I think this will imply a reencode at least for audio.
Depends on the format and software you are using. Softwares like eac3to and delaycut may delay audio without re-encoding. If that doesn't work ffmpeg may be able to encode some silence which you can manually prepend in mkvmerge.

hubblec4
17th June 2020, 22:34
Which tag allows me to do it? Where can I set it in MKV GUI?

I have looked at HEVC file with MediaInfo and there is a Video TAG, such as

Rotation : 90°

Isn't possible to have MKV GUI to automatically recognize Rotation and set the correct tag?

MKVToolNix has no Tags editor and the ROTATE Tag is not an official one.
You can use my chapterEditor -> MatroskaTools->Tags
In a SimpleTag set
TagName = ROTATE
TagString = 90 or -90
TargetUID = the type is TagTrackUID and the UID is the video track UID

vertigo220
20th June 2020, 16:05
Not sure if this is a bug or if I'm just not understanding how it's supposed to work, but I have some audio files and some video files, the latter consisting of a single frame each. I'm trying to combine them into a file where each image displays for the duration of one of the audio files. I tried changing the duration/FPS, but since they're different lengths, that didn't work. I tried stretching them, but if I stretch them by the proper amount (which took a fair amount of trial and error to figure out), they show for the proper durations, but the file is twice as long as it's supposed to be. In this case, if the first audio file is e.g. 90s long, and therefore the first chapter in the final file should also be 90s, the chapter is actually 180s long and when it reaches 90s it jumps to the next chapter. But if I click in the timeline between 90s and 180s, it just "plays" all the way to chapter 2. If I cut the stretch factors in half, the total and chapter lengths are correct, but the images only display half as long as they're supposed to, so the image for chapter two in the above example would display at 45s.

Any ideas either on how to do this or whether this is actually a bug? It seems like one to me, but apparently I have to know for sure before reporting it as such.

sneaker_ger
20th June 2020, 17:26
Hard to answer without having a sample file at hand. Video timings are usually(*) not related to chapters. You could try to manually set the timings for the video via timestamp (v2) files. https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.external_timestamp_files
(To check your output file let mkvextract create a timestamp v2 file for your video track or look into mkvinfo.)
If it still does not work I would say it is a problem of your player.



(*) if we ignore ordered chapters

jlw_4049
23rd June 2020, 21:16
I was wondering if there was anyway to allow the extraction of the DTS CORE from DTS-HD files via the mkvextract CLI?

sneaker_ger
24th June 2020, 17:22
Not directly, only via mkvmerge --reduce-to-core followed by mkvextract. Is ffmpeg an option for you? I think it should allow doing it in one operation (via -c copy and the "dca_core" bitstream filter).

Mosu
27th June 2020, 20:15
Hey everyone,

summer's upon us, and surely we're all itching to stay at home some more, aren't we? Well, despair not, at least you can update your MKVToolNix version to the latest & shiniest there ever was.

This release features massive improvements to the handling of Blu-ray playlists (MPLS files) & corresponding MPEG transport streams (M2TS files), both bug fixes and real enhancements. See the news below for details.

Important news for package managers are the new reuquirements for libEBML/libMatroska & the main development branch having been renamed in my source code repo. Again, see the news for details.

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

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:


Version 48.0.0 "Sick Of Losing Soulmates" 2020-06-27
New features and enhancements

mkvmerge: AC-3: file identification will report AC-3 tracks encoded in Dolby Surround EX as codec "AC-3 Dolby Surround EX". Implements #2740 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2740).
MKVToolNix GUI: multiplexer: on new installations the GUI will now recognize all known ISO 639-2 language codes in file names by default instead of only the top 100 of languages by native speakers.
MKVToolNix GUI: multiplexer: on new installations the list of "often used languages" will by default only contain certain agnostic ones ("multiple languages", "no linguistic content", "reserved for local use", "uncoded languages"), "English" and the default user interface language. The "list of spoken languages by native speaks" isn't used anymore. Also implements #2716 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2716).
MKVToolNix GUI: header editor: added an option to remove all attachments to the tree context menu. Implements #2835 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2835).
MKVToolNix GUI: while the GUI is running it will remember the last page that was selected when the preferences dialog is closed. Upon re-opening the preferences that page will be selected by default. Implements #2852 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2852).

Bug fixes

mkvmerge: fixed a segmentation fault when exiting prematurely due to write errors such as the destination having run out of space. Fixes #2843 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2843).
mkvmerge: DTS: fixed wrong channel count for DTS tracks with XCh extensions. Fixes #2715 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2715).
mkvmerge: MPEG TS reader: fixed detecting h.264/AVC and h.265/HEVC tracks that consist of only a single frame. Part of the fix of #2849 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2849).
mkvmerge: MPEG TS reader: fixed handling of unbounded PES sizes for tracks that consist of only a single PES packet. Part of the fix of #2849 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2849).
mkvmerge: MPEG TS reader: PGS subtitle tracks are now exempt from the "detect bogus subtitle timestamps" heuristic which could lead to some PGS subtitles not being timestamped correctly. Symptoms were that they were shown at the wrong time or that they were shown indefinitely. Fixes #2736 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2736) and partially fixes #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: MPEG TS reader: when reading MPLS playlists the start timestamps of a play items were handled wrong: all the timestamps of packets read were compared to that start timestamp, dropping those packets whose timestamps were smaller than the play item's start timestamp. The correct behavior is to accept all packets as soon as the first one with a timestamp equal to or larger than the play item's start timestamp is encountered. This could result in PGS subtitle entries located right at the start of the play item being garbled/lost as they consist of multiple PES packets for which some timestamps are often slightly smaller. Part of the fix of #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: MPEG TS reader: when reading MPLS playlists mkvmerge will no longer read the whole M2TS files they reference, processing only the packets lying inside the timestamp range given by the playlists's play item's start & end timestamps. Instead mkvmerge will use the index information present in corresponding clip information (CLPI) files in order to seek to the nearest file position of the play item's start timestamp. Additionally mkvmerge will simply stop processing a file once the end timestamp is seen. This change greatly speeds up processing files from which only small portions must be read. Part of the fix of #2824 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2824).
mkvmerge: WavPack: fixed support for files created by v5 of the program. Checksums, DSD audio data and non-standard sampling rates are handled correctly. Patch by David Bryant.
MKVToolNix GUI: multiplexer: fixed the cursor being positioned wrong after entering or pasting characters that aren't allowed in file names into the "destination file" control. Fixes #2855 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2855).

Build system changes

libEBML v1.4.0 and libMatroska v1.6.0 are now required.

Other changes

The source code repository's main development branch was renamed to "main".

Have fun :)

jlw_4049
27th June 2020, 22:56
Not directly, only via mkvmerge --reduce-to-core followed by mkvextract. Is ffmpeg an option for you? I think it should allow doing it in one operation (via -c copy and the "dca_core" bitstream filter).

Thank you sneaker! I was asking for the ability to extract/reduce to core when creating a GUI.

andiandi
29th June 2020, 20:54
I wondered if the cut was GOP accurate ?

Because on specific videos, it's impossible to know, AFAIK, if it's open gop or not.

Selur
5th July 2020, 19:53
How to properly mux 29.97 fps interlaced avc content with mkvmerge?

My source is interlaced AVC (duration: 00:00:41.542) and using:
mkvmerge --ui-language en -o "E:\Output\avc - interlaced_new_new.mkv" --global-tags "E:\Output\avc - interlaced_new_new_2020-07-05@20_21_37_3510__03.xml" -d 0 --default-track 0:yes XXXXXXX--fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "E:\Output\avc - interlaced_new_new_2020-07-05@20_21_37_3510_02.264" --default-track 0:yes --sync 0:-67 --forced-track 0:no -a 0 --compression -1:none --no-video --no-subtitles --no-chapters "E:\Output\iId_1_aid_4352_DELAY_-67ms_2020-07-05@20_21_37_3510_01.ac3"
as a base (and replacing the XXXXXXX):

I get:
when using:
--default-duration 0:30000/1001i --fix-bitstream-timing-information 0

Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Original frame rate : 14.985
Original frame rate : 14.985 (15000/1001) FPS
FrameRate_Original_Num : 15000
FrameRate_Original_Den : 1001
Duration : 00:01:23.083


when using:
--default-duration 0:60000/1001i --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542


when using:
--default-duration 0:30000/1001fps --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542


when using:
--default-duration 0:60000/1001fps --fix-bitstream-timing-information 0
Frame rate mode : VFR
Frame rate mode : Variable
Frame rate : 119.884
Frame rate : 119.884 FPS
Original frame rate : 60.000
Original frame rate : 60.000 FPS
Duration : 00:00:20.770

when using:
--default-duration 0:30000/1001fps
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542


when using:
--default-duration 0:30000/1001i
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:01:23.083

when using:
--default-duration 0:60000/1001fps
Frame rate mode : Variable
Frame rate : 119.884
Frame rate : 119.884 FPS
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 41 s 501 ms

when using:
--default-duration 0:60000/1001i
Frame rate mode : Variable
Frame rate : 59.940
Frame rate : 59.940 (59940/1000) FPS
FrameRate_Num : 59940
FrameRate_Den : 1000
Original frame rate : 29.970
Original frame rate : 29.970 (30000/1001) FPS
FrameRate_Original_Num : 30000
FrameRate_Original_Den : 1001
Duration : 00:00:41.542

So none of the above seem to totally correct, what I was aiming for was:
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:00:41.542


What am I missing? How to do it correctly?

Cu Selur

Mosu
6th July 2020, 11:23
"--default-duration 0:30000/1001i" should be the correct one. Yes, for interlaced content the track's "default duration" must be half the duration compared to progressive content (meaning other tools might show that as double the frame rate). Remember, Matroska doesn't have a header field for a progressive frame rate; it only has a field that tells the default duration of a single Matroska frame — whatever that "Matroska frame" might contain. For interlaced video content it's a single field, and a single field is shown half as long as a full progressive frame, obviously.

Selur
6th July 2020, 16:10
Confused,...when using "--default-duration 0:30000/1001i" I get:
Frame rate mode : Constant
Frame rate : 29.970
Frame rate : 29.970 (30000/1001) FPS
FrameRate_Num : 30000
FrameRate_Den : 1001
Duration : 00:01:23.083
which doubles the playback time and any play I used plays the video at half the speed.
Shouldn't it be "--default-duration 0:60000/1001i" then?

Selur
6th July 2020, 19:02
Also got another issue, using 'mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit' (same happens with 48.0.0.0)
and
mkvmerge --ui-language en -o "C:\Users\Selur\Desktop\In The Dark.track.mkv" -d 0 --default-track 0:yes --default-duration 0:50/1i --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "C:\Users\Selur\Desktop\In The Dark.track.264"
the output seems to be only the header without any content. :/
console output doesn't show any errors.
mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit
'C:\Users\Selur\Desktop\In The Dark.track.264': Using the demultiplexer for the format 'AVC/H.264'.
'C:\Users\Selur\Desktop\In The Dark.track.264' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'C:\Users\Selur\Desktop\In The Dark.track.mkv' has been opened for writing.
Progress: 100%
Uploaded the source .264 file to my GoogleDrive (https://drive.google.com/file/d/1O9w0cYcYer_CRLxrrGZP0Co3Vsoo7DvO/view?usp=sharing) (176MB)
(using --default-duration 0:25fps instead of --default-duration 0:50/1i doesn't change the output,...)

Cu Selur

Ps.: I suspect the source file is somehow broken, the raw stream plays fine in mpc-hc, but neither mkvmerge nor ffmpeg can remux it into a container,... :/

arrgh
6th July 2020, 23:29
if I demux with mkvextract.exe an 3D-MKV, created with MakeMKV, I get an "AVC" file of about the correct size (you might be aware of DGDemux which can demux from the BluRay the h264 and the mvc streams into separate files; the combined file sizes are in the fitting size range of the avc);

but it doesn't seem to be possible to remux this "avc" file with mkvmerge back to a working mvc-mkv (even with a manually set Stereoscopy-Tag);

on the other hand MediaInfo recognizes this avc file as “multiview”…
and a remux with the video taken directly out of the "original" mkv (without prior demuxig) does work...

what additional setting do I need to do? Or is there a bug in mkvextract, so that certain details of the video stream are lost?
Thanks

Mosu
7th July 2020, 13:33
mkvmerge doesn't support reading MVC from anything but other Matroska files yet. See this issue for general support for 3D Blu-rays (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/1106) and this other issue for MVC data in raw h.264 elementary streams (https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2709) for details.

arrgh
7th July 2020, 21:27
"yet" has a good sound to it...
I don't know whether the problem is on the "extract" or the "merge" side, but is it difficult to solve it? will it be solved?
I have seen in the second thread that you mention some changing standards... is there a risk that what did work up to now (reading MVC from MKV) might stop working in future?

Mosu
7th July 2020, 22:34
I'm not particularly interested in spending time on 3D stuff, haven't been for years. So that "yet" is definitely not a sign of things becoming supported soon, if ever.

The problem is on the merge side, not the extraction.

To the best of my knowledge the changes to the standard won't affect playback of existing files.

arrgh
7th July 2020, 22:45
...
The problem is on the merge side, not the extraction.
...

so, it seems to be very difficult to "emulate" the mkv-container environment on a primary stream containing all relevant data of the mkv in a way that that the remux would work?

the background of this is: even if the interlacing of the h264 and the mvc into a unified video steam would be done by a third party, mkvmerge would not support the muxing into a mkv file?

Mosu
8th July 2020, 08:57
"Problem" was the wrong word. "Difficult" isn't the right word either. I simply haven't implemented the functionality yet. It would most likely not be "difficult", just time consuming. That mkvmerge doesn't "support" it is simply due to that the time to implement it hasn't been spent yet.

Please don't try to read anything more into my statement than "I'm not motivated to spend time on this feature".

mkver
8th July 2020, 11:50
Also got another issue, using 'mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit' (same happens with 48.0.0.0)
and
mkvmerge --ui-language en -o "C:\Users\Selur\Desktop\In The Dark.track.mkv" -d 0 --default-track 0:yes --default-duration 0:50/1i --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "C:\Users\Selur\Desktop\In The Dark.track.264"
the output seems to be only the header without any content. :/
console output doesn't show any errors.
mkvmerge v48.0.0.16 ('Fortress Around Your Heart') 64-bit
'C:\Users\Selur\Desktop\In The Dark.track.264': Using the demultiplexer for the format 'AVC/H.264'.
'C:\Users\Selur\Desktop\In The Dark.track.264' track 0: Using the output module for the format 'AVC/H.264 (unframed)'.
The file 'C:\Users\Selur\Desktop\In The Dark.track.mkv' has been opened for writing.
Progress: 100%
Uploaded the source .264 file to my GoogleDrive (https://drive.google.com/file/d/1O9w0cYcYer_CRLxrrGZP0Co3Vsoo7DvO/view?usp=sharing) (176MB)
(using --default-duration 0:25fps instead of --default-duration 0:50/1i doesn't change the output,...)

Cu Selur

Ps.: I suspect the source file is somehow broken, the raw stream plays fine in mpc-hc, but neither mkvmerge nor ffmpeg can remux it into a container,... :/
This file doesn't contain anything marked as key frame. Use --engage all_i_slices_are_key_frames.

Selur
9th July 2020, 17:53
Thanks a lot didn't even know that opiton existed. :)

Cu Selur

arrgh
9th July 2020, 21:09
...
To the best of my knowledge the changes to the standard won't affect playback of existing files.

I was not refering only to playback but also to remuxing of mkv from existing mvc-mkv

Mosu
9th July 2020, 21:23
I was not refering only to playback but also to remuxing of mkv from existing mvc-mkv

If I ever decide to implement support for MVC in mkvmerge, it will include being able to read files written before the aforementioned change to the specs.

arrgh
10th July 2020, 18:06
If I ever decide to implement support for MVC in mkvmerge, it will include being able to read files written before the aforementioned change to the specs.

good!

meanwhile there is a tool available, which is part of the DGDemux package, which can interlace the primary h264 stream and the mvc stream into a unified h264 multiview stream;
I was able to mux with tsmuxer a working ISO with such a file.

I would therefore like to ask you to implement the muxing of such interlaced streams into a mkv. I could provide samples...

Thanks

ssjkakaroto
20th July 2020, 05:03
Hi mosu, I'm having a small issue with mkvtoolnixgui v48, which didn't happen with v47.

In a dual-monitor setup, if mkvtoolnixgui is on the secondary monitor and you click on the arrow of "Add job to queue", the menu will appear on the primary monitor.
You can see it here:
v48: https://imgur.com/a/EClTVGV
v47: https://imgur.com/a/TzZXeJL

OS is Windows 7 x64.

Thanks

Mosu
20th July 2020, 13:12
I don't support Windows 7 anymore.

ssjkakaroto
21st July 2020, 02:49
Sure, except it also happens on Windows 10 (Pro x64 version 1909): https://imgur.com/a/ZIjTgTy

Mosu
21st July 2020, 15:25
I see. That's a bug in Qt, then. Nothing I can do about it.

Perenista
27th July 2020, 23:20
I've been putting AVI files into MKV using MKVtoolnix and nothing wrong happened... until now. Audio is out of sync.

I checked the original AVI and there is no issue with it. So putting in MKV changed that. What is wrong here?

This is the MEDIAINFO from the AVI:

https://pastebin.com/gDiDdWEG

And from the MKV with this error:

https://pastebin.com/TbRDzeKb

EDIT: I checked the log for errors and found this:

'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 3344 bytes of invalid data which were skipped before timestamp 00:16:34.664000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1214 bytes of invalid data which were skipped before timestamp 00:16:38.296000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 63 bytes of invalid data which were skipped before timestamp 00:16:38.322000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 405 bytes of invalid data which were skipped before timestamp 00:16:38.348000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 122 bytes of invalid data which were skipped before timestamp 00:16:38.426000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1358 bytes of invalid data which were skipped before timestamp 00:16:38.452000000. The audio/video synchronization may have been lost.
'C:\Users\XXXXX\Desktop\FILE.avi' track 1: This audio track contains 1254 bytes of invalid data which were skipped before timestamp 00:16:38.557000000. The audio/video synchronization may have been lost.

Invalid data? I can play the original AVI without any issues. At 16:34 and 16:38 the image freezes for less than a second, so there must be some flaw in the file itself, I mean a failure like a broadcast transmission breaking and the image gets fuzzy *. Even so the whole thing continues and I confirmed it's only MKVToolnix that is rejecting this error when I put the content in MKV.

* https://i.imgur.com/hU9C3pe.jpg

I'll try extracting the MP3 with VirtualDubMOD and then adding to see if things change.

>>>>>
Update: it didn't work. I tried creating a MKV with the video stream (and the new subtitle I added) only. OK, no errors in the log. But when I added the MP3 extracted from the AVI they were there again.

That means the problem is not with the video, it's with the audio.

Even so, the question remains:

- Why MKVToolnix can't create a MKV with this error, and without losing sync?
- If it can, how do I enable that option?

Any suggestions to fix this? Despite the fact the original AVI file doesn't need fixing since it can be watched synchronized.

*******************

Update: just checked another file and when this problem happens the MKV created by MKVToolnix simply skips the defective part, making the audio jump. That's what makes the audio becoming out of sync. If I let the content in the original AVI this doesn't happen.

Unfortunately this is how MKVToolnix works, when it should leave the file as it is. So I am forced to watch the file in AVI, otherwise I will break it even more.

Correction: I checked two more files that had the same issue and they didn't lose sync, but in one of them the audio jumped (it cuts abruptly to the next second corrected) as I said before. They probably didn't lose sync because for them the flaw was seen quicker than the other ones that were way more corrupted.

>>>>>>>>>>>>

This situation is pretty much what happens when we play a vinyl (LP) and there's skipping.

LPs sound great when in good condition. Records can suffer from all sorts of deterioration, much of it causing unwanted skipping or audio distortion. Some of these problems can be remedied, while others, are permanent. One of the main problems of older records are that they skip, or have lots of crackling and popping when playing. This is a common problem when attempting to convert records to CD or MP3 files.

What MKVToolnix does is to make us notice the problem even further.

What I wanted: that MKVtoolnix displayed the AVI just like it is displayed before putting the same AVI into a MKV container.

In other words, that MKVToolnix ignored the error completely and didn't change anything.

I can only assume this is impossible in the AVI --------- > MKV conversion.

Mosu
2nd August 2020, 15:04
Hey y'all,

this is more or less a small bugfix release of MKVToolNix. One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Important news for package managers is that libMatroska v1.6.1 is now required (that one was released earlier today). As usual MKVToolNix bundles that version as a fallback.

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

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

Version 49.0.0 "Sick Of Losing Soulmates" 2020-08-02
New features and enhancements

mkvmerge: added support for copying the new track header elements "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData" from Matroska files if they exist. Part of the implementation of #2887 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2887).
mkvinfo: added support for the new track header elements "BlockAdditionMapping", "BlockAddIDName", "BlockAddIDType", "BlockAddIDValue" and "BlockAddIDExtraData". Part of the implementation of #2887 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2887).
MKVToolNix GUI: multiplexer: the list of recent directories can now be edited in the preferences → "Multiplexer" → "Destination file name". Implements #2861 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2861).
MKVToolNix GUI: preferences: the values in the various "predefined values" lists can now be re-ordered freely by dragging & dropping.

Bug fixes
mkvmerge: Matroska reader: when reading tracks (e.g. a subtitle track) from Matroska files with their "default track" flag set to "yes", and when overwriting those via the command line to "no", "mkvmerge" would not promote additional tracks of the same type from other files (e.g. another subtitle track from an SRT file). Fixes #2863 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2863).
mkvmerge: SRT reader: empty lines inside entries were doubled. Fixes #2888 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2888).
mkvmerge: subtitles: when calculating the rounded duration of each entry the error from rounding the corresponding timestamp will be taken into account. Fixes #2890 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2890).
mkvextract: SSA/ASS extraction: mkvextract is no longer inserting empty lines before the "Dialogue:" lines. Fixes #2876 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2876).
mkvextract: USF subtitles: start & end timestamps were too high by a factor of 1.000.000. Fixes #2875 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2875).
MKVToolNix: info tool: when saving to a text file the checkbox "Save as default for saving output to text files" did nothing. Fixes #2869 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2869).
MKVToolNix: info tool: when saving to a text file in "all elements in a tree-like structure" mode, the GUI always stopped at the first cluster regardless of the setting of the "verbosity" option.
MKVToolNix GUI: preferences: when tooltips were disabled the dialogs for adding new entries to the various "predefined values" lists were missing their texts.
Windows installer: the images are shown again. Fixes #2868 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2868).
configure: fixed detection of QtDBus. Fixes #2886 (https://gitlab.com/mbunkus/mkvtoolnix/issues/2886).

Build system changes
libMatroska v1.6.1 is now required. The bundled version has been updated to that version.


Have fun :)

quietvoid
2nd August 2020, 17:41
One rather important new feature is support for the new Matroska elements introduced for storing additional codec-initialization data needed for techniques such as MVC (3D video) or Dolby Vision metadata. mkvmerge cannot produce them itself yet, but it will keep the data that's present, e.g. when reading files created by MakeMKV.

Thanks for the new release :)

I was playing with test samples and the headers seem to be kept just fine (mkvinfo says so at least).

I was wondering if there were plans to be able to edit these (block addition mapping, and all) with mkvpropedit (or the GUI), as they don't seem to be in the current list.
It's possible that is what you refer to for mkvmerge cannot produce them itself yet,

Mosu
2nd August 2020, 21:48
No plans for making those fields editable with mkvpropedit/the header editor. The reason is that they're codec-specific data. I don't make CodecPrivate available for editing either.

quietvoid
2nd August 2020, 22:51
Okay, thanks for the info.

ssjkakaroto
3rd August 2020, 05:59
Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

Mosu
3rd August 2020, 12:15
Hey Mosu, can you tell me exactly what changed between v47.0.0 and v48.0.0/v49.0.0 regarding to Qt so I can try to open a bug report about the dual-monitor issue over the Qt bug tracker?

v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.

Selur
9th August 2020, 11:03
Small question about chroma sub sampling signaling.
From https://mkvtoolnix.download/doc/mkvmerge.html I gathered that for:

4:2:0 one should use 1,1
4:2:1 one should use 1,0

-> What should be used for '4:4:4' and 4:2:2' ?

nevcairiel
9th August 2020, 22:02
The wording of that option sure is bizarre, but either way, for 4:4:4 its clearly 0,0 since nothing is being removed. And 4:2:2 has full vertical resolution, so it should be 1,0.

I have never seen a MKV that uses that information though, when raw video is contained in MKV its usually with a FourCC to identify it or similar means, and encoded video carries that information in its bitstream.

Mosu
9th August 2020, 22:03
I actually don't know. Those options & the accompanying documentation was contributed by someone else.

ssjkakaroto
10th August 2020, 00:00
v47 was built with Qt 5.14.2, v48 with Qt 5.15.0. Apart from that no changes wrt. to monitor or menu or display handling were made on my end.
Hi Mosu, the bug with the popup menu will be fixed in Qt 5.15.1 (https://bugreports.qt.io/browse/QTBUG-84462)