MKVToolNix v24.0.0 released [Archive] - Page 42

Bigmango

4th March 2013, 14:49

I suspect it isn't and is rather DVD style: no marking for tracks but only for lines, with track selection done by the menus.

Forced subtitles selection is done automatically. Nothing to do with the menu.

MakeMKV, DVDfab, and other tools detect forced subtitles properly.

Blu-ray players also detect them an auto-play them properly.

This means, forced subtitles can be detected. Imho, Mkvmerge should auto-flag them as forced subtitle "YES".

Mosu

4th March 2013, 14:51

Let me repeat: where is that information stored? I mean where exactly? "Others can do it" and "mkvmerge should do it" don't help me.

Bigmango

4th March 2013, 14:53

Let me repeat: where is that information stored? I mean where exactly? "Others can do it" and "mkvmerge should do it" don't help me.

I am only giving the information I have. I hope others will contribute with "how it is done".

Many thanks for your great work.

sneaker_ger

4th March 2013, 15:05

MakeMKV, DVDfab, and other tools detect forced subtitles properly.

They may be able to detect forced lines, but this doesn't help with the forced track element of matroska. Forced subs are either incorporated into the full subtitles, with only the forced lines marked as forced, or as a separate track and not marked as forced at all. Either way there is no way for mkvmerge to detect these things. The only thing it could do would be to try some kind of smart auto-guessing or move lines that are marked as forced into a separate track - but that is probably out of scope and would require a full scan of the files before muxing and the guessing would also fail often.

Blu-ray players also detect them an auto-play them properly.

But Blu-Ray players go through the menu system first. These tell the player which (if any) subtitle track it should select and if it should play all or only forced lines.

Bottom line: Blu-Ray and DVD only work with forced lines which may or may not (separate track) be used by the authoring house. Matroska uses forced tracks instead of lines, so that's a different concept, meaning you cannot simply transfer these informations.

nevcairiel

4th March 2013, 15:38

Thats one of the main reasons i demux with eac3to, which notifies me if a stream contains forced lines, and also lets me look into the demuxed PGS streams with BDSup2Sub to identify the other streams, and make a decision which streams i want.
There isn't really a good automated way to solve all the troubles of BD forced subs.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.

Bigmango

4th March 2013, 18:36

Where is that piece of information stored?

Thanks to sneaker_ger we now have the answer: the forced lines are marked as forced within the subtitle track.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.

This would be great. It solves everything.

If a track contains forced lines and normal lines:

Move the foced lines to a separate track and mark it as forced
Move the normal lines to another track an mark it as unforced.

This would also solve the problem of the 2 different kinds of tracks (the tracks that support both forced and normal lines in the same track, and the separate tracks that contain only forced lines). In both cases, the above procedure would work (i.ex: if a track contains only forced lines and no normal lines, then the track with the normal lines would not be created).

Mosu

4th March 2013, 18:40

Sorry, but that is not going to happen. Mkvmerge would have to know in advance whether or not a track contains forced entries in order to write the file headers correctly. That could only be achieved by implementing two-pass muxing, something that I will most certainly never do. Way too much effort.

sneaker_ger

4th March 2013, 23:02

This would also solve the problem of the 2 different kinds of tracks (the tracks that support both forced and normal lines in the same track, and the separate tracks that contain only forced lines). In both cases, the above procedure would work (i.ex: if a track contains only forced lines and no normal lines, then the track with the normal lines would not be created).

Putting aside that Mosu is not willing to implement this, it wouldn't even work 100%. The problem is that authoring houses that put the forced lines into a separate track usually do not mark those lines as forced. They just tell the player via the menus that it should play that track. Since the track only contains forced lines it's unnecessary to mark them in any way.

mandarinka

5th March 2013, 04:03

I followed http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows and downloaded the binary installer and portable version from downloadbestsoft.com.
Both files had invalid MD5 (I used RapidCRC to check), so the files have probably been tampered with, possibly maliciously. Testing the 7z with 7zip showed no errors. (Redownloading didn't help.)

Maybe this should be investigated, since there is a chance they bundle something into mkvtoolnix :(

P.S. I tried to get the file from your server to check, but I think I didn't fool it and it just redirected me to that accursed host too - the file was identical to teh one from downloadbestsoft.com.

Chetwood

5th March 2013, 07:47

MakeMKV, DVDfab, and other tools detect forced subtitles properly.
No, they don't. There are various threads on both forums dealing with the issue of forced subtitles not being detectd properly.

Thanks to sneaker_ger we now have the answer: the forced lines are marked as forced within the subtitle track.
There are (at least) three methods for forced subs:

a separate stream that only has forced subs
a separate stream that has only forced subs but is not flagged (subs are turned on by navigational commands in the bdmv files)
a regular stream that has several items which are flagged as forced.

Thus the entire stream has to be parsed to determine which items are forced and Mosu already said he's not implementing two-pass muxing.

The only think mkvmerge potentially could do is allow splitting forced lines into another track, like most of the other tools support, but imho its not something i would use, because it only solves a small part of the problem.
It doesn't solve it at all since the detection itself is the problem.

nevcairiel

5th March 2013, 07:56

It doesn't solve it at all since the detection itself is the problem.

It doesn't solve everything, but it could potentially do what MakeMKV does - that is, write two streams for every PGS input stream, one stream gets all PGS lines, and the other one only gets the forced lines. And if no forced line was present, remove the stream from the MKV header again. Not that i think mkvmerge should do this, because it only solves a very small part of the problem, so you still need to do everything else.

Its not a perfect solution, but it does allow splitting out lines marked as forced in one-pass muxing. For everything else, people should demux and inspect the streams before.

What might be nice is an option to *only* take the forced lines out of a PGS input stream, in case you know it contains forced lines, and want to skip the step to split them out manually.

Mosu

5th March 2013, 07:57

I followed http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows and downloaded the binary installer and portable version from downloadbestsoft.com.
Both files had invalid MD5 (I used RapidCRC to check)

The checksums I use are SHA1 and SHA512. Not MD5, not CRC. So please use tools that actually support those checksums and stop spreading unwarranted accusations to the hoster I use. Thanks.

I've just re-checked, just to make sure. Downloaded both files from two different internet connections. They do match the published SHA1 and SHA512 checksums perfectly. No, downloadbestsoft.com is not modifying the files in any way, shape or form.

Mosu

5th March 2013, 07:59

It doesn't solve everything, but it could potentially do what MakeMKV does - that is, write two streams for every PGS input stream, one stream gets all PGS lines, and the other one only gets the forced lines. And if no forced line was present, remove the stream from the MKV header again.

Not possible in every case. Think of splitting. I'd have to re-write all files that have already been output. And what if the user has already moved some of them?

It's nothing I will implement. Period. You can all stop discussing it, or at least move it out of the context of this thread. Thanks.

mandarinka

5th March 2013, 22:18

Sorry, when I was reading the page, I interpreted the SHA1 as MD5. I simply saw that there, God knows why.

smok3

7th March 2013, 10:43

The automagic Bluray playlist selector is working great, thanks!

Reino

10th March 2013, 13:40

Hi there,

I've got about 300 ts-files, each 8 seconds long, that form a 40min documentary. In MKVToolNix I can easily use the append-feature to glue them all together into 1 mkv-file, but I'm facing a minor problem.
MKVToolNix detects the ts-file's video stream (h.264) as ID 1 and its audio stream (aac) as ID 0, which should be the other way around.
It wouldn't be such a fuss if it were only 10 files or so, but it's extremely cumbersome to move 600 streams (1 at a time!) up and down in the "Tracks, chapters and tags"-section to line them up correctly.

With...
ffmpeg.exe -i input.mkv -map 0:1 -map 0:0 -c copy output.mkv...I've found a way to correct this afterwards, but isn't there a way that mkvpropedit can do this for me? Or perhaps an extra option in MKVToolNix to switch the streams upon loading? Or another option of course... being able to move multiple streams up and down at once. That would help a lot too!

Mosu

10th March 2013, 13:56

You can also do that second step with mkvmerge. Load the muxed file again, then you only have one track to move.

On the command line: look at the --track-order option.

No, you won't get that "move multiple tracks at once" from me. Patches are welcome, though.

iSunrise

10th March 2013, 18:36

@Mosu:
Thanks for your great tools, appreciate the continued development on it!

Can you please explain how your new "split before chapters" works? Do you actually cut the files right before the chaptermarks irregardless of a keyframe or does that that take into account keyframes?

I am asking, because I end up with corrupted/invalid files after using that option.

Steps to reproduce:
I am using mkvmergeGUI 6.1.0 and I do a "split before chapters" and using "all" to split everything. While the original full-length MKV plays without problems whatsoever on all my devices and my PC, after the split I end up with several files that when played back, just show a black screen on all of my mobile devices (Android, Apple, etc.). Not even AirVideo (which does transcoding on-the-fly) can play it, says it´s an invalid file.

Right after starting playback I can only hear the audio track, but no video, all I get is a black screen, but the timecode still advances to the end of the file, so the audio is perfectly ok. I even tried to remux the contents (video and audio) to MP4/M4V containers, but it doesn´t help, the h.264 video track seems to be the problem.

For some reason LAV plays the files without any problems. But that doesn´t mean much, because LAV certainly is more "friendly" towards files in general.

Can you explain that? I can upload a sample if needed. Thanks a lot for looking into it.

Mosu

10th March 2013, 18:47

iSunrise

10th March 2013, 19:05

mkvmerge always splits right before key frames. With the "split by chapters" option all it does is take the start timecodes of selected chapters as they were entered in "split by timecodes" mode.

If you've got playback problems then that is your player's problem, not mkvmerge's. mkvmerge writes files that comply with the Matroska specs. That your LAV-based player can play the file just fine is only further proof of that. That's all that counts for me.

See these general troubleshooting information (https://trac.bunkus.org/wiki/Troubleshooting) for help on what you can try. And please, PLEASE, carefully read everything on that page and the ones linked from it. There's a ton of information and a ton of things you can try.
So, going by the info on that page the only thing I can do to avoid that is to use mkvmerge 5.8.0? Why does it behave different in that regard? I obviously would lose splitting by chapters then.

Not to doubt you or anything, but are you 100% sure that mkvmerge works 100% like it is supposed to work like you describe?

I find it very alarming that not even AirVideo that uses libav (avconv) in transcoding mode isn´t able to play the files.

Mosu

10th March 2013, 19:07

You obviously haven't read that page and the ones it links to carefully.

Yes, I'm sure mkvmerge works as I want it to.

iSunrise

10th March 2013, 19:14

You obviously haven't read that page and the ones it links to carefully.

Yes, I'm sure mkvmerge works as I want it to.
I obviously did.

Playback does not work at all or seeking does not work with files created by mkvmerge 5.9.0
The problem

Two symptons:

A player (mostly hardware devices like DVD or BluRay players) cannot play back a file muxed with mkvmerge 5.9.0 and later.
VLC cannot seek properly (or not at all) anymore with files created by mkvmerge 5.9.0 and later.

In both cases muxing with 5.8.0 fixes the issue.

Which is exactly my question. Does 5.8.0 fix my issue?

The only other thing that is mentioned on that page is a FAQ which points to some options to prevent player problems. How should I know what options to use?

Mosu

10th March 2013, 19:19

1. How would I know? I don't have your players with your problems, so how on earth should I know? I suspect it may.
2. No, obviously you didn't.

Quoting you:

So, going by the info on that page the only thing I can do to avoid that is to use mkvmerge 5.8.0?

Quoting my article:

Workaround with mkvmerge until player is fixed

You can prevent mkvmerge from writing these elements in the first place. This will make the file layout identical to the one written by 5.8.0. See the corresponding FAQ entry.

So please just try it. If it doesn't work then try the options listed on the general "what to do with incompatible players" page (https://trac.bunkus.org/wiki/FAQ%3AImprovingPlaybackCompatibilityWithPlayers).

Chumbo

10th March 2013, 19:33

iSunrise

10th March 2013, 19:45

@iSunrise,
After 5.7.0, I had to remux my MKVs using "--engage no_cue_duration --engage no_cue_relative_position" command line options to make sure my player's seeking and time are correctly "seen" and processed. You can set these as a default under Muxing | Add command line options. You can then check "Save as default..." to always mux with these options.
Thanks a lot Chumbo. I am currently in the process of splitting them again, as these options also seem the most likely to me.

Will report back after I´ve tested them and the other options.

Simon88

10th March 2013, 21:25

I was muxing some videos using mkvtoolnix 6.1.0 the other day and it found various errors at various XXXXXX position.... Resyncing at position 1, etc....

I'm wondering if there was a way for mkvtoonix to tell me where approximately (in minutes:second) in the video is that particular XXXXX position located.... so that I can simply cut the offending portion using an editor.... thanx...

Mosu

10th March 2013, 21:33

So far: no. But I may add that information in the near future.

Chumbo

11th March 2013, 03:33

I was muxing some videos using mkvtoolnix 6.1.0 the other day and it found various errors at various XXXXXX position.... Resyncing at position 1, etc....

So far: no. But I may add that information in the near future.
That would be greatly appreciated as I ran into a couple files with the same issue just yesterday.

Simon88

11th March 2013, 03:49

So far: no. But I may add that information in the near future.

Good to hear your considering such an addition....

I also noticed that these errors can cause hardware & software players to lockup, or audio to go silent from there onward. Cutting the offending portion virtually always fixes it.

It would be nice if you also show two values, BOTH the start location where errors are occurring and the location where it becomes OK.

That way, I can skip the editor and just use MKVToolNix to re-mux without bad areas....:)

Thanks....

hello_hello

12th March 2013, 03:52

Is there an option I'm simply missing, which can tell MKVMergeGUI to default to a specific language when adding additional streams to a muxing job?
I'm aware of the setting which places preferred languages at the top of the list, which is very handy, but not one which tells MKVMerge to actually select a particular language by default. If there's not such an option, would it be hard to implement?

Thanks.

Mosu

12th March 2013, 08:39

Wouldn't be hard. But it would pose more problems that it would solve. Therefore I won't implement it.

Here are a couple of examples:

What about files with multiple audio tracks? Do all of them get assigned the default language? Only one of them (if so: which one)?
What about files with both audio and subtitle tracks? Often users have audio in one language, subtitles in a different one.
There's reliable information (e.g. if the language is set on the container level like in MKV, MP4 or CLPI files for Blu-rays). If a default language applied it would be impossible for the user to distinguish between such reliable information and the unreliable information from the defaults. I can guarantee you that you'll forget to change the language for tracks whose actual language differs from the default one.
mkvmerge/mmg is careful not to change the file's semantics by keeping as much (meta) information from the source files as possible. With such a default language those semantics would often be changed in a way that would be pretty intransparent to the user.

etc.

hello_hello

12th March 2013, 10:20

I understand what you're saying, so I guess I'm looking at it from the perspective of an English speaker who usually only works with English streams.

What about a keyboard shortcut to change the language from "undefined" to the specified default etc? Or next to the drop down arrow where you now select the desired language, there could be a little "default" button. You could even have a little default button next to the Default and Forced track flag options. Although to be honest, I think doing away with the drop down menu and having three buttons for the latter two ("default", "yes" and "no") would be a better idea. You could highlight one to show which option is the currently selected one (or show it in a similar manner) and then it'd only take a single mouse click to change the setting for each. Even the language selection could have a few "common language" buttons which could be user defined, and there'd still be plenty of room from a drop down menu if you needed to select something else.

I know in the overall scheme of things it's nothing major, but I do mux quite a lot of files, and sometimes I open one with MKVMergeGUI and a little piece of my soul dies as I change the three dropdown boxes for each stream being added to the output again..... so I was thinking today if maybe there'd be an easier way, or a way to automate it a little.

Anyway.... that's just some thoughts. Everyone else might think it's a waste of time, but thanks for your continued work on MKVToolnix. It's much appreciated. I couldn't imagine life without it!

Mosu

12th March 2013, 10:27

Or next to the drop down arrow where you now select the desired language, there could be a little "default" button.

Why don't you just put "English" at the top of your preferred languages list? That way you can select it almost as easily as with such a button.

Basically you want me to spend a couple of hours on implementation and testing in order to save you a few seconds. Sorry but that's not how I usually work.

If you truly want to automate stuff then I highly suggest you learn a bit about programming. Everything you want to do can be achieved quite easily with a few lines of scripting (e.g. in Perl): parse the output of "mkvmerge --identify-verbose source.ext", assign a few command line options, run the muxing process. You can do anything you want with that approach. Sure, you have to spend some time on it, but here's my stance on bringing automation to mmg: Batch muxing with mmg? (https://trac.bunkus.org/wiki/FAQ%3ABatchMuxingWithMMG) The gist is this quote:

Implementing a powerful and flexible batch remuxer/header editor requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

hello_hello

12th March 2013, 17:40

Why don't you just put "English" at the top of your preferred languages list? That way you can select it almost as easily as with such a button.

English is at the top of my language list.

Basically you want me to spend a couple of hours on implementation and testing in order to save you a few seconds. Sorry but that's not how I usually work.

Well based on the assumption I'll only ever use MKVMergeGUI once, yes..... but those couple of seconds each time have probably added up to a minute or two already today.... give me another couple of weeks and your couple of hours work would have saved me a couple of hours worth a clicking. ;)

Anyway, it was just a thought.... thanks again.

zeropc

13th March 2013, 17:44

does anyone know why on some mkv files skipping takes very long until playback resumes?
i've seen this behavior on various players, e.g. mpc-hc, vlc, mplayerx.

can i fix this and is there something i need to know to prevent in on future mkv file-creations?

thanks :)

Mosu

13th March 2013, 17:48

Read the fine FAQ entry (https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590) I've written for this and that has been linked to about twenty times now in this very thread.

zeropc

13th March 2013, 18:03

thanks mosu :)

R=G

13th March 2013, 20:57

Can I use this to correct an audio stream of an out of synch MP4 file? Is there a tutorial on how to demux a MP4 file with an out of synch audio file?

DragonQ

16th March 2013, 13:15

If it's out of sync by a constant amount then you can just adjust the offset of the audio track when muxing to MKV. If the sync changes throughout then the frame rate might be wrong, which can also be corrected in MKV Merge.

nautilus7

16th March 2013, 19:20

Mosu, when loading a bluray playlist file into mkvmerge, the chapters it creates are ALL named "Chapter 0". I guess the correct would be "Chapter 1", "Chapter 2", etc.

Simon88

18th March 2013, 18:38

Is there a way to enter a PAR (pixel aspect ratio) value in mkvmerge? or to have it auto calculate an aspect ratio or display resolution from such a value?

It would makes life alot easier as mp4box seems to use PAR values exclusively...

thanx:)

sneaker_ger

18th March 2013, 19:04

Simon88

18th March 2013, 19:30

See mkvmerge doc for "--aspect-ratio-factor", but I would always recommend to already define a PAR when encoding the video to the bitstream (in case of x264 it's --SAR X:Y) - mkvmerge will then automatically read and apply that without any manual interventions.

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

thanx...

sneaker_ger

18th March 2013, 19:43

I think it only works on H.264 ES, but why would you want to remove it?

SeeMoreDigital

18th March 2013, 19:51

Is there a way to strip the bitstream aspect ratio that was encoded by x264 before encoding using mkvmerge?

The "--engage remove_bitstream_ar_info" doesn't seem to work the last time I used it....

thanx...Hmmm...

That should work. There was a time when MKVmerge would strip the bit-stream aspect ratio signalling by default :scared:

Simon88

18th March 2013, 21:13

I think it only works on H.264 ES, but why would you want to remove it?

Sometimes the bitstream AR is incorrect and a PAR correction must be applied to straighten it for correct display.

This sometimes confuses the media player... of whether to use the container AR or the bitstream AR... though, most players use container AR, nowdays...