Web lists-archives.com

Re: [MPlayer-dev-eng] [PATCH] aalib subtitle fix

On 2018-04-04 00:18 -0700, za3k@xxxxxxxx wrote:
> On Wed, Apr 04, 2018 at 12:17:52AM -0700, za3k@xxxxxxxx wrote:
> > On Sun, May 07, 2017 at 02:15:08AM -0700, za3k@xxxxxxxx wrote:
> > > For some time now, aalib rendering has had broken subtitles. -vo aa is designed to use human-readable text at the size of one character per character. In actuality, it's somehow switched to trying to render a standard font using dithering since its introduction. This patch fixes it.
> > >
> > > Explanation: vo_font doesn't seem to get used anywhere, because OSD rendering is actually done in a completely separate way from other video output, but I kept it in just in case.
> > >
> > > As a side note, someone may want to investigate unicode support for subtitles in -vo aa.
> >
> > See May 7 email for patch contents. Could someone merge this into the SVN?
> Sorry to double-post here but realized that would be confusing right after I hit send. May 7, 2017 -- this one's been waiting a while :)

Finally fixed somehow SVN r38126 .

I am sorry you're patch was sitting here for so long :(

I decided to go with a differen fix, because you're patch had a
type I think (vo_font vs sub_font)

    --- 250,258 ----

          /* now init our own 'font' */
          if(!vo_font_save) vo_font_save = vo_font;
    !     if(!sub_font_save) sub_font_save = vo_font;

and it didn't restore the sub_font in uninit.

The subtitle support in vo aa is rahter messy. With the introduction
of freetype font rendering it got even more so. AFAICT if bitmap
fonts are used it kind of works as one would expect from reading
the code in vo_aa, OTOH when using freetype it seems to work out
of luck because of NULL == NULL; clean up isn't done at all in that
case. It doesn't happen to completely go south, because the freetype
code in sub/ directory is working around it.

MPlayer-dev-eng mailing list