The `shutil.copy()` function calls `shutil.copyfile()` and
`shutil.copymode()`, and fails when either fails. By calling those
functions separately we can ignore errors copying the file mode (this
happens on SMB shares, for example).
See CVE-2019-11324.
The urllib3 library before 1.24.2 for Python mishandles certain cases
where the desired set of CA certificates is different from the OS store
of CA certificates, which results in SSL connections succeeding in
situations where a verification failure is the correct outcome. This is
related to use of the ssl_context, ca_certs, or ca_certs_dir argument.
To secure the previously-open-to-anyone worker registration on the Flamenco
Manager, we now have to send a JWT token that was signed by a pre-shared
secret. To enable this behaviour, set `worker_registration_secret` both
in the Worker and the Manager configuration files to the same string.
Blender's `--render-format` CLI parameter generally takes the same names
as the `bpy.context.scene.render.image_settings.file_format` DNA parameter,
except when it comes to OpenEXR.
See https://developer.blender.org/D4502 for a proposal to make this
consistent.
Previously the code was spread out through the `TaskRunner` and
`AbstractCommand` classes. Now it's in a class of its own and properly
tested.
Also, the timing info is now sent as one line in the task log, making it
less spammy.
For now every command logs its total runtime. The `AbstractBlenderCommand`
subclasses log more granular information, like starting blender, loading
the blendfile, and rendering.
This info is just sent to the task log, and not stored in the task itself
yet.
Nowadays we send the logs only to the Manager, and not to the Server any
more. Let's clog the Manager's harddisk with everything to make Dr. Debug
happier.
Fixes T54174, but rather than making a distinction between the username
not being found and the password being wrong (and only re-registering in
the former case), we now just always re-register. This could potentially
hide certain erroneous situations, but it does make the worker operational
in more cases, which I assume is generally preferred.
Added the `merge_progressive_render_sequence` for sample-merging sequences of EXR files. The
already-existing `merge_progressive_renders` command only performed on one frame at a time.
This commit also removes the last traces of the preview generation that
half-happened while merging. It was intrinsincly flawed and was superseded
by the `exr_sequence_to_jpeg` command.
H.264 requires that the width and height of the video frame are
multiples of the chroma block size. When using the default yuv420 pixel
format this means the dimensions should be even (e.g. multiples of 2).
The video filter added in this commit ensures this by padding out the
frame with black pixels.
This allows the command to run on a subset of the EXR files in the
directory, which is needed for generating previews of EXR files in the
intermediate render directory (which contains multiple EXR files for
each frame).
This is used for generating JPEG previews of EXR files. It is assumed that
the EXR files are named '######.exr', with any number of leading zeroes.
Gaps in the frame range are supported, and will be rendered as black
images.
This superclass AbstractBlenderCommand takes less parameters so that it'll
be easier to add Blender commands that don't use certain parameters (such
as frame range, render format, etc.)
