Handbrake: Multi-Process / Network Remote Control

[t4thfavor]

Describe the change or feature you'd like to see added to HandBrake:

I recently installed OpenMediaVault on top of Debian 9.0 and was thinking that it would be nice to run Handbrake as a "front end" to handbrake-cli on the headless debian machine. The machine is a dual quad Xeon, has tons of internal storage, and is genuinely headless (no video card, or serial console installed). The idea would be that Handbrake could be run on another machine, pointed to the remote machine, and interact with handbrake-cli to create jobs and queue new work. This could be used to queue jobs on several machines (separate queue's, not distributed) from a single workstation (I have 4 mac Pro's with a total of 48 cores available in my basement, and not attached to video)
I don't think installing a full GUI is very efficient if the only thing that would be using it is Handbrake. Perhaps there is already a feature like this that I am not aware of, or another product, but I've done some searching and come up with the following: VNC, SSH and use CLI directly.

In "ancient" times, I used Cinelerra, but I don't see that it is well supported anymore.

Thanks,
Chance

What version of HandBrake are you currently using? (e.g., 1.0.0)

1.2.0

What operating system and version are you running? (e.g., Ubuntu 16.04 LTS, macOS 10.3 High Sierra, Windows 10 Creators Update)

Windows 10 and Debian 9

HandBrake Activity Log (see https://handbrake.fr/docs/en/latest/help/activity-log.html)

~
If the request is off the back of failure or unsupported file format, please post a log as it can help us track down what is missing.
Either post it in full here, or drag/drop the file onto GitHub to upload it.
~

[jstebbins]

There is no such remote feature. I have long term plans to split encode tasks out as separate processes which could in theory be enhanced to run these processes on different machines. But that's a long way away yet.

You might be interested in using the GUI via GTK's broadway backend however. Fire up the broadway daemon, set the proper environment variables, run the GUI and access it via a web page remotely. It's remarkably responsive. Way better than a VNC session.
See https://developer.gnome.org/gtk3/stable/gtk-broadway.html

[sr55]

Network control is a can of worms with security, file handling and reliability. It sounds "fun" in theory though. Kinda torn on this one!

Most folks I've seen doing this are using scripting in phyton or ruby to: Transfer file (or have it on share), Run HandBrakeCLI, Transfer result (if necessary).

I'm defiantly for multi-process as it helps in reliability, load balancing on high CPU core count systems though. (Been experimenting with this locally for the WinGUI as I wasn't sure when you'd get to that :))

I'll mark it as an enhancement for now but we'll see where things go.

[t4thfavor]

I mean, SSH could handle all the security, and transport, but my whole reason is so I can command and control many queue's from one central location to several high processor count machines that don't generally have a GUI available.

[sr55]

It can, but it's also not user friendly or trivial to handle when your dealing with multiple operating systems, including windows. It's not overly difficult to implement in a cross-platform supported way. Something to think about down the road.

[t4thfavor]

Absolutely, it's just an idea, without ideas (bad or good) nothing would ever be accomplished. Thanks for taking the time to think about it.

[sr55]

Don't have to close the request ;) I don't believe we have anything tracking this. We generally keep them open until we discuss / decide on them.

[KizzyCode]

There could be an interim solution: create an "encoding bundle" which contains all the video files and settings and can be opened on any machine with Handbrake installed.

Pros:

• Allows you to simply move a job from one machine to another by transferring a single file (via SSH, SMB, magic wormhole or any already existing channel)
• Allows you to archive jobs for future execution
• Probably pretty easy to implement (e.g. as a TAR-archive with the videos and job configs as files)
• Could be used as underlying format for future job-sharing-from-GUI developments

Cons:

• May not be suitable for simultaneous workload distribution across multiple machines

The feature could be added as "Export Queue" button which then exports sth. like "MyQueue.hbqueue"

[t4thfavor]

Doesn't really solve the client/server problem. I'll never put a video card in the machines I'm trying to manage, but they are still fairly powerful. I could run the application directly on the other machines, but the point of this ticket is to remotely control the back end by pointing the front end at a listening back end. This way I could start jobs on each of the four machines from my laptop upstairs without venturing into the dungeon.

[KizzyCode]

Yes and no – you still have the need to open a SSH session and invoke HB manually, but if you have a HBQueue-bundle this gets much easier because you don't need to specify each setting as a CLI argument etc.
I mean, you have SSH on your machine?

[t4thfavor]

I believe you misinterpret the request. The request is literally "Decouple the UI from the backend so that you can specify within the UI which backend IP address you'd like to control". This would mean that you'd have a dropdown of prior backends which you would pick from, the front end would query the backend queue for it's current work, and allow you to manage it seamlessly from over the network. No manual manipulation of the handbrake-cli, or starting SSH whatsoever. Either way, I am using Linux, MacOS, and Windows, and all have pretty easily installed (or native) ssh implementations.

[DriverXX]

I think a first simple solution could be to simply "Decouple the UI from the backend" as @t4thfavor said.
Handle everything locally but split it into 2 different entity:

• A daemon which hold the queue and run the encodings
• A cli tool which can edit (add, remove, check the status of the endcoding) on the daemon process

In this way it is simple, through SSH, to add new job to the current queue and check the status of the current encoding, but without the need to keep the SSH session open.
One can simply create jobs from the GUI and then import them into the daemon through the cli tool.
Of course this is only a first step, but once it is done it opens up to huge amounts of possible improvements.

[t4thfavor]

Completely agree. Even if the first implementation uses a message bus or something and has no IP connectivity, that's a first step to two separate processes.

I have 4 beefy machines that I used to use Cinelerra on as rendering nodes. I'm not looking for that sort of feature, simply the ability to remotely manage a queue using handbrake, and not have to use RDP. Ideally you could install the rendering part without even installing X as I have some headless servers with massive amounts of free CPU for rendering stuff, but no way to run the handbrake gui.

I'm sure that I'm not alone in this regard.