GNOME Bugzilla – Bug 386504
[decodebin2] should error out on text/plain as primary type
Last modified: 2009-12-03 13:18:29 UTC
+++ This bug was initially created as a clone of Bug #380342 +++ Please describe the problem: Totem does not play mp3 files (I've not tested with other, sorry) when a text file with the same base name as the audio one is present. Totem advices that a subtitle stream has been detected but there is no video. Steps to reproduce: 1. Suppose that you have an mp3 file named "my.song.mp3" 2. Create a text file in the same directory with the name "my.song.txt" 3. Try to reproduce "my.song.mp3" with totem Actual results: An error window will appear advertising that a subtitle stream has been detected but there is no video to reproduce. Expected results: I expect totem to be able reproduce the audio file. Does this happen every time? Yes. Basically, this should work: gst-launch-0.10 playbin uri=file:///path/to/foo.mp3 suburi=file:///path/to/README.txt (if the subtitle-decodebin errors out, playbin will just ignore the subtitle, so either we make decodebin2 error out in this case, just like decodebin, or we add this logic to playbasebin somehow to achieve the same result).
I'm fine with adding this 'hack' because we can't solve this properly because of API compatibility (we can't use a proper caps type for plain text subtitles because it would break compatibility with existing demuxers). This patch should therefore provide BOTH: * The fix for decodebin2 * The addition to gstreamer/docs/design/part-TODO.txt stating we need addition to text/plain to indicate if it is non-parsed text, or parsed text, or timestamped text...
This seems to be working fine. The audio is played and the 'subtitles' stream is ignored. Isn't this the expected behavior?
It is. Looks like Mike fixed this ages ago: commit 277e46886ca911803af8117fbe4f52db66dd2aad Author: Michael Smith <msmith@xiph.org> Date: Thu Nov 20 22:11:38 2008 +0000 gst/playback/gstdecodebin2.c: If the top-level type of the stream is plain text, don't try to decode it, matching beh... Original commit message from CVS: * gst/playback/gstdecodebin2.c: If the top-level type of the stream is plain text, don't try to decode it, matching behaviour of decodebin. * gst/playback/gstplaysink.c: If we fail to generate a text chain (e.g. due to missing optional plugins), don't crash. (Re. comment #1 : this is not a hack, text/plain as e primary type does not describe a subtitle format; it is confusing, however, that we use this type for framed plain text subtitles in some cases where subtitles are embedded in containers; something to change in 0.11)