After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 637586 - playbin2 fails to recognize subtitle caps from katedec
playbin2 fails to recognize subtitle caps from katedec
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.32
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-12-19 16:53 UTC by Vincent Penquerc'h
Modified: 2010-12-21 16:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
playbin2: delay stream-changed messages (4.61 KB, patch)
2010-12-21 10:29 UTC, Vincent Penquerc'h
needs-work Details | Review
playbin2: delay stream-changed messages (5.15 KB, patch)
2010-12-21 16:40 UTC, Vincent Penquerc'h
committed Details | Review

Description Vincent Penquerc'h 2010-12-19 16:53:13 UTC
As discussed with slomo, playbin2 tries to get caps from katedec through inputselector, but fails, as inputselector has no active pad yet.
The sequence of events is:
- katedec gets the first buffer (header), and sets src caps from its contents
- katedec forwards any delayed events (including newsegment events)
- subtitleoverlay tries to get caps from katedec, but fails
Comment 1 Sebastian Dröge (slomo) 2010-12-19 17:04:34 UTC
Reason for this is the code in gstplaybin2.c around line 2733, which sends a sink-message event downstream *after* the subtitle inputselector and this event is causing the subtitleoverlay to block. Unfortunately the subtitle input selector did not get a newsegment event yet and as such did not select a active sinkpad yet, causing the get_caps/get_negotiated_caps calls in subtitleoverlay to return ANY.

One solution might be to delay the sink-message events to the selector_blocked callback in playbin2, which is called when the selector gets unblocked (i.e. got an event) (and this will also cause the events to be sent from the corresponding streaming threads).

OTOH the sink-message events should probably be sent immediately after the newsegment event to allow correct synchronization in the sink.
Comment 2 Vincent Penquerc'h 2010-12-21 10:29:14 UTC
Created attachment 176815 [details] [review]
playbin2: delay stream-changed messages
Comment 3 Sebastian Dröge (slomo) 2010-12-21 16:25:41 UTC
Review of attachment 176815 [details] [review]:

Looks good in general, just some cosmetic/minor things, after that I'll push this change :)

::: gst/playback/gstplaybin2.c
@@ +2323,3 @@
 
+static gboolean
+event_data_probe (GstPad * pad, GstMiniObject * object, gpointer data)

Maybe call it stream_changed_data_probe. It's not really an event data probe

@@ +2344,3 @@
+    /* push the event first, then send the delayed one */
+    gst_event_ref (GST_EVENT (object));
+    gst_pad_send_event (pad, GST_EVENT (object));

Please cast with GST_EVENT_CAST() here. You already know that it is an event :)

@@ +2797,3 @@
+
+        /* remove any data probe we might have, and replace */
+        select->sinkpad_delayed_event = event;

You'll be leaking any previously set event here. To be on the safe side unref any events here first

Maybe also add a comment here why we're not sending the event directly but defer it to the data probe (1: send it from the correct streaming thread, 2: pushing the event could block, leading to a deadlock, 3: things might not be linked correctly yet, after the data probe is called it will)
Comment 4 Vincent Penquerc'h 2010-12-21 16:40:01 UTC
Created attachment 176843 [details] [review]
playbin2: delay stream-changed messages

With requested changes.
Comment 5 Sebastian Dröge (slomo) 2010-12-21 16:43:33 UTC
Great, thanks :)

commit f221466099b9193fb737cafc6bde1195aaeec06a
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Tue Dec 21 10:26:40 2010 +0000

    playbin2: delay stream-changed messages
    
    https://bugzilla.gnome.org/show_bug.cgi?id=637586