Feauture Request: API

[LeeThompson]

I had an idea for a feature that may be a bit weird but anyway... A simple API (maybe a mini HTTPd or some other port) where you could get current status of jobs and do some rudimentary tasks.

Syntax would be something like host:port/api/key=APIKEY&command=APICOMMAND

Any additional arguments would follow &PARAMETER=VALUE

Commands: listjobs (returns a list in some format of current jobs, maybe just duplicate the columns in the UI but add a % complete. XML, JSON or CSV?) pause (tells VidCoder to pause processing) resume (tells VidCoder to resume processing) shutdown (tells VidCoder to exit, just like if you closed it normally) querystatus (additional parameter: job ID), returns status for specified job (not sure what the ID would be)

Future API additions could allow adding or editing pending jobs to the queue, importing / exporting the queue and import/export presets (single or batch).

I will now duck to avoid the tomatoes.

[RandomEngy]

What things are you trying to accomplish here? Do you need remote, manual control of VidCoder? Or are you tying it in with another program?

Are you just trying to keep an eye on the encode queue from a remote location?

[LeeThompson]

Mostly the latter, want to keep an eye on status. I run VidCoder on up to 4 different machines (depending on workload) so it would be nice if I could have an intranet webpage that consolidated all of the data.

The pause/resume would be handy but not as important for my usage. (RIght now I have a renamed notepad that launches if I need VidCoder to pause on that machine and it works but if an API is put in, it would be cleaner to use that.)

[RandomEngy]

Okay so you've got a bunch of "worker" machines that you want to chew through a single queue? And you want to keep track of that and control the workers from anywhere? Do you need to manually get all the encoded files back to a single location or do you encode to a network share/mapped drive?

[LeeThompson]

They all encode to a centralized UNC path. I'm not really looking to automate the entire process (but maybe others would), I'm just wanting a way to just be able to consolidate the encoding status into some php or perl driven web page. (With percentages and ETAs maybe).

I could probably make a mockup if that would help.

(Fully automating it would also be an issue since the profile selection I make depends on the content. What resolution is it? What aspect ratio (if it's 2.35:1 and has a lot of action, I'll go with a profile with a slightly higher bitrate. If the source aspect ratio is kinda messed up etc, I have some profiles that force it to a specific aspect ratio. If it's a movie and the frame rate is 25, I use a different program since Handbrake can't do a 4% slowdown and so on. Would need a full scripting language really to automate it.)

[RandomEngy]

You'd need to add authentication as well.

Anyway I'm curious, do they pull the source files from a UNC path as well? Working on this I'd like to think about the best way to split up work between multiple machines, and build it in to VidCoder. That way more people would be able to take advantage of the functionality, rather than those who set up their own monitor pages.

[LeeThompson]

That's what the APIKEY argument would be for, which would be set in that VidCoder config.

About 75% of the sources are UNC paths, a few are direct.

One plus with a full API implementation would be you could have the VidCoder UI use it to spread out jobs for having 'render farms' (well, transcode farms).

[RandomEngy]

Just FYI I probably won't be working on this for a while; It's a big project and I've got too many other things to do first.

[LeeThompson]

No worries and no rush.

[bcurran3]

I know it's low priority, but I would like to upvote this.

I have VidCoder running on up to three machines at a time. I find myself constantly remoting in to machine 2 & 3 to check status and delete the completed queue. A centralized place to check each would be nice. Maybe even hooks into a Chrome extension?

Running with the Chrome extension idea for a second, uTorrent easy client would be a good example: https://chrome.google.com/webstore/detail/utorrent-easy-client/fmfiejlelblhoaflnjajjjjkkgbeifpn

Possibly implementing webhooks could work? Dunno - knee-jerk-thought.

[LeeThompson]

@RandomEngy If it would be helpful (and I know if anything this is a very backburner feature) I can begin drafting an API feature list (I'm a software dev too so maybe help implement later). I could do it as a google doc for public viewing (but private editing).

[RandomEngy]

That sounds fine with me.

[LeeThompson]

I've begun a document, it's very skeletal and drafty right now but will keep working on it.

https://docs.google.com/document/d/1NDPM5ArwjcNYcNVQMvRElgTn7UlFzOxp5duIAEZvCCs/edit?usp=sharing

[RandomEngy]

I like it. A few thoughts:

• VidCoder uses JSON everywhere, so using that for responses and complex submitted objects would probably be the best
• http:// is not secure, people can intercept the communication and grab the API key. We would want HTTPS for remote access.
• What is the job "name"? It might be better to have an integer ID to identify it to more easily prevent duplicates.

Also I think it would be a little cleaner like this:

GET /jobs?state=queued|encoding|finished -> returns JSON list of job info with state or states requested GET /status -> returns global stats like total queue ETA, number of jobs queued and Idle/Encoding/Paused state GET /job/ -> returns JSON info about a particular job POST /job -> Pass in JSON representing new job to queue, get back JSON object representing the queued job. Can specify a preset name or a picker+preset name, or pass in raw job JSON. POST /actions/start POST /actions/stop POST /actions/pause POST /actions/resume

I don't see a great reason to split up "status" and "statistics" since the stats aren't going to be very heavy.

Also an important prerequisite to investigate would be the ability to set up an HTTP server on the box.

[LeeThompson]

If you're using JSON everywhere then that would make more sense (I don't know why I thought it was XML).

All good thoughts, I'll update it later.

There's lots of little embedded http/https servlets for this purpose, I didn't want to get into that while trying to figure out how it'll work ;) (Also my particular use case is all intranet, if I want remote access I'll VPN in but yeah https is a must as an option.)

[devildant]

+1 for this feature request.

For my own needs, it would be to be able to control via a site, because vidcoder is used on a separate machine (nuc) which consumes little energy for that power. and adding elements is tedious, I use the desktop remote which seems to cause a lot of problems with vidcoder

[LeeThompson]

To be fair, I was asked to spec out the API but I haven't really designed one before so I never really did that other than a very sketchy draft.

[LeeThompson]

The tricky thing with doing an API for VidCoder is it will need (if the API is enabled) a lightweight HTTP/HTTPS daemon running to service the requests.