mkvtoolnix 4.1.1 released

[Mosu]

Current version is 4.1.1; see http://forum.doom9.org/showthread.php?p=1414216#post1414216

--------------------------------------------------------------------

Hey users,

I'm proud to present you version 2.0.0 of mkvtoolnix. This release contains new features like support for AVC/h.264 elementary streams (both single files and from AVIs); proper support for MPEG-1/-2 videos without the ugly blockiness; support for extracting MPEG-1/-2 video tracks; use of "simple blocks" with subtitles has been fixed; tons of usability enhancements to mmg; and the usual list of smaller bug fixes.

A special "thanks" to all the people who extensively tested my h.264 support and provided a lot of insight and sample files.

The usual links...
...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-2.0.0.tar.bz2

...the Windows binaries (2000/XP or later):
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.0-setup.exe

The binaries for the various Linux versions that I provide have already been updated and are available from the download page: http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the ChangeLog since 1.8.1:

------------------------------------------------------------------
2007-01-12 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added another tab for each track in which the user can add arbitrary track options.
* mkvextract: enhancement: mkvextract will now also print which container format it uses for each track.
* mkvextract: new feature: Added support for extracting MPEG-1/2 video to MPEG-1/2 program streams.
* mkvmerge: bug fix: Fixed the file type detection for MPEG-1/2 ES files with a single frame inside.

2007-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG-1/2 video: The sequence and GOP headers are not removed from the bitstream anymore. This should fix the blockiness if the sequence headers change mid-stream. Fix for Bugzilla bug #167.

2007-01-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge now handles the first frames in AVC/h.264 ES streams properly, especially for files for which it did not find a key frame at the beginning in earlier versions.

2007-01-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Improved the detection of AVC/h.264 ES streams with garbage at the beginning.
* mmg: enhancements to the job management dialog: There's a minimum width for the columns. The "up" and "down" buttons are disabled if all entries are selected. Pressing "Ctrl-A" selects all entries.
* mmg: enhancements: "File -> New" will also focus the "input" tab.

2007-01-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancements: The job manager can be opened with "Ctrl-J". The last directory from which a file is added is saved even if the file identification failed. The automatically generated output file name uses the extension ".mka" if no video track is found and ".mks" if neither a video nor an audio track is found in the first file.
* mkvmerge: bug fix: Fixed the aspect ratio extraction for raw AVC/h.264 ES tracks.
* mkvmerge: bug fix: If a raw AVC/h.264 ES file does not start with a key frame then all the frames before the first key frame are skipped, and mkvmerge does not abort anymore.

2007-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: AVC/h.264 ES parser: Fixed wrong NALU size length information in the AVCC.
* mkvmerge: bug fix: AVC/h.264 ES parser: Fixed the decision if a NALU belongs to a previous frame or starts a new one.

2007-01-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added an input for the new "NALU size length" parameter.
* mkvmerge: bug fix: The NALU size length can be overridden for AVC/h.264 elementary streams. It defaults to 2 which might not be enough for larger frames/slices.

2007-01-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Support for AVC/h.264 elementary streams with short markers (0x00 0x00 0x01 instead of 0x00 0x00 0x00 0x01).
* mkvmerge: Removed the "--engage allow_avc_in_vfw_mode" hack.
* mkvmerge: enhancement: Added "x264" to the list of recognized FourCCs for AVC/h.264 video in AVI and Matroska files.
* mkvmerge: new feature: Added support for proper muxing of AVC/h.264 tracks in Matroska files that were stored in the MS compatibility mode (CodecID V_MS/VFW/FOURCC instead of V_MPEG4/ISO/AVC).
* mkvmerge: bug fix: Fixed invalid memory access in the AVC ES parser.

2007-01-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for proper muxing of AVC/h.264 tracks in AVI files.

2007-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading AVC/h.264 elementary streams.

2006-12-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: All inputs and controls are cleared and deactivated if the user select "File -> New".
* mmg: enhancement: The user can switch between the "generic" and "format specific options" pages even if no track is selected.

2006-12-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge would not write frame durations if "--engage use_simpleblock" was used resulting in unplayable and unextractable subtitle tracks.

2006-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Added a workaround for RealAudio tracks for which the key frame flag is never set.

2006-12-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a segfault that occured if the user had a track selected and its the file the track was read from is removed.
* mmg: bug fix: Fixed the behaviour of a couple of ComboBoxes on Windows after selecting "File -> New". E.g. if the user selected "700M" in the "split after this size" ComboBox, selected "File -> New" and selected "700M" again, then it would not show up in the command line window until he selected another option and returned to the "700M" afterwards.
------------------------------------------------------------------

Have a nice weekend :)

Regards,
Mosu

[shon3i]

Nice, thanks for hard work

[HeadBangeR77]

That's good news :) Much appreciated!

[buzzqw]

that's awesome ! thanks !!!

BHH

[Sharktooth]

linux version works perfectly, thanks ;)

[LeMoi]

If i'm on Global Settings Tab and and make a new muxing (via ctrl+n), mmg gets back to Input Tab :(

[Eragon4ever]

* mmg: enhancements: "File -> New" will also focus the "input" tab.

This feature was requested by me. I set the options on the Global tab always after I load a file and don't see the sense in doing it the other way.
Why do you prefere the old behavior?

Regards,
LaughingMan ;-)

[LeMoi]

Because sometimes i mux series of files with same prefix ; for example i mux with title : "Name of show - SXXEXX - title of episode", and after muxing, when i want to mux next episode, instead of typing again "Name of show - SXXEXX+1 - title of episode", i copy it before making new mux, then paste it into new mux, thus it's easyier to stay in Global Settings instead of getting back to Input, then Global Settings
I don't know if i'm clear :D

[Eragon4ever]

Got it (and doing it myself sometimes:p ).
However you still have to load the next file (or did I miss something?) so you could copy the title, load the next file etc. and THEN paste and mux.

[Mosu]

I can make it optional. Hmm, I think it's time to move the "settings" tab to its own window :)

[guada2]

great work Mosu.
Bye ;)

[madshi]

The new version is much appreciated!

:thanks:

[Isochroma]

Your work continues to be invaluable to the video community, so a heatfelt thank you!

I've been playing with demuxing EVOBs (http://forum.doom9.org/showthread.php?p=935396#post935396) recently (they're enhanced VOBs), and had the opportunity to test AVC-ES muxing in 2.0.0.

Now, I've already tested it on more generic AVC-in-AVI streams and it's worked fine, however...

Using Graphedit, I've been able to get a very wild & wooly .264 file from an EVOB. MKVToolnix muxes it with no errors, but when played the file shows bad blocking and artifacting on almost every frame.

After finding this out, I used Yamb 1.6.0 to mux to .mp4, which subsequently played just fine. Perfect results were also achieved after muxing this .mp4 into MKV with 2.0.0.

So there is some difference between your ES handling code and MP4Box's.

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

To finish off, many new file sources in VC-1 are coming online, and so I'd like to suggest the possibility of MKVToolnix supporting VC-1 muxing.

For example, many HD-DVDs are encoded with this new codec, but often the on-disc EVOBs are too difficult for users to play due to high CPU usage, or impossible due to HDCP requirements.

Remuxing AVC from EVOB to MKV has reduced the CPU usage at least 40%, by my latest test. It was enough to make an unplayable video playable, so this excellent format will undoubtedly also make a very significant difference in VC-1 playback performance.

[HeadBangeR77]

Just a small question: I've recently made an encode with XviD & AC3 5.1 with VDubMod directly into *.mkv container. As an error appeared during muxing the video with audio and the whole process didn't finish I decided to mux with MKVToolnix. Out of two possible ways one worked fine and one didn't:

1) Adding the final pure-video *.mkv worked just fine. I added the audio + subs + *.xml chapters and everything was ok.

2) I also extracted the resulting video from VDubMod's mkv using AVI-Mux GUI into raw MPG-4 ASP stream. MVKToolnix didn't want to swallow it.

Don't get me wrong, it's not a problem for me, as the first way is an easier and faster solution, but just a matter of supporting such streams (for my own curiosity :p). Am I missing sth obvious? (I'm pretty unexperienced with mkv muxing) ...

[LeMoi]

However you still have to load the next file (or did I miss something?) so you could copy the title, load the next file etc. and THEN paste and mux.
I don't load it, i "make" it, it's a new muxing from video and audio files. But i paste then mux, i'm not on Global Settings tab any more with mmg 2.0.
Any way it's no big deal, i was just used to this feature ^^

[Mosu]

Using Graphedit, I've been able to get a very wild & wooly .264 file from an EVOB. MKVToolnix muxes it with no errors, but when played the file shows bad blocking and artifacting on almost every frame.

After finding this out, I used Yamb 1.6.0 to mux to .mp4, which subsequently played just fine. Perfect results were also achieved after muxing this .mp4 into MKV with 2.0.0.

So there is some difference between your ES handling code and MP4Box's.

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

I don't know any tool for cutting, sorry. Just upload the full 107 MB :) It doesn't matter if it takes quite a while. Thanks.

To finish off, many new file sources in VC-1 are coming online, and so I'd like to suggest the possibility of MKVToolnix supporting VC-1 muxing.

I don't really know anything about VC-1 and how to parse it. And I'm still busy with other bugs/things, so I won't invest time into VC-1 right now. But I'll keep it in mind.

[Mosu]

2) I also extracted the resulting video from VDubMod's mkv using AVI-Mux GUI into raw MPG-4 ASP stream. MVKToolnix didn't want to swallow it.

As you've guessed mkvtoolnix does not support MPEG-4 part 2 ASP raw streams.

[HeadBangeR77]

As you've guessed mkvtoolnix does not support MPEG-4 part 2 ASP raw streams.
Short & clear, ta ;)

[Eragon4ever]

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

I use this (http://rapidshare.com/files/11808088/Chainsaw_3.7.7z.html) (uploaded it because I don't know where to get ). It's in German but the most things should be self-explanatory. Just set the size and drag the file on the chainsaw picture. It may cut every file type because it just starts an new file after the given size.

[DoctorEnsGabe]

Two quick questions about mkvtoolnix 2.x:

1) Are MPEG-2 in TS files on the radar for a future version?

2) In your ubuntu repositories, why do you have a separate package 'mkvtoolnix-mb' instead of a version-bumped mkvtoolnix? The way you have it set up, your package conflicts with and removes mkvtoolnix and subsequently removes everything that depends on it, e.g. mkvtoolnix-gui. Is this just an oversight, or are there some irreconcilable differences between those two packages?

[Mosu]

Two quick questions about mkvtoolnix 2.x:

1) Are MPEG-2 in TS files on the radar for a future version?

Most likely not.

2) In your ubuntu repositories, why do you have a separate package 'mkvtoolnix-mb' instead of a version-bumped mkvtoolnix? The way you have it set up, your package conflicts with and removes mkvtoolnix and subsequently removes everything that depends on it, e.g. mkvtoolnix-gui. Is this just an oversight, or are there some irreconcilable differences between those two packages?

That's the intention. mkvtoolnix and mkvtoolnix-gui are the official packages in Debian and Ubuntu. My package is mkvtoolnix-mb and contains both the command line and the GUI versions. I just don't want to get in the way of the official packages.

[madshi]

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?
You can use a hexeditor to look for "00 00 00 01 67". Make sure that the h264 file begins with that sequence and make sure that it ends directly "before" such a sequence. Then you should have a good and clean cut.

[HyperDrive]

Just tested mkvmerge 2.0.0. The subtitles with short blocks problem I mentioned in this thread (http://forum.doom9.org/showthread.php?t=120179) is apparently corrected. Thank you very much for this new version! :)

[yonta]

problem with muxing MPEG4 AVC ES into .mkv. mkvmerge GUI muxes it fine but no player that I have can play the muxed file. I tried VLC, MPC, Mplayer, and plain old windows built-in mplayer2 with haali's splitter and ffdshow, all players just play audio only. If I mux the same source ES first into .mp4 with mp4box then .mkv with mkvmerge GUI, it plays just fine.

[Eragon4ever]

problem with muxing MPEG4 AVC ES into .mkv. mkvmerge GUI muxes it fine but no player that I have can play the muxed file. I tried VLC, MPC, Mplayer, and plain old windows built-in mplayer2 with haali's splitter and ffdshow, all players just play audio only. If I mux the same source ES first into .mp4 with mp4box then .mkv with mkvmerge GUI, it plays just fine.

Confirmed. I have such files, too.

[Mosu]

Isochroma uploaded a file for me which seems to show exactly the behaviour you two are encountering. I'll try to fix this later this week. But if you could upload some more files to my FTP server then I'd be grateful. 10 MB or so should be enough, but you can also upload 50 MB or so.

[Eragon4ever]

First 20 MB of my file are on your ftp (folder: LaughingMan; name: "Elfen Lied - 01 - ...").

It muxes fine with simple block enabled, without it says the NALU size is to small.

[Mosu]

Please read the error message. You can and must set the NALU size manually for such files.

The only alternative would be to always use bigger NALU sizes resulting in bigger files which I don't want to do.

[Eragon4ever]

I read it and did as it said however BOUTH files (the one with simple block enabled and with NALU 3) don't play. I should have been more exact.

[bob0r]

When i open a H.264 .ts file with 2 AC3 audio tracks, only the video is added.

Is this a feature or a bug?

and an off topic question:
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.ac3 file.ts

Doing that (those files mux perfect in .mkv now) will only extract 1 of the 2 AC3 tracks, how can i extract both?

[Mosu]

When i open a H.264 .ts file with 2 AC3 audio tracks, only the video is added.

Is this a feature or a bug?

Feature. Or a bug. Depends on your point of view. mkvmerge does NOT support transport streams! If it says it finds a h.264 es file then mkvmerge is mis-detecting the file, and I guess that the resulting .mkv is not playable.

and an off topic question:
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.ac3 file.ts

Doing that (those files mux perfect in .mkv now) will only extract 1 of the 2 AC3 tracks, how can i extract both?

Try selecting a different track with -aid in the second case.

[bob0r]

Thanks for the quick answers, on all issues you were correct, helped a lot.

Very very sad you dont support .ts to .mkv directly, it would be the most perfect way to store satellite captures.
.ts to .mkv (if http://rickman.ri.funpic.de/ can calculate the audio delay, than so can you), then deselect any unwanted audio track, or all, and mux DD or DTS with the Video.

Cut the perfect end result file (who needs credits?), save some space on your HDD..... man i wish i never wake up.

[Mosu]

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

[Mosu]

Very very sad you dont support .ts to .mkv directly, it would be the most perfect way to store satellite captures.

:) Does anyone have specs for h.264 transport streams? And just as important: lots of sample files?

[bob0r]

Additional it seems like who ever gave you the samples, wasn't using any of mine.
Muxing BBC-HD MBAFF raw.264 + raw.mp2 is giving glitches.
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.mp2 file.ts

I tried on this sample: beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror01.x264.nl//public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts)

I got more samples:


all 19.0 MB (19,963,908 bytes) (dd if=source.ts of=result.ts bs=188 count=106191 skip=0)

00:07 premiere.hd.ts
00:08 bbc.hd.ts
00:09 anixe.hd.ts
00:09 sky.movies.9.hd.ts
00:13 astra.hd.ts
00:14 arte.hd.ts
00:16 euro1080.hd5.ts
00:16 prosieben.hd.ts
00:17 luxe.hd.ts
00:18 hd.forum.tf1.hd.ts

~08mbit hd.forum.tf1.hd.ts
~09mbit luxe.hd.ts
~10mbit prosieben.hd.ts
~10mbit euro1080.hd5.ts
~11mbit arte.hd.ts
~12mbit astra.hd.ts
~17mbit sky.movies.9.hd.ts
~17mbit anixe.hd.ts
~19mbit bbc.hd.ts
~22mbit premiere.hd.ts

Guessed encoders:
grass valley bbc.hd.ts
grass valley euro1080.hd5.ts
tandberg anixe.hd.ts
tandberg arte.hd.ts
tandberg astra.hd.ts
tandberg luxe.hd.ts
tandberg premiere.hd.ts
tandberg prosieben.hd.ts
tandberg sky.movies.9.hd.ts
scientific atlanta hd.forum.tf1.hd.ts

grass valley, ViBE H.264: http://www.thomsongrassvalley.com/products/transmission/vibe/encoder_mpeg4_hd/
scientific atlanta, H.264: http://www.scientificatlanta.com/customers/Source/7006554.pdf
tandberg, H.264: http://www.tandberg.net/our_story/h264.jsp


I can give you a PM if you are interested in these samples.

Edit:
@Mosu guess i read your mind :p

[Eragon4ever]

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

Thanks!
All my samples play fine now.

[bob0r]

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

This update fixed my BBC-HD H.264 MBAFF also, i set it to nal size 3 as the warning showed me, great work.

[madshi]

:) Does anyone have specs for h.264 transport streams? And just as important: lots of sample files?
Are you seriously working on this? That would be lovely, of course! I've lots of h.264 transport streams. But I guess most are just the same, because they're all captured with the same software from the same TV channel.

[Isochroma]

Thanks to your efforts, my problem is solved also... but one more thing, the test.264 that I muxed with Yamb, I set the fps to 23.976, and when the MP4 was merged into MKV, the framerate now showed as 24...

With the new MKVMerge, muxing directly the ES and setting its framerate to 23.976, the output MKV has a framerate of 24.975025? Strange...

[Audionut]

Thanks Mosu.

[yonta]

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

problem solved! muxed avc es with nalu set to 3 and it plays fine!
Thank you.

[Mosu]

Are you seriously working on this? That would be lovely, of course! I've lots of h.264 transport streams. But I guess most are just the same, because they're all captured with the same software from the same TV channel.

I'm seriously considering working on it ;) Problem is that I don't have any specs so far, and it's always easier working with specs than just digging into the source code of various media players and muxing applications.

[Mosu]

@Mosu guess i read your mind :p

Indeed you do :) Thanks for the samples.

[Mosu]

but one more thing, the test.264 that I muxed with Yamb, I set the fps to 23.976, and when the MP4 was merged into MKV, the framerate now showed as 24...

I cannot reproduce that. I've done the following:

0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ MP4Box test.mp4 -fps 23.976 -add test.264
...
0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvmerge -o test.mkv test.mp4
...
0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvinfo test.mkv | grep 'Default duration'
| + Default duration: 41.708ms (23.976 fps for a video track)


With the new MKVMerge, muxing directly the ES and setting its framerate to 23.976, the output MKV has a framerate of 24.975025? Strange...

Oops, my bad. For some special values (23.976 and 29.97) mkvmerge was supposed to use more exact values, and I made a typo there :) Please try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070117-1.rar

[Mosu]

Hey,

this is a small "poll" of sorts. It concerns mkvmerge's AVC/h.264 ES handling code. As some of you have noticed mkvmerge has a new parameter, "--nalu-size-length". A short explanation of what it does and why it is neccessary:

In MP4 and Matroska files each h.264 slice is prefixed with its size. This "NALU size" is always a fixed number of bytes long. It can be between one and four bytes, but it cannot vary inside a file. Two bytes means that each slice can be at most 65535 bytes long, three bytes allow for 16777215 bytes. mkvmerge defaults to "two bytes".

However, with HDTV content this almost always seems to be too low, and three bytes are needed. Hence mkvmerge's error message. Now I can have mkvmerge default to "three bytes" for the NALU size. But what would that mean?

Advantage: mkvmerge will no longer abort with this error message.

Disadvantage: For each slice mkvmerge will need one more byte of space. As each frame can consist of many slices (I have files with six slices per frame) this may become quite an extra overhead. For example, take a 25 FPS movie with six slices per frame and a duration of 90 minutes. This would mean that the resulting file would be 90 (minutes) * 60 (seconds per minute) * 25 (frames per second) * 6 (slices per frame) = 810000 bytes.

Another possibility would be to have mkvmerge scan the complete input file first in order to find the "optimal" value for the NALU size length. But that would, as I said, require reading the same file twice -- once for scanning, once for muxing.

So I'd like to know which option you prefer. Is it...

1. keep it like it is (default "two bytes", no scanning),
2. change it to "three bytes", no scanning or
3. implement scanning?

Thanks for the answers :)

[Eragon4ever]

I have a 4th possibility (I think):
Keep it as it is but if the NALU is to small try 3 bytes.

Besides, I would prefer scanning as it gives me smaller sizes in a reasonable amount of time (and the chance of using just 1 byte).

Edit: I think I found the TS specs: ISO 13818-1 (http://neuron2.net/library/mpeg2/iso13818-1.pdf)

[Mosu]

I have a 4th possibility (I think):
Keep it as it is but if the NALU is to small try 3 bytes.

Nah, not really. This would require either rewriting the part of the file that has already been written or to restart mkvmerge. I don't like either case very much; even though the latter is way easier to implement.

Besides, I would prefer scanning as it gives me smaller sizes in a reasonable amount of time (and the chance of using just 1 byte).

Don't underestimate the time it takes to scan a complete file. But anyway, I'll count this as a vote for "3." :)

Edit: I think I found the TS specs: ISO 13818-1 (http://neuron2.net/library/mpeg2/iso13818-1.pdf)

Cool, thanks.

[Henrikx]

@Mosu
Thank You ! Great Work !

[madshi]

So I'd like to know which option you prefer. Is it...

1. keep it like it is (default "two bytes", no scanning),
2. change it to "three bytes", no scanning or
3. implement scanning?
I vote for implementing 3 as default, as I'm running mkvmerge in batch in background, anyway, so time cost is not the most important factor for me. But if you decide to implement 3, you could still offer 1/2 as alternative options, if you think it's worth it.

Alternative: How late in the game could it happen that you find out that NALU 2 is not enough? If you can find out by scanning only the first 200 MB, that would be my most preferred option.

[Mosu]

Alternative: How late in the game could it happen that you find out that NALU 2 is not enough? If you can find out by scanning only the first 200 MB, that would be my most preferred option.

Worst case is that I find out with the very last slice that is read. Therefore scanning the first 200 MB should be enough for almost all files, but I don't want to rely on that too much.