Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ratei]

Thank you for the explanation. Remuxing with new mkvtoolnix fixed the line ordering. Only noticed a minor pixel offset from the more blurred text. I guess vsfilter handles text with higher blur with a higher line height.

Going to start testing for issue97

[cyberbeing]

Only noticed a minor pixel offset from the more blurred text.

This occurs because one pair of lines has a border and the other doesn't. VSFilter uses a dynamic offset to prevent large borders from causing line collisions. Libass uses a fixed offset and doesn't care about line collisions caused by large borders. If Coalgirls wanted the same effect in both VSFilter and Libass, they would have needed to use \pos instead of allowing automatic alignment.

[ratei]

Did some random test using the scaler test build.

xy-VSFilter Customize: depending on script's intended size
FFDshow Resize: 2560x1440
-- though I only have 1360x768 monitor, I set ffdshow to 2560x1440 to test scaling

screenshot set > 480p - 720p

scaling looks like working good so far.
in this picture this is a 720p video with 1080p script. skewing is incorrect when not set to xy-vsfilter set to 1080p with ffdshow resize on. the unresized ffdshow one looks incorrect.

tried testing again after getting some sleep and turning on my pc. and it's freaking me out. font is not loading correctly.

tried switching with stable xy-vsfilter and then mpc-hc's isr but it's still they're using the same plain font. i didn't touch my codec setup at all. all other fonts are loading correctly in other scenes, only this particular scene. must be something wrong with my windows font system?

about the \be discussion. \blur doesn't seem to be affected by xy-vsfilter custom size while \be is affected.

[cyberbeing]

though I only have 1360x768 monitor, I set ffdshow to 2560x1440 to test scaling

For our purposes, it would be better if you 'Specify Horizontal Size' to 1360 in FFDShow with 'Keep Original Aspect Ratio' set so subtitles are rendered at the native resolution of your monitor. This is how the scale function would normally be used when viewing fullscreen on your PC with new subtitle interface, and it also happens to be a more interesting scale factor of 1.0625 for 720p and 0.708333 for 1080p.

screenshot set > 480p - 720p

Thanks for all the comparison screenshots. If you are wondering why there is such a big difference on the non-scaled 480p, it's because VSFilter's 4:2:0 rendering quality at low resolution can be quite poor. If you have FFDShow output RGB32 (4:4:4) video for non-scaled result would probably look quite a bit better. At the moment, we aren't doing anything to compensate for low resolution video becoming blurrier when upscaled.

in this picture this is a 720p video with 1080p script. skewing is incorrect when not set to xy-vsfilter set to 1080p with ffdshow resize on. the unresized ffdshow one looks incorrect.

This is to be expected. If a script already looks incorrect when rendered at video resolution without scaling, it will look just as incorrect when scaled normally with xy-VSFilter. We have been considering allowing scripts to be tagged in order to identify cases like your example, of a 1080p typesetting used on a 720p video without 3D transforms being corrected for 720p.

must be something wrong with my windows font system?

Sounds like it. I'd first try deleting all the mkf****.tmp files from C:\Users\[Username]\AppData\Local\Temp and rebooting. If that doesn't work, I've listed some more in-depth Windows Font troubleshooting steps on the previous page.

about the \be discussion. \blur doesn't seem to be affected by xy-vsfilter custom size while \be is affected.

I assume this comparison contained \be ? Could you attach that script and any others where you find \be scaling to be a problem?

Script \be values are multiplied by the scale_factor when using xy-VSFilter custom size, but in the current build it will be less blurry than not scaling, while more blurry than using the script \be value on the higher resolution subtitles. If non-identical blurriness is seen to be a bigger problem than non-identical 'lightness' of the \be blur, we could once again try some variation of scale_factor*scale_factor. Though as mentioned in Issue #97, this will usually look visually worse when upscaling results in very high \be values.

[ratei]

For our purposes, it would be better if you 'Specify Horizontal Size' to 1360 in FFDShow with 'Keep Original Aspect Ratio' set so subtitles are rendered at the native resolution of your monitor.

OK, will do.

If you are wondering why there is such a big difference on the non-scaled 480p, it's because VSFilter's 4:2:0 rendering quality at low resolution can be quite poor.

That must be I'm noticing with old encoded files. SRT subs having funny colors. White doesn't look like white at all. Black border looks like shifting to bluish color.

Sounds like it. I'd first try deleting all the mkf****.tmp files from C:\Users\[Username]\AppData\Local\Temp and rebooting. If that doesn't work, I've listed some more in-depth Windows Font troubleshooting steps on the previous page.

I'll ignore this problem for now. Did clean my temp files. Weird though the font is not included in the mkv in the first place. Looked for the font and installed my system and displays correctly. Mysteriously why did it render the font correctly before.

I assume this comparison contained \be ? Could you attach that script and any others where you find \be scaling to be a problem?

Sure, attached. Will post if I ever discover some \be in other videos.

EDIT:
I now understand about the problem with \be. Trying to mimic the original behavior of \be so replacing it with any kind of blur algorithm that scales is not an option.

[cyberbeing]

\be = 2D Binomial Blur (i.e. fast, approximated Gaussian using a 3x3 filter, strength adjusted by use of multiple iterations)
\blur = True Gaussian Blur (i.e. slower, higher quality, strength adjusted with floating-point blur radius value, always a single iteration)

They each produce a different look, but for well done typesetting, it can be hard to tell which was used. In the case of this scale test build, just look out for any typesetting which looks out of place, and then toggle the FFDShow Resize & Aspect check-box to see if it looks the same when not scaled.

[ratei]

They each produce a different look, but for well done typesetting, it can be hard to tell which was used. In the case of this scale test build, just look out for any typesetting which looks out of place, and then toggle the FFDShow Resize & Aspect check-box to see if it looks the same when not scaled.

Alright. I'll look on to it with my free time. Might not give a feedback for a while. I'll be busy for a week.

[cyberbeing]

For our next stable build release, we intend to include all the performance enhancements and changes which have been available for testing in our preview beta releases during the past 3 months. If anybody is aware of any outstanding issues which exist in xy-VSFilter 3.0.0.144, but not in xy-VSFilter 3.0.0.65, now would be a good time to inform us.

[namaiki]

Not a bug, just wanted to pass on the typesetting that someone reported that they had trouble playing in real time:

Code: [Select]

Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b1\move(497.6,107.2,479.25,65.69,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}How to cross over to the Otherworld
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b1\fs34\c&H878788&\move(459.2,217.6,434.91,193.19,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}Firstly, walk to the seventh pylon and chant "Wolensak Tanbur Wetzler!"
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b1\fs30\c&H7D7D7D&\move(467.2,289.6,444.15,276.34,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}Then do the same at the third pylon, followed by the fourth and the ninth.
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b1\fs30\c&H7D7D7D&\move(345.6,436.8,303.72,446.34,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}You must not talk with any humans along the way.
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b1\fs34\c&H7D7D7D&\move(503.47,616.53,486.03,653.9,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}Next, go to the thirteenth pylon and put the mirror under it.
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\frz346.8\blur0.6\b0\fs34\c&H434342&\fnmine\move(1168,561.33,1253.47,590.15,28,5867)\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}13{\fnpencilPete FONT\b1}th pylon
Dialogue: 0,0:09:53.19,0:09:59.07,paper,,0000,0000,0000,,{\blur0.8\b0\fs34\c&H595A59&\fnmine\move(856,571.2,893.16,601.55,28,5867)\frz2.492\fscx100\t(28,5867,\fscx115.49)\fscy100\t(28,5867,\fscy115.49)}You talk, you fail.
I couldn't play it either without lag and VLC Player (with libass I think) couldn't do it either. :p

From here: http://www.cccp-project.net/forums/index.php?topic=6555.0

[ratei]

Saw some bad clipping of text. I'm not sure if a vsfilter error or a hackish subtitle. Looks fine on libass.

Code: [Select]

Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 1,{\clip(440,737,705,752)\pos(573,775.5)\1c&HF7FBF7&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 2,{\clip(440,752,705,767)\pos(573,775.5)\1c&HDAF1D1&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 3,{\clip(440,767,705,782)\pos(573,775.5)\1c&HBDE7AB&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 4,{\clip(440,782,705,797)\pos(573,775.5)\1c&H8FDF67&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 5,{\clip(440,797,705,812)\pos(573,775.5)\1c&H5FD621&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ad1 6,{\clip(440,812,705,827)\pos(573,775.5)\1c&H5BD61A&}Question 6
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 1,{\clip(32,978,1170,993)\pos(601.5,1017)\1c&HF7FBF7&}Me, a Peeping Tom, and the Brotherhood of Men!
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 2,{\clip(32,993,1170,1008)\pos(601.5,1017)\1c&HABCDF1&}Me, a Peeping Tom, and the Brotherhood of Men!
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 3,{\clip(32,1008,1170,1023)\pos(601.5,1017)\1c&H60A0EB&}Me, a Peeping Tom, and the Brotherhood of Men!
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 4,{\clip(32,1023,1170,1038)\pos(601.5,1017)\1c&H448DDF&}Me, a Peeping Tom, and the Brotherhood of Men!
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 5,{\clip(32,1038,1170,1053)\pos(601.5,1017)\1c&H2B7BD3&}Me, a Peeping Tom, and the Brotherhood of Men!
Dialogue: 0,0:01:36.15,0:01:39.41,Title,,0000,0000,0000,gradient @ac7 6,{\clip(32,1053,1170,1068)\pos(601.5,1017)\1c&H297AD2&}Me, a Peeping Tom, and the Brotherhood of Men!

vsfilter


libass


EDIT:
Found the culprit~ I'm using Haali Splitter and the otf fonts embedded were not set to application/x-truetype-font.

@namaiki tried testing that video too. it's lagging like hell. the built-in mpc vsfilter lag less but the subtitle animation is choppy. tried with potplayer's builtin subtitle it plays smooth but the animation moves like 3 steps only.

[cyberbeing]

Not a bug, just wanted to pass on the typesetting that someone reported that they had trouble playing in real time

This type of script is an example of worse-case for xy-VSFilter, since the font has an extremely complex outline and GDI becomes bottlenecked.
Unfortunately Windows is not open source , so this cannot be easily optimized as long we use built-in font handling.

On the original script we are ~3x faster than regular VSFilter, but because of the font used, Libass ends up 2x faster than xy-VSFilter:

Core i5-3570K @4.4Ghz
Libass: 110 fps avg | ??fps min
xy-VSFilter: 65fps avg | 30fps min
VSFilter: 24fps avg | 10fps min


Replace with a lightweight font like Arial in the script and everything changes. We maintain a ~3x faster lead over regular VSFilter, but now xy-VSFilter has a ~10% lead over Libass as well.

Core i5-3570K @4.4Ghz with font changed to Arial
xy-VSFilter: 170fps avg | 85fps min
Libass: 155 fps avg | ??fps min
VSFilter: 65fps avg | 30fps min

Hint: The more complex and numerous the holes, gaps, or notches in a font outline, the slower it will render.
Examples: [1] [2] [3] [4] [5] [6]
Only with static typesetting performance will be acceptable for such fonts using xy-VSFilter (along a pre-buffering video renderer like EVR-CP or madVR).
I hope script authors will learn to avoid these and similar overly complex fonts when softsubbing multiple lines of motion tracked typesetting or complex karaoke.

[ryrynz]

Unfortunately Windows is not open source , so this cannot be easily optimized as long we use built-in font handling.

Perhaps inquire with MS on how to optimize for this then? Someone there might be helpful.

[ratei]

Any progress with the \blur scaling?

Maybe the developer of this blur plugin for avisynth can help. He implemented binomial blur with floating radius.
http://forum.doom9.org/showthread.php?t=88645

[cyberbeing]

We recommend users update MPC-HC to 1.6.5.6197 (x86) or newer. [Edit: CCCP users should wait for an updated CCCP]
With these newer MPC-HC builds, you'll no longer be required set DirectVobSub (auto-loading version) to Prefer in External Filters for xy-VSFilter to be used.

[Lenmaer]

We recommend users update MPC-HC to 1.6.5.6197 (x86) or newer.
With these newer MPC-HC builds, you'll no longer be required set DirectVobSub (auto-loading version) to Prefer in External Filters for xy-VSFilter to be used.

Thanks, but I don't know if it's possible, MPC-HC is bound to CCCP and CCCP is still not updated yet. It's been over a year now.