This commit implements two things for subtitle tracks:
1. There are several situations in which mkvmerge doesn't let the user
change the subtitle character set, e.g. due to a byte order mark in
the source file or the source file only supporting UTF-8
anyway (e.g. Matroska). In such a case the GUI will now disable the
"subtitle character set" drop-down box.
2. mkvmerge now outputs a track's encoding/character set as a track
property during file identification if that encoding can be
determined with confidence (same situations as in 1.). If that is
the case, the GUI will auto-select that encoding in the "subtitle
character set" drop-down box, even if that drop-down box is
disabled.
Both changes together give the user the information that she doesn't
have to take care of the encoding herself, and which encoding it
actually is.
Implements the GUI's part of #2053.
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.
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. See #2053.
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.
