[MPlayer-dev-eng] [PATCH]warning about bad timing in a subtitle line

[Ivan Kalvachev]

2005/10/14, Attila Kinali <attila at kinali.ch>:
> On Fri, 14 Oct 2005 10:20:21 +0200
> Adam Tlałka <atlka at pg.gda.pl> wrote:
>
> > Dnia Fri, 14 Oct 2005 09:53:13 +0200, Attila Kinali <attila at kinali.ch>
> > napisał:
> >
> > > Rejected. The warning message is .. err.. shit.
> >
> > What does this mean? Could you explain please.
>
> Have you read the output of your patch?
>
> SUB:23:Huston we have a Problem
>
> If i'd see something like that i would immediately ask
> myself what the heck the one who wrote this crappy
> message meant.
>
> > > Beside, i do not think that anyone is interested in these
> > > warnings. So it shouldn't be a warning but rather a -v or
> > > -v -v message.
> >
> > Why not? If someone wants to have a good subtitle file which has
> > correct timing then he must sometimes correct it by himself.
> > Searching manually through the file to find a bad line
> > is time consuming and should be up to the computer.
> > MPlayer knows which lines have bad timing so it can display
> > a message while it corrects them internally during loading.
>
> Well, MPlayer corrects it already.
> And if you really want to fix your sub files, then you
> should write a perl script that does it. It's
> not only simpler to write it in perl, no it can be even
> written in a way that can cope easily with different
> sub file formats and fix them in a way the user wants it.
>
> IMHO fixing sub files belongs really into a script in the
> TOOLS directory instead of MPlayer.
>
> > Why it is a warning? Because warning means that something is not
> > correct here but we could go over it. Same as a compiler warnings.
> > If all is proper there is no warnings at all.
> > What is broken in this logic?
>
> Oh, quite simple: With a compiler you have code written
> _by_yourself_ and want to see whether it has any problems.
> Not to talk about that you have to explicitly switch these
> warnings on (warnings are nearly completely off by default on
> any compiler i know).
>
> Here we are dealing with files that we got _from_somewhere_else_.
> We do not want to know whether they are correct or not.
> The only thing we care about is whether these files work
> with MPlayer or not.
>
>
> > Anyway I can change the mentioned patch if you insist.
> > This menans only that as MPlayer displays only number of corrected
> > subtitles normaly so to obtain additional info to have knowledge about
> > which are bad line numbers one must start the player again with appropriate
> > option. So more time spent by a user. It's rather inconvenient.
> > That is all and nothing more.
>
> LOL. How many users do READ the MPlayer output ?
> MPlayer is already oververbose so that it is already
> quite hard to see the information that is relevant.
> Adding more messages here is not only, as you put it,
> inconvenient but decreases usability.
>
> If you want to waste your time fixing this patch, be my guest.
> But i see no sense in it and i doubt it will be commited
> by anyone else.
>
> You should rather concentrate your energy on things that matter.

Just to add something.

MPlayer correction may not do the thing you hope.
The problem comes that mplayer supports overlapped subtitles.  It only
correct subtitles that overlap by a little (to prevent visible
flashing with unreadable speed).
Making numerous small correction by hand where they would be nearly
unnoticeable, is not really good way to spend your time.

So I'm also in favour of dropping this patch.

Best Regards
  Ivan Kalvachev
iive