Audio frames at the start of the file should have higher precedence,
especially over formats that don't always have start codes at the
beginning of the file.
Fixes certain AC-3 files being mis-detected as encrypted MPEG program streams.
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.
