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

[Oded Shimon]

On Tue, Nov 29, 2005 at 01:41:53PM -0500, The Wanderer wrote:
> 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.

IMO this patch 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.

Well, the whole idea was to prevent the stupid user wasting his time 
encoding a file '-o file.bla' and being surprised only at the END that it's 
not a "bla" file. So, it has to be in the begginning, not the end.

> >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.

OK, how about this idea, if the file is "test.avi", and -of mpeg was 
chosen, output "test.mpg" by default. it has the small advantage of 
overriding an explicit 'test.avi', but it would be silly to explicitly ask 
"-o test.avi -of mpeg". This is in addition to my patch, as it doesn't 
solve the other problem.

> 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.)

About lowercase, easy fix by changing to 'strcasecmp'. (can anyone testify 
on it's portability? I think it should be ok..)

About 'no extention' and 'double extention', you obviously didn't read the 
e-mail I JUST send! I explained exactly how it was treated!

file.avi => "avi"
file.mpg.avi => "avi"
file. => ""
file => "file"

Do you still have objections? Can I commit?

- ods15