CLI custom presets

[bry2k]

Any new news regarding using custom presets with the CLI?

I found Manicure and tried it out, but it throws error messages when trying to parse my custom presets, I presume because it hasn't been updated since 0.9.3 was released.

Any chance of simply making the CLI read the GUI/XML presets file?

Or, any chance of adding a feature to Handbrake to display the CLI equivalent of the GUI settings...like an option under the Window menu, ie, "Show CLI String"...? That sure would make life easier....

Thanks!

[jbrjake]

I found Manicure and tried it out, but it throws error messages when trying to parse my custom presets, I presume because it hasn't been updated since 0.9.3 was released.

Um. I've updated it twice in just the last week. How do you think I got the new built-in presets into the CLI?

Any chance of simply making the CLI read the GUI/XML presets file?

No. Modifying it would be ridiculously complicated, and if it can't be modified it would be worthless to anyone who doesn't use a GUI. The benefit of the GUI preset system is for the GUIs -- it's widget based, and pretty much every widget has a key, and because the interfaces are rather synchronized, they all pretty much have the same widgets that accept the same values. Whereas, if you take a look at the API section of manicure, moving to the CLI format is rather convoluted. Doing it in C instead of a string-and-plist-and-array-and-block-friendly language like Ruby would be torture.

Or, any chance of adding a feature to Handbrake to display the CLI equivalent of the GUI settings...like an option under the Window menu, ie, "Show CLI String"...? That sure would make life easier....

Not happening, because there is absolutely no reason for the GUIs to know anything about the CLI syntax nor for them to keep track of every change in it when they don't even use it.

[bry2k]

I found Manicure and tried it out, but it throws error messages when trying to parse my custom presets, I presume because it hasn't been updated since 0.9.3 was released.

Um. I've updated it twice in just the last week. How do you think I got the new built-in presets into the CLI?

Deja vu...

I don't post often, but I've had this kind of exchange with you previously. I post a straightforward question, and get an ascerbic and unhelpful response from you. Searching your post history, I see that you have a nasty reflexive habit of chastising people when they ask for help, so I won't take it personally.

I figured out the CLI in as much as I have time for such things. I know how to use it. Nevertheless, it is tedious, particularly in this case, and I'm looking for a better solution. Hence my feature request.

I researched the issue and found the posts about manicure (which I knew nothing about), but the links I found all point to old versions. Obviously, I'm looking in the wrong place.

An intelligent person such as yourself might have ascertained that fact by reading my post, and replied with a helpful link to these "um", two latest builds you have done in the past week, but you chose not to do that. Instead, you wasted our time and energy to inform me only that you've updated the software. No link. No instructions. No help. Why did you bother to reply at all?

Um. I've updated it twice in just the last week. How do you think I got the new built-in presets into the CLI?

I don't have any idea how you get presets into the CLI, nor do I care, nor should I, nor should you presume I should care. I have no knowledge of how this software is designed. I am an end user. I feel like I am talking to a little child. My purpose here is to use the software, not to ascertain how you develop it. Do you understand?

Any chance of simply making the CLI read the GUI/XML presets file?

No. Modifying it would be ridiculously complicated, and if it can't be modified it would be worthless to anyone who doesn't use a GUI. The benefit of the GUI preset system is for the GUIs (snip) Whereas, if you take a look at the API section of manicure, moving to the CLI format is rather convoluted. Doing it in C instead of a string-and-plist-and-array-and-block-friendly language like Ruby would be torture.

Ridiculously complicated? Torture? Are you always this melodramatic? I don't mean to be insulting by asking this jbrjake, but what is your malfunction? You're a software developer. I'm an end user requesting assistance. Why in the world would you waste your time or mine suggesting I review API's for the software you've written, rather than just provide me with a link and a simple one sentence description of how to run the software and achieve the result I'm looking for? How ridiculous.

Or, any chance of adding a feature to Handbrake to display the CLI equivalent of the GUI settings...like an option under the Window menu, ie, "Show CLI String"...? That sure would make life easier....

Not happening, because there is absolutely no reason for the GUIs to know anything about the CLI syntax nor for them to keep track of every change in it when they don't even use it.

This is the part of your reply where you are just being absurdly dismissive. In point of fact, it would be very useful if the GUI showed CLI strings which represent the users settings, if the other method I suggested (CLI reading XML) is truly so difficult. The fact is, I could really use this feature, therefore, there is a reason for it. In searching on these forums, I quickly discovered in a matter of minutes that there are many others who have requested similar functionality. Therefore, there is a reason for it. So you see? You're wrong.

Whether or not you'll consider actually implementing the feature is another matter, but the need for a bridge between the GUI and CLI is indisputable. Some users use both.

Ok. Enough tit-for-tat in dealing with your attitude.

If you could be a pal for just a minute, your assistance, and not your condescending replies would be much appreciated. If that's not too much to ask...

I will restate my case:

The default Handbrake presets are great, but do not cover a variety of scenarios I have to deal with (I'm a producer/filmmaker/editor and I deal with a lot of different media). While I understand there would be some work involved, it would not be "torture" to have the GUI generate the simple CLI equivalent strings representing the user selected GUI settings. The GUI is great for testing conversion results, particularly for those among us who have not mastered and memorized all of the equivalent CLI strings. My first suggested approach was that under the Window menu in Handbrake, you put a menu item, "Show CLI string", and simply populate a string variable with the equivalent CLI commands based on whatever the user has selected in the GUI. That would not be difficult to implement. If hiding the relationship between the CLI and the GUI from GUI users is such a huge priority (seems unimportant to me), then an alternate method I'd suggest would be to just write a separate file in Lib:App Support:Handbrake which contains the CLI string equivalents of the current GUI settings and/or presets. That would be very useful to users who use both the GUI and CLI. Search your own forums to prove to yourself that such users exist. If you care. If not...so be it. I tried.

Thanks

[bry2k]

Figured out how to download the latest version of manicure.rb from the svn, but I have no idea how to use it. Executing it produces this result:

Code: Select all

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- plist (LoadError)
	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require'
	from ./manicure.rb:15

[bry2k]

After more searching...apparently it relates to this...

http://forum.handbrake.fr/viewtopic.php ... 1&start=58

[bry2k]

The saga continues...

Got plist installed...

Run manicure. Result:

./manicure.rb:573:in `generateCLIParse': undefined method `size' for nil:NilClass (NoMethodError)
from ./manicure.rb:158:in `displayIndividualPreset'
from ./manicure.rb:128:in `displayCommandStrings'
from ./manicure.rb:124:in `each'
from ./manicure.rb:124:in `displayCommandStrings'
from ./manicure.rb:115:in `each'
from ./manicure.rb:115:in `displayCommandStrings'
from ./manicure.rb:108:in `initialize'
from ./manicure.rb:1265:in `new'
from ./manicure.rb:1265

[bry2k]

Well, I got manicure running (must be a bug in the latest build or not compatible with 0.9.3 release?). In any event, this has led me to discovering that perhaps this entire pursuit was in vain. When I try to convert files with CLI, it doesn't work.

Question: Can the CLI operate on files like the GUI (0.9.3), or does CLI only operate on DVD/VIDEO_TS folders?

[KonaBlend]

I will restate my case:

The default Handbrake presets are great, but do not cover a variety of scenarios I have to deal with (I'm a producer/filmmaker/editor and I deal with a lot of different media). While I understand there would be some work involved, it would not be "torture" to have the GUI generate the simple CLI equivalent strings representing the user selected GUI settings.

No. The GUI and CLI are decoupled. I don't find anything "simple" about coupling them and introducing a never-ending sync issues between the two.

The GUI is great for testing conversion results, particularly for those among us who have not mastered and memorized all of the equivalent CLI strings.

I like to use CLI for testing, but that's just me.

My first suggested approach was that under the Window menu in Handbrake, you put a menu item, "Show CLI string", and simply populate a string variable with the equivalent CLI commands based on whatever the user has selected in the GUI.

No. As mentioned earlier they are decoupled. Saying the word "simple" over and over does not change the software design.

I have no knowledge of how this software is designed. I am an end user.

That would not be difficult to implement.

When someone has no knowledge of this software design, and obviously no software design methodology of any kind, their assessment of feature cost is worth about this much |..|

If hiding the relationship between the CLI and the GUI from GUI users is such a huge priority (seems unimportant to me)

Yes it would seem unimportant to the end user. But terribly important to those who care for software design and architecture.

...That would be very useful to users who use both the GUI and CLI.

You don't seem to realize that as part of a software development strategy, one has to manage resources, and make design decisions which has pros and cons for the (amongst other things) features for a product. And one thing this project actually doesn't have is a formal CLI. Yes, it's made available because people asked, begged, for it. And now you have access to it, but it's not even an official interface to HandBrake and now you're asking for it to be coupled to the GUI.

There's not a lot of development bodies here, very few individuals, each with peaked areas of interest that they work on, without pay, on a volunteer basis; do bear that in mind, eh?

[bry2k]

...That would be very useful to users who use both the GUI and CLI.

You don't seem to realize that as part of a software development strategy, one has to manage resources, and make design decisions which has pros and cons for the (amongst other things) features for a product. And one thing this project actually doesn't have is a formal CLI. Yes, it's made available because people asked, begged, for it. And now you have access to it, but it's not even an official interface to HandBrake and now you're asking for it to be coupled to the GUI.

There's not a lot of development bodies here, very few individuals, each with peaked areas of interest that they work on, without pay, on a volunteer basis; do bear that in mind, eh?

I've made no assumption to the contrary. I'm not demanding anything. I suggested a feature, and explained why I need it. I asked a few questions. And neither of you "developers" answered any of them. Just "no no can't won't don't not no no no"...

I see you're a developer too. If you're busy, I would understand a terse reply along the lines of "Download manicure here to parse XML. Download gem plist here to run manicure. Yes/No, CLI will/will not encode files. Read here where its been discussed before."

Instead, both of you spent at least twice the amount of time it would take to type up a quick helpful reply to instead argue with me, while providing no useful response to a single question I asked. How juvenile.

What's up with you guys? Every time I search these forums, I find somebody asking a question where one of the developers jumped in to heap scorn upon the question without providing any information. Not "dumb" questions...good questions...which melted down into flames instead of useful information exchanges because the devs acts like teenagers in an AOL chat room with the way they treat people.

No, you're not getting paid. We know...we know. As a regular reader of these forums, I also note that you guys rarely miss an opportunity to point that out. You're volunteers. Quit if it bothers you so much. I would gladly pay for a supported version of Handbrake, but you choose not to run it that way.

Now, please...enough of this. Stop cluttering up your own forums with this nonsense. Can I get a simple question answered?

Does CLI process files, or only DVDs? If not, is that functionality in the pipeline for 0.9.4 or anytime soon?

Thanks.

[s55]

From the homepage

HandBrake is no longer limited to DVDs: it will now accept practically any type of video as a source. This massive enhancement was achieved by tapping into the power of libavcodec and libavformat from the FFmpeg project.

Was that so hard?

[KonaBlend]

I've made no assumption to the contrary. I'm not demanding anything. I suggested a feature, and explained why I need it. I asked a few questions. And neither of you "developers" answered any of them. Just "no no can't won't don't not no no no"...

1. You have made ignorant assumptions all along. Assuming your feature request is "simple". Repeatedly.
2. Your questions have been answered. Repeatedly. And with more depth than you deserve.

No, you're not getting paid. We know...we know. As a regular reader of these forums, I also note that you guys rarely miss an opportunity to point that out. You're volunteers. Quit if it bothers you so much. I would gladly pay for a supported version of Handbrake, but you choose not to run it that way.

Again you have things backwards. I conveyed to you this project was volunteer because you are acting as if people here owe you something; like you are paying a service contract of some kind. You are not. You are a mooch who is unwilling to contribute in any way. How convenient for you that this is a free project; otherwise you would shell out the big $$ i'm sure. How convenient for you that you do not have software development experience; otherwise you would rearchitect this product i'm sure. So now that those two things are conveniently impossible, and you're some innocent end-user victimized by missing life-or-death HandBrake features, why not troll the devs for some feature they're not interested in pursuing and you're hell bent on getting.

[bry2k]

You are a mooch who is unwilling to contribute in any way.

You're calling someone a "mooch" for using software which is offered for free?

By that logic, anyone who uses Handbrake but doesn't contribute code is a "mooch", since this project accepts no other means of contributing, ergo, the Handbrake dev team gives their software to people for whom they have nothing but contempt (since thinking of someone as a "mooch" is nothing if not contemptuous).

What can be said about that, except...how oddly masochistic. Oh...and incredibly stupid, I might add.

How convenient for you that you do not have software development experience; otherwise you would rearchitect this product i'm sure.

Allow me to translate what you meant, since you appear to be too passive-aggressive to articulate it: "People who do not write software are inferior to me, and lack the capacity to provide any useful input on the design or functionality."

Best of luck to you whenever you get around to finding a paying job. At least now I understand why you are working for free.

I can relate to you having a superiority complex regarding your skillset. As a cinematographer, I'm similarly certain that a snarky button pusher who simmers with resentment towards people who "mooch" his free software (a contradiction in terms if there ever was one) could never produce an evocative image worthy of being converted in the very software he developed.

So there you go. Each of us has his own set of skills to contribute to the universe. Carry on.

Your technical support grade for this session: F- ...I figured it out myself.

Thanks!

[KonaBlend]

I'm wondering if you'll address why you are ignorantly classifying a feature request as "simple" and oblivious to the true complexities of the task. Or you can go on sidestepping that faux pas and trolling in an attempt to mask it.

[jbrjake]

*adds another entry to his Horrible HandBrake Users list*

I'm locking this now. Kona has said everything that needs to be said. bry2k, we eagerly await your patch.