Export queue as script...

Archive of historical feature requests.
Please use the GitHub link above to report issues.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
rachel
Posts: 67
Joined: Thu Mar 15, 2007 7:34 pm

Export queue as script...

Post by rachel »

I already use Handbrake a lot in OS X; but I'm about to build a fast Linux system to be a compute and RAID server for my in-home media empire :-) This machine will be considerably faster than my fastest Mac.

Handbrake exists for Linux, but last time I looked it didn't have a GUI, and the CLI seems fairly opaque if you don't already know exactly where on the dvd the stuff you want to rip is, and how you want to crop it, etc.

In lieu of a full GUI for the Linux version, how about being able to use Handbrake on the Mac to make the selections, with all the options, cropping etc. exactly how I want it, add everything to the queue, then instead of executing in on the Mac, export the queue as a shell script, simply containing the commands to execute that queue against the CLI version of the program on my Linux box?

(Possibly some mapping of device node names would be needed; but that may possibly just be a preference setting?)

rhester
Veteran User
Posts: 2888
Joined: Tue Apr 18, 2006 10:24 pm

Post by rhester »

Absolutely not. This is a perfect example of a request that benefits a very small (read: one) amount of the total user base.

Please see the sticky at the top of the Requests forum for details on what are - and aren't - good requests.

If you still want it after reading this, no problem - we look forward to your patch to the source.

Rodney

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

To explain "No" in a little more detail...

I think you might be working under the assumption that the Mac GUI of HandBrake is a lot like the Mac GUI of mkvmerge, or ffmpegX or something. Where it's just an easy, graphical way to assemble a command line.

The Mac GUI of HandBrake doesn't just generate a command line. It accesses the core library of the program directly. So it's not like when you click buttons on the Mac you're creating a command string that gets send to HandBrakeCLI...

...so to do this, someone would have to go and make a translation table between the api calls and the command line arguments, then make a little parser to convert between them. Then, they'd have to add a new window and a new controller class and write a bunch of boring Cocoa stuff to make it display on screen.

As rhester said, a patch would be great, nice little bit of additional functionality...but not so nice I feel compelled to write it myself.

As for HandBrake's CLI being "opaque"....I'd argue that it's the simplest CLI video encoder available. Transcode is more feature-full but more difficult, and mencoder's manual takes days to read through. And ffmpeg's interface is a bit of a mess, imo.

rachel
Posts: 67
Joined: Thu Mar 15, 2007 7:34 pm

Post by rachel »

rhester wrote:Absolutely not. This is a perfect example of a request that benefits a very small (read: one) amount of the total user base.

Please see the sticky at the top of the Requests forum for details on what are - and aren't - good requests.

If you still want it after reading this, no problem - we look forward to your patch to the source.

Rodney
Thank you for your welcoming and encouraging response. I had in fact read both sticky notices. It's sometimes difficult to guess whether something one wants is something other people might be interested in without actually mentioning it somewhere.

Okay, I've had a look at the source. Unfortunately the XCode project for the MediaFork macosx application doesn't appear to build. (I'm looking at Media Fork 0.8.0b1) Doesn't matter, I'm sure there's a file somewhere that tells me what to do to make this build, even if I can't find it right now. Maybe just doing the make as mentioned in the BUILD file will in some way fix the XCode project into a buildable state.

That doesn't matter to my point; if it did I'd have tried harder. :-)

My point is that what I'm suggesting is really just a facility to dump the contents of a hb_job_t (as defined in common.h in the api directory) into a textual format written to a file, repeat for every job in the queue (whatever object I currently can't find that holds a list or sequence of jobs). This shouldn't be very hard, even for me even though I haven't written a line of C in about twelve years. (These days I'm a Java developer.)

What *would* involve me weeks of learning about Cocoa development and Objective C, is making the *button* that appears on the handbrake window (eg, "Export Queue", next to "Show Queue", when the queue is enabled) that pops up the cocoa save dialogue and actually calls the method or function to do the export. This would probably take someone who already knows Cocoa and is familiar with the project about a minute - well, maybe five.

So I thought it was worth making the suggestion.

Okay, so maybe I'm the only person who wants exactly this. How about making the suggestion more generic:

A way to save and subsequently load a queue of jobs. Essentially, a way to serialize a list of hb_job_t structures, and then deserialize them again.

One reason aside from mine where this might be useful: You've got a long complicated queue running but something unforseen means you really need to quit handbrake right now. (Maybe the machine needs to be restarted.) Save the queue, quit, when you restart you can reload the queue and resume at least from the start of the current job rather than having to set everything up again. (In fact, the same facility could just be made automatic: have it save the queue automatically and invisibly just before each job is started, so you can resume from where you left off if Handbrake has to die for a while for whatever reason.)

Another possibility is that people could upload queuefiles for given DVDs, so later when other people want to rip the same DVD that they have, they can just insert it and either automatically or manually fetch an existing queuefile that optimally rips that whole dvd. That might even be integrated with the metadata scrape stuff already slated for 1.0. (I don't know about anyone else, but setting up a DVD for ripping if you don't want the default options is a job of a few minutes, especially with careful cropping of each program, and especially if it's got, say, a number of music videos or several TV episodes or commentary etc. rather than just a movie. Plus as I always rip to h.264 at a fairly high bitrate and 2-pass, the rip itself takes long enough that a resume that works over an application restart would have several times come in handy.)

Just make the save format something that can be read in by the CLI version too - so you can call that with a queuefile saved from another instance of handbrake, potentially on another platform; so basically, in some textual or at least portable form rather than just fwriting the structure and the pointed-to hb_title_t. I would say XML, but for the plain C CLI version away from OSX that would probably mean having to link in some third party XML parsing library :-( and what's needed is probably simple enough not to warrant that. (It could literally still be a list of command-line parameters, one per job; after all, the CLI version already has code to parse that, and in fact it would then be trivial to write a shell script to feed each such job to the CLI version without that needing extra support at all...)

As for the re-mapping of device nodes from a /dev/rdisk3 to a /dev/hda, for instance, maybe that is too specialised to my needs, and i'd be ok with just doing that with sed myself outside the program.

rachel
Posts: 67
Joined: Thu Mar 15, 2007 7:34 pm

Post by rachel »

jbrjake wrote:To explain "No" in a little more detail...
(quickly... my reply crossed yours in the ether, and thus doesn't take any of what you next said into account).

rachel
Posts: 67
Joined: Thu Mar 15, 2007 7:34 pm

Post by rachel »

jbrjake wrote:To explain "No" in a little more detail...

I think you might be working under the assumption that the Mac GUI of HandBrake is a lot like the Mac GUI of mkvmerge, or ffmpegX or something.
No such assumption; I'm not familiar with those programs. :-)
The Mac GUI of HandBrake doesn't just generate a command line. It accesses the core library of the program directly. So it's not like when you click buttons on the Mac you're creating a command string that gets send to HandBrakeCLI...

...so to do this, someone would have to go and make a translation table between the api calls and the command line arguments, then make a little parser to convert between them.
There does seem to be an almost 1-1 mapping between a hb_job_t and the parameters that the CLI version takes. Maybe that's more of a coincidence than was apparent. :-) I'll admit it was an assumption that the CLI version would parse the commandline arguments into a hb_job_t, and then call the same code to actually process the job as the GUI version does, with a pointer to that structure. I assumed that, because that's how I'd have written it. :-)
Then, they'd have to add a new window and a new controller class and write a bunch of boring Cocoa stuff to make it display on screen.

As rhester said, a patch would be great, nice little bit of additional functionality...but not so nice I feel compelled to write it myself.
Mm. As mentioned in my long post, I'm not thoroughly against submitting a patch myself, except that I'd have to climb the whole Cocoa development learning curve from scratch to do it. (I've just spent this evening reconnoitering, as it were.) It seems, however, that it shouldn't take long for someone already familiar with this project. I'd certainly be up for writing the C to actually print the hb_job_t struct data to file, but at the moment I wouldn't have any way of testing it.
As for HandBrake's CLI being "opaque"....I'd argue that it's the simplest CLI video encoder available. Transcode is more feature-full but more difficult, and mencoder's manual takes days to read through. And ffmpeg's interface is a bit of a mess, imo.
The opacity isn't in the options to Handbrake, but in obtaining the values to supply to those options from a DVD in the drive. :-) It just occurred to me that the Handbrake GUI is already good at harvesting that data, as well as the exact encoding options and cropping etc. from a user, so exporting them from a hb_job_t struct would be not too hard.

And the CLI already knows how to parse them back...

But this is repeating what was in my long post. I'll readily concede I don't know much about how hard it is to add an export button to the GUI in cocoa, beyond the Apple Kool-Aid that Cocoa development is supposed to be quick and easy :-) From my imperfect understanding it looked like an NSButton like the Show Queue or Add To Queue buttons could be made, with a Connection to a method in Controller.mm ExportQueue, alongside AddToQueue, which would call the probably plain C function to write the contents of the hb_job_t struct to which we'd have the pointer (as we do in AddToQueue) to file. Except there's some Cocoa business I don't know with a file save selector I'm sure...

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

rachel wrote:No such assumption; I'm not familiar with those programs. :-)
Okay, good. We just get a lot of that here.
There does seem to be an almost 1-1 mapping between a hb_job_t and the parameters that the CLI version takes. Maybe that's more of a coincidence than was apparent. :-) I'll admit it was an assumption that the CLI version would parse the commandline arguments into a hb_job_t, and then call the same code to actually process the job as the GUI version does, with a pointer to that structure. I assumed that, because that's how I'd have written it. :-)
I'm sorry if my post confused matters; I didn't realize how much research you'd done already. It functions exactly how you think they should. The CLI parses arguments into a job struct, and so does the GUI.
Mm. As mentioned in my long post, I'm not thoroughly against submitting a patch myself, except that I'd have to climb the whole Cocoa development learning curve from scratch to do it. (I've just spent this evening reconnoitering, as it were.) It seems, however, that it shouldn't take long for someone already familiar with this project. I'd certainly be up for writing the C to actually print the hb_job_t struct data to file, but at the moment I wouldn't have any way of testing it.
Well first of all, understand that when a dev here says "we await a patch" or whatever it's not just a write-off...contributions are always welcome, we have a dire need of new developers.

I don't know any Cocoa myself yet (well, I'm learning...halfway through the intro O'Reilly book). So let me say, there's a great way to get your stuff into the GUI...it's the method I've used successfully on several occasions...

Step 1: Write something that works in the CLI. Make it really easy from the interface's point of view...
ideally, just another variable to load. Do everything else in libhb. Remember: the CLI was originally called HBTest. It's a testing ground. Things should work there before they reach the GUI.

Step 2: Show people it works and get it checked into the source.

Step 3: Beg dynaflash =) This is why you want something that's really easy from the interface's point of view. Just a string to load, maybe a checkbox that's a boolean. If you check the Trac timeline, you'll see he's single-handedly keeping the GUI from falling apart, and it's grueling. At the same time, he's expanding it with cool new features. So dynaflash is a busy man. I try to give him as little work as possible.

In this case, you're going to want to do is have a string variable I guess. Use a conditional on whether or not it exists as a boolean for whether or not to save the job list right before work begins. Then you put a conditional somewhere in the workflow (if you're really interested in pursuing this I'll tell you exactly where tomorrow) which could call a function in, I guess, common.c, to actually write the jobs to disk. At least, that's how I'd do it. Sounds like you have a hell of a lot more coding experience than me, though, so I'll admit right now that it's pretty crude.

The other problem is going to be file path. You could have another variable, a string, to store that.

So lemme imagine a theoretical command line:

./HandBrakeCLI -i dvd -o ~/Movies/movie.mp4 --saveJob ~/Documents/hb-job-log.txt

Loading would be a little more difficult, but I can see it happening.

One really useful thing this could do is add a sort of queue to the CLI, which currently lacks it. You'd have to add another variable which would say whether or not to continue with the encode after writing the log. Then you could send a bunch of commands to the CLI, and have it append the jobs to a text file instead of encoding. When you're ready to encode, just do

./HandBrakeCLI --loadJobs ~/Documents/hb-job-log.txt

It'd be kinda cool. I really mean it when I say I look forward to seeing a patch.
The opacity isn't in the options to Handbrake, but in obtaining the values to supply to those options from a DVD in the drive. :-) It just occurred to me that the Handbrake GUI is already good at harvesting that data, as well as the exact encoding options and cropping etc. from a user, so exporting them from a hb_job_t struct would be not too hard.

And the CLI already knows how to parse them back...
I'm not sure what you mean...the CLI has default values it loads and default cropping and aspect ratio it applies that function the exact same as the GUI, as far as I know.
From my imperfect understanding it looked like an NSButton like the Show Queue or Add To Queue buttons could be made, with a Connection to a method in Controller.mm ExportQueue, alongside AddToQueue, which would call the probably plain C function to write the contents of the hb_job_t struct to which we'd have the pointer (as we do in AddToQueue) to file. Except there's some Cocoa business I don't know with a file save selector I'm sure...
That's pretty much it, I think. So hey, maybe you won't have to beg dynaflash at all. You're already better off that me ;P

rhester
Veteran User
Posts: 2888
Joined: Tue Apr 18, 2006 10:24 pm

Post by rhester »

Rachel,

I just want to say that I'm thankful to have you as a user here...and hopefully someday a contributing developer. You have very clearly done your homework, and your more generic presentation of your suggestion absolutely has merit. It's one of those novel things that few think of because it's that obvious...and worth doing.

Devs, let's please make sure this individual gets any coding support we can offer. jbrjake, your offer of helping narrow the source scope is a valued one.

Rodney

rachel
Posts: 67
Joined: Thu Mar 15, 2007 7:34 pm

Post by rachel »

I'll reply to the rest later. I'm supposedly at work now. :-}
jbrjake wrote:
rachel wrote:The opacity isn't in the options to Handbrake, but in obtaining the values to supply to those options from a DVD in the drive. :-) It just occurred to me that the Handbrake GUI is already good at harvesting that data, as well as the exact encoding options and cropping etc. from a user, so exporting them from a hb_job_t struct would be not too hard.

And the CLI already knows how to parse them back...
I'm not sure what you mean...the CLI has default values it loads and default cropping and aspect ratio it applies that function the exact same as the GUI, as far as I know.
Yes, what if I don't want the default values? What if I want to rip programme 2 all chapters to h.264 at 1200 kbps with 320kbps aac and with 2,1,2,1 cropping around the edges, then each chapter of programme 5 separately (say, each one's a music video) with interlace off and different cropping, and so on...? At the moment I don't even know how to identify the programme and chapter numbers to *give* to the CLI, let alone have a way of setting up the cropping I want. The Handbrake GUI does, but it would be laborious to manually transcribe off the options on screen to a commandline every time.

That's the whole reason I came up with this idea... To my knowledge there's no way to actually obtain the information to *give* to the CLI version unless you just want it to do its default thing.

I mean, I could have just asked for a full Linux GUI and full queue editing capability... <fx: ducks and runs>

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

From a mac gui standpoint. Seems plenty feasible. Frankly, totally rewriting the HandBrake queue is coming up on my list of things to do. So, maybe that would be a good time to seriously look at incorporating this functionality, as all of the queue code is likely to be rewritten anyway.

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Post by jbrjake »

rachel wrote:Yes, what if I don't want the default values? What if I want to rip programme 2 all chapters to h.264 at 1200 kbps with 320kbps aac and with 2,1,2,1 cropping around the edges, then each chapter of programme 5 separately (say, each one's a music video) with interlace off and different cropping, and so on...? At the moment I don't even know how to identify the programme and chapter numbers to *give* to the CLI, let alone have a way of setting up the cropping I want. The Handbrake GUI does, but it would be laborious to manually transcribe off the options on screen to a commandline every time.
If you run

./HandBrakeCLI -i dvd -t 0

It'll give you a readout of the titles and chapters on the DVD along with their durations; this is exactly the information the GUI uses to seed the title chapter menus with numbers.

The commands aren't that laborious.

./HandBrakeCLI -i dvd -t 2 -o movie.mp4 -e x264 -b 1200 -B 320 --crop 2:1:2:1 ; ./HandBrakeCLI -i dvd -t3 -c 1 -o movie.mp4 -e x264 -b 1200 -B 320 --crop 2:2:3:2 --deinterlace; etc etc

The sticking point, though, as you note, is custom cropping. To know what custom values to use, you have to look at the image...which is pretty much the only reason I ever fire up the GUI.

Oh, btw, dynaflash? I think this can be done independently from the GUI queuing rewrite. All this export feature would need is to save the jobs list right before encoding starts. Whatever changes are made to the queuing, it should still fill the jobs list the same way.

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

jbrjake wrote:Oh, btw, dynaflash? I think this can be done independently from the GUI queuing rewrite. All this export feature would need is to save the jobs list right before encoding starts. Whatever changes are made to the queuing, it should still fill the jobs list the same way.
Okay, what do we want them saved to? I think I see what you mean. I just figured if I am going to overhaul the queue, we could wait until then. Othewise, if this is getting pushed up the priority list, we can do it sooner.

cbud
Bright Spark User
Posts: 181
Joined: Thu Feb 22, 2007 2:24 am

Post by cbud »

I like this idea. Having more queue information would be very useful to me as a double check before I walk away for two days. If MF can export details about the queue, then I can quickly read through them to make sure I did not mess something up (presets would really help too).

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Post by dynaflash »

cbud. Presets are done in our svn. They will make it into our next release :)

Post Reply