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

Liisachan · 14th November 2006, 09:46

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

Code:

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 · 14th November 2006, 22:51

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

Code:

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 · 4th January 2007, 22:03

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 · 10th January 2007, 18:21

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:

Quote:

Originally Posted by jfs

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

Download URL: http://www.animereactor.dk/aegisub/v...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.

Code:

 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 · 12th January 2007, 05:33

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.

Code:

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.

With the patched VSFilter, the face color is degraded to 00fefe

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.

Code:

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

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

Code:

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.

For the patched VSFilter, the diagonal line is removed by this, but the face is still 00fefe.

(4) Now let's enable the shadow.

Code:

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.

* 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?

Code:

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

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.

Otherwise, the diagonal line will be dirty like this.

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.

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)

Code:

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:

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

Liisachan · 12th January 2007, 05:43

Quote:

Originally Posted by 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.

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 · 13th January 2007, 17:33

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 · 16th January 2007, 20:38

Quote:

Originally Posted by Liisachan

--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 · 17th January 2007, 02:43

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...03&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 · 13th February 2007, 23:37

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 or 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 · 14th February 2007, 05:22

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

Suchy · 14th February 2007, 23:58

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

Thanks

jiifurusu · 15th February 2007, 00:44

See ArchMageZeratuL's post above, but for convenience here it is again:
http://www.animereactor.dk/aegisub/v...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 · 15th February 2007, 03:30

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 · 22nd March 2007, 16:01

Quote:

Originally Posted by jiifurusu

http://www.animereactor.dk/aegisub/v...38-clipfix.rar

The link doesn't work. Any idea where I could get instead?
Didn't find it with google or others.

Liisachan · 22nd March 2007, 17:54

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

ron.v.f · 23rd March 2007, 02:37

Thanks a lot!

Liisachan · 29th August 2007, 08:25

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

Code:

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.

Code:

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 · 29th August 2007, 13:58

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:

Quote:

<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 · 29th August 2007, 14:35

Quote:

Originally Posted by Liisachan

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

Code:

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

Code:

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

int64_t microsecond timestamps will overflow after...

Code:

>>> (1<<63)/1000000./60./60./24./365.
292471.20867753599

So, er, I think 292471 years should be enough for everyone

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

14th November 2006, 09:46	#1 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	VSFilter ASS {\clip(m... l...)} Problem, Textsub.vdf=Ok 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!! Code: 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

4th January 2007, 22:03	#3 \| Link
TheFluff Excessively jovial fellow Join Date: Jun 2004 Location: rude Posts: 1,100	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. Last edited by TheFluff; 4th January 2007 at 22:05. Reason: fail.

12th January 2007, 05:33	#5 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	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. Code: 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. With the patched VSFilter, the face color is degraded to 00fefe 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. Code: 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 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. Code: 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. For the patched VSFilter, the diagonal line is removed by this, but the face is still 00fefe. (4) Now let's enable the shadow. Code: 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. * 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? Code: 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 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. Otherwise, the diagonal line will be dirty like this. 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. 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) Code: 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: As you can see, if you use -1 px, borders are "antialiased" Last edited by Liisachan; 12th January 2007 at 11:22.

13th January 2007, 17:33	#7 \| Link
clsid ***** Join Date: Feb 2005 Posts: 5,698	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. __________________ MPC-HC 2.3.9

29th August 2007, 08:25	#18 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	Yet another VSFilter bug: 1 Frame off Just fyi... Check this sample at Frame 2400 @ 24000/1001 fps, i.e. 0:01:40.10 exactly, for instance on VirtualDub. Code: 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. Code: 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

17th January 2007, 02:43	#9 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	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...03&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.

13th February 2007, 23:37	#10 \| Link
jiifurusu Aegisub developer Join Date: Jan 2007 Posts: 17	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 or 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.)

14th February 2007, 05:22	#11 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	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

14th February 2007, 23:58	#12 \| Link
Suchy Registered User Join Date: Aug 2005 Posts: 68	Where can I get binnary VSFilterr.dll v2.37 with applied this patches (aka 2.38)? Thanks

15th February 2007, 00:44	#13 \| Link
jiifurusu Aegisub developer Join Date: Jan 2007 Posts: 17	See ArchMageZeratuL's post above, but for convenience here it is again: http://www.animereactor.dk/aegisub/v...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.)

15th February 2007, 03:30	#14 \| Link
Suchy Registered User Join Date: Aug 2005 Posts: 68	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.

22nd March 2007, 17:54	#16 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	VSFilter+vsfilter_clipbug-patch-take3.patch+vsfilter_fax_fay-SVN611v2.patch binary is included in the 'ax' posted here. http://forum.doom9.org/showthread.ph...213#post965213 I didn't test the above one very well, but jfs's version might be faster. http://ffdshow.faireal.net/tmp/vsfil...38-clipfix.rar

23rd March 2007, 02:37	#17 \| Link
ron.v.f Registered User Join Date: Dec 2005 Posts: 9	Thanks a lot!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode