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 585197 - [subparse] fails to detect subrip subtitles with fewer than 3 digits after the comma
[subparse] fails to detect subrip subtitles with fewer than 3 digits after th...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.x
Other Linux
: Normal normal
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-08 21:20 UTC by Kamil Páral
Modified: 2009-06-10 13:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
example of bad subtitles (67.72 KB, application/x-subrip)
2009-06-08 21:21 UTC, Kamil Páral
Details
example of good subtitles (67.12 KB, application/x-subrip)
2009-06-10 11:11 UTC, Kamil Páral
Details

Description Kamil Páral 2009-06-08 21:20:47 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.
Comment 1 Kamil Páral 2009-06-08 21:21:24 UTC
Created attachment 136174 [details]
example of bad subtitles
Comment 2 Bastien Nocera 2009-06-08 21:31:29 UTC
Does it work with playbin or playbin2?

For example:
gst-inspect-0.10 playbin2 uri=file:///fdhfdhj.avi suburi=file:///hjdshjk.sub
Comment 3 Kamil Páral 2009-06-08 21:38:35 UTC
$ 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".
Comment 4 Bastien Nocera 2009-06-08 21:45:51 UTC
Silly me, replace gst-inspect by gst-launch. Sorry.
Comment 5 Kamil Páral 2009-06-08 21:51:35 UTC
"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
$
Comment 6 Bastien Nocera 2009-06-08 21:55:26 UTC
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
Comment 7 Robin Stocker 2009-06-08 22:00:16 UTC
It's the same when you remove the first subtitle (the one with index 0); gst-typefind doesn't recognise it.
Comment 8 Kamil Páral 2009-06-08 22:03:54 UTC
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

Comment 9 Wim Taymans 2009-06-10 11:11:24 UTC
I'll try to improve the typefinder for this variant.
Comment 10 Kamil Páral 2009-06-10 11:11:55 UTC
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).
Comment 11 Tim-Philipp Müller 2009-06-10 13:42:40 UTC
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.