HBBatchBeast turns HandBrake and FFmpeg into a watched batch pipeline

Folder structure is preserved, so a library converts without being reorganised

The organising idea of HBBatchBeast is that the destination folder mirrors the source folder. The description states that the destination folder structure is kept the same as the source folder structure, and that media in subfolders is also converted. That single behaviour is what separates this from a one-off command line invocation of HandBrake. You point the tool at a library, it walks the tree, and the output lands in a parallel tree of the same shape. Multiple folders can be monitored at once, and different conversion presets can be specified for each folder, so a downloads folder and a home video folder can carry different encoder settings. The design assumes a person who already has a tidy library and does not want to reorganise it to suit the tool. The repository is small, with a HBBatchBeast directory holding the application and a LICENSE file, and the primary language is HTML, which tells you the interface is a web view rather than a native desktop toolkit.

A scan, a compare and a queue, then four workers do the conversion

The processing model is described step by step and it is worth following closely, because the compare step explains the tool's behaviour. The program scans the source folders for all files, then compares the source folder files with the destination folder files to see whether any of the source files already exist in the destination. Files that are not already present get queued for conversion. Four worker modules, described as the default number, then work through that queue. If periodic scanning is enabled, the program runs at the chosen interval, which is the mechanism behind folder watching. Because the check is existence based rather than checksum based, a file whose output exists in the destination is skipped even if the source was replaced with a different file of the same name. That is a reasonable trade for a fast scan over a large library, and it is also the sort of detail that surprises people who re-encode the same source with different settings.

Multiple HandBrake and FFmpeg instances run at the same time

The project description calls it a free GUI for HandBrake and FFmpeg/FFprobe on Windows, macOS and Linux, plus a Linux Docker image, with an emphasis on multi HandBrake/FFmpeg instance batch conversion. FFprobe enters the picture because the tool needs to inspect media properties before it encodes, and that inspection is what lets a preset be applied per folder with some confidence about the source. The concurrency model is the interesting part for anyone with a fast disk and slow encoder. Rather than a single process grinding through a queue, several encoder processes are launched and the tool keeps them fed. A GUI for this kind of work is a real convenience, since the alternatives are shell loops that get fiddly once you want per-folder presets, a destination structure and a queue view. The four worker modules are the tuning point, and the documentation frames the default as a starting value rather than a fixed choice.

Health checks find corrupt files, and the author says the result is not always accurate

Two extra features sit outside the conversion pipeline. The health check feature can scan for corrupt video files using HandBrake for a quick scan or FFmpeg for a thorough scan, and there is an attempt repair file feature as well. The documentation is careful here, noting that the result is not always accurate, and that caveat is worth taking seriously because a false positive on a thorough FFmpeg scan of a large library is expensive in time. There is also a basic h265 benchmarking feature, which gives a rough sense of what the hardware can do before you commit a queue to a codec. A remote monitoring feature lets you watch batch file conversions in any browser, which matters when the conversions are running on a machine you are not sitting at. Settings help is available through the blue question mark diamond icons spread throughout the interface, a small design choice that keeps the documentation inside the program rather than in a separate manual.

Installation is documented in the wiki, and Linux and macOS need HandBrakeCLI

The setup and installation details are not in the repository. The project links to a wiki page on the GitHub wiki for setup and installation, so that is the place to read before installing. One dependency detail is stated in the README itself: this is a standalone program on Windows, but it requires HandBrakeCLI to be installed on Linux and Mac. That is a meaningful difference between platforms, since the Windows build bundles or expects a different arrangement, while the Linux and macOS paths assume the command line encoder is already present. There is also a Docker image published for HBBatchBeast, so a headless Linux deployment is possible as well as the desktop application, and the README carries a Docker build badge for it. The platform list in the title is Windows, macOS and Linux, and the tooling is a mixture of the two encoders plus FFprobe for inspection.

A destination folder inside the source folder causes an infinite loop

The most concrete failure mode the documentation describes is a directory layout mistake. The program will not work properly if the destination folder sits inside the source folder, because the program recreates the source folder structure inside the destination folder, and it will cause an infinite loop of creating more and more sub-folders each time you run the program. The example given puts the source at D:\Videos and the destination at D:\Videos\Converted, which is the broken case, and the working case moves the destination to D:\Converted. This is a design consequence rather than a bug that could be patched away, since preserving structure means the output tree is written by walking the input tree. A second, subtler failure is related to downloads. The documentation warns that monitoring a folder which is being downloaded to can cause conversions to start before a file has fully downloaded, and recommends a temporary download folder that you move completed files out of. The related trap is an incomplete downloads folder placed inside the main source folder, which causes each file to be converted twice.

The last push is 2026 but the last release tag is from 2019

The maintenance picture is mixed, and the two facts need to be read together. The repository is not archived and the last push was on 2026-05-11, so there has been commit activity in 2026. The release tags, however, stop in 2019: 2.1.5 on 2019-07-29, 2.1.4 on 2019-07-13 and 2.1.3.1 on 2019-06-08. That gap means there is no packaged build that corresponds to the current state of the tree, and anyone installing is effectively taking whatever is in the repository rather than a released artefact. The licence is GPL-3.0, which is a straightforward licence for a free tool of this kind and carries the usual obligation to pass on the same terms if you redistribute a modified build. There is no versioning scheme in the tags beyond the 2.1.x numbering, no changelog in the tree, and the top level of the repository holds only a .github directory, a .travis.yml, the HBBatchBeast application directory, the LICENSE and the README, which is a narrow surface for a project that is still being pushed to.

For a server that re-encodes on arrival, the author's own pointer is Tdarr

The clearest alternative is not a competing GUI but a different deployment model, and the author points at it directly. The author says that for a server application with similar functionality please see Tdarr. The difference is where the tool sits. HBBatchBeast is a desktop application you open, configure with a GUI, and watch while workers chew through a queue, and its folder watching exists to catch new files arriving in a directory on a machine you own. A server-oriented tool in the same family is designed to be triggered by an event when a file lands in a watched path and to run the conversion as part of a pipeline, without a person choosing presets per folder in a settings screen. The other difference is cost of failure. On a desktop, a misconfigured watch wastes your own time. On a server, the same mistake means every incoming file is converted twice or never, which is why the download-folder warnings in the documentation are not incidental detail but the kind of operational guidance a server deployment needs more of.

Editorial conclusion

Adopt HBBatchBeast when a single machine holds a media library you want to convert in bulk, with a folder watch standing in for a download pipeline, and keep looking elsewhere when the source is a server that receives files continuously, because the author's own pointer to Tdarr covers that case. Verify first that the destination sits outside the source tree, since nesting the two makes the program recurse into itself, and read the wiki installation page before assuming the HandBrakeCLI dependency is already satisfied on Linux and macOS.

Frequently asked questions

Official sources

1. HaveAGitGat/HBBatchBeast on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases