[MPlayer-users] MPlayer incorrectly handles some kind of ASS subtitles using -noass option

[Nicolas George]

Le decadi 20 brumaire, an CCXXI, None None a écrit :
> Hello.
> I'm using mplayer 1.1 and expecting some troubles with ASS subtitles. I'm
> using -noass option and for this subtitle file (for example):
> [V4+ Styles]
> Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
> Style: Default,Comic Sans MS,53,&H00FFFFFF,&H0000FFFF,&H00000000,&H00000000,-1,0,0,0,100,100,1,0,1,2,1,2,10,10,25,204
> Style: Title,Trebuchet MS,25,&H00FFFFFF,&H0000FFFF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,2,1,1,12,12,75,204
> [Events]
> Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
> Dialogue: 0,0:00:00.00,0:00:06.00,Default,Test,0000,0000,0000,,Example text1
> Dialogue: 0,0:00:00.00,0:00:06.00,Title,Test,0000,0000,0000,,{\fad(0,800)\p1\pos(30,130)\bord0\1c&H000000&\shad0}m 0 0 l 100 0 l 100 100 l 0 100 l 0 0 {\p0}
> Dialogue: 0,0:00:00.00,0:00:06.00,Default,Test,0000,0000,0000,,Example text3
> 
> MPlayer shows all almost correctly using -noass:
> Example text1
> m 0 0 l 100 0 l 100 100 l 0 100 l 0 0 ## Should MPlayer show such line in
> this mode? In -ass mode it's draw black square at top left corner.

This is completely expected: this script is just too complex to be rendered
completely without ASS parsing.

> Example text3
> But for this:
> [V4+ Styles]
> Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
> Style: Default,Comic Sans MS,53,&H00FFFFFF,&H0000FFFF,&H00000000,&H00000000,-1,0,0,0,100,100,1,0,1,2,1,2,10,10,25,204
> Style: Title,Trebuchet MS,25,&H00FFFFFF,&H0000FFFF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,2,1,1,12,12,75,204
> [Events]
> Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
> Dialogue: 0,0:00:00.00,0:00:06.00,Default,Test,0000,0000,0000,,Example text1
> Dialogue: 0,0:00:00.00,0:00:06.00,Title,,0000,0000,0000,,{\fad(0,800)\p1\pos(30,130)\bord0\1c&H000000&\shad0}m 0 0 l 100 0 l 100 100 l 0 100 l 0 0 {\p0}
> Dialogue: 0,0:00:00.00,0:00:06.00,Default,Test,0000,0000,0000,,Example text3
>  
> MPlayer shows much more incorrectly: 
> Example text1
> m 0 0 l 100 0 l 100 100 l 0 100 l 0 0
> 0000,,Example text3
> And ALL subtitles after this will be prefixed by 0000,, until end of file, even if second line was skipped using -ss 10
> I think it's may be even secutity vulnerability.
> Can You fix this? 

There are two problems combined here.

The first problem is that MPlayer does not parse the Format line. Instead,
it just counts the commas and uses an heuristic to guess when the comma is
in fact part of the text.

That means that for example, the following script is incorrectly parsed:

Dialogue: 0,0:00:00.00,0:00:01.00,Default,,0,0,0,,I have 1,000.
Dialogue: 0,0:00:01.00,0:00:02.00,Default,,0,0,0,,No.
Dialogue: 0,0:00:02.00,0:00:03.00,Default,,0,0,0,,I really have 1,000.

In the first line, MPlayer mistakes the comma inside "1,000" for a field
separator. It does not happen on the third line because the second line made
it realize that there are only 9 fields to skip.

The second problem is that the parser incorrectly assumes that fields can
not be empty: "A,,B" is parsed as "A" + ",B" rather than "A" + "" + "B". In
your example, on the second line, MPlayer sees 4 fields to skip: "Title",
",0000", "0000" and "0000"; on the third line, the 4 fields to skip are
"Default", "Test", "0000", "0000", leaving the third "0000" displayed.

I just sent a patch on the mailing list for the second problem, it is
trivial.

The second problem would require more work, I am not sure it is worth the
effort, because it is much less likely to be triggered (it requires the
first line of dialogue to have a comma not followed by a space), and much
more harmless (it does not contaminate the rest of the script).

Note that neither of these problems are a security concerns.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20121118/181250e8/attachment.asc>