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 386504 - [decodebin2] should error out on text/plain as primary type
[decodebin2] should error out on text/plain as primary type
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 380342
Blocks:
 
 
Reported: 2006-12-16 14:06 UTC by Tim-Philipp Müller
Modified: 2009-12-03 13:18 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Tim-Philipp Müller 2006-12-16 14:06:46 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).
Comment 1 Edward Hervey 2007-08-03 14:42:22 UTC
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...
Comment 2 Thiago Sousa Santos 2009-12-03 12:55:07 UTC
This seems to be working fine. The audio is played and the 'subtitles' stream is ignored. Isn't this the expected behavior?
Comment 3 Tim-Philipp Müller 2009-12-03 13:18:29 UTC
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)