On Windows an extra line "exec: Process pid=... exited with status code 0"
is reported after terminating the subprocess. This isn't relevant for
the `text_exec_invalid_utf` test, so the extra line is just ignored.
No functional changes.
When multiple versions of the same frame are generated (like EXR and
JPG), always report the most web-preview-friendly version.
In other words, when the frames are produces by Blender in the order
(`frame-001.jpg`, `frame-001.exr`), only the JPEG is reported. When the
JPEG follows the EXR, both will be reported as when the EXR is created
it is not yet know whether it will be followed by a JPEG or not.
Before this, the 2nd file would never be reported due to the Worker
throttling such reports to the Manager (to not swamp it when rendering
sequences of images, for example).
Panic when an older subprocess is already running when trying to start a
new subprocess. This situation was already detected, but instead of
failing the current task (and keeping the Worker running), the Worker
now shuts down completely. When running as a systemd service, the Worker
will automatically be restarted.
When this panic occurs, the Worker still signs off at the Manager,
causing its current task to be returned to the queue. That way another
Worker (or this one, after the restart) can retry it.
This is basically a hack to work around the issue that sometimes Blender
is running twice on the same machine.
When running Flamenco Worker from the distribution package, it actually
runs a bundled Python with its own libraries. This is done by setting the
`LD_LIBRARY_PATH` environment variable. Subprocesses inherit this variable,
causing library conflicts (mostly libz) when running Blender or FFmpeg.
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).
On Windows, the loop was recreated on every call to `construct_asyncio_loop()`,
whereas on Linux the existing loop would be reused if possible. Now both
platforms work the same.
Globbing is the only way in which we can convert arbitrary frame sequences
to a video; the other input options all assume that the frame numbers are
sequential, and stop at the first gap. Globbing just skips gaps and
actually uses all available frames.
The workaround consist of doing the globbing in Python and creating an
index file that lists all the input files.
The 'blender_render' and 'blender_render_progressive' commands now look for
a file named 'thefile-overrides.py' in the same directory as
'thefile.blend'. If it exists, Blender will be told to load that Python
file between loading the blend file and starting the rendering.
This should solve issues when tasks fail after the worker shuts down or
goes to sleep. Previously the task would be set to 'claimed-by-manager'
when the Worker when to sleep, but flushing the task queue on the Worker
could still trigger reactivation of the task on the Manager. Since the
Worker wouldn't be running the task any more, it would time out. This is
now fixed.
This is for consistency with the `blender_cmd` setting of Blender render
commands. The splitting is done so that extra CLI commands can be given
in the Manager config.
This requires FFmpeg to be installed (not just for the command, but also
for running the accompanying unit test). Because of this external
dependency, the worker has to declare task_type='video-encoding' in its
configuration file before it gets such tasks. This is not enabled by
default.
The 'may-i-run' endpoint may say 'no' to us running task X, but when the
response comes in and is handled the worker may already be working on task
Y. This case is now recognised, and the 'no' will be ignored.
This makes a clearer distinction between Flamenco tasks ('task') and
AsyncIO tasks ('future'). The AsyncIO Task class is a subclass of its
Future class.
