GNOME Bugzilla – Bug 633466
[katedec] Pushes events before the final caps are known
Last modified: 2010-12-27 10:57:02 UTC
WARNING: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:tbin/GstSubtitleOverlay:suboverlay: Internal GStreamer error: negotiation problem. Please file a bug at http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer. Additional debug info: gstsubtitleoverlay.c(736): _pad_blocked_cb (): /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:tbin/GstSubtitleOverlay:suboverlay: Subtitle sink is blocked but we have no subtitle caps This happens if the peer of the subtitleoverlay pad doesn't give any caps on get_negotiated_caps() or doesn't give fixed caps on get_caps() although a buffer or newsegment event arrived already.
Ok, working on it now. That's easy to fix.
Not, not easy to fix. The bug is in katedec in bad. The problem is, that it pushes events before the final tags are known. And it can't be easily fixed because the final tags are only known after the first subtitle buffer arrived... and this could be 1000 hours into the file, which would let the pipeline stall. No idea how to fix this, attached is a patch that caches events and tags but for the above reason it doesn't work with Sintel.
Created attachment 173509 [details] [review] katedec: Only push events downstream when the final caps are known See bug #633466.
This looks like part of what this patch does: https://bugzilla.gnome.org/attachment.cgi?id=153537&action=diff Any chance the patches in https://bugzilla.gnome.org/show_bug.cgi?id=600929 could be looked at, if they were merely unnoticed ? I was waiting for feedback as I was (and still am) not at east with gst, and very unsure if I was heading in the right direction.
Nevermind, these patches seem to have rotted since I posted them, and were ignored anyway, so strike my last comment.
Maybe what we can do is look at the category in the header and just either set pango markup caps or subpic caps on the sink pad depending on that. I'll try that later. > [T]hese patches ... were ignored anyway I don't think they were (actively) ignored, it's just that no one has had time to look at them closely enough yet. That's a bit unfortunate of course given how long it's been, but segment handling here is not entirely trivial, and there's just so much other stuff, and it's easy to overlook/forget about some patches. Maybe you could post a ping on the bug every now and then to attract attention to it. (Anyway)
Sorry, I do realize there's a lot of more important things to do in too little time :) It's just that I was very unsure of what I was doing with that segment handling code, and wanted to get feedback before working more on it. I'll just wait till slomo's patch is in, then post updated patches, I guess.
(In reply to comment #6) > Maybe what we can do is look at the category in the header and just either set > pango markup caps or subpic caps on the sink pad depending on that. I'll try > that later. What do you mean by category in the header? Note that you can't change the caps from pango markup to plaintext or the other way around unless you use a real getcaps function on the srcpad. (In reply to comment #7) > Sorry, I do realize there's a lot of more important things to do in too little > time :) It's just that I was very unsure of what I was doing with that segment > handling code, and wanted to get feedback before working more on it. > I'll just wait till slomo's patch is in, then post updated patches, I guess. ...and Tim's patch to extract the type from the header :) I'll take a look at your patches this evening and give you some feedback about the segment handling. I planned to look at them ages ago already but forgot about it for some reason. Sorry for that.
Thanks much. As for the markup/plaintext switch, the category can't distinguish, but there's a markup type in the header that's already used to set caps on the buffers (see gbbolean plain in gstkatedec.c). It sounds like I'd need one of these getcaps functions, so I'll look around to see if I can find another element that does something similar to see how that's used.
We don't necessarily have to distinguish between plain text and markup. We could just always output markup and escape plain text as needed. With category I mean this in the header: http://wiki.xiph.org/OggKate#Category_definition (plus legacy version) - we already use this to determine the kate caps in oggdemux.
Fixed by https://bugzilla.gnome.org/show_bug.cgi?id=600929 and https://bugzilla.gnome.org/show_bug.cgi?id=637822