Posts: 190
Joined: Sep 2008
Reputation:
5
magao
Senior Member
Posts: 190
Mazui/UTW Toaru Kagaku no Railgun S ep. 23 720p - many of the subtitles in the ending (karaoke and dialog) are replaced by blocks. I've seen this happen in the past, but it's becoming more prevalent. I don't have the subtitle expertise to determine what's triggering the corruption.
Can anyone confirm if this is happening with other versions of XBMC other than OpenELEC 3.2.0?
Posts: 190
Joined: Sep 2008
Reputation:
5
magao
Senior Member
Posts: 190
2013-09-28, 01:03
(This post was last modified: 2013-09-28, 01:09 by magao.)
I've narrowed the issue down to interactions with the ASS \blur tag. Changing all \blur tags to the closest equivalent \be tag resulted in working subtitles.
It looks like OpenELEC is using libass 0.10.1 (the latest) so I'll raise an issue against libass.
Posts: 31,445
Joined: Jan 2011
I looked it up and it looks like UTW and/or Mazui screwed up the subs themselves.
Posts: 31,445
Joined: Jan 2011
Doh, my bad, I was looking at the SSA tags and not the ASS tags.
Posts: 6
Joined: Sep 2013
Reputation:
0
2013-09-29, 00:09
(This post was last modified: 2013-09-29, 00:51 by Chortos-2.)
Hello, I’m the aforementioned dev.
As far as I can see, the subs are fine, and indeed they play correctly in both mplayer2 and VLC on OS X. I thought this could be some sort of older libass bug that had been fixed between the release of XBMC 12.2 and now, but I couldn’t reproduce it in mplayer2 even with an appropriately old libass.
What makes it weirder is that the symptoms vary between platforms: as magao said, on Windows and OS X the player almost freezes when it encounters the first affected line (even after the video is paused) and apparently renders all not-fully-transparent pixels as fully opaque*, while on Linux it doesn’t freeze but shows some amazing block art instead of Latin letters. There are screenshots of both the OS X and the Linux rendering on the libass issue tracker.
* This effect seems to fade away along with the affected line during the animated fade, \fad.
I also observed a huge increase in memory usage on OS X when the first affected line was encountered and a slower huge increase over the rest of the file.
Other potentially useful information: there is a whole bunch of blurred lines in the same frame, but they are clipped to non-overlapping rectangles. They also have different colours to achieve a vertical gradient, and on OS X, I can see the gradient in XBMC, so the clipping seems to work fine. Meanwhile, in the Linux screenshot, I’m inclined to say I don’t see the gradient, which would suggest that clipping is somehow broken. (Which is weird per se, because clipping is done internally in libass.)
And magao, \be and \blur arguments are far from equivalent. As it happens, just recently I did some (mathematical) experiments with \be and \blur, and here’s the conversion formula I obtained: \be argument = (\blur argument)^2 * 8 / log(256). So for \blur3 you actually want \be13!
Posts: 190
Joined: Sep 2008
Reputation:
5
magao
Senior Member
Posts: 190
2013-09-29, 03:21
(This post was last modified: 2013-09-29, 04:44 by magao.)
Interesting. I used the suggested algorithm for converting \blur -> \be and I started getting the same issues with \be tags (e.g. \be13). The other thing I've discovered is that it's in combination with vector clipping that the issue occurs - if I change all the vector clipping to rectangular clipping (where the vector clip actually is a rectangle) the corruption goes away on OpenELEC (Windows still has the huge aura and slowdown) e.g.
Dialogue: 4,0:22:06.20,0:22:10.17,ED4-Romaji,,0,0,0,,{\pos(60,32)\blur3\bord3\fad(480,320)\clip(m 0 30 l 1280 30 1280 32 0 32 0 30)\c&HEEC69B&\3c&HEEC69B&}kawaita kaze ni sakebu
to a rectangular clip:
Dialogue: 4,0:22:06.20,0:22:10.17,ED4-Romaji,,0,0,0,,{\pos(60,32)\blur3\bord3\fad(480,320)\clip(0, 30, 1280, 32)\c&HEEC69B&\3c&HEEC69B&}kawaita kaze ni sakebu
It also seems to require multiple clipped lines for the problem to occur, but I'm not sure about that.
BTW I also tried removing all the lines with clipping and the slowdown on Windows went away, so that's definitely an issue with rendering that many subtitles (with that many transformations) per frame.
Posts: 6
Joined: Sep 2013
Reputation:
0
2014-04-03, 01:02
(This post was last modified: 2014-04-03, 17:29 by Chortos-2.)
TL;DR I know what the OS X/Windows issue is.
I did some more testing today, and the conclusion is... uhh. The corruption on OS X, presumably Windows and possibly Linux only occurs when playing an external subtitle file.
I can’t remember how exactly I did my testing last time, but when I went back to the same files today, I had an external ASS file next to the MKV. At first I tried various things and was very confused when corruption appeared and disappeared depending on such factors as whether I opened the file through the GUI or passed it as a command-line argument, whether the file was a symbolic link or a regular file, and whether it’s the original file or a remuxed copy. I thought I established that XBMC completely ignored my external ASS file at one point, but after exhausting my other options I tried testing it once more. Sure enough, it does use the external file, and moreover, it goes crazy when the external file is present and works correctly (albeit with an occasional slight stutter) when it’s absent.
And from reading the XBMC source code, I know just what the problem is. (I actually read the code and saw this as a potential problem—“unless it’s handled somewhere else”—before I figured out that it was indeed the entire issue. Remember, I thought it was ignoring my external subtitles.) CDVDSubtitleParserSSA creates a separate overlay for each ASS event, even when there are multiple events on screen at the same time. CDVDOverlayContainer::Add then checks for overlapping events but doesn’t do anything because it explicitly avoids touching events that share an exact same start time. So all these duplicate events are rendered, and each blends the entire ASS frame onto the video. So you end up with the same subtitles blended 53 times over, which looks, well, like my screenshot!