Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Subtitles

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th November 2006, 09:46   #1  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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
Liisachan is offline   Reply With Quote
Old 14th November 2006, 22:51   #2  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
Join Date: Nov 2002
Posts: 1,340
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
Liisachan is offline   Reply With Quote
Old 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.
TheFluff is offline   Reply With Quote
Old 10th January 2007, 18:21   #4  |  Link
ArchMageZeratuL
Aegisub developer
 
ArchMageZeratuL's Avatar
 
Join Date: Nov 2005
Posts: 15
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.

Last edited by ArchMageZeratuL; 10th January 2007 at 18:27.
ArchMageZeratuL is offline   Reply With Quote
Old 12th January 2007, 05:33   #5  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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.
Liisachan is offline   Reply With Quote
Old 12th January 2007, 05:43   #6  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
Join Date: Nov 2002
Posts: 1,340
Quote:
Originally Posted by TheFluff View Post
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. )

Last edited by Liisachan; 12th January 2007 at 06:19.
Liisachan is offline   Reply With Quote
Old 13th January 2007, 17:33   #7  |  Link
clsid
*****
 
Join Date: Feb 2005
Posts: 5,643
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.1.7.2
clsid is offline   Reply With Quote
Old 16th January 2007, 20:38   #8  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by Liisachan View Post
--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
TheFluff is offline   Reply With Quote
Old 17th January 2007, 02:43   #9  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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.
Liisachan is offline   Reply With Quote
Old 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.)
jiifurusu is offline   Reply With Quote
Old 14th February 2007, 05:22   #11  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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
Liisachan is offline   Reply With Quote
Old 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
Suchy is offline   Reply With Quote
Old 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.)
jiifurusu is offline   Reply With Quote
Old 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.
Suchy is offline   Reply With Quote
Old 22nd March 2007, 16:01   #15  |  Link
ron.v.f
Registered User
 
Join Date: Dec 2005
Posts: 9
Quote:
Originally Posted by jiifurusu View Post
The link doesn't work. Any idea where I could get instead?
Didn't find it with google or others.
ron.v.f is offline   Reply With Quote
Old 22nd March 2007, 17:54   #16  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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
Liisachan is offline   Reply With Quote
Old 23rd March 2007, 02:37   #17  |  Link
ron.v.f
Registered User
 
Join Date: Dec 2005
Posts: 9
Thanks a lot!
ron.v.f is offline   Reply With Quote
Old 29th August 2007, 08:25   #18  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
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
Liisachan is offline   Reply With Quote
Old 29th August 2007, 13:58   #19  |  Link
jiifurusu
Aegisub developer
 
Join Date: Jan 2007
Posts: 17
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...
jiifurusu is offline   Reply With Quote
Old 29th August 2007, 14:35   #20  |  Link
eqvinox
the asa guy
 
eqvinox's Avatar
 
Join Date: Jan 2006
Location: Germany
Posts: 1
Quote:
Originally Posted by Liisachan View Post
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...]

Last edited by eqvinox; 29th August 2007 at 14:47. Reason: bug origin?
eqvinox is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.