[MPlayer-dev-eng] [PATCH] subtitle reload, slave mode - 2nd try

kiriuja mplayer-patches at en-directo.net
Thu Oct 14 02:37:43 CEST 2004


On Wed 13 Oct 2004 08:42, Salvatore Falco wrote:
> On Wed, Oct 13, 2004 at 07:11:00AM -0400, kiriuja wrote:
> > I would expect the first subtitle file you give MPlayer to have the index 0,
> > the second one to have the index 1, and so on. Is that not the case? A host
> > program should have no problem keeping track of subtitles it passed to MPlayer.
> 
>     Remember the autosubload feature, you can end with MPlayer loading more subs
> than you passed it.

Right, but in that case you wouldn't know the file names either, unless
you copied over the exact autoload algorithm from MPlayer, in which case
you would know the indexes also.

> However, with a clever use of -noautosub switch, it is possible 
> to do what you expect.

And I guess by "clever" you mean "always use it if you want to be in
control of your subtitles", which is what KPlayer does of course, and
I imagine so does KSubtile.

>     If we decide to allow this command to add subs, its name would be changed to,
> for example, sub_manage, or something like that.

Actually after thinking about it some more, instead of sub_manage I would
prefer something like:

sub_add <file> [<index>]

and

sub_remove [<index>]

<index> defaulting to zero of course. And then

sub_reload <file> [<index>]

would be just a shorthand for sub_remove + sub_add, and by the way I would
prefer if it did the sub_add part anyway even if sub_remove failed for
whatever reason.

This would take care of both Load Subtitles and Unload Subtitles cases,
where KPlayer now has to restart MPlayer every time.

>     Its main disavantage is, IMO, it relies on an assumption (the subs are loaded
> and placed sequentially) that is true now, but could be broke in future.

I really cannot imagine why it would have to ever change, especially if your
change relies on it and so makes it a feature rather than just a coincidence.

--
kiriuja




More information about the MPlayer-dev-eng mailing list