This is a destructive action; no user confirmation is requested. The
action only works for multiplexer jobs, not for info jobs.
The action is disabled by default. It has to be enabled to be usable
at all, and if it should always be executed, one of the two options
"After a job completes successfully or with warnings" or "After a job
exits with an error or the user aborts the job" must be enabled, too.
Implements #869 and #2570.
A lot of cultures do not adhere to this type of format. There doesn't
have to be a last name in the first place, or a first one. The family
name doesn't have to be the last one, it might be the first one. There
might be a lot more components to names.
The internal libEBML was updated to v1.3.9. That version contains
changes to cmake to build an additional header file, ebml_export.h. In
MKVToolNix, which isn't cmake-based, that file has to be created
manually, and the Rakefile does so.
However, when configure runs the file doesn't exist yet. This means
that any attempt to compile a test program with the internal libebml
will fail due to the header not being found. configure's compilation
checks will therefore fail.
For the detection of libebml::FindNextChild doing a compilation check
against the internal libebml isn't really needed as we know that the
version does include it. So just hardcode that knowledge and avoid the
compilation check.
With very large video frames (one test file has h.264 from Blu-rays
with ten seconds between key frames and an average frame size of ~350
KB) buffering due to external timestamps being applied could easily
lead to the packetizer holding more than 128 MB of data in memory
while waiting for the next key frame before it can apply the
timestamps. The reader must not refuse to deliver frames in such a
case, otherwise the next I frame will never appear, the packetizer
will never write out those buffered frames and the whole process ends
up in an endless loop.
Fixes#2550.
