GNOME Bugzilla – Bug 358213
Totem subtitles handling bugs
Last modified: 2012-03-29 12:59:08 UTC
Totem needs support for this enhacements in subtitle handling: - Change subtitle color (some people prefer yellow subs instead of white ones) - Change the subtitle position (up or down), even out of the image (for example, to locate subs on the black borders of a film) - Set delay for subtitles (positive or negative), to adjust bad synchronized subs. - Enhace font rendering: some subtitles appear to be "crispy", for example, italic fonts. - Enable manual selection for subtitles (so the user can select files from another directories) - More flexible subs autodetection: if file is movie.avi, totem should recognize movie.srt, movie.en.srt, subtitles/movie.srt, etc. This could be fixed with manual selection. Thanks, and i hope this could be added to totem.
(In reply to comment #0) > Totem needs support for this enhacements in subtitle handling: > > - Change subtitle color (some people prefer yellow subs instead of white ones) xine-lib doesn't allow for that. It hardcodes XINE_OSD_TEXT1. You can change some bits in ~/.gnome2/totem_config: # palette (foreground-border-background) to use for subtitles and OSD # { white-black-transparent white-none-transparent white-none-translucid yellow-black-transparent }, default: 0 #ui.osd.text_palette:white-black-transparent Not sure how useful this config option is. > - Change the subtitle position (up or down), even out of the image (for > example, to locate subs on the black borders of a film) xine-lib only allows to change the vertical offset: # subtitle vertical offset # numeric, default: 0 #subtitles.separate.vertical_offset:0 Shouldn't it be putting the subtitle in the middle, down the bottom anyway? > - Set delay for subtitles (positive or negative), to adjust bad synchronized > subs. There are subtitle editors that will allow to change that, and I wouldn't be too happy adding this to Totem. > - Enhace font rendering: some subtitles appear to be "crispy", for example, > italic fonts. That's a problem to deal with in the backend. File a bug against GStreamer or xine-lib for that. > - Enable manual selection for subtitles (so the user can select files from > another directories) > > - More flexible subs autodetection: if file is movie.avi, totem should > recognize movie.srt, movie.en.srt, subtitles/movie.srt, etc. This could be > fixed with manual selection. Those 2 last ones are covered by bug #165981
> Totem needs support for this enhacements in subtitle handling: > > > > - Change subtitle color (some people prefer yellow subs instead of white ones) > > xine-lib doesn't allow for that. It hardcodes XINE_OSD_TEXT1. > > You can change some bits in ~/.gnome2/totem_config: > # palette (foreground-border-background) to use for subtitles and OSD > # { white-black-transparent white-none-transparent white-none-translucid > yellow-black-transparent }, default: 0 > #ui.osd.text_palette:white-black-transparent > > Not sure how useful this config option is. > Changing this option on the totem_config file works for the xine backend, but it doesn't work for the gstreamer one. I think totem must have a gui dialog to change color for subtitles, both gstreamer and xine backends. > - Change the subtitle position (up or down), even out of the image (for > > example, to locate subs on the black borders of a film) > > xine-lib only allows to change the vertical offset: > # subtitle vertical offset > # numeric, default: 0 > #subtitles.separate.vertical_offset:0 > > Shouldn't it be putting the subtitle in the middle, down the bottom anyway? > One more time, it works for xine backend, but not for gstreamer. GUI option also recommended. > - Set delay for subtitles (positive or negative), to adjust bad synchronized > > subs. > > There are subtitle editors that will allow to change that, and I wouldn't be > too happy adding this to Totem. > Some other popular players (like mplayer, vlc, or even bsplayer on windows) have this option, which i think is very useful for people watching films with subtitles. > - Enhace font rendering: some subtitles appear to be "crispy", for example, > > italic fonts. > > That's a problem to deal with in the backend. File a bug against GStreamer or > xine-lib for that. > The xine backend shows better subtitles than the gstreamer one. I'll fill the bug. > - Enable manual selection for subtitles (so the user can select files from > > another directories) > > > > - More flexible subs autodetection: if file is movie.avi, totem should > > recognize movie.srt, movie.en.srt, subtitles/movie.srt, etc. This could be > > fixed with manual selection. > > Those 2 last ones are covered by bug #165981 > Great.
Gstreamer textoverlay now has a "shaded-background" property that puts the text inside a conventional black rectangle. This is how I'm used to watch subtitles, it looks more neat I think. Can this be used by totem? All that would be needed is a simple checkbox along with the other subtitles settings.
If #340887 is applied to gstreamer-base then Totem could have support for changing the subtitle color, which in my opinion is one of the big lacks of this great piece of software.
I'll work on changing the "<i>" and "</i>" to turn the subtitles italics. If some one have any pointers on this subject i'd apreciatte... I'm working on Totem version 2.19.4. I could also do some of the GUI stuff, but again, some pointers needed... I just have done something about DVD menu navigation until now.
It's the xine backend who does the subtitle rendering?
(In reply to comment #5) > I'll work on changing the "<i>" and "</i>" to turn the subtitles italics. If > some one have any pointers on this subject i'd apreciatte... I'm working on > Totem version 2.19.4. I believe the GStreamer backend already supports italics, it would be a problem for the xine-lib backend now. See xine-lib/src/libsputext/xine_sputext_decoder.c
Most of the requests are covered in the less generic bug 497130. Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 497130 ***