Open GoogleCodeExporter opened 8 years ago
By the looks of it, this has been an issue ever since we introduced the feature
back in October 2011. Some sort of weird interaction between PlayResX &
PlayResY set below the video resolution, use of \N, and the 8x8 Bilinear
sub-pixel positioning option. We'll look into it, since there shouldn't be such
a large difference on lines broken with \N.
Workaround: Author scripts with PlayResX & PlayResY matching to the video
resolution
Just keep in mind that the reason we introduced the 8x8 Bilinear setting was
not to blur subtitles or make them look better. The original hope was that it
would be faster than rasterization, but it turned out to be slightly slower...
We left it in only in hopes of future performance improvements, still haven't
occurred yet. Most users should stick to using the 8x8 VSFilter Default.
Original comment by cyber.sp...@gmail.com
on 12 Aug 2012 at 1:30
Thank you for the response! Of course changing the resolution in the scripts
causes the subtitles to appear at the wrong size (not xy-VSFilter's fault but
the script author's lazy work), but that's okay. For now I've switched back to
default instead of bilinear.
However, since doing a test fix (setting PlayResX and Y to 1280 and 720) caused
all the subtitles to be uniformly jaggy... is there any way to get an option
that would make all subtitles appear nicely like the bottom one in my example
image? It looks a lot less jarring that way, like the subtitle is actually part
of the rendered image. Of course I can't be sure if such a look is the
intention of the script author. You guys who know the VobSub engine inside and
out would probably know better than I would how it's intended to interpret a
script.
Original comment by shirocla...@gmail.com
on 12 Aug 2012 at 3:08
> Of course I can't be sure if such a look is the intention of the script
author.
The \be and \blur tags are available if the person authoring a script wants a
softer look like your screenshot. It's not something we intend to allow the
end-user to override within xy-VSFilter. The side-effect of a softer look from
using the 8x8 Bilinear sub-pixel positioning option, is about as far as we'll
go in that regard.
The underlying issue is VSFilter's GDI-based rasterizer has always had a bit of
a problem with aliasing (jagged edges) on TrueType outlines. On some lower
quality font outlines, the problem can be quite horrible. As a long term goal,
we tentatively plan to do a rewrite of the rasterizer to enable higher quality
anti-aliased font rendering similar to FreeType which Libass uses. No ETA, but
that would be the proper solution to the issue of aliased font rendering.
Workaround: Use fonts with Postscript outlines instead of TrueType outlines,
and rendering quality will be much nicer with VSFilter and GDI alike.
Original comment by cyber.sp...@gmail.com
on 12 Aug 2012 at 7:03
> Workaround: Use fonts with Postscript outlines instead of TrueType outlines,
> and rendering quality will be much nicer with VSFilter and GDI alike.
I should probably say 'Partial Workaround', since it looks like that release
does use a font with PostScript outline. Half of the aliasing in your image is
likely caused by the resize algorithm used by your video renderer. Bottom line
is VSFilter's rasterizer needs an overhaul, which may occur eventually.
Original comment by cyber.sp...@gmail.com
on 12 Aug 2012 at 7:24
Issue 192 has been merged into this issue.
Original comment by cyber.sp...@gmail.com
on 28 Dec 2014 at 10:36
Original issue reported on code.google.com by
shirocla...@gmail.com
on 11 Aug 2012 at 11:32Attachments: