MKVToolNix v24.0.0 released

[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]

Originally Posted by hello_hello

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/mkv...x/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]

Originally Posted by Mosu

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:



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]

Originally Posted by Lincoln Burrows

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

http://forum.doom9.org/showthread.ph...96#post1564296

[Chumbo]

@hello_hello,
In addition to what Mosu provided for debugging, there are great tools available in the Sysinternals Suite available here. 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]

Originally Posted by sneaker_ger

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]

Originally Posted by Mosu

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]

Originally Posted by Mosu

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.