Several container formats provide an internal ID of some kind. mkvmerge
already output that ID for some of the container formats it supports
albeit under different property names:
- Matroska: "number"
- MPEG program streams: "stream_id" and "sub_stream_id", encoded as a
hexadecimal string instead of integers
- MPEG transport streams: "ts_pid"
With this commit the support is extended to other container formats. The
MPEG program and transport stream reader modules output their IDs as the
property "number" (in addition to the older identifiers) in order to
have a consistent naming scheme which makes using the output easier for
other applications.
The changes are:
- QuickTime/MP4: the track ID from the 'tkhd' atom
- MPEG program stream: the sub-stream ID in the upper 32 bits and the
stream ID in the lower 32 bits
- MPEG transport stream: the program ID
- Ogg/OGM: the stream's serial number field
- RealMedia: the track ID
Implements #1541.
This reverts commits 2c11d3f3bd and
9436271a04.
The reason is that users have chimed in with legitimate use cases,
especially extracting text subtitles on Windows, modifying them and
re-muxing them later. This worked out of the box before but requires
setting the subtitle character set to UTF-8 upon re-muxing now.
It is possible that the seek head at the front has been removed due to
moving the seek head at the back one byte to the front which calls
remove_from_meta_seeks() with that second seek head. This leads to the
first seek head being empty and therefore being removed.
Later calls to add_to_meta_seek() must therefore make sure that, even if
the element could be added to an existing seek head at the end, a new
seek head is created at the start referencing the one at the end.
Fixes#1513.
The layout is: track headers, void, attachments, chapters,
clusters. When extending the void there are elements for attachments and
chapters in memory whose position will change; therefore their in-memory
copies will have to be updated, too.
Fixes#1498 but also applies to #1485.
Part of an ongoing effort to replace the use of the term 'timecode' with
'timestamp'. Timecodes have a very specific meaning in the audio/video
world, and it's not what MKVToolNix has been using the term for.
Part of an ongoing effort to replace the use of the term 'timecode' with
'timestamp'. Timecodes have a very specific meaning in the audio/video
world, and it's not what MKVToolNix has been using the term for.
Part of an ongoing effort to replace the use of the term 'timecode' with
'timestamp'. Timecodes have a very specific meaning in the audio/video
world, and it's not what MKVToolNix has been using the term for.
The net win is that changes in the order the properties are added won't
affect the output and therefore the test cases anymore allowing for
easier refactoring of file identification.
