GNOME Bugzilla – Bug 585197
[subparse] fails to detect subrip subtitles with fewer than 3 digits after the comma
Last modified: 2009-06-10 13:42:40 UTC
Totem fails to load any SubRip (*.srt) subtitles, which are indexed from 0. Most of the subtitles are indexed from 1 (I don't know if the specification requires it), but some subtitles are indexed from 0. See the attached file and look at the first line (index is 0). VLC plays such subtitles fine. Totem doesn't. Even if the format would not be perfectly correct, Totem should be able to play it, because it is quite common and users don't know why the subtitles doesn't show up. Try the attached file, it is not possible to show these subtitles in Totem. If you use gnome-subtitles (or similar tool) to recount the indices starting from 1, it plays fine.
Created attachment 136174 [details] example of bad subtitles
Does it work with playbin or playbin2? For example: gst-inspect-0.10 playbin2 uri=file:///fdhfdhj.avi suburi=file:///hjdshjk.sub
$ gst-inspect-0.10 playbin2 uri=file:///home/ripper/videa/HOME/HOME.mp4 suburi=file:///home/ripper/videa/HOME/HOME.srt No such element or plugin 'suburi=file:///home/ripper/videa/HOME/HOME.srt' The same with "playbin".
Silly me, replace gst-inspect by gst-launch. Sorry.
"playbin" plays fine, but no subtitles are present. $ gst-launch-0.10 playbin uri=file:///home/ripper/videa/HOME/HOME.mp4 suburi=file:///home/ripper/videa/HOME/HOME.srt Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstAudioSinkClock ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 4583582060 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... $ "playbin2" doesn't play at all. $ gst-launch-0.10 playbin2 uri=file:///home/ripper/videa/HOME/HOME.mp4 suburi=file:///home/ripper/videa/HOME/HOME.srt Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin1/GstDecodeBin2:decodebin20: This appears to be a text file Additional debug info: gstdecodebin2.c(1425): type_found (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin1/GstDecodeBin2:decodebin20: decodebin2 cannot decode plain text files ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... ^CCaught interrupt -- ^C $
Probably the same bug, just that playbin1 ignores the unhandled subtitle (should playbin2 do the same?) My guess is a bug in the typefinding: $ gst-typefind /home/hadess/Desktop/HOME.srt /home/hadess/Desktop/HOME.srt - text/plain
It's the same when you remove the first subtitle (the one with index 0); gst-typefind doesn't recognise it.
Now I know where's the difference. It's not in the index. It's in the timing. This is recognized: 00:01:28,400 --> 00:01:31,000 And this is not: 00:01:28,4 --> 00:01:31,0
I'll try to improve the typefinder for this variant.
Created attachment 136266 [details] example of good subtitles Just for completeness, I attach a recognized version of the same subtitles. The bad one were opened in gnome-subtitles and resaved. The difference is in index (starting with 1) and in time format (milliseconds at 3 decimal place precision).
Should be fixed now, thanks for the bug report: commit 40bea96ff60c20207c2c54125e12730fa4f24958 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Wed Jun 10 14:37:36 2009 +0100 subparse: recognise more subrip timestamp variants Be even less restrictive in what we accept for .srt timestamps when typefinding and parsing subrip subtitles and add a unit test for the 'new' format. Fixes #585197.