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 660233 - DVB subtitles stop being rendered
DVB subtitles stop being rendered
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.22
Other Linux
: Normal normal
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-27 09:19 UTC by Tvrtko Ursulin
Modified: 2012-07-10 16:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Hacky workaround patch (579 bytes, patch)
2011-09-28 15:42 UTC, Tvrtko Ursulin
none Details | Review

Description Tvrtko Ursulin 2011-09-27 09:19:31 UTC
Occasionally and rarely when playing DVB-T/S MPEG transport streams with subtitles, they can stop being rendered indefinitely. When it happens I still see dvbsuboverlay logging new subtitles arriving and feeding them to libdvbsub, or in other words I see no difference in log output between when subtitles are displayed and when they are not.

Since it is very difficult to reproduce this with a live stream, the thing I noticed is that same thing can happen when seeking in a recorded stream.

I have a ~100Mb test stream which when played with gst123 and seeking a bit you can get from one state into another and vice versa.
Comment 1 Tvrtko Ursulin 2011-09-28 15:42:19 UTC
Created attachment 197685 [details] [review]
Hacky workaround patch

From my limited understanding of what is happening inside: There is a queue of pending subtitles and a callback called periodically whose job is to render them at correct time.

After a seek one or more subtitles at the top of the pending queue get their timestamps modified to 0xFFFFFFFFFFFFFFFF.

I don't really understand the mechanism behind that(*) , but what I have tried is to just skip those (delete them from the queue) and that hack seems to work. It can lose a few subtitles but that is better than them stopping forever.

Also, what would happen before the patch is that queue would grow indefinitely since it was blocked by an impossible timestamp at the top.

*)
Maybe somewhere in code someone tries to re-timestamp those and messes up? Because on seek I see running time stamp go back from zero, so I can only assume subtitle timestamps received before the seek have to be adjusted, I just do not see where is that done.
Comment 2 Mart Raudsepp 2011-12-10 06:39:29 UTC
0xFFFFFFFFFFFFFFFF == GST_CLOCK_TIME_NONE == (unsigned int) -1

So new_dvb_subtitles_cb is called with subs->pts set to GST_CLOCK_TIME_NONE or -1.
This originates from deeper interaction with dvb-sub.c through callbacks, but basically gstreamer side gives the pts that is stored in the subtitle structures with the call to dvb_sub_feed_with_pts() via gst_dvbsub_overlay_process_text().
This usage comes with a FIXME comment from me:

/* FIXME: We are abusing libdvbsub pts value for tracking our gstreamer running time instead of real PTS. Should be mostly fine though... */

Apparently it isn't completely fine then :(
It would be GST_CLOCK_TIME_NONE or -1 if the gst_segment_to_running_time call is returning it, and it can return -1 per documentation if the position is outside of segment start and stop.
So I suspect we should be dropping it there already then, not push it to the GQueue via _process_text(), but I'd need to think a bit further regarding the segments handling.
Comment 3 Jaroslav Klaus 2012-02-04 15:53:30 UTC
Maybe I'm also facing similar issue.

I'm using simple playbin2 to play sample stream (http://hell.sh.cvut.cz/mg/ch-yes2-2.ts) stored on local FS. When I change subtitle track using current-text and glib_timeout_add subtitles never appear anymore quite often (>50%) but not always. You can try to change track at 2.8sec. May be you will need to start the playback several times or try to move the changing time slightly (+-0.1sec).
Comment 4 Jaroslav Klaus 2012-02-04 21:43:42 UTC
btw hacky workaround patch seems working although it usually needs few seconds to render new subtitles.
Comment 5 Tvrtko Ursulin 2012-06-12 09:12:03 UTC
In absence of a better fix, could this workaround be upstreamed? I don't see that it can have any bad side effects so I think it is safe.
Comment 6 Mark Nauwelaerts 2012-07-10 16:07:13 UTC
The appropriate way to deal with subtitles and segments IMO is to first decode the subtitle whether or not in segment, since it may contain data needed by subsequent in-segment subtitles, and it may partially fall in the segment (depending on the decoded/parsed page time out).

When decoded, the page time out then allows to decide whether it can be discarded altogether or is still partially useful.

Following commit applies this approach and should then also avoid ->pts ending up with GST_CLOCK_TIME_NONE (-1) (which is where the problems basically come from):

commit ba0448111d18b7fda9630a156e3c56ea6fa1c1cd
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Tue Jul 10 11:25:30 2012 +0200

    dvbsuboverlay: ensure valid subtitle running time by proper clipping
    
    In particular, pass buffer timestamp (pts) to dvb_sub, and then clip
    and convert to running time when the duration (timeout) is known after
    decoding it.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=660233