VSFilter ASS {\clip(m... l...)} Problem, Textsub.vdf=Ok

[Liisachan]

Sorry if this is a known problem.

ASS {\clip( drawing )} works ok with Textsub.vdf, but VSFilter doesn't like this. Can anyone reproduce my problem? Tested the official 2.37 VSFilter and celtic_druid's 20060512 VSFilter on Win2K and XP. The problem seems to be alpha-related, i.e. the color is not as opaque as it is supposed to be. Also the border is jaggy-ish. I'm always feeling Textsub.vdf is better than VSFilter, but I thought the bugs in VSFilter were already fixed...

Does anyone know any workarounds...? Thank you very much in advance!!

http://ffdshow.faireal.net/tmp/vsts.png


Style: TestStyle,Verdana,80,&H0000ffff,&H0,&H0,&H0,-1,0,0,0,100,100,0,0.00,1,1,0,7,0,0,0,0

; OK
Dialogue: 1,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,Test

; OK
Dialogue: 2,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(0,0,110,80)}Test

; Not OK with VSFilter!
Dialogue: 3,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test

[Liisachan]

Ok, I found a workaround. The result may not be perfectly the same, but usable enough. The tricky part is, to draw the same face 4 times overlapping along the z direction, to make it opaque enough. (If the face was not opaque, this hack would be slightly more complicated, but it should be possible to adjust the alpha of each layer so that the final alpha will be what you want.)

http://ffdshow.faireal.net/tmp/vsts-hack.png


Style: TestStyleFace,Verdana,80,&H0000ffff,0,-1,-1,-1,0,0,0,100,100,0,0.00,1,1,0,7,0,0,0,0
Style: TestStyleBord,Verdana,80,-1,0,&H00000000,-1,-1,0,0,0,100,100,0,0.00,1,1,0,7,0,0,0,0

; Draw the same face without border 4 times on different layers (in theory quite meaningless but this is the hack)
Dialogue: 3,0:00:00.00,0:00:05.00,TestStyleFace,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test
Dialogue: 4,0:00:00.00,0:00:05.00,TestStyleFace,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test
Dialogue: 5,0:00:00.00,0:00:05.00,TestStyleFace,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test
Dialogue: 6,0:00:00.00,0:00:05.00,TestStyleFace,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test

; Draw the border separately, on a higher layer, without \clip
Dialogue: 999,0:00:00.00,0:00:05.00,TestStyleBord,,0000,0000,0000,,Test

[TheFluff]

It's a known (by some typesetters, at least) bug in 2.37. It does not exist in 2.36 or older.

See also http://asa.diac24.net/wiki/index.php/VSFilter

EDIT: fail, thread necromancy. It still applies, though.

[ArchMageZeratuL]

jfs (the Aegisub co-founder) has written a patch that fixes this issue. He uploaded a build with that patch applied, as well as equinox's patch for \fax and \fay support. The patches themselves are also available in the rar. Quoting his own words:


This version should fix all known rendering bugs, and also adds two additional override tags.

Download URL: http://www.animereactor.dk/aegisub/vsfilter-2.38-clipfix.rar
(Includes patch files for guliverkli svn rev 611. They should be applied in the src/subtitles/ dir.)

The new override tags are \fax and \fay. They perform a shearing operation. Giving them parameter 0 is the same as no change.
For those mathematically inclined, transforms the text by this matrix, in a text-local coordinate system. Shearing happens before rotation.


1 fax
fay 1


This is especially useful for typesetting signs whose parallax lines are too far away to make an \frx and \fry with \org practical.

What this does not fix:
I can't remember if the crash on excessive rectangular clips is also present in this svn revision, but if it is, it isn't fixed.
Also, the "100% CPU usage thread spawned when using in Avisynth without absolute path to subs file" bug isn't fixed either.

[Liisachan]

Thank you very much jfs! You guys are REALLY great. I'm not yet good enough to understand what you did in the patch, but it should be something amazing.

While this VSFilter is working very well, I have to report that even with this patch, VSFilter's result is not as good as the result by Textsub.vdf. Simply draw 2 yellow (0x00ffff) areas, without border without shadow. Textsub .vdf makes it 00ffff, but this VSFilter degrades it down to 0x00fefe. I suppose this is actually related to some intrinsic bugs in VSFilter, because not same but similar problems do exist in Textsub.vdf too.

(1) Simple- No border, No shadow.


Style: TestStyle,Verdana,80,&H0000ffff,&H0,&Hffffffff,&Hffffffff,-1,0,0,0,100,100,0,0.00,1,3,0,7,0,0,0,0

Dialogue: 51,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test
Dialogue: 52,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m 130 0 l 260 0 220 80 90 80)}Test


With .vdf, everything is ok. Face color is 00ffff as specified.
http://ffdshow.faireal.net/tmp/diagonal.png

With the patched VSFilter, the face color is degraded to 00fefe
http://ffdshow.faireal.net/tmp/diagonal1.png

Maybe the eyes don't see any difference, as ffff and fefe are very close, but slight color difference can be a serious problem when doing something complicated. Anyway, this shows that .vdf and the patched VSFilter are different, and there's something wrong in the VSFilter.

(2) Enable the border, and the face is damaged (00fefe) even with the .vdf, and you'll see a diagonal line along the clipping border. This line shouldn't be there.

Style: TestStyle,Verdana,80,&H0000ffff,&H0,&H00000000,&Hffffffff,-1,0,0,0,100,100,0,0.00,1,3,0,7,0,0,0,0

http://ffdshow.faireal.net/tmp/diagonal2.png

*This problem exists both in the patched VSFilter and old .vdf. So I'm gessing everything is basically a bug by gabest.

(3) Quick and strange workaround: Set the secondary alpha = 0xff, we are not karaoke'ing at all, but this will fix the pb. Fushigi da ne.


Style: TestStyle,Verdana,80,&H0000ffff,&Hff000000,&H00000000,&Hffffffff,-1,0,0,0,100,100,0,0.00,1,3,0,7,0,0,0,0


This hack works 100% for .vdf.
http://ffdshow.faireal.net/tmp/diagonal3.png

For the patched VSFilter, the diagonal line is removed by this, but the face is still 00fefe.
http://ffdshow.faireal.net/tmp/diagonal3a.png

(4) Now let's enable the shadow.

Style: TestStyle,Verdana,80,&H0000ffff,&Hff000000,&H00000000,&H80000000,-1,0,0,0,100,100,0,0.00,1,3,3,7,0,0,0,0


Again, the color was degraded to 00fefe, and we are seeing the annoying diagonal line.
http://ffdshow.faireal.net/tmp/diagonal4.png

* This problem happens both with the old .vdf and the patched vsfilter.

(5) So, how about drawing the normal line first, and then Clip1 and Clip2 on top of that?

Style: BaseStyle,Verdana,80,&H0000ffff,&Hff000000,&H00000000,&H80000000,-1,0,0,0,100,100,0,0.00,1,3,3,7,0,0,0,0
Style: TestStyle,Verdana,80,&H0000ffff,&Hff000000,&Hff000000,&Hff000000,-1,0,0,0,100,100,0,0.00,1,3,3,7,0,0,0,0

Dialogue: 10,0:00:00.00,0:00:05.00,BaseStyle,,0000,0000,0000,,Test

Dialogue: 51,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m 0 0 l 130 0 90 80 0 80)}Test
Dialogue: 52,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m 130 0 l 260 0 220 80 90 80)}Test

http://ffdshow.faireal.net/tmp/diagonal5.png

This seems to be working well, but the face color is degraded to 00fefe, not 00ffff. This problem exists in the both too.

EDIT
In order for the method (5) to work, BaseStyle must have the same face color with the pixel by the diagonal line (in this case yellow). For instance, if you have yellow and blue by the diagonal line, like the following picture, the BaseStyle must be yellow or blue.
http://ffdshow.faireal.net/tmp/diagonal5a.png
Otherwise, the diagonal line will be dirty like this.
http://ffdshow.faireal.net/tmp/diagonal5b.png
This means, if you want to use 3 or more colors, (5) doesn't work. For instance, if you have yellow, pink, blue, and you use yellow for the Base, the yellow-pink border will be OK, but pink-blue border will be not clear. Like this.
http://ffdshow.faireal.net/tmp/diagonal5c.png

If you need to use 3 or more colors this way, the following code (-1 px for the 1st and 7th params) may produce a better result. (this method is usable for 2 colors too)

Dialogue: 1000000,0:00:00.00,0:00:05.00,TestStyle,,0000,0000,0000,,{\clip(m -1 0 l 80 0 0 80 -81 80)}Test
Dialogue: 1000010,0:00:00.00,0:00:05.00,TestStyle1,,0000,0000,0000,,{\clip(m 79 0 l 160 0 80 80 -1 80)}Test
Dialogue: 1000020,0:00:00.00,0:00:05.00,TestStyle2,,0000,0000,0000,,{\clip(m 159 0 l 240 0 160 80 79 80)}Test

Result:
http://ffdshow.faireal.net/tmp/diagonal5d.png

As you can see, if you use -1 px, borders are "antialiased"

[Liisachan]

It's a known (by some typesetters, at least) bug in 2.37. It does not exist in 2.36 or older.

See also http://asa.diac24.net/wiki/index.php/VSFilter

EDIT: fail, thread necromancy. It still applies, though.

Thanks for the info :)

--First, I was going to say "The bug list in the above page is missing one of the most important bugs." I meant, when 1a is non-zero 1c is interfered by 3c. Example, white face + blue border + no shadow -> do fade -> when fading, the face gets blue-ish, it should be white + alpha.

While I was testing the patched VSFilter, I accidentally found an easy and strange workaround for this old pb. Setting 2a = 0xff works for this problem too. I don't know why. But it does.

(Still, VSFilter's fade is not perfect. If you fade white on the white background, that color should be always ffffff, but it isn't. )

[clsid]

Does this version also include a fix for a problem that occurs on some old DivX encoded files? I can't remember the exact details of that bug. I am currently using a version that contains a fix for that bug. I think it was made by some Russian guy.

[TheFluff]

--First, I was going to say "The bug list in the above page is missing one of the most important bugs." I meant, when 1a is non-zero 1c is interfered by 3c. Example, white face + blue border + no shadow -> do fade -> when fading, the face gets blue-ish, it should be white + alpha.
Then add it. It's a wiki, you know. :V

[Liisachan]

i called it a bug but it might be by design. plus it's too well-known, as written in guliverkli in 2004 "\fad-fades tend to blur into gray instead
of becoming transparent smoothly."
http://sourceforge.net/tracker/index.php?func=detail&aid=1022372&group_id=82303&atid=565649
He or she said "gray" probably because his/her border color is black. A better solution than \t would be to use layered \fad fades (much less cpu-intensive w the same results), but I was too lazy to post it there. I doubt there's any typesetter who doesn't notice it.

[jiifurusu]

A bit late for me to reply here, but I would just like to report that while I did try to fix the remaining off-by-one and fade problems etc. in VSFilter I've given up now. Apart from my debugger failing to properly read out variables, I can't figure out where those errors result from and all my attempts at fixing it have failed.

It seems all of the code was only checked into version control after 2.23 was released, and I can't find the source for the actual 2.23 version anywhere. It seems the bug was introduced when Avery Lee's original MMX-based blitter (from Subtitler.vdf) was replaced with some SSE2-intristics code, but I can't figure out where the error is occurring when comparing my patch with the oldest code in the version control.

So yes, I've officially given up on fixing anything more in the beast known as VSFilter.
I'll recommend supporting/trying alternative renderers such as asa (http://asa.diac24.net/) or libass (http://sourceforge.net/projects/libass). (Note that libass at this time has a hardcoded limit of 100 subtitles on-screen, which can make it useless for eg. advanced karaoke effects.)

[Liisachan]

Thanks for posting. Your efforts are really appreciated. and you are right, everything has a beginning and an end... even though gabest is a God for me. Also, mplayer's ass support is getting better, slowly but clearly. The sad fact is that you guys (devs) are so great and skilled that I, just a user, can't even understand how great you really are and how difficult what you are doing really is. Anyway keep up the great job :D

[Suchy]

Where can I get binnary VSFilterr.dll v2.37 with applied this patches (aka 2.38)?

Thanks

[jiifurusu]

See ArchMageZeratuL's post above, but for convenience here it is again:
http://www.animereactor.dk/aegisub/vsfilter-2.38-clipfix.rar

(You only need the DLL file in the package, the two patch files are only intended for programmers, but distributing the DLL without them is probably a GPL violation.)

[Suchy]

Thanks.
I noticed this link, but I thought that this dll is normal 2.37, and added patch files are to apply (In other word, I thought that this dll isn't 2.38).

But if it's 2.38, then fine.
Thanks again.

[ron.v.f]

http://www.animereactor.dk/aegisub/vsfilter-2.38-clipfix.rar
The link doesn't work. Any idea where I could get instead?
Didn't find it with google or others.

[Liisachan]

VSFilter+vsfilter_clipbug-patch-take3.patch+vsfilter_fax_fay-SVN611v2.patch binary is included in the 'ax' posted here.
http://forum.doom9.org/showthread.php?p=965213#post965213
I didn't test the above one very well, but jfs's version might be faster.
http://ffdshow.faireal.net/tmp/vsfilter-2.38-clipfix.rar

[ron.v.f]

Thanks a lot!

[Liisachan]

Just fyi... Check this sample at Frame 2400 @ 24000/1001 fps, i.e. 0:01:40.10 exactly, for instance on VirtualDub.


Dialogue: 0,0:01:30.00,0:01:40.10,Default,,0000,0000,0000,,This sub should not be on Frame 2400
Dialogue: 0,0:01:40.10,0:01:50.00,Default,,0000,0000,0000,,This sub shoud be on Frame 2400


Textsub (SSA/ASS) and Subtitler (SSA) work correctly. VSFilter doesn't work correctly for this, being off by one frame. (Start Time should be inclusive, or subs can never start from Frame 0. End Time should be exclusive.) Maybe rounding error (maybe internally v below is a bit too small and v < s, when in reality v = s).

Workaround:
s : SSA/ASS Timestamp
v : Video frame timestamp meant by s (minimal v such that s<=v)
If v-s is 0 or too small, and if s >= 0.01 sec, use s-0.01 sec for s, like this.


Dialogue: 0,0:01:30.00,0:01:40.09,Default,,0000,0000,0000,,This sub should not be on Frame 2400
Dialogue: 0,0:01:40.09,0:01:50.00,Default,,0000,0000,0000,,This sub shoud be on Frame 2400

[jiifurusu]

You're right, just confirmed it with VSFilter inside Aegisub. And it also showed the same bug in Aegisub, in how it considers timestamps for frames (for the purpose of timing subtitles to specific frames.)

The problem indeed is a floating-point rounding bug, equinox confirmed this:
<eqvinox> >>> 2400 / (24000/1001.)
<eqvinox> 100.09999999999999
<eqvinox> >>> 2400 / 24000. * 1001.
<eqvinox> 100.10000000000001

The problem is only really fixable by using true fractional framerates (nominator/denominator) and that could require some reworking of the software. I'm not sure if this is reasonably fixable...

[eqvinox]

VSFilter doesn't work correctly for this, being off by one frame. [...] Maybe rounding error (maybe internally v below is a bit too small and v < s, when in reality v = s).

This really looks like a floating point rounding bug...

>>> 2400 / (24000/1001.)
100.09999999999999
>>> 2400 / 24000. * 1001.
100.10000000000001

Lession? Don't use float/double timestamps. Sadly, I didn't consider that myself when outlining the CSRI interface, so we'll switch it to int64_t with microsecond precision as soon as possible.

>>> 2400 * 1001 * 1000000 / 24000
100100000L

int64_t microsecond timestamps will overflow after...
>>> (1<<63)/1000000./60./60./24./365.
292471.20867753599
So, er, I think 292471 years should be enough for everyone :D. Actually we could use nanosecond precision timestamps, but... does anyone use videos with like 100000 fps? ;)

[EDIT: btw, what app did this bug trigger on? it is sufficient for FP math to occur *anywhere* the timestamp passes...]

[Liisachan]

Thank you for confirmation. I happened to notice it while using VSFilter. We should be able to use a subtitle that is on Frame 0 (the first frame), so Start Time must be inclusive. And if so, End Time must be exclusive, because if both were inclusive there would be a collision just because End Time = Next Start Time like this, which would be very confusing and not acceptable.
00:01.00,00:05.00 ... line 1
00:05.00,00:10.00 ... line 2

The problem is only really fixable by using true fractional framerates (nominator/denominator) and that could require some reworking of the software. I'm not sure if this is reasonably fixable...

True..... The similar problem may occur when you write 23.976, because (double) 23.976 is not equal to what is called 23.976.

I'm not a pro programmer but just a learner, so I can't give you any clear explanation, but experience shows: using (double) fps, or (double) ms_per_frame is not safe, and something like this is relatively safer and may be practical enough.
sub_start_frame = ceil( sub_start_time * dwRate / dwScale )

eqvinox: 1 ns is not really needed, but directx has 100ns resolution, so 100 ns might be a good idea so that you can always tell for sure which event is before and which is after.

[jiifurusu]

Now, this is indeed a rounding error, and it doesn't happen on frame 0. The problem is that due to the base 2 binary decimal representation of floating point numbers, 2400 / (24000 / 1001) is represented as something just smaller than 100.1, something alike to 100.09999999999999990 (not the correct number of decimals) so indeed that time can't be represented correctly. However VSFilter does use strict inclusive/exclusive for start/end times, it's only that on this time stamp (and some other border cases) the lack of precision results in wrong results.
It might be fixable in the Avisynth and VirtualDub interfaces to TextSub, but is inherently unfixable in DirectShow, since DirectShow doesn't work with framerates, but rather simply a timestamp per frame, similar to how eg. Matroska stores it.

The best workaround to the problem is simply to make sure subtitles that need to be frame timed are timed within a safe margin instead of exactly on the start display time for the frame, ie. time the subtitle to begin 0.01 second too early. (Aegisub does something to this effect.)

While there formally is a bug, I think it's a bad idea to fix it, since it will potentially break some things that might expect the technically incorrect behaviour.

[Liisachan]

Just reported this probable bug in Guliverkli2.
https://sourceforge.net/tracker2/?func=detail&aid=2579931&group_id=205650&atid=994494

I'll post it here too hoping someone who knows better will read this, considering the nature of the Guliverkli2 project, and with images so that what I'm saying will be clearer. Also, this problem is very basic, so I think anyone who softsubs wants to know this. Also I'll suggest a workaround which you can use now, with almost no bad side effects.

Maybe should I report this to Aegisub people? But this bug is in MPC too. Anyway:

If ASS is muxed into MKV (softsubbed) and played back by VSFilter/MPC, when 2 subs overlap timing-wise, the 2nd-coming sub ("Ich..." in the example below) gets the wrong shadow alpha (4a); the 4a suddenly returns to normal when the 1st-coming sub ("Los!") disappears. Both older VSFilter and the newest version are affected.

bug_sample.mkv (http://www.faireal.net/image/2009/bug_sample.mkv) 30KiB

Demo/Workaround/ASS files used (http://www.faireal.net/image/2009/VSFilter_4a_bug.7z) 3 KiB

(An example explained)
Style: style1,Verdana,50,
&H00ffeeff,&Hffffffff,&H00000000,&H80000000,
-1,0,0,0,100,100,0,0.00,1,1.00,10.00,2,20,20,20,0
Style: style2,Verdana,24,
&H0080ffff,&Hffffffff,&H80000000,&Hcc000000,
-1,0,0,0,100,100,0,0.00,1,0.75,1.50,8,2,2,8,0

;; Non-Overlapping
Dialogue: 0,0:00:01.00,0:00:03.00,style1,,0000,0000,0000,,Ich will spielen!

;; Overlapping
Dialogue: 0,0:00:05.00,0:00:09.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:15.00,style1,,0000,0000,0000,,Ich will spielen!

The 1st "Ich...", not overlapped, shows how it should be:
http://www.faireal.net/image/2009/Ich1.png
When the 2nd "Ich..." appears:
http://www.faireal.net/image/2009/Ich2.png
When the "Los" ends, the 2nd "Ich..." suddenly returns to normal.
http://www.faireal.net/image/2009/Ich3.png

A quick-fix (workaround) is to divide the 1st-coming sub timing-wise:

Dialogue: 0,0:00:05.00,0:00:08.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:09.00,style2,,0000,0000,0000,,Los!
Dialogue: 0,0:00:08.00,0:00:15.00,style1,,0000,0000,0000,,Ich will spielen!

Hardsub (TextSub) and an external ASS loaded to MPC, not muxed into MKV, don't have this problem.

[clsid]

I suggest you contact jiifurusu. He is the Aegisub developer that has worked on improving VSFilter. He also has write access to Guliverkli2 repository.

[Liisachan]

Is he the only person who is actually doing VSFilter now? I hope he's checking the guliverkli2 tracker as a VSFilter dev, but if needed, I'll PM or email or otherwise try to contact him then. I feel it a bit weird to report MPC/VSFilter's bug to Aegisub people, because it's not a problem of Aegisub. I always wonder who I should report a bug of VSFilter to, and after all, usually when I notice a small problem I'll just try to find a workaround without telling anyone. I feel, though, I must share info about big problems like this.

[clsid]

Aegisub used to maintain their own repository with a modded version of VSFilter. That has moved to Guliverkli2 some time ago.

There is not really anyone else that is working on VSFilter. The MPC-HC devs are too busy with other things. So jiifurusu is your best change of getting this bug fixed.

[Liisachan]

Thank you clsid. Their bug tracker seems to be down, and their forums are not accepting bug reports, so I posted a comment to their blog. I know it's not the best place to report a bug to, but he/she will read it eventually. Well if it's moved to Guliverkli2, my first post to sf. might have been already enough, now that I think about it...