[MPlayer-dev-eng] [SURVEY] change mencoder's default ofilename extension?

The Wanderer inverseparadox at comcast.net
Tue Nov 29 19:41:53 CET 2005


Oded Shimon wrote:

> On Tue, Nov 29, 2005 at 12:15:20PM -0500, The Wanderer wrote:
> 
>> ...okay, now that I think about it, this doesn't even make sense as
>>  being related to the problem under discussion. The problem is not
>> "people give a file extension with -o which doesn't match the
>> container format they've requested" (although that is *a* problem),
>> the problem is that "when people don't give a '-o' option at all,
>> but *do* specify a non-AVI container format, the file extension is
>> wrong".
>> 
>> Unless you mean "giving no output file" to be semantically
>> equivalent to "giving the output file 'test.avi'", I don't see how
>> the two problems can be conaidered directly related. Yes, it would
>> be good to fix both, but fixing the former would not by itself fix
>> the latter.
> 
> I do consider them equivalent, and i think my patch fixes both
> problems. Actually, I don't even consider the first one a problem.
> Someone does '-of mpeg' and gets a 'test.avi', he knows it's an mpg
> file since he expliticly asked, especially now with the big loud
> warning, and can rename it to 'test.mpg' himself...

However, the problem which the thread was discussing is the one which
you don't consider to be a problem. If you think that your proposed
solution to another problem makes the problem at hand moot, then you can
certainly argue that.

I think that your suggested patch fixes the problem you're aiming it at,
but counts as (at best) no more than a fairly ugly workaround for the
problem which was actually being discussed. I would really prefer
something which fixes both problems.

> Only thing for me left undecided in the patch is the loud warning, I
> think it's not loud enough give mencoder's... verbosity. Maybe pad it
> with '\n' so it has it's own special line?.. I think that's noticable
> enough.

...if it appears after the encoding is finished, which is what would
make sense to me, I don't think it needs to be exceptionally loud.
Still, this isn't really my bailiwick.

> Regarding your other remark - having the muxer choose the file
> extention isn't feasible either. muxer_mpeg has several extentions
> ("mpg", "mpeg", "vob"), muxer_lavf has many many more possible
> extentions, and the idea involves changing user's input which imo is
> just wrong.

Of course there are multiple valid extensions for some formats, but
surely choosing *one* of the known valid extensions is better than
leaving an unrelated and invalid extension in place.

And muxer_lavf can determine which format to append a default extension
for based on the format which was requested by '-lavfopts format='; if
there *was* no such option specified, then there *would* indeed be
nothing to do but fail out.

Note that I am *not* suggesting overriding the filename if the user
*does* specify a -o option. I am speaking only of the case where the
user does *not* specify a -o option. If that isn't what you were
thinking of when you made your final comment, above, then I don't know
what you were finding objectionable.

> I'm doing the "\n" pad thing and committing in a few days.. speak now
> or forever hold your peace?

Well, for one thing your patch assumes that the extension it is trying
to detect will always be lowercase, which is not necessarily valid. For
that matter, what happens with your patch if someone specifies an output
filename which *has* no extension, and thus does not contain a period?
Or if someone specifies an output filename which contains multiple
periods? (I've done a few of the latter myself.)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.




More information about the MPlayer-dev-eng mailing list