Since videos with translations appear to require at least as many audio
streams in the intro/outro as there are audio streams in the main video,
this allows to create intro/outro files for videos with more than one
translation (so far, the code already created 2 streams).
It seems that when processing a SVG file passed via a pipe, Inkscape emits
errors/warnings about an XML parser error if the SVG file is UTF-8
encoded. It still does seem to successfully process the SVG file and
generates the expected output, however, these messages are at least
confusing. Not passing the encoding parameter to etree.tostring() makes
it output ASCII with non-ASCII characters encoded as XML entities, so this
can then be correctly parsed again, and this does not seem to 'confuse'
Inkscape.
This was already suggested in #22. In addition to potentially being a
little more efficient, this also avoids the problem of files referenced
from the SVG not being found, since the SVG is now rendered while in the
artwork directory, so relative paths inside the SVG are still correct.
Please note that the pipe functionality of Inkscape requires a relatively
new version of Inkscape, i.e. the version from Debian Buster is not
sufficient (the Buster backport from Debian should be though).
Unfortunately, the same does not work when using ImageMagick, since it
seems like they use different delegates/libraries to render the SVG based
on how it is passed, i.e. when passed as file, it got rendered with
Inkscape on my machine, when passing it as blob, it seemed to be some
internal library or another delegate which did not seem to support the
same feature set as Inkscape, which resulted in inferior output. Therefore,
a temporary file is still used for ImageMagick. However, the issue of
included images that could be solved for Inkscape with these changes
still persists, since at least when using the Inkscape delegate,
ImageMagick seems to create a temporary symbolic link in /tmp, which
prevents that the Inkscape delegate finds included images.
