[MPlayer-users] ass subtitles, vo gl and amd video

[wm4]

On Wed, 25 Sep 2013 21:45:04 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> > The idea for reducing the number of sub images was rendering runs of
> > glyphs with same attributes (at least same color) into one image, I
> > think. There was something about this not being entirely correct in
> > corner cases, but was considered good enough because vsfilter does the
> > same.
> > 
> > What do you envision?
> 
> Doesn't work. I was hoping I could detect consecutive characters and
> string them together when copying to a texture.
> The problem is that this is not really possible since the bounding
> boxes of neighbouring characters overlap.

Yes, overlaps are specially handled (see render_overlap()). The
blending this does looks a bit strange, but that whole code is a bug
fix to ancient libass.

> > > Thanks!
> > > Btw. a minor thing I noticed is that basically the same condition
> > > is used in process_text.
> > > Also when having a closer look I wonder if I did this really
> > > correctly, there are similar conditions in get_bitmap_glyph
> > > and measure_text functions that do not check \r.
> > > I believe I didn't change it because I didn't have a sample
> > > that needed it and did not know what I was doing, but maybe worth
> > > reviewing?
> > 
> > I don't know what I'm doing either. I just showed greg your patch, and
> > he ok'ed it.
> > 
> > I just keep wondering why \r has to be handled (where does \r even come
> > from?),
> 
> I would expect subtitles edited on ancient MacOS or Windows might end up
> with them.
> 
> > and isn't just filtered out in get_next_char(). (There's also
> > trim_whitespace().)
> 
> If you removed it in get_next_char you wouldn't be doing the
> automated line-breaks correct in files that use it as
> the only whitespace character.

I doubt there are any Matroska files that have \r embedded in ASS
packets. For normal files read directly by libass, \r is handled in
process_text() apparently. That leaves the case of applications using
libass to render other types of subtitles with libass by directly
adding ASS_Events. But mplayer subreader.c doesn't handle \r as far as
I can see, and other applications probably don't use it this way
either. So I don't understand where \r came from in your case.

> Also you'd have to be quite careful and defensive,
> since there might be multiple ways to encode \r,
> for example ass_utf8_get_char accepts non-normalized
> encodings, so you'd have to be careful to do the
> comparison at least only after that.

That would be invalid UTF-8. Who cares if libass renders garbage in
these cases? As long as it doesn't crash, you don't have to care.
Unless this type of invalid UTF-8 is particularly widespread and used
for legitimate applications.