The upstream project intends the include files to be installed in
`$includedir/nlohmann/json.hpp`,
e.g. `/usr/include/nlohmann/json.hpp`. Debian did not follow that
recommendation and installed them directly in `$includedir`. Therefore
`configure` was only looking for the latter, not the former.
However, Debian will soon follow suit. Therefore detection has been
extended to check for the intended location first.
Fixes#2048.
Initializing the structure with {…} yields the following error
message:
src/output/p_aac.cpp: In constructor
‘aac_packetizer_c::aac_packetizer_c(generic_reader_c*, track_info_c&,
const aac::audio_config_t&, aac_packetizer_c::mode_e)’:
src/output/p_aac.cpp:31:89: error: cannot convert
‘const aac::audio_config_t’ to ‘unsigned int’ in initialization
, m_packet_duration{m_timestamp_calculator.get_duration(ms_samples_per_packet).to_ns()}
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.
Otherwise the GUI will generate instructions for mkvmerge for track
IDs that mkvmerge won't use, and mkvmerge in turn aborts with an
error.
Fixes#2039.
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 function is available from the "additional modifications" dialog.
For most entries the smallest start timestamp of all chapters on the
same level higher than the current chapter's start timestamp will be
used as its end timestamp. If there is no such chapter, the parent
chapter's end timestamp will be used instead.
If the chapters were loaded from a Matroska file, the end timestamp
for very last chapter on the top-most level will be derived from the
file's duration.
Implements #1887.
Earlier versions fail to build on both my development system as well
as my CentOS 7 BuildBot CI instance. Therefore I cannot properly
support that version anymore.
See #2037.
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`.
This avoids clashing with Windows' input method for arbitrary
characters by pressing and holding `Alt` and typing the codepoint on
the number pad.
Implements #2034.
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.
This is the HEVC/h.265 equivalent of #2028.
