Closed vr8hub closed 4 years ago
@vr8hub The --name
option was designed to make it easier to write automated test rigs such as those that @khaosx and @rhapsodians were working with during development. And it was designed for those people bold enough to use the same directory for both input and output. I never intended the --name
option to be a common user feature. Which is why it's buried in --help more
.
I believe that choosing either an input or an output name is the province of the mv
command. If "Movie_Name_t00.mkv" is a troubling, then a user should just change it before they transcode. Or change it afterwards. It makes no difference because the name of the file has no effect on the contents of the file.
And the --name
option has no effect on the metadata in the output file. I think you're misinterpreting -metadata:g title= sample.mkv
at the end of the FFmpeg command line that I generate. Notice the space between the =
and sample.mkv
there. I'm not setting the title equal to the filename. I'm setting the title to an empty string. And sample.mkv
is the output filename.
As to the use of "colon options" in the generated FFmpeg command line, these are required for mapping input streams to output streams or designating stream types. And all of that nomenclature is actually in the documentation, although I will admit that documentation is often hard to fathom.
Every command (and app) on the planet that produces output has a way to name that output. It is the definition of "common," so much so it can't even be classified as a "feature." Why would I issue two commands when what I want to do can be done in one? That's silly and user-hostile. And you're neither. :) So we'll agree to disagree.
@vr8hub A fair assessment, sir, on both points. Thank you.
So, would a real --output
option, which could specify a complete path+name+extension combination, be better?
I have been against adding such a feature because it's gotten users of transcode-video
into trouble before. But I am willing to discuss it again.
Well, now we have two issues. (Reminds me of a regex meme…)
The ability to specify an output filename is a standard function of any software that produces output. There should be a way to do that (there is), and the way to do that should be clearly documented (it is and it isn't, hence this issue).
The ability to specify the location of that filename is a little hazier. I would personally say that should be part and parcel of the output filename. Again, I can't think of a piece of software that produces output that doesn't let me tell it where to put the output. I can recollect software that does that with two different parameters, but that's always struck me as making things easier for the programmer rather than the user, and I always side with the user in those situations. (Computers are supposed to make things easier for the people that use them, not the people that program them. I say that as a person who occasionally has to program them.)
What that parameter is called, e.g. name vs output, etc., I have no strong feelings about. -o
and/or --output
are pretty common, but certainly not ubiquitous (e.g. ffmpeg
itself doesn't use them).
Now, then we have users who do dumb things (this set includes me). For example, I initially ran the other-transcode
in the source directory. Before I knew there was a --name
option. Fortunately, you or ffmpeg
or something told me the output filename already existed, and I didn't lose my input file. Which was kind.
And that's what should happen, where possible. If a user specifies the same name for input and output, then kind software will warn them of that before it gets started. Not all software, just kind software. You are (generally) kind and you produce kind software. Yes, I know that resolving input and output filenames can be hairy, but there's software for that. (I had to do something similar once upon a time when I wrote a SQL module that copied the contents of a table from one table to another. I had to jump through all kinds of hoops to make sure that the database/schema/tablename resolved to something different for source and destination.)
If users go out of their way to workaround the kind software and still shoot themselves in the foot, well, then, I don't have a lot of sympathy. "Hey, I told you a) guns are dangerous, b) you shouldn't point them at yourself, and c) you shouldn't pull the trigger if you ignore a) and b). I feel bad for your missing toe, but that's on you." I have done some of that shooting before, and I owned it, I didn't yell at the software maker.
@vr8hub It's other-transcode
that's doing the warning if the output filename is already in use.
But that was a trick question I asked about --output
. My apologies. And that's because specifying a full path+name+extension combination wouldn't work for other-transcode
. In fact, it has exactly the same limitation/problem/bug that the current --name
implementation has now.
You see, the other-transcode
tool allows multiple inputs. So specifying a single output name will work for the first output but fail for any after that.
This is another reason I'm burying the --name
option. :)
(Thanks for the warning, it saved me from having to re-rip Dark Knight!)
Oh my. So. Many. Problems.
Help has…
…
after [FILES]
to communicate that, it didn't work.)This violates "least surprise" in oh so many ways.
I'm going to fall back to the "agree to disagree." :) This is your software, you get to do it the way you want to do it, and we can use it or not. I now know the --name is there, I'm never going to specify multiple inputs, so I'm good to go. Thank you for your patience with an opinionated user. :)
@vr8hub Well, I hate to break it to you but transcode-video
takes multiple inputs and is documented the same way. And the ellipsis is commonly used to document that usage in the --help
output of other tools like grep
, sed
, chmod
, etc.
So, with this being a near-universal idiom for command line tools, I won't be changing that.
As to not documenting what --name
does if multiple inputs are specified, so far nobody—not even any of the project contributors as far as I know—has noticed that or commented to me about the behavior. So, for now, I'm fine with the error message users receive when the second input is processed.
But it does make me seriously consider removing the --name
option altogether because, like you, I like things to be consistent.
Well, I hate to break it to you, but I didn't know that, either. :) So the documentation is two for two in not communicating very well.
The problem isn't with the ellipsis, the problem is with no discussion of multiple inputs anywhere in help or the readme.
You and the project contributors have "the curse of knowledge"; you know too much. (Chip/Dan Heath's Made to Stick relates a story about a tapping test study. The basics are covered here. I am guilty of this several times a day, usually with my wife. But at least now I'm (sometimes) aware of it. :) )
I like things to be logical, easy to use, easy to figure out ("least surprise"), and probably a couple of other things before I get to consistent. Consistency is the least of the issues here. :)
Allowing multiple inputs without allowing multiple outputs is, IMO, a fundamental design flaw. (And I wouldn't fix it by allowing multiple outputs, I'd fix it by not allowing multiple inputs.) Please don't exacerbate that by not allowing the people who don't use multiple inputs to be penalized for that flaw.
I'm sorry I brought the whole thing up. Let's go back to arguing about how bad The Rise of Skywalker was.
@vr8hub If allowing multiple inputs without allowing multiple outputs is a design flaw, then I think we'll have to throw out most command line tools. :)
And, yes, I'll close this now so we can argue about "Star Wars" sequels in a different issue. :)
I realize this is all a matter of opinion, and less is better, and design is all about saying "No", and all the other things.
Nevertheless, I would suggest that "--name" be added to the standard help. I didn't see an option for it when I did
--help
, and I also didn't notice that there were other options for help (more
,full
), because they were at the very end where I wasn't looking for the information. (I piped it to less, so I only read as far as I needed for what I was looking for.) Yes, I'm an idiot, but that's not news, and it's also a common affliction.The output of a rip "normally" (is there anything "normal" about any of this?) contains a track# (Movie_Name_t00), and we rarely/never want that in the transcoded file name. Maybe some/most people rename the ripped file before they do the transcode and this isn't an issue. I don't know, but either way, I don't. So I always want to rename the transcoded file. I don't think that's uncommon. Since that means specifying the name is a commonly used function, I would say that it should be in the most commonly used help, which is the default help.
As with some of my other suggestions, this no longer affects me, since I now know it's there. But I suspect other new users might to have the same problem, and thus having it in the default help would make things more
help
ful for them.On a related note, the
ffmpeg
command-line that's output shows ametadata:g title=<the output filename>
. I've confirmed that the string specified in--name
is also used there. But shouldn't the title be the--name
without the extension, i.e. just "Movie name", not "Movie Name.mkv"? And ffmpeg help indicates the "basic" command line isffmpeg -i infile outfile
, but there's no outfile specified on theother-transcode
generated command line, even with--name
. (I'm just doing a-n
since I've already done the transcode.)(And since I'm here, what are the
:g
and:s:v
and:s:a:0
things on the variousmetadata
options? I've looked at the ffmpeg help and online documentation, and both just reference "metadata string"; I don't see any mention of colon options anywhere.)