Type: Bug
Where: jadiv-timelapse_plus.py, class FfmpegVideoWriter (__init__/write, roughly lines 46-72)
Problem:
FfmpegVideoWriter launches ffmpeg with both stdin=subprocess.PIPE and stderr=subprocess.PIPE, then repeatedly calls self._process.stdin.write(frame.tobytes()) in VideoWorker.run()'s per-image loop, one raw frame at a time. stderr is never read until release() is called after the entire write loop finishes (self.error_output = self._process.stderr.read()...).
This is the textbook subprocess pipe-deadlock hazard: OS pipe buffers are finite (commonly 64KB on Linux). If ffmpeg emits enough to stderr during encoding — a burst of warnings, or any unexpected condition even under -loglevel error (e.g. certain malformed/exotic frame data, unsupported color edge cases, disk-full errors written before it decides to exit) — its stderr pipe fills up, ffmpeg blocks trying to write more of it, and this process's stdin.write() call blocks right back once ffmpeg stops reading from stdin, since nothing is draining stderr concurrently. The two processes then wait on each other forever; the "Zrušiť" cancel button doesn't help since cancel() only sets a flag checked between frames, and the hang is inside the blocked write() call itself.
Suggested fix:
Drain stderr on a separate thread (or redirect it to a temp file) concurrently with writing to stdin, rather than reading it only after all writes complete — the same pattern already correctly used for subprocess.Popen + a background reader thread is a standard fix for this class of bug.
This issue was created by an automated issue-hunt routine.
Type: Bug
Where:
jadiv-timelapse_plus.py, classFfmpegVideoWriter(__init__/write, roughly lines 46-72)Problem:
FfmpegVideoWriterlaunches ffmpeg with bothstdin=subprocess.PIPEandstderr=subprocess.PIPE, then repeatedly callsself._process.stdin.write(frame.tobytes())inVideoWorker.run()'s per-image loop, one raw frame at a time.stderris never read untilrelease()is called after the entire write loop finishes (self.error_output = self._process.stderr.read()...).This is the textbook
subprocesspipe-deadlock hazard: OS pipe buffers are finite (commonly 64KB on Linux). If ffmpeg emits enough to stderr during encoding — a burst of warnings, or any unexpected condition even under-loglevel error(e.g. certain malformed/exotic frame data, unsupported color edge cases, disk-full errors written before it decides to exit) — its stderr pipe fills up, ffmpeg blocks trying to write more of it, and this process'sstdin.write()call blocks right back once ffmpeg stops reading from stdin, since nothing is draining stderr concurrently. The two processes then wait on each other forever; the "Zrušiť" cancel button doesn't help sincecancel()only sets a flag checked between frames, and the hang is inside the blockedwrite()call itself.Suggested fix:
Drain
stderron a separate thread (or redirect it to a temp file) concurrently with writing tostdin, rather than reading it only after all writes complete — the same pattern already correctly used forsubprocess.Popen+ a background reader thread is a standard fix for this class of bug.This issue was created by an automated issue-hunt routine.