Re: Why does mplayer call ass_flush_events() when seeking?
Reimar Döffinger <[email protected]>
| Newsgroups | gmane.comp.video.mplayer.devel |
|---|---|
| Message-ID | <[email protected]> |
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. _______________________________________________ MPlayer-dev-eng mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng