Otherwise the following steps would end up overwriting an existing
file:
* add a file
* start multiplexing
* re-use the same settings
* don't change anything regarding files & track selection (but modify
e.g. a track language)
* start multiplexing again
Fixes#2052.
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.
