[MPlayer-dev-eng] Why does mplayer call ass_flush_events() when seeking?

[Reimar Döffinger]

On Tue, Feb 02, 2016 at 06:10:05PM +0300, Basin Ilya wrote:
> Hi list.
> 
> Do you know why mplayer calls ass_flush_events() when seeking?
> 
>     (gdb) bt
>     #0  ass_free_event (track=0x555557864470, eid=0) at ass.c:142
>     #1  0x00007ffff4ace693 in ass_flush_events (track=0x555557864470) at
> ass.c:985
>     #2  0x0000555555685f5c in seek (mpctx=0x555556e2a880 <mpctx_s>,
> amount=-5, style=0) at mplayer.c:2755
>     #3  0x0000555555689c6a in main (argc=11, argv=0x7fffffffe748) at
> mplayer.c:4016
> 
> I doesn't look right. Instead we should let the events accumulate in the
> track. Libass will handle possible duplicate events.

Maybe duplicate ones. But it would mean that e.g. incorrect ones (too
long duration) would be impossible to get rid of for example.
It also means that seeking is not reproducible (the result of seeking
would always depend on what you played before).
I admit that it is probably to a large degree an artifact of libass
probably not handling it well at some point and might no longer
be truly appropriate, but I do kind of appreciate the reproducible
behaviour aspect at least.