2013-09-29, 00:09
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!
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!
