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.
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.
There are Matroska files where the AC-3 core and the corresponding
E-AC-3 extension are stored in two different blocks. That's against
the specs, so mkvmerge has to fix it. Additionally only the first
block's timestamp should be used; otherwise mkvmerge will double the
total duration: in the source the core's and the extension's timestamp
are the same, but mkvmerge was assigning the core's block one
timestamp and the extension's block an incremented timestamp.
The `program_config_element` (PCE) in the frame is authoritative
regarding the number of channels encoded in the frame. The container
information might be wrong (e.g. the ADTS headers containing a channel
configuration of 0, which is invalid). Therefore parse the PCE if it's
located at the start of the frame and override the ADTS header
content.
Fixes#2107.
Some source files only provide one timestamp every `n` DTS frames. In
such situations the next provided timestamp might arrive before all of
the data for the previous DTS frame has been flushed (due to the DTS
parser buffering data in order to determine whether or not a dependent
frame is following). The result is a single gap of one frame after frame
number `n - 1`.
Fixes#2071.
This change requires the upcoming libEBML release v1.3.5 as earlier
versions will complain about missing mandatory elements even if said
mandatory elements have default values in the specifications.
This implements one half of #2038.
Note that this commit breaks the GUI's header editor until support for
editing sub-sub-sub-masters will be added to it (soon).
This is preparation for making the GUI present the encoding detected
by e.g. a byte order mark to the user so that she doesn't have to (and
cannot) chose a subtitle character set herself. Implements mkvmerge's
part of #2053.
Also refactors SBR detection & handling. There were cases in which
reading AAC from MPEG TS resulted in 2-byte `CodecPrivate` with no
`OutputSamplingFrequency` set, even though the sampling frequency was
24.000 Hz and therefore an indicator for SBR.
The feature was implemented by removing all 0 bytes in before the next
start code (and all 0 bytes at the end of the buffer). The problem is
that a slice structure may very well end in 0 bytes. The only way to
determine the end of the slice structure with confidence is
implementing a parser for the whole slice structure.
The result of removing bytes belonging to the slice structure may or
may not end in visual artifacts upon decoding. Other results include
error message by the decoder (e.g. ffmpeg which reports errors such as
"slice mismatch" or "motion vectors not available").
I lack the time and motivation to implement a proper slice parser. As
the current behavior is dangerous and just plain wrong, I'm removing
the feature again. It was introduced in release 5.8.0 response to
issue #734, which will now remain not implemented.
Fixes#2045.
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.
Old pugixml versions didn't recode to UTF-8 themselves. Therefore
mkvmerge contains code to determine the encoding from the XML
declaration's `encoding` attribute and recoding the content to UTF-8
before passing it to pugixml. The old `encoding` attribute was left
untouched.
Newer pugixml versions do recode to UTF-8. In order to prevent
that (and therefore recoding twice), the XML declaration's `encoding`
attribute must be set to `UTF-8`.
Whenever a sequence parameter set or picture parameter set
changes (meaning an SPS with the same ID as an earlier SPS but with
different content is found), all frames queued for order & timestamp
calculation must be flushed. Otherwise frame order calculation will be
based on wrong values for some frames and on correct values for other
frames.
Fixes#2028.
Other track types such as DTS will already fetch more PS packets from
the stream if detection fails on the first packet. The same logic is
now applied to (E-)AC-3 tracks: as long as the track parameters cannot
be determined and the probe range hasn't been exceeded, fetch more
data from the stream and retry detection.
This enables track detection even if the first PS packets contain too
little (E-)AC-3 data.
Fixes#2016.
