MKVToolNix v24.0.0 released

[Selur]

thanks for the new release :)

[sneaker_ger]

http://www.mediafire.com/?lidxnvnc3997dzd

VFR H.264 file with pic-struct, automatic FPS detection results in all timecodes = zero

[Mosu]

Pic struct are not supported yet. You'll have to keep using --default-duration for such files.

However, pic struct parsing is more or less on my TODO list.

[szabi]

probably a 'bug' in MediaInfo,..

It's not a problem of mkvmerge. I've experienced a similar problem for example when both video and audio tags have ENCODER_SETTINGS (it looks like the value of the audio one "overwrites" and hides the video's one). I've seen that both in MPC-HC and VLC but it's so minor it didn't bother me.

Which splitter do you use with mpc-hc?
My experiment only haali splitter reading metadata more or less.
In this case ARTIST is mixed with AUTHOR.
Inbuild of mpc-hc and LAV splitter NOT reading any tag info. :rolleyes:

Anyway it means there is a bug in MediaInfo, mpc-hc and vlc as well!?

bye
szabi

[Mosu]

Well, all these talk about tags is definitely off-topic in this thread. Please move it over to a more appropriate one (MediaInfo support or whatever) or create a new one. Thanks.

[DragonQ]

There is nothing like 25i. 25i would mean 12.5 frames per second. If your material is 50 interlaced frames/fields then you use 50i.
Actually, the European Broadcasting Union notation uses the frame rate rather than field rate. So in this notation, a video with 50 interlaced fields per second is "25i". A 1920x1080 video of the same type is "1080i/25".

[Mosu]

Quoting http://en.wikipedia.org/wiki/1080i :

The frame rate can be implied by the context, while the field rate is generally specified after the letter i, such as "1080i60". In this case 1080i60 refers to 60 fields per second. The European Broadcasting Union (EBU) prefers to use the resolution and frame rate (not field rate) separated by a slash, as in 1080i/30 and 1080i/25, likewise 480i/30 and 576i/25.[1] Resolutions of 1080i60 or 1080i50 often refers to 1080i/30 or 1080i/25 in EBU notation.

You'll note that in neither case is the 'i' postfixed to the frame/field rate, but to the resolution. "25i" vs "1234i25". See the difference?

OK, there's also nothing like a pure "50i" in high def broadcasting... however, for mkvmerge the resolution doesn't matter in this case. Therefore I only needed a way to describe the number of frames per second.

Maybe I shouldn't have introduced those values after all ~~ Too much damn confusion.

[DragonQ]

Hmm true, I guess "50i" by itself is acceptable notation (and certainly used very often). I wasn't talking about the new options in MKV Merge, just your comment from this thread. The new options for frame rate are definitely useful, IMO.

[mbcd]

http://forum.doom9.org/showthread.php?p=1563669#post1563669 ;)

:confused:
:confused:

Welcome into the world of crazy framerates Mosu ... ;)

Thats why I suggested to deal only with FULLFRAMES, to get a right definition --> How much fullframes you have per second ?

Thats because the future is in progressive material, so I think its better to handle with progressive values.

Its hard to deal with. Problem is, that in future even 50p/60p or 100p might get around, so dealing with assigned values could give some problems in future. Some Camcoder are able to deal with 50p, so ...

If you only take care of DVD or BD (PAL/NTSC) you wont get problems there, so only a hint of mine ... if you want change it in future again, then there must be a clear way for definition now.

[sneaker_ger]

Its hard to deal with. Problem is, that in future even 50p/60p or 100p might get around, so dealing with assigned values could give some problems in future

I suppose that's why there's also "50p" and "60p" to choose from...
(And you don't have to wait for the future, 50p is already used for broadcasting and Blu-Ray.)

[DragonQ]

BD only supports 50p or 60p at 1280x720 resolution, unfortunately. Although ATSC and DVB both support 1080p/50 and 1080p/60, I don't think these are currently used anywhere. Fortunately, DVB's "Scalable Video Coding" support means that older hardware that pre-dates 1080p/50 should just use the 1080i/25 "part" of the stream rather than crash or whatever. So, in theory, the switch to 1080p/50 can be made at any point in the future without affecting current consumer hardware.

I guess the timescale of the switch depends on what existing infrastructure broadcasters have in place - if they've shelled out on suites that only support up to 1080i/25 (or 30) then they're not gonna switch to 1080p/50 (or 60) any time soon, even though it shouldn't require any more bandwidth to broadcast. This is why they should've just ditched interlaced broadcasting from the beginning when HD standards were devised. >_>

[sneaker_ger]

No one was talking about 1080, right?
There are 720p50 Blu-Rays and DVB broadcasting channels. Also, users may want to deinterlace 1080i content to 50p/60p and store it in a Matroska file.

Anyhow, I didn't really want to start a discussion about it, just point out that these rates are not that uncommon and that mmg already has these values in the drop down box.

[hello_hello]

Just an "out of curiosity" question.....

I have two identical PCs. Well almost identical. They have exactly the same hardware aside from the CPU. One is a Q9450 and the other an E6750. Both CPUs usually run at the same clock speed, although currently the quad is slightly overclocked (3.2GHz) while the dual core is running at stock speed (2.67GHz). The Windows (XP) and programs installations are also identical. I installed everything on one PC, imaged the setup, then "restored" that image to the second PC.

So my question is, why does MKVMergeGUI take two or three times longer to open on the PC with the quad core CPU than it does when opening it on the PC with the dual core CPU? I just opened MKVMergeGUI on each PC, shut it down, then opened it again and timed how long it took (to ensure I wasn't opening it for the first time on one PC but not the other). 2 to 3 seconds to open using the dual core, 6 to 7 seconds using the quad core. The time it takes to open has always been slower using the quad core regardless of which version of MKVToolNix has been installed, yet for any other software, I can't say I've ever noticed a difference.

It's no big deal at all, but I've always wondered "why?"

[Snowknight26]

Process Monitor should tell you.

[Mosu]

It's no big deal at all, but I've always wondered "why?"

I have no idea :) However, I'm curious, too. So here's a special debug build for your: http://www.bunkus.org/videotools/mkvtoolnix/win32/debug/ (build 424)

Install it, run mmg, quit mmg. mmg will write a small text log file to your temporary files folder called "mmg-startup-time-debug.log". Please send me that file to moritz@bunkus.org -- and let's continue the rest of the debugging session via email, please.

If you don't know how to find your temporary files folder: for me it's something like C:\Users\mosu\AppData\Local\Temp. You can also use Windows' search functionality for the file name mentioned above.

[hello_hello]

Please send me that file to moritz@bunkus.org -- and let's continue the rest of the debugging session via email, please.

Email sent.

Cheers.

[Lincoln Burrows]

I noticed MKVToolnix is not warning us the fps will be set to 25 when opening .264 files (original source is MPEG-4 AVC). This one was extracted from a Blu-ray (I used TSMuxer GUI on a m2ts file), released in US. I usually informed this setting in the MKVToolnix fps tab:

http://i.imgur.com/iziy7.png

Can you confirm if we need to keep doing that or if it's not necessary anymore?

[Selur]

should not be necessary due to the h.264 parsing rewrite,... ;)

[DragonQ]

Yeah I think it reads the timecodes (or maybe the stream header, or both) from the file to determine the frame rate now. There was a big rewrite in between 5.3.0 and 5.4.0 and I for one am very grateful since it fixed the muxing of UK TV streams. :)

[Mosu]

Can you confirm if we need to keep doing that or if it's not necessary anymore?

http://forum.doom9.org/showthread.php?p=1564296#post1564296

[Chumbo]

@hello_hello,
In addition to what Mosu provided for debugging, there are great tools available in the Sysinternals Suite available here (http://technet.microsoft.com/en-us/sysinternals/bb842062). In your case, Process Monitor would be very handy as you can set it to monitor the specific executable for MKVToolnix and monitor all activity to see where the bottleneck is occurring.

[sneaker_ger]

Some parts of your homepage are no longer visible in the browser, but appear as downloads. The changelog for example.

[Mosu]

I've switched from Apache to nginx last week. Looks like nginx uses application/octet-stream for files without extension. Will fix; should only concern ChangeLog and README so far.

[Mosu]

Fixed. Thanks for noticing. If you still get the download on at least those two files then it's your browser that's caching.

[Mosu]

http://www.mediafire.com/?lidxnvnc3997dzd

VFR H.264 file with pic-struct, automatic FPS detection results in all timecodes = zero

That particular file will always require user intervention. Yes, it does contain picture timing SEIs, but those do not contain a clock timestamp. Furthermore the timing parameters in the SPS are as follows: num_units_in_tick = 1, time_scale = 2000000000 -- meaning that each frame is supposed to have a duration of 1 nanosecond. No wonder all timecodes are 0.

The bitstream itself simply doesn't provide useful/enough information for mkvmerge to work with.

[MasterNobody]

Furthermore the timing parameters in the SPS are as follows: num_units_in_tick = 1, time_scale = 2000000000 -- meaning that each frame is supposed to have a duration of 1 nanosecond.
No, as it is VFR so it only means that minimum tick interval between frames is 1 ns (precision of timebase). It doesn't say anything about average frame duration (it is of course higher than minimum). And yes, there is no ways to get real frame durations here from elementary stream (bad idea to encode VFR without container with timestamp support).

P.S. If you output VFR to raw elementary stream it better to consider using --tcfile-out option.

[kieranrk]

Yes, it does contain picture timing SEIs, but those do not contain a clock timestamp.

Whilst I appreciate MKV incorrectly uses timecode and timestamp interchangeably, you should not be using any of the timecodes present in the picture timing SEIs since timecodes != timestamps.

[Mosu]

At the moment mkvmerge doesn't use them at all. However, I don't see the harm in using them in one specific way and in one specific situation. The situation: if and only if the source file is a raw h.264, the user hasn't specified an external timecode file for that track. The way: use them as they are but zero-base them -- meaning subtract the smallest of them from all of them.

BTW: The h.264 specs talk about "clock timestamps" for the stuff in the picture timing SEIs, not about "timecodes present in the picture timing SEIs" as you do. Simple error on your part? And why should I not use them at all?

[tormento]

Mosu: could you please make MMG recognize the stream language from the first three characters of the filename? Let's say iso_filename... Sometimes I have to mux lot of files and one step less should make me faster.

[Mosu]

No, sorry. That would be catering to a very small minority of users. It would also mean way too many false positives as there are tons of ISO language codes that are prefixes of perfectly normal words.

[kieranrk]

BTW: The h.264 specs talk about "clock timestamps" for the stuff in the picture timing SEIs, not about "timecodes present in the picture timing SEIs" as you do. Simple error on your part? And why should I not use them at all?

It's probably because it has been abstracted away by JVT from the original definition of timecode because not all applications are the same. However, it's clear this field is meant to be the same as the MPEG-2 timecode field.

[szabi]

Since the new update to version 540, runtime error-application closing occurs when i click on video tag button.

bye
szabi

[Mosu]

Thanks for noticing, I can reproduce it. Will investigate.

[Mosu]

Fixed in builds 429 and higher: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

[szabi]

Thnx, checking. :thanks:
I tought it was only for me, because the offtopic tagging discussion (http://forum.doom9.org/showthread.php?p=1564434#post1564434). :D

bye
szabi

[Mosu]

Well, that particular bug had been present for a couple of years, and only pure luck prevented the app from crashing at that point until now.

[tormento]

No, sorry. That would be catering to a very small minority of users. It would also mean way too many false positives as there are tons of ISO language codes that are prefixes of perfectly normal words.
There could be a special char between the iso and the filename, such as _ or # or some other ASCII...

[Selur]

Sorry, but for me the whole get parameters from a 'user created&named'-file just sounds like a bad idea. If the whole thing is done by a program that looks over the whole naming, it's not a problem, but as things are this would still lead to tons of false positives, for people that are not aware that they are not allowed to use this char in their filenames.

Cu Selur

[mbcd]

Of course you cant catch all variants, but what about pattern:

(DE) (EN)
, german, , english,

, de, , en,


As I said before, there are some main programs out there which might be the most popular tools for handling audio and video.

Build in some pattern for handling those filenames should not be that bad, and whats negative if there is a false ?

If you dont have any recognizion, you have to set e.g. language-field from "und" to "eng".
If you have a false recognizion, you have to set language-fiels from "rus" to "eng".
If you have correct recognizion, you have to set : nothing.
So you dont have more work, even if recognizion is false, its not more work, but on the other hand: it could be less work.

I think only few people do not set languages, so I dont see any problems to implement a few patterns. Normaly you check settings bevore muxing, so I you use a pattern which is not known correctly by mmg you have to check, if you know the pattern is known, you dont have ...

[Selur]

If you dont have any recognizion, you have to set e.g. language-field from "und" to "eng".
which doesn't change a thing, since 'und' and 'eng' are the same. ;)

If you have a false recognizion, you have to set language-fiels from "rus" to "eng".
only if you recheck, the fields, if you don't the auto-detection might set a false value.

@Mosu: if you implement something like this, please only implement it for mmg, not for mkvmerge. (I normally don't use mmg, so I can live with 'strange things happening when one uses mmg'. ;))

[sneaker_ger]

which doesn't change a thing, since 'und' and 'eng' are the same. ;)

They are not.
"und" is not the same as an empty language field.

[Selur]

"und" is not the same as an empty language field.
which is the same as 'eng' (since eng is the default value if there is no track language :) and iirc no matter if you set 'und' or 'eng' mkvmerge does not write a language flag in both cases ;))

[sneaker_ger]

If you don't specify a language (and the source container does not have that info) mkvmerge will explicitly write "und". Otherwise there would be no way to distinguish between English and undefined. "eng" is the standard value of the matroska spec, not what mkvmerge writes by default.

[Selur]

let's wait what Mosu has to say, but afaik you can't distinguish between English and undefined (and this has probably been discussed in this thread before,.. ;))

[sneaker_ger]

Well, you could easily confirm it with the header editor:
Mux two tracks, for one you set "eng" and for the other you let it at "und". Then open the file with the header editor and look at the language value of each track. The first track will have no language element and the second track will have "und". Also note that "und", "eng" and "remove element" are three separate options in the header editor.
Also MediaInfo, LAV Splitter, MPC-HC's Splitter etc. will differ between those.

[Mosu]

which doesn't change a thing, since 'und' and 'eng' are the same. ;)

No, they aren't. "und" stands for "undefined" which means that the language is either not known or that the concept of "language" isn't applicable to a track.

[Selur]

Okay, so 'eng' <> 'no track set'. :)

[Mosu]

To elaborate.

The Matroska specs say that "eng" is the default value of the "TrackLanguage" attribute. This means that if the track headers do NOT contain a copy of the "TrackLanguage" element then an application reading the file must treat that track as if the "TrackLanguage" was actually present and was set to "eng". That's the meaning of "default value" regarding the Matroska specs. Nothing more.

"eng" and "und" are two different and distinct possible values for the "TrackLanguage" element. The former says the obvious: the track is in English. Simple.

The latter says that the person creating the file did not know about the language, did not care about it or that the concept of "language" is not applicable to this track (e.g. a video track without any text showing up).

Now to mkvmerge. If the user does NOT specify the track's language then mkvmerge will assume that the person creating the file did not know about the language, did not care about it or that the concept of "language" is not applicable to this track (e.g. a video track without any text showing up). Therefore it sets "TrackLanguage" to "und" (undefined).

This is one of the few cases in which mkvmerge's default value for one of mkvmerge's options does not equal the default value of the corresponding Matroska item from the Matroska specs.

[Thunderbolt8]

I always use 'und' for silent movies and then use the language identifier for the video track (which usually gets 'und' for my movies, because usually video track itself doesnt really have any language)

[Chetwood]

I never bothered to set this value for video tracks or chapter files.