GNOME Bugzilla – Bug 518709
GStreamer backend - MicroDVD subtitles
Last modified: 2008-02-25 23:18:44 UTC
Hello, There is a small issue with MicroDVD subtitles on GStreamer backend. GStreamer subtitles parser is not able to read the FPS from the movie file (subparser element does not have access to FPS data). This is clearly an issue on the GStreamer side, but fixing this can take some time (a bigger patch). Totem player can fix the issue easily - when loading a file, just get the FPS number from the movie and then put the number on the beginning of the subtitle file: {1}{1}25.000 GStreamer reads FPS from this line, if it won't find it, it uses hardcoded 23.976. On some movies this don't work properly and you need to manually add this line. I'm submitting this bug as an enchancement, because it's not the bug on the Totem's side (but fixing this won't cause any regression). GStreamer won't fix this bug shortly (mayble I'll try to work on it and send them a patch), but in Totem it can be done easily. Or maybe should Totem support its own subtitle engine? So it can create nice looking unscaled subtitles for both (xine and gst) engines. It could be better for Xine - it does not use Pango, so the font selection dialog on xine engine doesn't work properly in Totem.
Totem isn't in the business of reading subtitle files directly.
Also, I have already explained my opinion on this in bug #518709 - using the fps of the movie is not any more correct than using a random default value (it just happens the default doesn't work so well for you), also it's very messy and racy to implement (external subtitles will be prerolled before the video). As I said, I'd accept an addition to subparse that reads the default from an environment variable.
I am sorry, but I've posted this bug because MPlayer, ffdshow and Xine are using movie's FPS or current frame to decode subtitle - *every* other engine is displaying the subs properly without adding {1}{1}FPS to the sub file - the same subs are working even for movies encoded in different frame rate. So, if every engine is doing this properly (only GStreamer have problems) IMHO it is the problem with GST. I've posted this bug here, because adding this line could be a little workaround. I've also noticed that ffdshow, mplayer and xine are using the same way to decode subs. But every Linux media player have issues - Xine is best with sub handling and media compatibility (DVD menu) - but seeks *very* slow when subs are enabled, no matter if unscaled or not. MPlayer is the fastest one (I can play Apple HD trailers with MPlayer, GStreamer seems to need more CPU - I am playing the same file), but have a ugly gui (some people prefer not skinnable, like totem, which is imho best) and, like Xine, doesn't format subtitles. GStreamer uses Pango - it formats subs very well, but AFAIK doesn't support unscaled subs and have problems with handling mdvd. So it forces many people to convert the subs to another format, use other player or add FPS line by hand to the sub file. That's why I've compared it to Windows - Windows players handle subs on themselves (Polish players for example, like SubEdit), or if the subs are rendered by engine, they are timed properly. IMHO you should look at SubEdit's capabilities (http://subedit.com.pl/) - it uses own (not ffdshow's) sub engine, it is very flexible - you can do everything you want with the movie - rescale it in real-time, change sub position in real-time, resize subs, rescale movie, change the movie play speed, load subtitles on demand (File->Open Subtitles) etc etc. It even uses separate configuration for each file you've played - so if you will start playing this file again, it will start from previous position with previous settings (so for movie X you will have subs on the top, for movie Y you will have TWO subtitle streams at one time - one on the top (english), second one on the bottom (polish)). That's why I've been posting these bugs, because I want to make Totem & GST at least comparable to Subedit (at least if it comes to proper sub handling). > As I said, I'd accept an addition to subparse that reads the default from an > environment variable. What env variable you are talking about?