Repository navigation
The first release since June. Live video on the V4L2 paths now recovers from
a camera that drops off on its own, hardware H.264 works on non-Pi hosts, and
the bundled proxy moves from bitbang-cli 0.4.3 to 0.5.2.
A camera that drops out no longer needs an OctoPrint restart
If the capture ended -- a USB camera re-enumerating, a cable or a hub
glitching, a powered-down webcam -- video stopped for good and the only way
back was restarting OctoPrint. That was deliberate, and it is the wrong
behavior for a camera that blinks once in fifteen hours.
The device is reopened now. What decides whether to keep trying is how long
the capture had been running, not how many attempts have been made: a capture
that ran for hours and then stopped is a disconnect and will probably come
back, while one that ends within a second or two, repeatedly, is a setup that
cannot work -- a missing device, another process holding the camera, an
encoder this machine does not have. A run that lasts clears the counter, so a
camera that drops daily never runs out of attempts, and five immediate
failures still stops and says why.
This covers the V4L2 capture paths: a camera that encodes H.264 itself, and
the h264_v4l2m2m and h264_vaapi re-encoders. The picamera2 path and the
software-encode fallback do not recover yet and still need a restart, so a
Pi CSI camera on a stock image -- where auto-detect prefers picamera2 -- is
not covered by this release. That is the remaining work in #6.
While it retries, the WebRTC connection stays up and the browser simply
waits, so a dropout looks like a stall rather than a stream that never comes
back. Tested with a real unplug on a Pi 4: the capture failed, waited 26
seconds for the device node to return, reopened, and the picture resumed
without touching the browser.
Found by @snargledorf, whose camera went away after 15.6 hours and took the
video with it.
Hardware H.264 on Intel and AMD hosts (VAAPI)
A new rung on the encoder ladder: h264_vaapi, for any host with a DRI render
node whose driver can encode H.264. OctoPrint on a NUC, a mini PC or a laptop
now gets hardware encoding instead of falling through to software.
Render nodes are probed by actually encoding a frame rather than trusting that
ffmpeg lists the encoder, because distro ffmpeg almost always does and plenty
of GPUs with VAAPI have no H.264 encode entrypoint. Where several render nodes
exist, the one that can encode wins.
Optional hardware MJPEG decode for the same path, and -encoder /
--vaapi-device / --vaapi-hwaccel-decode to pin a choice. Contributed by
@snargledorf.
Camera detection also falls back to ffmpeg where v4l2-ctl is absent, so
hosts without v4l-utils can still enumerate formats.
Clearer logs when something else has the camera
The old report could not name the process that is almost always responsible.
It inspected /proc/<pid>/fd, which is readable only for your own processes,
so OctoPi's webcamd running as root never appeared -- and that is the usual
reason the camera is busy. A streamer that is running is now named as the
likely holder, with the systemctl disable line that fixes it.
Repeated failures also used to lose ffmpeg's own error. The first failure in a
sequence is often the least informative, and it was the retry that said
"Device or resource busy". Each distinct error is reported once now.
The bundled proxy is bitbang-cli 0.5.2
Up from 0.4.3. Nothing to install -- the proxy ships inside the package -- but
the two moved together on purpose: 0.5.0 reworked how serve reads its
arguments, and the plugin follows that grammar now. An older bundled proxy
would refuse the arguments this version passes it.
If you install from the GitHub source zip rather than the Plugin Manager or
PyPI, the proxy binaries are not in it and remote access will not start. Use
release.zip below, the Plugin Manager, or pip.
