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

[Reimar Döffinger]

On Wed, Sep 25, 2013 at 09:27:23PM +0200, wm4 wrote:
> On Wed, 25 Sep 2013 19:57:42 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > On Wed, Sep 25, 2013 at 05:57:32PM +0200, wm4 wrote:
> > > On Tue, 24 Sep 2013 22:36:20 +0200
> > > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > > 
> > > > On Tue, Sep 24, 2013 at 11:18:28AM +0200, wm4 wrote:
> > > > > that 1. different libass versions with different bugs (up to mplayer's
> > > > > completely retarded builtin copy, which is slightly modified compared
> > > > > to official libass, you should fix that)
> > > > 
> > > > Last I heard there was no willingness to support compiling without
> > > > fribidi support.
> > > > Maybe not exactly a huge feature, but I kind of like it and it's
> > > > not much to maintain.
> > > 
> > > We decided that we don't want more ifdeffery. But a clean way to add
> > > this functionality would be accepted. That'd be a bit more work, though.
> > 
> > Ok, I'll try to work towards that long-term, but it's certain to
> > take some time.
> > I also think I might have a sensible way of merging the characters
> > at least for cases like this inside libvo...
> 
> 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.

> > 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.
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.