Offer: create daemon mode HB

[bluepill]

Hi,
I noticed that in your Cool Idea's section of the website you are interested in the creation of a daemon mode Handbrake. I'd like to offer my time for the development and maintenance of this feature. It would be useful to me personally and I am sure there are quite a few people who would also like this type of functionality.

If it's ok with whoever is in charge of this project then I'd like to contribute.

Also, if anyone has already started working on this I'm happy to lend a hand to speed up development.

I can build on Mac/Windows/Linux/iOS/Android using C/C++/C#/ObjC/Java.

[Deleted User 11865]

Cool. The best way to get in touch with us directly is via IRC:

https://trac.handbrake.fr/wiki/IRC

#handbrake - we can voice you in #handbrake-dev if/when it becomes necessary.

[bluepill]

thx.

[s55]

Fwiw, when I added it, here was roughly what I envisioned.

- Maybe JSON API.
- Method for Scanning with optional bitmap images encoded in the stream.
- Method for encoding with callbacks for progress updates,
- Method for getting Status
- Method for getting encode / scan progress (where callbacks may not work)

If that works well, I'd then like to extend it to provide much more access to the HandBrake API (which may mean we need to do some tidy up on our API)

I kind of like the idea of using JSON as a real easy API.

[bluepill]

Hi s55. It's good to get some background on the feature. If you don't mind me paraphrasing it seems like you are interested in a scenario where a 'server' exposes the Handbrake API for one or more 'clients' to operate with. The server is a worker doing the bidding of the client UI's. One logical outcome of this is that the Handbrake UI could become quite simple and potentially be ported to low end platforms (phones/tablets) with all the heavy lifting happening on the 'server'.

Let's call this the client-server scenario.

I have 2 other scenario's from discussions on the IRC channel:
1. the daemon operates in as a transcode job worker. It accepts jobs from client UI's and provides status and results back. In this scenario the client remains doing all the heavy lifting up to the submission of a transcoding job.

2. the daemon operates as a watchful worker. It monitors locations (local and remote) for data to be dropped in and performs transcoding based on a preset and some rules for determining which title/s to process.


All 3 scenario's sound pretty good to me. I plan to flesh out the scenario's and provide them back to the IRC for review/comment. I guess whatever sticks is what will be created.

btw I agree that JSON is a reasonable API choice; however I think the usage scenario's need to be agreed before the technology solution can be selected.

[s55]

Once you have the API exposed, it opens up an awful lot of possibilities, including 1 and 2.

2 however wouldn't necessarily need this. You can achieve this currently with scripting fairly easily. Plenty of examples in the CLI forum. It wouldn't really be that difficult to add a watch mode into the CLI but I suspect that most people that are doing this, want a lot of flexibility that would make for a complex feature that can be achieved with simpler scripting.

[ty2010]

Virtualdub's works rather nicely and is very simple in it's implementation.

[styteen]

Can you help me ? Who have document "JSON API" ?

[Deleted User 11865]

http://en.wikipedia.org/wiki/JSON