[MPlayer-dev-eng] [PATCH] Subtitle display is based on audio - should be video
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Sat Oct 2 19:37:22 CEST 2010
On Sat, Oct 02, 2010 at 07:19:14PM +0200, gillou.ray at free.fr wrote:
> > > You can easily produce the bug giving a -delay option to a subtitled
> > > movie. I tested various combinations of demuxers and files. The bug
> > > happens when :
> > > - ass rendering is disabled
> > > - subtitles are packed in a container (not red from a text file)
> > > - with both ffpmeg and mplayer mkv demuxer, and ffmpeg ogg demuxer
> > > - with muxed ASS or SRT
> >
> > I have to admit that this inconsistency is not so good though.
>
> It's quite confusing indeed, that's why I actually got it all wrong.
> What I was thinking to be the correct way is a bug, and the "regular
> way" (i.e. everything that doesn't match the above list) is buggy. Even
> the good old -sub file.srt is video synced.
Unfortunately it is not quite as easy.
Mainly the thing that happened is
0) Nobody really considered the -delay case much (it still does not
generally work right, to a degree necessarily).
1) If you disregard the delay case, audio, video, ... time will all
be the same, if not things are already unwatchable anyway
2) So everyone when implementing distinct parts just grabbed whichever
time was available. For ASS, since it is a video filter that is
the video time stamp (except when we do not have any, I suspect then
it is actually generated from the "real"/audio time). It also has
the advantage that it would work better if frames at some point
would be buffered after the filter chain.
For a lot of the other code, it is the the other timer that is more
available (though actually in most cases I think it might be easy
to change).
Mostly this issue is a lack of proper design. Fixing it tends to be
a lot of work with few immediate advantages and many new bugs,
so it usually isn't done, at least not in the short term.
More information about the MPlayer-dev-eng
mailing list