MKVToolNix v24.0.0 released

[Ripman]

Thanks for the 9.9 update.

I mostly use the command line, but have tried to use the GUI also since the switchover - to help identify things after the big changes.

Anyway, I thought we could use Ctrl-U to set the mkv title in the new GUI. Did this feature get retired?

Not important or anything tbh - if it something to address say as much and I'll put it in github.

[Ripman]

A few months back I asked if MKVToolnix would ever support dsf audio files. At the time, I believe you were not aware of the audio format's details and uses, so I supplied some info.

Most of the music download sites offer dsf downloads now (hdtracks, acoustic sounds, etc.).

Would you consider implementing support for dsf/dsd in MKVToolnix?

I'll try to dig up a dsf/dsd specification doc. [edit: here is the dsf file format spec from Sony. http://dsd-guide.com/sites/default/files/white-papers/DSFFileFormatSpec_E.pdf]

[Mosu]

Anyway, I thought we could use Ctrl-U to set the mkv title in the new GUI. Did this feature get retired?

It's still available, but its hotkey has been changed. See the "Multiplexer" menu for which hotkey to use. The reason for that change was to have the global hotkeys match the menu hotkeys (e.g. pressing "f" while the "Multiplexer" menu is open invokes the same action as pressing "Ctrl+F" while not in a menu).

[Mosu]

Would you consider implementing support for dsf/dsd in MKVToolnix?

Not at the moment, no. Nor in the near future.

[VAMET]

Dear Friends

I would like to ask, are there any possibilites to change video and audio tags in .mkv file?

I would like to change tags for video: "Length" and for audio: "Bit rate", "Channels", "Audio sample rate". I know I can use --tags track:a1:audio.xml and leave .xml file empty and audio tags will be removed, but I would like to change them as above. I don't want to autocalculate using --add-track-statistics-tags, I would like to add my custom ones.

I would be glad for your help and support.

Thank you in advance.

Sincerely

[sneaker_ger]

What's preventing you from setting --disable-track-statistics-tags and adding custom tags via xml?

[VAMET]

Dear sneaker_ger

What's preventing you from setting --disable-track-statistics-tags and adding custom tags via xml?

I don't want to double audio tags like "Bit rate", I would like to edit exist tags. So are there any possibility to change audio tags like "Bit rate"? I know I can change via mkvpropedit "Channels", "Audio sample rate", but there is no possibility to override "Bit rate" tag.

Sincerely

[sneaker_ger]

If you want to edit tags you need to extract the tags (as xml), edit the xml and re-add them via mkvpropedit or mkvmerge. (or create them from scratch instead of extracting them first)

https://mkvtoolnix.download/doc/mkvextract.html#mkvextract.description.tags
https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.tags
https://mkvtoolnix.download/doc/mkvpropedit.html

That said, I have no idea why you would want to edit the bitrate tag ("BPS"). The one calculated by mkvmerge is correct as far as I can see. So if you edit it you will most likely end up with a wrong value.

[VAMET]

Dear sneaker_ger

Thank you for your time and help. All I need is "BPS", but when I use this below .xml file, I have a result with 0kb/s for video and audio "Bit rate", when I view information about .mkv file. Is something wrong with this .xml file? File contains only two tracks: 1 - video, 2 - audio.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE Tags SYSTEM "matroskatags.dtd">

<Tags>
<Tag>
<Targets>
<TrackUID>1</TrackUID>
<TrackUID>2</TrackUID>
</Targets>
<Simple>
<Name>BPS</Name>
<String>700kb/s</String>
</Simple>
</Tag>
</Tags>

I will be glad for your help and support.

Sincerely

[sneaker_ger]

Yes, something like that. But drop the "kb/s", the unit is already implied. Of course I can't see if the UIDs are correct without the complete mkv file. But if this achieves your end goal (which you have not explained) is a different question altogether. You say "I have a result with 0kb/s for video and audio "Bit rate"" but I don't know what you are talking about. I still recommend to let mkvmerge calculate everything automatically instead.

[VAMET]

Dear sneaker_ger

I don't think NAME=BPS and STRING=<SOME_BPS> is working, when I use NAME=TITLE and STRING=<SOME_TITLE> it's OK.

I just want to put BPS to be custom thats all and it's for my private purpose. But as I said earlier I cannot manage to do it. Maybe I am doing something wrong with this .xml file. Maybe you will try on any media file of your own and change BPS to any other value.

Thank you for your time and help.

EDIT

OK, I know what was the problem with BPS :) I want to set 640kb/s and in string I put 640 and everytime I have a result of 0kb/s. BPS should be set as 640000 for 640kb/s. My fault, everything works as it should. Thank you once again for your help.

Sincerely

[sneaker_ger]

Yes, "BPS" is short for "bits per second", not "kilobits per second". I overlooked that as well.

[hubblec4]

@VAMET

You could use my chapterEditor, there is a Matroska Tags editor which can read Tags directly from a Matroska file.
Tags editing was never so easy :-)

[VAMET]

Dear Friends

I have used command: mkvmerge.exe --identify <input> and have the below results:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (DTS)
Track ID 2: audio (AC-3/E-AC-3)
Track ID 3: audio (DTS-HD Master Audio)
Track ID 4: audio (DTS-HD Master Audio)
Track ID 5: subtitles (SubRip/SRT)
Track ID 6: subtitles (SubRip/SRT)
Track ID 7: subtitles (SubRip/SRT)
Track ID 8: subtitles (SubRip/SRT)
Track ID 9: subtitles (SubRip/SRT)
Track ID 10: subtitles (SubRip/SRT)
Track ID 11: subtitles (SubRip/SRT)
Track ID 12: subtitles (SubRip/SRT)
Chapters: 28 entries

As you can see Track ID 3 and 4 have got the same name DTS-HD Master Audio. When I use MKVToolNix I can see language of this audio track, but when using command line there is no such possibility. Maybe there is other command used with --identify to have something like below:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (DTS) eng
Track ID 2: audio (AC-3/E-AC-3) eng
Track ID 3: audio (DTS-HD Master Audio) eng
Track ID 4: audio (DTS-HD Master Audio) spa
Track ID 5: subtitles (SubRip/SRT) eng
Track ID 6: subtitles (SubRip/SRT) spa
Track ID 7: subtitles (SubRip/SRT) rus
Track ID 8: subtitles (SubRip/SRT) myn
Track ID 9: subtitles (SubRip/SRT) pol
Track ID 10: subtitles (SubRip/SRT) hun
Track ID 11: subtitles (SubRip/SRT) nor
Track ID 12: subtitles (SubRip/SRT) swe
Chapters: 28 entries

EDIT

I am preparing my own script and I would like to recognize language of audio and subtitles tracks via command line.

Thank you in advance for your help and support.

Sincerely

[Mosu]

Use mkvmerge's JSON output. It includes the language, among other things, and is trivial to parse as there are JSON parsers for pretty much every language out there:

mkvmerge --identification-format json --identify your-file.ext

or its much shorter version:

mkvmerge -J your-file.ext

[VAMET]

Dear Friends

I have got .mkv file with below tracks:

Track ID 0: video (MPEG-H/HEVC/h.265)
Track ID 1: audio (AC-3/E-AC-3)
Track ID 2: audio (AAC)
Track ID 3: audio (TrueHD Atmos)
Track ID 4: subtitles (SubRip/SRT)
Track ID 5: subtitles (SubRip/SRT)
Track ID 6: subtitles (SubRip/SRT)
Track ID 7: subtitles (SubRip/SRT)
Track ID 8: subtitles (SubRip/SRT)
Chapters: 10 entries

I have used command:

mkvmerge --output <output.mkv> --video-tracks 0 --compression 0:none --audio-tracks 3 --compression 3:none --no-subtitles --no-buttons --no-track-tags --no-chapters --no-attachments --no-global-tags <input.mkv>

After that I have checked properties of the file <output.mkv> under Windows 10 and there are video and audio tabs. For video everything is correct - "Duration", "Resolution", "BPS", "Total BPS" and "FPS", but for audio there is only visible value for "BPS". For two other fields: "Channels", "Audio sample rate" there are empty fields without any values. I have checked headers under MKVToolNix and in audio section there are 48000Hz and 8 Channels.

I have also tested the same for .mkv file with DTS-HD MA 7.1 and in this case properties of such .mkv file under Windows 10 is correct for every field in video and audio section.

Why there is a problem for TrueHD Atmos 7.1 (48000Hz, 24 bit)?

EDIT

I have also used command:

mkvpropedit --add-track-statistics-tags <input.mkv>

...but again for TrueHD Atmos 7.1 there are no values for "Channels" and "Audio sample rate", but for DTS-HD MA 7.1 (48000Hz, 24 bit) there isn't any problem.

I would be glad for any help and support.

Sincerely

[AYColumbia]

Hey, I recorded a video with my phone and had the phone upside down (turned 180 deg) so the mp4 has a rotation of 180 degrees on it. When I remux it to an MKV it plays with the video upside down. So my stupid question is this, did the phone actually record the video upside down since I hastily had it that way and added the 180 deg rotation meta data so players that support it will read it and play the video properly right side up? Or, does the phone record video right side up all the time and uses the meta data to tell the player how it should be played? I guess what I'm getting at is, does the remuxed MKV actually show the video the way it was recorded and does MKV support rotation meta data and that to get it correctly turned right side up I'll have to reencode it? Thanks.

Also, I did some poking around and it doesn't look like the MKV spec has support for rotation which would mean asking for it to be added, I guess to the header editor, would probably not be useful at this point right?

[Mosu]

The Matroska specs has no provisions for rotating the content (or for storing the recording device's orientation). You're out of luck here.

[Mosu]

Another month, another release of MKVToolNix: v10.0.0. It's solely a bug fix release, and the number of fixes in this release is on the small side.

Nothing's changed for packagers.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & Mac OS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries have been built already and are available for download. The Linux binaries will be available later today.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 10.0.0 "To Drown In You" 2017-03-25

## New features and enhancements

* mkvmerge: AVC/h.264 parser: mkvmerge will now drop all frames before the first key frame as they cannot be decoded properly anyway. See #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: mkvmerge will now drop all frames before the first key frame as they cannot be decoded properly anyway. See #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: added a workaround for invalid values for the "default display window" in the VUI parameters of sequence parameter sets. Fixes #1907 (https://github.com/mbunkus/mkvtoolnix/issues/1907).

## Bug fixes

* mkvmerge: MP4 reader: fixed track offsets being wrong in certain situations regarding the presence or absence of edit lists ('elst' atoms) & composition timestamps ('ctts' atoms). Fixes #1889 (https://github.com/mbunkus/mkvtoolnix/issues/1889).
* mkvmerge: MP4 reader: offsets in "ctts" are now always treated as signed integers, even with version 0 atoms.
* mkvinfo: the timestamps of SimpleBlocks with negative timestamps are now shown correctly.
* mkvmerge: Matroska reader: fixed handling BlockGroups and SimpleBlocks with negative timestamps.
* mkvmerge: MP3 packetizer: the MP3 packetizer will no longer drop timestamps from source containers if they go backwards. This keeps A/V in sync for files where the source was in sync even though their timestamps aren't monotonic increasing. Fixes #1909 (https://github.com/mbunkus/mkvtoolnix/issues/1909).
* mkvmerge: AVC/h.264 parser: mkvmerge will now drop timestamps from the source container if no frame is emitted for that timestamp. Fixes #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvmerge: HEVC/h.265 parser: mkvmerge will now drop timestamps from the source container if no frame is emitted for that timestamp. Fixes the HEVC equivalent of the problem with AVC described in #1908 (https://github.com/mbunkus/mkvtoolnix/issues/1908).
* mkvextract: SSA/ASS: fixed extraction when the "Format" line in the "[Events]" section contains less fields than the default for SSA/ASS would indicate. Fixes #1913 (https://github.com/mbunkus/mkvtoolnix/issues/1913).

Have fun :)

[mata7]

hi guys, can someone please tell me if there a way of when i open a file mkv or bluray playlist whit multiple audio and subtitles tracks can mkvtoolnix disable or uncheck all audio and sub and keep only the english check

thanks in advanced

[sneaker_ger]

Preferences>Multiplexer>Enabling tracks

[mata7]

Preferences>Multiplexer>Enabling tracks

thanks that is what i have enable, but every time that i open a file or bluray playlist it have all language track check and i just want the english

[sneaker_ger]

Does mkvextract prepend SPS/PPS from CodecPrivate to an H.264 stream even when using the --raw switch?

[Mosu]

No. "--raw" causes mkvextract to write the block content as-is without any format-specific interpretation. It's not really all that useful.

[vidschlub]

Hi guys, I googled for MKValidator and came across this thread.

I'm re-encoding some files using FFMPeg (x265) and a ALL files are spitting out errors like.
WRN00C: Unknown element in Video [55][B0] at 480 (size 8 total 11)
I've decided this is probably not too bad, since they all do it, yet all the files work.

However, I'm also getting
WRN0C0: First Block for video track #1 in Cluster at 99223249 is not a keyframe
WRN0C0: First Block for video track #1 in Cluster at 204950185 is not a keyframe

For a few files
Problem is I've re-encoded multiple times and keep getting that, yet the source file (x264) doesn't have that error.

Any ideas?

[albt]

I have a feature request:
Can you make it possible inject HDR metadata in x264 video?

only applications I know that can do it are from avtop, SEIedit (250€) and HDRmaster (500€).

I found a modified version of mkvmerge that seems to be able to do it: https://github.com/YouTubeHDR/hdr_metadata
but my TV (LG E6) doesn't detect the metadata.

i have the same problem.

[albt]

@Q-the-STORM: https://github.com/SK-Hardwired/nv_hevc_hdr_patcher might be worth a look.

it says for nvenc.

[Selur]

Yes, but may be it could be adjusted to x265/x264, personally I think this is something that should be done in a separate tool and not in mkvtoolnix, since it is not really mkv specific.

[albt]

Yes, but may be it could be adjusted to x265/x264, personally I think this is something that should be done in a separate tool and not in mkvtoolnix, since it is not really mkv specific.

yes i know, i didn't ask mkvtoolnix to do that as it has nothing to do with mkv, but any other tool, for example can you add it in hybrid? :D

[Selur]

Hybrid is a frontend (GUI) for other tools and doesn't manipulate anything itself. :)
-> if there's a free cli tool I could use in Hybrid I would add support for it.

[albt]

tested the nv_hevc_hdr_patcher but didn't work, gave me a corrupted file.

[Selur]

no surprise there,... never thought it would work without modifications,...

[gpower2]

Hey Mosu, a Linux user of gMKVExtractGUI reported here (https://forum.doom9.org/showthread.php?p=1801448#post1801448) that mkvextract doesn't respect the --ui-language switch and outputs the messages according to the system locale. You could see the gMKVExtractGUI log in this post: https://forum.doom9.org/showthread.php?p=1801465#post1801465
From the log, it seems that mkvmerge does respect the --ui-language switch...

Have you any thoughts on this?

[Mosu]

If you're trying to parse the progress from the program output, then you should use the option "--gui-mode". This will make mkvextract (and also mkvmerge) output specially-formatted lines that

are prefixed with "#GUI#" and
that are always in English no matter which user interface language has been selected.

For the progress those lines look like this: "#GUI#progress 12%".

That's what MKVToolNix GUI does, too, in order to ensure that certain control messages can always be parsed by the controlling GUI.

[gpower2]

Thanks for the quick answer!
Any luck remembering in which version --gui-mode landed on mkvextract?

[Mosu]

The change was commit d6d9f40 (https://github.com/mbunkus/mkvtoolnix/commit/d6d9f4007e279fe208603f540ac9af779f77b884). The first release to contain that commit was 9.7.0.

[gpower2]

Thanks Mosu!

[Mosu]

You're welcome.

[sneaker_ger]

There's a small discussion about HEVC HDR metadata here (https://forum.doom9.org/showthread.php?p=1803902). I'm wondering if mkvmerge should be changed to copy the corresponding SEIs (payLoadTypes 137 and 144) into CodecPrivate. Otherwise the data could be missed on seeking. (I assume the same applies to AVC.)

(HEVC sample with HDR metadata (https://www.sendspace.com/file/jgdvep))

[Mosu]

I can definitely think about it. Please open an issue over on Github for it. Thanks.

[sneaker_ger]

I don't know if you have read the discussion I linked but nevcairiel argued having the SEI only before the first IDR frame might be wrong anyways. I'm currently looking through the HEVC specs and I believe he is (like so often) correct. I guess I'll bring this up to the x265 developers instead.

[Mosu]

thanks that is what i have enable, but every time that i open a file or bluray playlist it have all language track check and i just want the english

As your screenshot shows, you have configured the GUI to *always* enable audio tracks, regardless of what their language is. Therefore the list below isn't even considered. Uncheck the checkboxes "audio" and "subtitles", and the GUI will only enable audio/subtitle tracks whose language is on your "selected" list.

[Mosu]

Here's release v11.0.0 of MKVToolNix. There have been several important bug fixes to the HEVC/h.265 and AVC/h.264 parsers. Among the fixed bugs are some that will silently produce invalid files. I therefore recommend everyone to update.

This release includes a couple of smaller enhancements to the GUI as well. Noteworthy is the implementation of features that have been requested several in the past: playing a sound or shutting down the computer after the current job's been completed. The implementation is very flexible and not limited to those two actions, though.

There have been several changes the package maintainers should be aware of. See the section "build system changes" below for details.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer/portable version & macOS DMG (https://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

The Windows and macOS binaries have already been built and uploaded. Linux binaries are still being built and will be available shortly.

Here are the NEWS (https://mkvtoolnix.download/doc/NEWS.md) since the previous release:

# Version 11.0.0 "Alive" 2017-04-22

## New features and enhancements

* mkvmerge: FLAC reader: added support for handling embedded pictures as attachments. Implements #1942 (https://github.com/mbunkus/mkvtoolnix/issues/1942).
* mkvmerge: MP4 reader: merged pull request #1804 (https://github.com/mbunkus/mkvtoolnix/issues/1804) adding support for parsing the "COLR" atom and including its values as track headers.
* MKVToolNix GUI: watch jobs: the user can now have the GUI execute an action once as soon as the current job or the whole queue finishes. The actions are the same ones that can be configured to be run automatically after job or queue completion.
* MKVToolNix GUI: implemented several built-in actions that can be executed either on special events or once via the "watch jobs" tool. These are: playing an audio file (implemented for all operating systems); hibernating, sleeping and shutting down the computer (only implemented for Windows and for Linux systems using systemd).
* MKVToolNix GUI: multiplex tool: added a new option for what to do after starting to multiplex/adding to the job queue: "close current settings" will close the current multiplex settings without opening new ones.

## Bug fixes

* mkvmerge: AAC parser: fixed mis-detection of certain data as valid ADTS AAC headers resulting in memory allocation failures. Fixes #1941 (https://github.com/mbunkus/mkvtoolnix/issues/1941).
* mkvmerge: AVC/h.264 parser: mkvmerge will now ignore bogus timing information in the sequence parameter sets (values indicating more than 100000 progressive frames per second). Fixes #1946 (https://github.com/mbunkus/mkvtoolnix/issues/1946).
* mkvmerge: AVC/h.264 & HEVC/h.265 parsers: all trailing zero bytes will now be removed from NALUs. Fixes #1952 (https://github.com/mbunkus/mkvtoolnix/issues/1952).
* mkvmerge: HEVC/h.265 parser: fixed copying the `bitstream_restriction_flag` and all dependent fields in the VUI parameters of the sequence parameter sets. Fixes #1924 (https://github.com/mbunkus/mkvtoolnix/issues/1924).
* mkvmerge: HEVC/h.265 parser: fixed the calculation of the number of parameter set arrays in the HEVCC data structure stored in CodecPrivate. Fixes the video-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: HEVC/h.265 parser: fixed writing superfluous and uninitialized bytes at the end of the HEVCC data structure stored in CodecPrivate. Another fix for the video-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: HEVC/h.265 parser: fixed the assumption that the HEVCC data structure always includes arrays for all parameter set types (VPS, SPS, PPS and SEI), and that the order is always VPS → SPS → PPS → SEI. Instead now only the arrays actually present are parsed, and they can be in any order. This fixes mkvinfo's output for Matroska files created from files such as the one from #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: AVC/h.264 packetizer: when reading a framed track (e.g. from Matroska or MP4 files), specifying a default duration as fields (e.g. `50i`) would result in double the actual duration for each frame and the track's default duration header field. Fixes #1916 (https://github.com/mbunkus/mkvtoolnix/issues/1916).
* mkvmerge: Matroska reader: invalid track language elements are now treated as if they were set to `und` = "undetermined". See #1929 (https://github.com/mbunkus/mkvtoolnix/issues/1929) for context.
* mkvmerge: MPEG TS reader, AAC: mkvmerge will now require five consecutive AAC headers with identical parameters before track type determination is considered valid. This avoids false positives and consequently wrong track parameters. Fixes the audio-related part of #1938 (https://github.com/mbunkus/mkvtoolnix/issues/1938).
* mkvmerge: fixed an endless loop in certain circumstances when splitting by `parts` or `parts-frames` and the start of the file is discarded. Fixes #1944 (https://github.com/mbunkus/mkvtoolnix/issues/1944).
* MKVToolNix GUI: multiplexer tool: the "show command line" dialog will no longer include the mkvmerge executable's location as the first argument for the two "MKVToolNix option files" escape modes. Fixes #1949 (https://github.com/mbunkus/mkvtoolnix/issues/1949).
* MKVToolNix GUI, header editor: empty track language elements are now treated the same as those set to invalid ISO 639-2 codes: as if they were set to `und` = "undetermined". See #1929 (https://github.com/mbunkus/mkvtoolnix/issues/1929) for context.

## Build system changes

* bug fix: configure now looks for the `strings` binary by using the `AC_CHECK_TOOL()` autoconf macro. That way it will be found in multiarch setups, too. Fixes #1923 (https://github.com/mbunkus/mkvtoolnix/issues/1923).
* bug fix: the environment variable USER_CXXFLAGS was accidentally removed from the compiler flags in release 9.8.0. It's been re-added. Fixes #1925 (https://github.com/mbunkus/mkvtoolnix/issues/1925).
* The `.desktop` files have been renamed to `org.bunkus.mkvtoolnix-gui.desktop` and `org.bunkus.mkvinfo.desktop`. This allows Wayland compositors to associate the correct icons with running applications for e.g. task switchers. Fixes #1948 (https://github.com/mbunkus/mkvtoolnix/issues/1948).
* Qt's multimedia component is required for compilation of the GUIs since version 11.0.0.

Have fun :)

[NikosD]

Great jump in numbering.

No incremental 10.1.0, 10.2.0 etc versions ?

I think we are going to see "huge" numbers like 20, 40 ... 90 too soon.

[Mosu]

See this reply (https://www.bunkus.org/blog/2017/04/mkvtoolnix-v11-0-0-released/comment-page-1/#comment-25157) for more information about the change to version numbering.

I think we are going to see "huge" numbers like 20, 40 ... 90 too soon.

Sure. At ~ten releases per year we'll get to 90 real soon now (as in: in eight years).

[NikosD]

You maybe right, I hadn't been keeping records of the number of releases per year.

My impression was around at 20 to 30 releases per year.

If it's only 10, we are OK I suppose.

Hope that doesn't keep you from releasing a new version harder than before :)

[Mosu]

Increasing the version number is still the same amount of work. It shouldn't have any influence on the other work at all :)

[sneaker_ger]

Thanks.

So many bug fixes for HEVC and AVC (14 years old!) in every release... Can't wait for their next codec with 1000 pages specification.

[Mosu]

AVC and HEVC are incredibly complex beasts. And I don't get a lot of their decisions. My guess is that the foremost goal is lowest size at high quality. But that isn't really achieved either compared to some simpler methods of storage or bitstream layout.

Let's take two examples:

Determining the length of a NALU. Both bitstreams use three or four byte start codes. Due to the usage of start codes they also have a way of escaping certain byte sequences inside the NALU so that NALU data won't be mistaked for a nother start code. If, however, they'd simply used a length+payload system they wouldn't need such an escaping mechanism, parsing would be much simpler, they'd even save space due to no escaping (and a four byte length field would suffice for every possible bitstream out there). That way leading or trailing zero bytes wouldn't be required either, and neither would the RBSP trailing bit syntax — because a parser would already know how long the NALU is.
Determining where a decoder can start decoding without needed any prior frame for decoding any following frame, aka real key frames. The rules for that are so long and complex that it requires parsing several data structures, keeping track of existing pictures (open GOP situations) etc. etc. mkvmerge still doesn't support this fully because it's so much work, and I honestly don't want to spend the hours. Other video formats (e.g. VC-1) on the other hand use a couple of tiny bits for signaling this important piece of information. Right at the start of each frame. It's ridiculous how much of a difference that makes in complexity, and complexity begets bugs. I haven't received a single bug report for VC-1 in… I don't know… five years or so? Granted, it's much less used, but still.

End of rant :)

[nevcairiel]

The Annex B startcodes are meant for re-synchronization, so you can find a NAL start in a broken stream, and also why double zero bytes are forbidden in the content of a NAL and need to be escaped (to prevent aliasing the synchronization point).
Annex B is primarly used for broadcast, where transmission problems do happen, so this part is quite important (and the mpegts container used in those scenarios does not solve that problem for them, either.)