Download-Tools/mkvtoolnix
1
0
Fork 0
mirror of https://gitlab.com/mbunkus/mkvtoolnix.git synced 2024-10-22 07:21:21 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix links

Moritz Bunkus 2019-05-18 10:21:56 +02:00
parent 451bb5c8f2
commit 4e079d8663
No known key found for this signature in database
GPG Key ID: 74AF00ADF2E32C85
5 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
All-tracks-vanished-after-mkvpropedit,-the-header-or-chapter-editors.md

@ -30,6 +30,6 @@ This leads to the following algorithm that all applications reading Matroska fil
2. Recursively read all meta seek elements starting with the one(s) found in step 1. Remember all positions of important elements pointed to from the meta seek elements.
3. Read all important elements found in steps 1. and 2. keeping in mind that elements found in 2. may point to the same elements found in 1.
Do note, though, that in mkvinfo's default processing mkvinfo will not find those track headers. In order to understand why please see [this FAQ entry](/mbunkus/mkvtoolnix/wiki/Understanding-mkvinfo's-output).
Do note, though, that in mkvinfo's default processing mkvinfo will not find those track headers. In order to understand why please see [this FAQ entry](Understanding-mkvinfo's-output).
Categories: [metadata](FAQ#category-metadata), [playback](FAQ#category-playback)

2
Meta-data-fields-like-bitrate-lost.md

@ -13,6 +13,6 @@ You might notice that MediaInfo still shows bitrate information for some Matrosk
1. The bitrate might be stored on the bitstream level. This is only possible for audio/video types whose specifications provide fields for that kind of information in the bitstream.
2. If there's only a single track in a Matroska file then the bitrate can be estimated with the following formula: `bitrate_in_kbit_per_second = (file_size_in_bytes * 8) / (file_duration_in_seconds * 1024)`
Note that starting with v7.0.0 mkvmerge [will create track-specific statistics](Automatic-tag-generation) and store them in tags. Newer versions of MediaInfo should be able to use that information properly.
Note that starting with v7.0.0 mkvmerge [will create track-specific statistics](Track-statistics-tags) and store them in tags. Newer versions of MediaInfo should be able to use that information properly.
Categories: [merging](FAQ#category-merging), [metadata](FAQ#category-metadata)

2
Segment-duration-vs-track-duration.md

@ -2,7 +2,7 @@
## The problem
Looking at the [new track statistics tags](Automatic-tag-generation) generated by mkvmerge you may notice that neither of the track's duration matches the segment duration in the global segment info block.
Looking at the [new track statistics tags](Track-statistics-tags) generated by mkvmerge you may notice that neither of the track's duration matches the segment duration in the global segment info block.
## The explanation

2
mkvalidator-ERR201-Invalid-CueRelativePosition-for-profile-matroska-v2-in-CueTrackPositions.md

@ -16,7 +16,7 @@ This is a bug in mkvalidator in versions up to and including 0.4.2. It has been
## The in-depth explanation
mkvmerge creates files in which the [DocType is set Matroska v4 but the read DocType is set to v2](/mbunkus/mkvtoolnix/wiki/mkvalidator-ERR009-read-doc-type-version-higher-than-doc-type-version). In layman's terms this means that a player must support at least the elements from Matroska v2, but that elements from Matroska v4 have been used as well. A player supporting v2 but not v4 should still be able to play the file just fine by skipping the elements it doesn't know about.
mkvmerge creates files in which the [DocType is set Matroska v4 but the read DocType is set to v2](mkvalidator-ERR009-read-doc-type-version-higher-than-doc-type-version). In layman's terms this means that a player must support at least the elements from Matroska v2, but that elements from Matroska v4 have been used as well. A player supporting v2 but not v4 should still be able to play the file just fine by skipping the elements it doesn't know about.
During validation mkvalidator wrongfully checks against the elements allowed by v2 and not against the ones allowed by v4. It will then encounter a lot of elements belonging to v4 and wrongfully report them as not being allowed.

2
mkvinfo-track-summary.md

@ -15,7 +15,7 @@ A Matroska file has a pretty flexible layout. There are several level 1 elements
For example, the chapters can be located at the end of the file. As long as there's a meta seek element at the beginning of the file pointing to those chapters a player can find them quickly without having to read the whole file. The same applies to track headers (e.g. those might be re-located to the end by applications like mkvpropedit or mmg's header editor if they don't have enough space at the beginning of the file to fit the changed headers into).
See [All tracks vanished after mkvpropedit or header editor](All-tracks-vanished-after-mkvpropedit-or-header-editor) for a more in-depth explanation.
See [All tracks vanished after mkvpropedit or header editor](All-tracks-vanished-after-mkvpropedit,-the-header-or-chapter-editors) for a more in-depth explanation.
mkvinfo is a development tool. Its purpose is to read a file from beginning to the end and to report the elements the moment they've been read. As this information can be overwhelming mkvinfo stops as soon as the first cluster is encountered by default.