GNOME Bugzilla – Bug 606744
Totem fails to play video file: "Can't display both text subtitles and subpictures."
Last modified: 2010-02-09 09:55:06 UTC
media-video/totem-2.28.5 Totem shows an error occurred dialog with: "Can't display both text subtitles and subpictures." Following is displayed on console: [snip] ** Message: Error: Can't display both text subtitles and subpictures. gstplaysink.c(2175): gst_play_sink_reconfigure (): /GstPlayBin2:play/GstPlaySink:playsink0: Have text pad and subpicture pad [/snip] File plays ok with mplayer: [file] File size is 254815695 bytes LAVF_check: Matroska file format Checking for YUV4MPEG2 ASF_check: not ASF guid! Checking for REAL Checking for SMJPEG [mkv] Found the head... [mkv] + a segment... [mkv] /---- [ parsing seek head ] --------- [mkv] /---- [ parsing seek head ] --------- [mkv] \---- [ parsing seek head ] --------- [mkv] /---- [ parsing cues ] ----------- [mkv] \---- [ parsing cues ] ----------- [mkv] /---- [ parsing chapters ] --------- [mkv] Chapter 0 from 00:00:00.000 to 00:00:00.000, Prologue [mkv] Chapter 1 from 00:00:53.587 to 00:00:00.000, Open [mkv] Chapter 2 from 00:02:21.641 to 00:00:00.000, Chapter 1 [mkv] Chapter 3 from 00:12:39.325 to 00:00:00.000, Chapter 2 [mkv] Chapter 4 from 00:23:45.591 to 00:00:00.000, Close [mkv] \---- [ parsing chapters ] --------- [mkv] \---- [ parsing seek head ] --------- [mkv] |+ segment information... [mkv] | + timecode scale: 1000000 [mkv] | + duration: 1548.318s [mkv] |+ segment tracks... [mkv] | + a track... [mkv] | + Track number: 1 [mkv] | + Track type: Video [mkv] | + Default flag: 1 [mkv] | + Codec ID: V_MPEG4/ISO/AVC [mkv] | + CodecPrivate, length 43 [mkv] | + Default duration: 33.367ms ( = 29.970 fps) [mkv] | + Language: eng [mkv] | + Video track [mkv] | + Pixel width: 720 [mkv] | + Pixel height: 480 [mkv] | + Display width: 720 [mkv] | + Display height: 480 [mkv] | + a track... [mkv] | + Track number: 2 [mkv] | + Track type: Audio [mkv] | + Default flag: 1 [mkv] | + Codec ID: A_AAC [mkv] | + CodecPrivate, length 2 [mkv] | + Default duration: 21.333ms ( = 46.875 fps) [mkv] | + Language: jpn [mkv] | + Audio track [mkv] | + Sampling frequency: 48000.000000 [mkv] | + Channels: 2 [mkv] | + a track... [mkv] | + Track number: 3 [mkv] | + Track type: Audio [mkv] | + Default flag: 0 [mkv] | + Codec ID: A_AAC [mkv] | + CodecPrivate, length 2 [mkv] | + Default duration: 21.333ms ( = 46.875 fps) [mkv] | + Language: eng [mkv] | + Audio track [mkv] | + Sampling frequency: 48000.000000 [mkv] | + Channels: 2 [mkv] | + a track... [mkv] | + Track number: 4 [mkv] | + Track type: Subtitle [mkv] | + Default flag: 1 [mkv] | + Codec ID: S_TEXT/ASS [mkv] | + CodecPrivate, length 1111 [mkv] | + Language: eng [mkv] | + Name: ASS [mkv] | + a track... [mkv] | + Track number: 5 [mkv] | + Track type: Subtitle [mkv] | + Default flag: 0 [mkv] | + Codec ID: S_TEXT/UTF8 [mkv] | + Language: eng [mkv] | + Name: SRT [mkv] | + a track... [mkv] | + Track number: 6 [mkv] | + Track type: Subtitle [mkv] | + Default flag: 0 [mkv] | + Codec ID: S_VOBSUB [mkv] | + CodecPrivate, length 348 [mkv] | + Language: eng [mkv] | + Name: IDX [mkv] |+ found cluster, headers are parsed completely :) ==> Found video stream: 1 [mkv] Aspect: 1.500000 [mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0 ==> Found audio stream: 2 [mkv] Track ID 2: audio (A_AAC), -aid 0, -alang jpn ==> Found audio stream: 3 [mkv] Track ID 3: audio (A_AAC), -aid 1, -alang eng [mkv] Track ID 4: subtitles (S_TEXT/ASS) "ASS", -sid 0, -slang eng [mkv] Track ID 5: subtitles (S_TEXT/UTF8) "SRT", -sid 1, -slang eng [mkv] Track ID 6: subtitles (S_VOBSUB) "IDX", -sid 2, -slang eng [/file info]
Got a test file?
Example file: http://store20.com/totem-fail.mkv PS. It is ~250 megabytes
This looks like a duplicate of bug #591662. However, at least one of the streams doesn't render properly, which looks like a problem with texoverlay, and switching between them or seeking leads to many-second delays, so you may want to move this to gst-plugins-base.
(In reply to comment #3) > This looks like a duplicate of bug #591662. However, at least one of the > streams doesn't render properly, which looks like a problem with texoverlay, > and switching between them or seeking leads to many-second delays, so you may > want to move this to gst-plugins-base. Possibly yes, I tried to apply the patch, but it didn't apply straight on top of 0.10.25 so it'll take a bit to confirm.
Yes, there definitely is still a problem with subtitles, at least with this file here. Not sure what causes it though...
I have no idea whether the following is related to this, but I recently noticed that subtitleoverlay sets textoverlay's wait-text property to FALSE. AFAIK, having this to default TRUE is typically needed to ensure proper rendering. The effects of this may be limited with typical long-duration subtitles, but could be more pronounced (as in: no subtitles) in other cases (e.g. if (ASS) subtitles come in shorter fragments, as in clip in bug #604131).
Mark, if wait-text is set to TRUE, textoverlay will wait for text buffers before rendering the video IIRC. Because subtitle streams are sparse this will lead to a forever waiting textoverlay. Also this property was always set to FALSE in textoverlay for subtitles by playbin2, even before I introduced subtitleoverlay. This commit here fixes disabling of subtitles at least, other things are still not perfect: commit 3b842bc98b73a568f0fab91624b9549c415e16ba Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Jan 14 13:36:23 2010 +0100 playsink: Fix disabling of subtitles if subtitles were used before In this case the video still goes through the text chain and subtitles are still going in there, in case subtitles are enabled again. This makes sure that re-enabling subtitles happens instantly. Fixes hanging video when disabling subtitles, caused by an unliked video pad.
I think I never fully understood the rationale for using wait-text=FALSE here. Which elements don't send newsegment updates and can't be fixed to do so?
Ok, so after some more testing the remaining problem is only seeking it seems. And this is also a problem if subtitles are disabled. Any ideas what could be the cause? :)
Created attachment 152508 [details] [review] Fix newsegment bridging stream gaps AFAICS, the gap filling and stream synchronization interacted badly here, leading to newsegment events with start_time going back and forth, leading to increasing accum time (and derived running_time). This patch remodels gap filling somewhat, and should also take care of seeking here. [btw, I have a few other minor patches w.r.t. stream synchronization, but this sort-of fits here as it fixes the seeking]
Comment on attachment 152508 [details] [review] Fix newsegment bridging stream gaps Let's put this into the next pre-release, since it actually fixes something :)
*** Bug 608671 has been marked as a duplicate of this bug. ***
commit b527360f21f426cb4853fc6d4fa48d1c51a012af Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Thu Jan 28 18:53:18 2010 +0100 matroskademux: fix bridging (time) gaps in streams As a side effect, avoid sending newsegment updates with start times that go back and forth, which leads to bogus downstream running_time. Also fixes seeking in bug #606744.