MKVToolNix v24.0.0 released

[Mosu]

A new build is available (492 and higher) (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/) that fixes the VP6-in-FLV issue.

[Simon88]

I recently purchased a Hauppauge 2250 TV Card to watch TV while using the computer. The WinTV 7 software can create MPEG-TS OR MPEG-PS.

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file? VLC seems to display the subtitles without issues.

Also, the MPEG-TS file gave an error when trying to import it into an MKV,:

Output:

Error: Found B frame without second reference in a non closed GOP. Fix the MPEG2 video stream before attempting to multiplex it.


Is this a known unsupported feature?

I hate having to post-process the files before importing into an MKV. eg. re-stream the MPEG-2/audio & extract the subtitles.

Thanks...

[Mosu]

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file?

Nope. Subtitles in MPEG PS and TS streams are not supported. See also https://trac.bunkus.org/ticket/773

Unfortunately it seems that a single TS subtitle stream can contain several logical subtitle streams which make demuxing them a major PITA. That's why I've practically stopped looking into it.

Also, the MPEG-TS file gave an error when trying to import it into an MKV,:

Output:

Error: Found B frame without second reference in a non closed GOP. Fix the MPEG2 video stream before attempting to multiplex it.


Is this a known unsupported feature?

Yes, otherwise such an error message wouldn't exist. Improving my MPEG2 handling code has almost zero priority for me.

[Kurtnoise]

However, only the MPEG-PS muxed the MPEG2 & AC3, the EIA-608, EIA-708 (A/53 / DTVCC Transport) subtitles were not muxed into the MKV. Is it possible to store the "raw" subtitle data into the MKV container or an srt file?
you should try TS-Doctor to extract subtitles streams from TS files...this tool is able to convert them to srt.

[Simon88]

Thanx for the suggestion, Kurtnoise, I'll definitely give TS-Doctor a close look.

I was having issues with ccextractor 0.64 creating subs that were not synced correctly. I had to cut a few frames in the beginning of the MPEG-PS/TS file before extracting the subs. And then muxing into an Matroska file.

[Thunderbolt8]

The header removal compression feature fired a lot of talk in the past, so i can't help not asking why you turned it off by default now? Did anything changed in the specs?that header options seems to be removed now from options. does that mean when I normally mux audio and video files I dont have to change any setting, header compression will automatically be deactivated?

[Mosu]

Quoting from my ChangeLog:

2013-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: removal: The 'header removal compression' method is not turned on by default anymore. This affects the following track types: AC3, AVC/h.264, Dirac, DTS, MP3. The setting in mmg that turned it off by default has been removed.

[Simon88]

On the subject of compression, why is it that I get the following error when trying to compress "video" using "bz2" under the "Extra options"

Error: bzip2 compression failed. Result: 3

AVC/h.264 & Xvid was used for my test of various compressions, although I wouldn't expect ANY space savings for such already highly compressed videos... I was thinking of using it for a few short uncompressed avi files that was unnecessarily large, which was not at hand at the moment.

[Mosu]

That is an error that I cannot reproduce at the moment. Could you upload a sample file for which it does happen, please?

[nevcairiel]

Unrelated to your error, however note that bz2 is deprecated, and only zlib is officially part of the Matroska spec now. That means that a bunch of players may have issues with bz2 compressed streams.

[sneaker_ger]

Why not just remove them?

[Mosu]

From the specs? Because you don't just remove stuff from specs if they've been there for some time, you deprecate them. And in revision N you forbid them.

[sneaker_ger]

I mean the ability to compress using those schemes from mkvmerge.

[Mosu]

Ah. Yes, it will be removed one of these days.

[Simon88]

That is an error that I cannot reproduce at the moment. Could you upload a sample file for which it does happen, please?

Ah... I finally was able to consistently re-produce it... Apparently bz2 does not like ANY filename/path names which contain Chinese characters OR many brackets. zlib, lzo, blank, none are OK... only bz2 produces this error:

Error: bzip2 compression failed. Result: 3

If I upload a CJK filenamed file, I'm not sure if the UTF-8 filenames will be preserved.

Can you rename an MP4 (AVC) or AVI (XviD) to "一二三四.mp4" & "一二三四.avi" and test it out. In English it just means "1234.mp4" & "1234.avi"... Just copy & paste these 4 chars for the rename.

[Mosu]

Ah... I finally was able to consistently re-produce it... Apparently bz2 does not like ANY filename/path names...

Stop right there. Compression is completely internal. The compression code has no access to file names whatsoever.

But anyway, Sneaker_ger's right, I'll remove the support for BZ2 compression soon anyway, so I won't be fixing this.

[fakey]

Hi
http://i45.tinypic.com/vevlnt.png
The redbox here(Edit19 in control name) became dropdownstyle with recent updates.
In this way it's a bit cumbersome to paste a timecode in there because activating mmg window always makes the box select-all state.
Is there a way the dropdownstyle could apply only when we select split-by-size mode?

http://i46.tinypic.com/34476nn.png
dozens of items in ListBox1 -> maximize mmg window -> restore -> layout off

[Mosu]

Hi
http://i45.tinypic.com/vevlnt.png
The redbox here(Edit19 in control name) became dropdownstyle with recent updates.
In this way it's a bit cumbersome to paste a timecode in there because activating mmg window always makes the box select-all state.
Is there a way the dropdownstyle could apply only when we select split-by-size mode?

I won't spend a few hours coding this (no, it's not just a flag; I would have to hide that control and show a normal input one; then handle loading & saving of arguments, arg validation, build command lines, tooltips etc etc -- yes, this would amount to two or three hours) so you can save a second or two. Sorry. I'm open to patches, though.

http://i46.tinypic.com/34476nn.png
dozens of items in ListBox1 -> maximize mmg window -> restore -> layout off

Not my problem. The toolkit I use, wxWidgets, handles all layouting. So if it does something like that then it's a bug in wxWidgets that I will certainly not try to fix myself.

[Overdrive80]

Hi Mosu, I create mkv file with ordered chapters. I understand that chapters havent correlative tempos, but If I create subchapters is necesary to use global times.

I put example. Using this script, I get times of episode:

DGDecode_mpeg2source("E:\DBZ\DBZ1_22\127\Title_3.d2v", info=3)

ColorMatrix(hints=true, threads=0)

trim(2616,32431)++trim(34736,0)

# ^Episodio^ ^Avance^

If I choose times for subchapters by this script, will not create subchapters in position.

http://s6.postimage.org/sln0nrfy5/image.jpg (http://postimage.org/image/sln0nrfy5/)

However, If I use times of this script (without split):

DGDecode_mpeg2source("E:\DBZ\DBZ1_22\127\Title_3.d2v", info=3)

ColorMatrix(hints=true, threads=0)


mkvmerge create subchapters in position properly.

I dont understand that for subentries of chapter I need global times and for principal chapters relative times. It is correct??

[Mosu]

All chapter timecodes are absolute and not relative. No matter on which layer they're located.

[Overdrive80]

Then I dont understand that ocurr.

Metric of full episode without split is:


Opening: frames 0-2615 --> times 00:00.000-01:49.067
Episode: frames 2616-32431 --> times 01:49.109-22:32.643
First part episode: frames 2616-16047 --> times 01:49.109-11:09.294
Eyecatch: frames 16048-16339 --> times 11:09.335-11:21.472
Second part episode: frames 16340-32431 --> times 11:21.514-22:32.643

Ending: frames 32432-34735 --> times 22:32.685-24:08.739
Preview: frames 34736-35472 --> times 24:08.781-24:39.478


If I use times in bold, mkvmerge create subchapters properly.

Metric with split is (episode+preview):


Opening: frames 0-2615 --> times 00:00.000-01:49.067
Episode: frames 0-29815 --> times 00:00.000-20:43.534
First part episode: frames 0-13431--> times 00:00.000-09:20.185
Eyecatch: frames 13432-13723 --> times 09:20.226-09:32.363
Second part episode: frames 13724-32431 --> times 09:32.405-20:43.534
Ending: frames 0-2303 --> times 00:00.000-01:36.054
Preview: frames 29816-30552 --> times 20:43.576-21:14.273


If I use times no bold, mkvmerge create subchapters wrong.

Why?

Ordered Chapters Correct (https://dl.dropbox.com/u/19135067/ordered%20chapters_Correct.xml)

[Mosu]

I have no experience with prdered chapters, sorry.

[vdcrim]

I don't think that subchapters + ordered is a very common combination. It could also be the splitter's fault. Did you try adding your subchapters at the top level instead?

[Overdrive80]

I don't think that subchapters + ordered is a very common combination. It could also be the splitter's fault. Did you try adding your subchapters at the top level instead?

I could create it properly, my dude is: Why I have use different times? Its as if time chapters were relative times, and subchapters absolute times?

I think that to muxing generate times of playback adjust to times of chapters, and subchapters times arent adjust and for this reason is necessary provide absolute times.

[Mosu]

The chapter timecodes are only adjusted by mkvmerge if you use splitting as well. If you don't it writes the chapter timecodes to the output file as they were.

[yonta]

2013-02-03 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Implemented support for reading MPLS
BluRay playlist files. All M2TS files referenced from an MPLS file
are processed. Chapter entries from that MPLS file are used as
well. Implements #765.

Good to have a great new feature and thank you for your effort. But, mmg doesn't accept MPLS files and I don't see MPLS in the mkvmerge's supported file types?

One more thing, does MPLS support include support for seamless branching Blu-ray?

[Mosu]

Good to have a great new feature and thank you for your effort. But, mmg doesn't accept MPLS files and I don't see MPLS in the mkvmerge's supported file types?

Hrmph, forgot to add it to the list. For the time being you can drag & drop MPLS files and you can change the file selector to "all files" in the "add file" dialog. I'll see that I get MPLS listed as their own type so you won't have to resort to workarounds.

One more thing, does MPLS support include support for seamless branching Blu-ray?

No idea. I only own two BluRay discs (due to me not being willing to shell out hundreds of bucks for high-end equipment when I have a Linux-based media PC right here...). For one the main MPLS file only lists a single M2TS file. For the other it's > 30 M2TS files. Both cases work just fine for me, but that's as far as I could test it.

Please also note that the error messages might be confusing. For some MPLS mkvmerge will claim not to support this file type. This usually means that the underlying M2TS file(s) don't contain enough video information for mkvmerge to recognize them properly. This often happens for stills or short clips usually used in menu background stuff.

[nautilus7]

Latest build seems to have problems with m2ts files.

Command line used:

"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" --output-charset UTF-8 --identify-for-mmg "D:\POLAR_BEAR\BDMV\STREAM\00001.m2ts"

Output:

Error: memory.cpp/safemalloc() called from file src/common/memory.h, line 203: malloc() returned nullptr for a size of 3956920320 bytes.

[Mosu]

Edit: I think I don't need that upload, I just thought of something...

[zeropc]

i encountered something very while demuxing a mkv file (created with mkvtoolnix 5.9.0) with eac3to

eac3to v3.24
command line: "C:\eac3to\eac3to.exe" "J:\movie.mkv" 1: "E:\movie.h264" 3: "E:\movie.sup" 2: "E:\movie.flac"
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 1 subtitle track, 1:39:53, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
"Main Program [AVC]"
2: FLAC, 2.0 channels, 1:39:53, 24 bits, 48kHz
"Main Audio [FLAC 2.0 Mono]"
3: Subtitle (PGS), "Subtitle [SDH]"
[v01] Extracting video track number 1...
[a02] Extracting audio track number 2...
[a02] Decoding FLAC...
[a02] Encoding FLAC with libFlac...
[v01] Creating file "E:\movie.h264"...
[a02] Creating file "E:\movie.flac"...
[s03] Extracting subtitle track number 3...
[s03] Creating file "E:\movie.sup"...
[v01] Video has a gap of 1 frames at playtime 0:01:25. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:28. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:31. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:33. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:36. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:39. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:42. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:45. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:48. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:51. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:54. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:01:57. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:00. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:03. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:05. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:09. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:11. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:15. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:18. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:20. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:23. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:26. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:29. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:32. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:35. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:38. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:41. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:44. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:47. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:50. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:52. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:55. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:02:59. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:02. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:05. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:07. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:10. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:13. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:16. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:19. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:22. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:25. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:28. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:31. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:34. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:37. <WARNING>
[v01] Video has a gap of 1 frames at playtime 0:03:40. <WARNING>
<snip>
[v01] Video has a gap of 1 frames at playtime 1:39:35. <WARNING>
[v01] Video has a gap of 1 frames at playtime 1:39:37. <WARNING>
[v01] Video has a gap of 1 frames at playtime 1:39:40. <WARNING>
[a02] The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 143698 frames.
Subtitle track 3 contains 1 forced caption.
eac3to processing took 12 minutes, 12 seconds.
Done.



any idea what's causing this. i had no error message when muxing this to mkv and i don't have a similar problem with another file. when watching the movie, there are dropouts or other problems. i run the same demux with eac3to 3.27 just to be sure it's not a problem with eac3to 3.24.

[Mosu]

I suggest you ask the eac3to author directly or open a new thread for it. This is not a eac3to support thread. It's big enough as it is already.

[zeropc]

i was adding it in here, in case this was a problem with mkvtoolnix muxing and not a demuxing problem from eac3to

[Mosu]

Well, how should I know why eac3to outputs what it outputs? So please make sure to check strange messages in program A with the author of program A first. My time's already used up with stuff I'm 100% certain are related to MKVToolNix. Thanks.

[Mosu]

Latest build seems to have problems with m2ts files.

Should be fixed in builds 495 and higher (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/).

[nautilus7]

Yes, thanks.

[ImAhNoBoDy]

What are VobButtons [btn]? I saw this on the Supported file types in Mkvmerge. If there are any documentation on it, I'll like to read it. It just sounds interesting.

[Mosu]

That's something Steve Lhomme invented a while ago when he worked on menu support in Matroska. The idea was to export certain VobSub-like stuff from DVDs, put it into Matroska and have that working as buttons. I don't think there's any documentation anywhere, and I solely keep it for compatibility purposes.

[doomNoNine]

My VLC 2.0.0.4 have problems with files I created with MKVToolNix 6.0.0.0. The video plays well until I jump to another time (e.g. from 00:01:00 to 00:44:00). From that moment on the video stops and I have wait a very long time or I have to close and reopen VLC. If I jump a short time (e.g. from 00:01:00 to 00:02:00) VLC continues the video correctly after a short thinking time (maybe 500ms).
The video works well with other players like KMPlayer or MPC-HC.
The mkv parts were ripped with eac3to. The video format is h264/AVC, 1080p24, the audio format is DTS, 5.1 channels, 1509kbps, 48kHz

Is this a known issue? Or am I the only one with that problem? Any ideas what can causes this issue?


PS: many thanks for the great tool!

[Mosu]

Read several posts in this very thread, or just read this: https://trac.bunkus.org/wiki/FAQ%3APlaybackDoesNotWorkVLCCannotSeekMkvmerge590

[doomNoNine]

Thank you very much for your answer. That answers my question and also give me the solution :).

Please keep you work going on your awesome tool.

[Chumbo]

Do the new frame/field splitting features supposed to be frame accurate splitting? I ask because I just tried these on some junk I wanted to remove from the beginning and end of one of my files but am not getting frame accurate. So the i-frame at the beginning of the file is at frame 213 but when I split the file, the first file created has 252 frames. Does this sound right?

I also tried the "by parts" which worked but not correctly on the end of the file. The end of the file was split too soon, i.e., needed to include another 15,715 frames. The source file is an 50fps AVC progressive video.

[Mosu]

Do the new frame/field splitting features supposed to be frame accurate splitting?

Of course not. mkvmerge will still only split on key frame boundaries.

So the i-frame at the beginning of the file is at frame 213 but when I split the file, the first file created has 252 frames. Does this sound right?

Sounds like you're providing the wrong numbers.

1. Mux the file without splitting.
2. Run "mkvinfo -s" on the resulting file.
3. Count the line numbers for the video track.
4. Use the proper line number for splitting.

[Chumbo]

Of course not. mkvmerge will still only split on key frame boundaries.



Sounds like you're providing the wrong numbers.

1. Mux the file without splitting.
2. Run "mkvinfo -s" on the resulting file.
3. Count the line numbers for the video track.
4. Use the proper line number for splitting.
I got the numbers by loading the source in VideoReDo. I just changed its timecode display to frames. I guess the i-frame is NOT the same as the key frame that mkvmerge uses?

I used mkvinfo, out of curiosity, but it's not really helpful in that I can't really use it to figure out the cut spot without a visual cue. I'd still have to load the file into something like VRD or MPC-HC and note the time code and then look up the closest one in the generated output from mkvinfo.

BTW, is it possible to update mkvmerge to split on i-frames? If it is, it would be tremendous as it would give us more accurate cutting/splitting.

Here's some of the output from mkvinfo. Note that VRD shows the cut point I want is at time code 00:00:04.13 which is an i-frame. I have a couple question regarding the output below. The closest time is the line in red below but that doesn't show as an i-frame as VRD showed. How do I determine what is a key frame? Why do some lines below display out of sequence in that the time code on a line may be after the next line (see the time code of the line above the red line which is larger).Track 1: video, codec ID: V_MPEG4/ISO/AVC (h.264 profile: Main @L4.0),
mkvmerge/mkvextract track ID: 0,
default duration: 20.000ms (50.000 frames/fields per second for a video track),
language: und, pixel width: 1280, pixel height: 720, display width: 1280, display height: 720
Track 2: audio, codec ID: A_AC3, mkvmerge/mkvextract track ID: 1,
default duration: 32.000ms (31.250 frames/fields per second for a video track),
sampling freq: 48000, channels: 2
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa600c17d
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xfa3707b5
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x7b86e8ec
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x0efb0179
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa7f8e99d
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xa4e30b41
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0xe478f7ce
I frame, track 2, timecode 0 (00:00:00.000), size 1536, adler 0x9425ff1e
I frame, track 1, timecode 50 (00:00:00.050), duration 17.000, size 26203, adler 0x6d83acb8
P frame, track 1, timecode 117 (00:00:00.117), duration 17.000, size 8561, adler 0x0896c834
P frame, track 1, timecode 67 (00:00:00.067), duration 17.000, size 6769, adler 0x11713793
P frame, track 1, timecode 83 (00:00:00.083), duration 17.000, size 5196, adler 0x79701d13
P frame, track 1, timecode 100 (00:00:00.100), duration 17.000, size 9341, adler 0x99401e5a
P frame, track 1, timecode 183 (00:00:00.183), duration 17.000, size 24597, adler 0xe1b3edfb
P frame, track 1, timecode 133 (00:00:00.133), duration 17.000, size 8295, adler 0xff7bf89b
P frame, track 1, timecode 150 (00:00:00.150), duration 17.000, size 5846, adler 0x05424def
P frame, track 1, timecode 167 (00:00:00.167), duration 17.000, size 8942, adler 0x780c5d87
P frame, track 1, timecode 250 (00:00:00.250), duration 17.000, size 21551, adler 0x281023d8
P frame, track 1, timecode 200 (00:00:00.200), duration 17.000, size 8390, adler 0x28452b21
P frame, track 1, timecode 217 (00:00:00.217), duration 17.000, size 6116, adler 0x2ccb050b
P frame, track 1, timecode 233 (00:00:00.233), duration 17.000, size 11348, adler 0x61f22e32
. . .
P frame, track 1, timecode 4050 (00:00:04.050), duration 17.000, size 24013, adler 0x01178a0d
P frame, track 1, timecode 4000 (00:00:04.000), duration 17.000, size 13182, adler 0x2e919ed3
P frame, track 1, timecode 4017 (00:00:04.017), duration 17.000, size 7637, adler 0x64bed522
P frame, track 1, timecode 4033 (00:00:04.033), duration 17.000, size 12911, adler 0x663e07d6
P frame, track 1, timecode 4117 (00:00:04.117), duration 17.000, size 14352, adler 0xf15906a7
P frame, track 1, timecode 4067 (00:00:04.067), duration 17.000, size 12235, adler 0x4032ec87
P frame, track 1, timecode 4083 (00:00:04.083), duration 17.000, size 9814, adler 0xf8cbe7a1
P frame, track 1, timecode 4100 (00:00:04.100), duration 17.000, size 7123, adler 0xe27ae2f9
P frame, track 1, timecode 4183 (00:00:04.183), duration 17.000, size 8621, adler 0x613cc166
P frame, track 1, timecode 4133 (00:00:04.133), duration 17.000, size 3868, adler 0x42adaa57
P frame, track 1, timecode 4150 (00:00:04.150), duration 17.000, size 5307, adler 0xd7fc7d9c
P frame, track 1, timecode 4167 (00:00:04.167), duration 17.000, size 5644, adler 0x47e7f2d0
P frame, track 1, timecode 4250 (00:00:04.250), size 8404, adler 0xe3e049d7

[Overdrive80]

Hi Mosu, the option "adjust timecodes" of "Chapter editor" doesnt save the changes.

[Mosu]

Hi Mosu, the option "adjust timecodes" of "Chapter editor" doesnt save the changes.

If you mean that the same value you've entered once is not pre-selected the next time you use that function: of course not. The moment you use that option the offset you've entered is added to all chapter timecodes. It would be highly confusing to the user if, after having applied an offset of e.g. 2min, the dialog box would be pre-selected with 2min yet again. This would lead the user to the assumption that it simply stays the same if he hits enter right now, while in truth it would apply another 2min of offset.

If you mean that the offset you enter is not actually added to the start/end timecodes: I cannot reproduce that.

For me this is working as intended.

[Mosu]

I got the numbers by loading the source in VideoReDo. I just changed its timecode display to frames. I guess the i-frame is NOT the same as the key frame that mkvmerge uses?

How would I know? I've never used VideoReDo, nor have I written it myself. Quoting mkvmerge's documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.description.split):

Note:

The numbers given with this argument are interpreted based on the number of Matroska(tm) blocks that are output. A single Matroska(tm) block contains either a full frame (for progressive content) or a single field (for interlaced content). mkvmerge does not distinguish between those two and simply counts the number of blocks. For example: If one wanted to split after the 25th full frame with interlaced content one would have to use 50 (two fields per full frame) as the split point.

BTW, is it possible to update mkvmerge to split on i-frames? If it is, it would be tremendous as it would give us more accurate cutting/splitting.

I don't really understand what you want here. Being able to enter the n-th I frame (e.g. "5" would split on the fifth key frame encountered)? Anyway, the answer is almost certainly "no interest in implementing that, sorry".

Here's some of the output from mkvinfo. Note that VRD shows the cut point I want is at time code 00:00:04.13 which is an i-frame.

Not according to how it is stored in Matroska. I'm not saying that it isn't a key frame, I'm just saying that it isn't marked as one. That's the fault of whatever software didn't mark it as a key frame, and mkvmerge cannot do anything about it.

How do I determine what is a key frame?

mkvmerge relies on the information on the container level for frame type distinction. The frames it can split on are the ones that mkvinfo reports as "I frame ....".

I stress that again: mkvmerge is not in the business of fixing the container information if a previous program gets that wrong! So if the source container said "the video frame at 00:00:04.whatever is a P frame, not a key frame" then mkvmerge will believe it.

Why do some lines below display out of sequence

B frames not marked as B frames. Read up on presentation timecodes vs. decode timecodes somewhere if you don't know what that means.

[Chumbo]

How would I know? I've never used VideoReDo, nor have I written it myself...
It was really a rhetorical question meaning shouldn't there be consistency in the standard in how the apps read and parse these streams? So what VRD would show as an i-frame would still be an i-frame in the stream when mkvmerge works with it or whatever software.

I don't know enough about this stuff that's deeper than below the surface which is why I'm asking some of these questions. From my perspective, it seems that regardless of the container, the elementary stream would contain the same info.

Yeah, I'll definitely have to read up on more than just the B frames stuff.

In regards to using i-frames rather than key frames. I noticed that key frames can really be problematic when splitting a file because they can have long intervals between them, e.g., 10 seconds between each key frame. So you can never get a clean split. Again, not knowing much about this, I know that other software splits on i-frames and is more accurate for splitting. So that's all I was asking. Maybe that's not doable in mkvmerge and that's fine, but I thought I'd ask.

[Mosu]

From the point of view of mkvmerge/Matroska key frames and I frames are the same thing. If your source signals wrong frame type flags on the container level then that is not mkvmerge's problem, sorry.

[magic75]

I just upgraded from 5.1.0 to 6.0.0 (Linux) and I am having problems with the --aspect-ratio option.

excerpts from mediainfo

Writing application : mkvmerge v5.1.0 ('And so it goes') built on Feb 1 2012 11:31:23
Writing library : libebml v1.2.2 + libmatroska v1.3.0
Width : 700 pixels
Height : 420 pixels
Display aspect ratio : 16:9
Original display aspect ratio : 1.667

Writing application : mkvmerge v6.0.0 ('Coming Up For Air') built on Jan 20 2013 10:28:01
Writing library : libebml v1.3.0 + libmatroska v1.4.0
Width : 700 pixels
Height : 420 pixels
Display aspect ratio : 1.667

The files created with 5.1.0 are stretched to 16/9 when played in mplayer, but the files created with 6.0.0 are played as is at 700x420.

[sneaker_ger]

And this is with the same source file?