[MPlayer-dev-eng] [patch] RT subtitle timestamp parsing buggy

[hhaamu at gmail.com]

Hi

The subtitle parser for .rt subtitles fails on hh:mm:ss and hh:mm:ss.ff
type of timestamps and generally thinks they should all be displayed on
the 0-second mark. This only happens when there is no 'end' attribute
for the subtitles.

For example, the following lines

<time begin="01:39.40"/><clear/> It's different now.
<time begin="00:02:14.7"/><clear/> Look...

parse to [1]:
01:01:39.04 01:01:41.01 {~}  It's different now.
00:00:02.00 00:00:08.00 {~}  Look...


The code is a long chain of sscanf() functions.

There are two issues at play here:

1) sscanf sets a1, a2 etc even when the whole line does not match. The
lines that try to parse begin/end tags will partially match and set
those variables, leading to faulty timestamps. The variables should be
reset to zero after each match attempt.

2) The line that tries matching for mm:ss timestamps actually matches
more than it is supposed to. The mm:ss.ff and hh:mm:ss.ff lines are
never run.

Attached is a minimal patch that fixes these two issues.
(It moves the problematic match downwards and resets the variables as
necessary.)


Other concerns relating to the surrounding code:

1) the 'len' variable sits completely unused and can be removed.

2) the timestamp calculation lines (a1*360000+a2*6000+a3*100+a4/10)
assume that the fourth value parsed (a4) is in milliseconds. This
assumption does not hold: the subtitle files I have are marked in
tenths of a second. I'm not sure it can be fixed without rewriting the
parsing code.


[1] Incidentally, the -dumpjacosub option creates a dumpsub.jss file
rather than the dumpsub.js file promised on the man page.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: subreader.diff
Type: text/x-diff
Size: 1295 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20140321/ec87fdcd/attachment.bin>