[Chortos-2]

It looks like a libass bug. Milhouse has identified the commit when it appeared: https://github.com/OpenELEC/OpenELEC.tv/issues/3059

Yeah, but the only externally visible change that commit introduces is it makes images bigger and fewer by combining them. Before that commit, each letter would be a separate image, and they would be packed into a texture by XBMC, splitting them in multiple rows if needed to fit in the maximum texture width. After that commit, the whole line is a single image—with a width of around 1900 judging by the resolution of Milhouse’s original screenshot that he posted on #libass—that XBMC puts in the texture whole, so if it exceeds the allowed width and is clipped, the output will look just like in the “bad” screenshots.

There is no corruption either on the Raspberry Pi with a simple libass-based software renderer or on other platforms in XBMC, so we’re fairly sure it’s not a libass bug. At this point the only thing unique to the setup that exhibits the corruption (XBMC on Rasperry Pi) is that it uses OpenGL ES on the Raspberry Pi’s particular GPU hardware instead of OpenGL on a desktop- or laptop-class GPU. So I thought: either the hardware could have some particular restrictions, or some of the XBMC source code that differs between GL and GLES might have a bug.

I run with 1920x1080 fanart, which are rendered using textures. The limit is 2048x2048, so I don't think it is a texture size issue.

Thanks. Well, I’m really out of ideas now! Unless libass is outputting an image that is larger than 2048 for some reason, I guess. I’ll check that in a moment. Edit: it’s 1777×79 pixels, so nope.