[Bug 638168] textoverlay: don't return wrong-state when stopping while in text chain
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Tue May 15 08:25:21 PDT 2012
https://bugzilla.gnome.org/show_bug.cgi?id=638168
GStreamer | gst-plugins-base | unspecified
Andre Moreira Magalhaes <andrunko> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #214010|0 |1
is obsolete| |
--- Comment #34 from Andre Moreira Magalhaes <andrunko at gmail.com> 2012-05-15 15:25:19 UTC ---
Created an attachment (id=214114)
View: https://bugzilla.gnome.org/attachment.cgi?id=214114
Review: https://bugzilla.gnome.org/review?bug=638168&attachment=214114
gstplaysink: Re-sync queue after sending flush-stop.
(In reply to comment #31)
> Review of attachment 214010 [details]:
>
> ::: gst/playback/gstplaysink.c
> @@ +633,3 @@
> +
> + _playsink_reset_segment_event_marker_id =
> + g_quark_from_static_string ("gst-playsink-reset-segment-event-marker");
>
> Please do this in class_init, only has to be done once
Done
> @@ +1895,3 @@
> + if (format != GST_FORMAT_TIME) {
> + GST_ERROR_OBJECT (pad, "Newsegment event in non-time format: %s",
> + gst_format_get_name (format));
>
> You should not ignore non-TIME segments here but just handle all formats
> equally
Done
> @@ +1933,3 @@
> +
> + /* make queue drop all cached data.
> + * This event will be dropped inside subtitleoverlay. */
>
> I think it would be cleaner to send the event from outside subtitleoverlay and
> also drop them from outside subtitleoverlay. This way we now have a quite
> weird, asymmetric interaction between playsink and subtitleoverlay. Letting it
> go through subtitleoverlay has no negative side effects because we update the
> segments afterwards again. (also, isn't subtitleoverlay flushing itself
> anyway?)
Done. The event is being handled completely inside playsink now and the events
marked will never leave the playsink:tbin.
--
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.
More information about the gstreamer-bugs
mailing list