Chapters and tags in WebM only allow a subset of elements. The
unsupported ones must be removed before chapters are written to a WebM
file.
Implements MKVToolNix GUI's chapter editor's part of #2002.
Chapters and tags in WebM only allow a subset of elements. The
unsupported ones must be removed before chapters are written to a WebM
file.
Implements mkvpropedit's part of #2002.
Chapters and tags in WebM only allow a subset of elements, among them
certain elements that are mandatory in Matroska. So if the caller is
already aware of that, it can take care of them properly so that the
analyzer doesn't have to anymore.
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.
