[Bug 638168] textoverlay: don't return wrong-state when stopping while in text chain

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=638168
  GStreamer | gst-plugins-base | unspecified

--- Comment #32 from Sebastian Dröge <slomo at circular-chaos.org> 2012-05-15 08:11:14 UTC ---
(In reply to comment #30)
> This last patch I attached at comment 29 reduces the delay when switching
> subtitles, but it still takes too long.
> 
> For example, switching the subtitles at video from Comment 6 at 6s makes the
> subtitles disappear and only appear again at 14s, that's a lot.
> 
> What happens from input-selector:
> 
> 0) Subtitle-0 is active, pushing buffers (there is a buffer already at
> textoverlay, another stored at subqueue and another one blocked while waiting
> to enter the subqueue, so input-selector is always 3 buffers behind)
> 1) Subtitle-0 buffer pushed with ts=11s
> 2) Switch to subtitle-1 (video on screen is still at 6s)
> 3) Subtitles disappear at screen
> 4) input-selector closes the current segment by pushing a newsegment with
> start=14s *
> 5) subtitle-1 pushes a buffer with ts=11s (gets dropped at textoverlay)
> 6) subtitle-1 pushes a buffer with ts=14s (rendered, finally!)
> 
> 
> * The stream closes at 14s when switching because oggdemux sends some kind of
> synchronization newsegment and input selector keeps that event.

I don't see an apparent solution for 0.10 (but for 0.11). What's the
filler/update segment that is sent by oggdemux? Does it really advance the
running time to 14s already?

The segments could be adjusted a bit in subtitleoverlay maybe, changing them
for the elements inside the accept new text buffers that happen at the current
video time (and before the segment start as given by oggdemux). But this would
become even more hackish then

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.