xy-VSFilter Project (High Performance VSFilter Compatible Subtitle Filters)

[romulous]

Sorry to be a pest, but I have another sample that is problematic. Seems to affect both xyVSFilter and XYSubFilter. Zoom Player (my main player) will play the MKV file alone (without either of the external sub files present), but as soon as the external sub files are copied into the same folder, Zoom won't even play the file. Using MPDN (to rule out a player problem), I see an instant hang with MPDN, again when both the subs files are copied to the same folder as the movie. Not sure what is going on with this one:
https://dl.dropboxusercontent.com/u/105555957/Test.zip (55.2MB)

The original report to me was that the subs show fine with xyVSFilter, but do not show at all with XYSubFilter (using the new release, no change).

romulous

[cyberbeing]

Does the problem resolve itself if you move 'sub' after 'idx' in the LOAD_EXT_LIST registry string at:
HKEY_CURRENT_USER\Software\Gabest\XySubFilter\General

I've pushed out a XySubFilter 3.1.0.705 build with this change since it resolved the crash on my PC with that sample.
This change in the registry won't take effect unless you reset to defaults, so I've included a reg file to do this in the zip.

What appears to be happening here, is XySubFilter attempting to read the VobSub .sub (bitmap) as MicroDVD .sub (text) which for some reason triggers an _Xout_of_range crash in std::basic_string on that sample. I've not run into this before, so I suspect VOBSUB .sub files which can trigger this issue are rather rare.

Unfortunately the change here is just a workaround for when there is a valid VOBSUB .sub+.idx pair present. It will still crash if you delete the .idx for your sample, but this should at least avoid the common case. If you come across more samples like this, hopefully someone could track this down and fix it properly.

[romulous]

Works for me :) I have asked the person who provided the sample to test on the full file, just to make sure. Will hopefully get back to you shortly!

romulous

[romulous]

Ok, I was mistaken. XYSubFilter was not being used, xy-VSFilter was being instead. Unfortunately, I cannot get XYSubFilter to work with the new dll. Zoom just reverts back to xy-VSFilter, which is why the clip now plays (as xy-VSFilter was fine, it was only XYSubFilter that was broken). So, the question is, why does XYSubFilter seem to be broken totally?

Just on another subject, while you are updating the builds, probably time for a reminder about post #649 on page 33 (the adding of .\Subs to the default search path).

[cyberbeing]

Did you install the 64bit version by mistake?

[romulous]

I don't believe so - the other person reports that the new XYSubFilter still does not work for them either (they report that the video does not even start with 705). I will install again though just to be sure.

[cyberbeing]

And you are saying XySubFilter does work when you roll back to the previous version? I've double-checked the sample you provided using XySubFilter 3.1.0.705 + madVR 0.87.11 with ZoomPlayer 9.60b4, MPC-HC, MPC-BE, MPDN, and Potplayer and all are functioning just fine on my Win7 SP1 computer. I'd suspect something else is going on, so please redownload & reinstall the x86 version from GitHub (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.705/XySubFilter_3.1.0.705_x86_BETA2.zip), run Restore_Default_Settings.reg, and then run Install_XySubFilter.bat as Administrator and ensure you see a 'DllRegisterServer in XySubFilter.dll succeeded' message.

In general, the only reasons XySubFilter wouldn't load by default are:

The sample did not have an audio track
No internal subtitle pin available.
No external subtitles found.
No valid subtitle consumer found.
XySubFilter wasn't registered successfully.
Must install x86 version for 32bit media players.
Must install x64 version for 64bit media players.


If the video does not even start, maybe the user has MPC-HC VSFilter installed instead of xy-VSFilter? There is an issue with regular VSFilter which can cause playback failures when XySubFilter removes it from the graph. If you require VSFilter for other things, you need to ensure you install xy-VSFilter for proper operation. Otherwise just uninstall VSFilter if you don't need it. If another transform filter like FFDShow's Raw Audio/Video Processor are being used, you may want to try disabling those as well for troubleshooting purposes.

[romulous]

The previous version works on other clips, but does not work at all on the sample clip (Zoom doesn't even play the file). I am hampered slightly by not having access to the full file - but I have asked bLight (it is his file and he noticed the problem) to try uninstalling xy-VSFilter. As you would be aware, Install Center installs both xy-VSFilter and XYSubFilter (for good reasons), and Zoom chooses which one to use based on what video renderer you have selected. I will get back to you!

romulous

[cyberbeing]

I'm now totally confused now who has what problem, and what has and has not been tested. I have a hard time believing 3.1.0.705 not functioning at all with any subtitle sample could possibly be anything but user error, if that is what is being claimed. If there is still a problem only with a specific sample or setup or OS, but otherwise 3.1.0.705 functions the same as 3.1.0.697, that would be more believable. Could you please clarify the following along with any other details you find relevant:

1)
romulous, have you yourself done what I described in my previous post, including resetting to defaults?
What works and what doesn't work with 3.1.0.705 on your computer specifically?
If you uninstall 3.1.0.705 and repeat the steps in my previous post to install 3.1.0.697 (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.697/XySubFilter_3.1.0.697_x86_BETA2.zip) manually, what changes if anything?
If you place 'sub' after 'idx' in the LOAD_EXT_LIST key with 3.1.0.697, is there any change with your small sample?

2)
Has Blight himself done what I described in my previous post, including resetting to defaults?
What works and what doesn't work with 3.1.0.705 on Blight's computer specifically?
If Blight uninstalls 3.1.0.705 and repeats the steps in my previous post to install 3.1.0.697 (https://github.com/Cyberbeing/xy-VSFilter/releases/download/3.1.0.697/XySubFilter_3.1.0.697_x86_BETA2.zip) manually, what changes if anything?
If Blight places 'sub' after 'idx' in the LOAD_EXT_LIST key with 3.1.0.697, is there any change with his full sample?

[romulous]

Ok, short story didn't work, so here is the long story. bLight tells me that he has a movie which XYSubFilter does not show the subtitles on, and asks me to chase it up (report it as a bug in XYSubFilter). I don't have the movie myself, and I know that just posting here that 'XYSubFilter does not work with movie xyz' would not achieve anything. So I ask for a sample, which he cuts off the main movie (that 50MB file I posted). When I try the sample on my system, it has a different issue than bLight - I'm fairly certain that is because of how the sample was generated. bLight's issue was that the subtitles do not show. The problem I see is that Zoom does not play the movie at all, and MPDN (the other player I tried) crashes instantly. That to me says there is a fairly severe issue with XYSubFilter with the clip (the problems resolve when I move the two external subtitle files from the same folder as the movie).

So, that leads to my post here. You post build 705 - which I initially think works (because Zoom now plays the file). I then ask bLight to try it on the full movie, as I think the sample is problematic. He responds that Zoom does not play the movie at all with build 705, and asks me how I got it to work. I check - and find out that Zoom was not using XYSubFilter, but xy-VSFilter (it was using madVR, I don't know why XYSubFilter was not loading). I tell bLight that I was wrong, it doesn't work - and that leads to my 'I was mistaken' post above. I have asked bLight to do what you suggest - I don't think there is any point in me doing it, as I am convinced the sample is faulty in a different way - and am still waiting for a reply. If he can get Zoom to actually use build 705, and then get it to actually show the subtitles - all on the full movie - that is all that really matters. If XYSubFilter crashes MPDN and causes Zoom to not work on the sample, that is not really relevant.

When I get a response from bLight (I have just asked a second time, a few minutes ago, as a reminder to him), I will get back to you.

romulous

[cyberbeing]

I check - and find out that Zoom was not using XYSubFilter, but xy-VSFilter (it was using madVR, I don't know why XYSubFilter was not loading). I tell bLight that I was wrong, it doesn't work - and that leads to my 'I was mistaken' post above. I have asked bLight to do what you suggest - I don't think there is any point in me doing it, as I am convinced the sample is faulty in a different way - and am still waiting for a reply.

The reason I'm asking you to do it, is because of this. That should not occur, so I'd like you to try what I suggested and see if it resolves your problem with XySubFilter not loading (with any subtitle sample?). Honestly, what you are reporting yourself sounds like a more serious issue than Blight's problem, so I'd like to deal with that first. There was a crash/hang with the small sample, which 3.1.0.705 should have resolved if both idx+sub are present. Once you hopefully get XySubFilter working again I'd like confirmation if you can reproduce what I described with LOAD_EXT_LIST. Test in a media player other than Zoom Player if you must. I at least need to ensure there was not a serious regression from 3.1.0.697 to 3.1.0.705 which makes it stop functioning entirely upon update for some users.

[romulous]

Ok, sure - while waiting for a response from bLight, I shall run the test with 705 again. I am currently on the version that comes with Install Center (which is .211 for xyVSFilter and .697 for XYSubFilter I believe).

[romulous]

I will only be able to test with .697 and .705 though - I deleted my downloaded copy of .704 after .705 was released, and I see it has been removed from github (so I can't re-download it).

romulous

[romulous]

Ok, here are some results.

.697: By default (no registry changes), same results as previously reported. Zoom Player opens but does not play the file (but you have to restart it to actually play any other clips as well, so it may in fact be a crash), and MPDN instantly hangs. Removing both external subs files removes both issues.

.697: With the registry change, both Zoom and MPDN seem to work ok. I think the subs show as well. The reason why I say 'I think' is that they look odd, they look more like closed captions to me - for example, at 00:40, the words (Indian Music Playing) appear, including brackets. That does not look like any subtitle I have ever seen, so I am not sure that the sample clip actually has them (another reason why I wanted bLight to test with the full file).

.705: This time, Zoom seems to actually use XYSubFilter instead of xyVSFilter, as does MPDN. Both players seem to work ok.

Those were my results. bLight's results were roughly similar. He reported - and this was something I had noticed myself - that when you reset XYSubFilter's config, many of the registry keys (including load_ext_list) are not regenerated until you open the XYSubFilter config dialog from the tray icon and click Ok (you don't need to change anything, you simply click Ok). I don't think that is ideal myself.

Anyway, he wanted me to ask you something: is it possible to ignore 'sub' extension if there is an 'idx' file in the same folder instead of fooling with the order in the registry? He believes that would be a more reliable fix. The problem we have now is that the current registry fix will only work for new users - ie people who do not have a current installation of XYSubFilter.

[cyberbeing]

.697: By default (no registry changes), same results as previously reported.

.697: With the registry change, both Zoom and MPDN seem to work ok. I think the subs show as well.

.705: This time, Zoom seems to actually use XYSubFilter instead of xyVSFilter, as does MPDN. Both players seem to work ok.

Okay good, these are expected results.


Those were my results. bLight's results were roughly similar. He reported - and this was something I had noticed myself - that when you reset XYSubFilter's config, many of the registry keys (including load_ext_list) are not regenerated until you open the XYSubFilter config dialog from the tray icon and click Ok (you don't need to change anything, you simply click Ok). I don't think that is ideal myself.
I mentioned this to our developer a long time ago, but he seemed to have no interest in fixing the behavior which was a side-effect of the major refactor he performed on settings and registry handling. Overall it doesn't matter much, since our default settings will be used when a registry key is not present and normally you shouldn't be hacking at the registry.


Anyway, he wanted me to ask you something: is it possible to ignore 'sub' extension if there is an 'idx' file in the same folder instead of fooling with the order in the registry? He believes that would be a more reliable fix. The problem we have now is that the current registry fix will only work for new users - ie people who do not have a current installation of XYSubFilter.
I'm sure it's possible, but we have no active developer at the moment and it's not something I feel comfortable attempting to do myself. If the registry key change from 3.1.0.705 works, then that is your only option for the time being. Since Blight creates his own installer, he could modify it to delete LOAD_EXT_LIST upon install of 3.1.0.705 as a temporary measure. Since as mentioned above, the key does not actually need to be present in the registry for the new defaults to be used.

There used to be a way to depreciate registry settings with a new build since I know our dev did it once early on, but it's never anything I had done personally myself. Looking into it again now, I think I figured out why I could never get it working before. I thought I just needed to increase the supported version number, but I actually needed to enable this function for each setting I wanted updated individually, since for whatever reason it wasn't enabled globally. The original function only supports integer registry values, but after a bit of fiddling I seem to have gotten it working for string values as well.

I could probably include this in the next build, but I'm going to hold off releasing another build until next month, so I'm positive there are no more changes or fixes I need to include. I'll remember to include the .\subs path as well. In the meantime, I'll send you a test build.

[romulous]

Thanks, I got the PM :) I have asked bLight to take a look at your post as well.

romulous

[cyberbeing]

Blight is free to use those test builds in ZoomPlayer Install Center if he desires. They should hopefully work with his sample out-of-box, and depreciate load_ext_list and cache size registry values from prior versions (if they exist). Also as a reminder, he no longer needs to bundle unrar.dll from his installer when he updates it since both xy-VSFilter and XySubFilter have it static now.

[gommorah]

but we have no active developer at the moment

Do you think you could mirror the current codebase to SVN on the Google Projects host? As far as I could tell, all the git links I could see on the main page haven't had commits in a year or more (also, I don't know how to use git :P )

[cyberbeing]

Github repositories supposedly can be accessed via SVN as well. (https://help.github.com/articles/which-remote-url-should-i-use/#cloning-with-subversion) Does that not work for you? It really wouldn't hurt to just start getting familiar with GIT though. First just grab the latest msysgit release (https://github.com/msysgit/msysgit/releases) along with a client like SmartGit (http://www.syntevo.com/smartgit/) (free for non-commercial use), and you should rarely if ever need to touch the command line.

The only repository which is up-to-date is mine on GitHub (https://github.com/Cyberbeing/xy-VSFilter/) which updated last week for the recent releases. Only our dev has push access to repo.or.cz, so it's gotten way out of date at this point. Here is a quick rundown of active branches and some commits of interest, if you were going to work on things:
Master (xy-VSFilter Stable) (https://github.com/Cyberbeing/xy-VSFilter/tree/master)
vsfilter_rc (xy-VSFilter Development) (https://github.com/Cyberbeing/xy-VSFilter/tree/vsfilter_rc) Currently identical to Master, since I just released 3.1.0.306.
xy_sub_filter_rc3 (XySubFilter Development) (https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc3) + Temporary commit revert for xy_sub_filter_rc3 (https://github.com/Cyberbeing/xy-VSFilter/commit/caded623f9a801dbbf76eee3cf30bac6b8544fd0) Bugfix required
xy_sub_filter_rc2 (XySubFilter Unstable New Features) (https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc2) Requires bug fixes for partial-rasterization and partial-scanline.
blur_be_fixes (Blur/BE Implementation fixes) (https://github.com/Cyberbeing/xy-VSFilter/tree/blur_be_fixes) Not correct yet, introduces some rendering bugs
be_scaling_2 (Experimental alternative /be scaling method) (https://github.com/Cyberbeing/xy-VSFilter/tree/be_scaling_2) Visually more accurate most of the time, but has some issues with not always having a linear appearances with small jumps in scale factor
Experimental 8bit Blur/BE/Clip (https://github.com/Cyberbeing/xy-VSFilter/commit/def6de60dded8dcf2aaf06064c79412e238aa3f7) Unfortunately results in a rather extreme change in appearance for \be at high strength because it eliminates the 6bit rounding error of VSFilter 2.39

[ryrynz]

If I have a subtitle that starts at 2:00 and disappears at 2:07 if I change subtitles at say 2:03 or I skip to 2:03 then no subtitle shows until the next one appears.
Since the subtitle is supposed to stay till 2:07 why is it not shown at any stage up until that time?

[sneaker_ger]

This is not the fault of xy-vsfilter/XySubFilter but of the splitter/container format. The subtitle in e.g. mkv is stored at 2:00 and if you skip to 2:03 it might not be read by the splitter and consequently never forwarded to xy-vsfilter/XySubFilter. New additions to mkv could be used to fix this but a patch for LAV splitter (https://code.google.com/p/lavfilters/issues/detail?id=302&colspec=ID%20Type%20Status%20Priority%20Filter%20Summary%20Modified) with support has not been accepted.

[ryrynz]

This is not the fault of xy-vsfilter/XySubFilter but of the splitter/container format.

So it would seem the fix is to simply remux with MKVToolNix 7.0.0+

[sneaker_ger]

You would also need a suitable splitter - I only know of the patched LAV build. Vanilla LAV does not. (I can imagine there may be other splitters which handle these situations better than LAV even without the new mkv features, though.)

[Aleksoid1978]

Internal MPC-BE Matroska Splitter support CueDuration and CueRelativePosition on seek.

[Neroldy]

Maybe the xysubfilter didn't work fine for PGS subtitles in my laptop.
Here are two pictures about the xysubfilter and potplayer.

[cyberbeing]

Maybe the xysubfilter didn't work fine for PGS subtitles in my laptop.
Here are two pictures about the xysubfilter and potplayer.

Try XySubFilter + EVR-CP in MPC-HC, since they made a change in their subtitle consumer a few months ago so this would no longer happen, and PGS aspect ratio and positions would be maintained (matching their internal ISR behavior). Currently madVR stretches the XySubFilter PGS bitmaps like your left attachment when subtitle aspect ratio doesn't match video aspect ratio (like cropped video). This behavior is actually somewhat intentional for text-based subtitles and the like, but it's ultimately up to the subtitle consumer to decide how fixed resolution PGS bitmaps are displayed. I'd suggest opening a bug on madVR's bug tracker if you find the current behavior undesired.

[Neroldy]

Try XySubFilter + EVR-CP in MPC-HC, since they made a change in their subtitle consumer a few months ago so this would no longer happen, and PGS aspect ratio and positions would be maintained (matching their internal ISR behavior). Currently madVR stretches the XySubFilter PGS bitmaps like your left attachment when subtitle aspect ratio doesn't match video aspect ratio (like cropped video). This behavior is actually somewhat intentional for text-based subtitles and the like, but it's ultimately up to the subtitle consumer to decide how fixed resolution PGS bitmaps are displayed. I'd suggest opening a bug on madVR's bug tracker if you find the current behavior undesired.

:thanks:
In my laptop, XySubFilter in EVR-CP + MPC-HC/PotPlayer doesn't work, it seems XySubFilter only works on madVR. Like you said, if I use this PGS to match a 1280x720 movie, everything is fine. But for 1280x534, it becomes terrrible.
Another problem is that if I use XySubFilter, the PGS didn't match the movie's original time code, the PGS is faster than the movie nearly 5s. And if I use PotPlayer/MPC-HC without XySubFilter, everything is fine...

[cyberbeing]

In my laptop, XySubFilter in EVR-CP + MPC-HC/PotPlayer doesn't work, it seems XySubFilter only works on madVR.
Only MPC-HC and recent MPC-BE 1.4.4.65+ nightly builds support XySubFilter with EVR-CP. If you are sure you've disabled the ISR, yet XySubFilter still doesn't load with EVR-CP but does with madVR, you should ask in the MPC-HC thread (http://forum.doom9.org/showthread.php?t=166689) and see if someone can help you. There is no reason that should be happening.

Potplayer does not support XySubFilter with EVR-CP.


Like you said, if I use this PGS to match a 1280x720 movie, everything is fine. But for 1280x534, it becomes terrrible.
This isn't our issue, so you'd need to take this up with madVR or use XySubFilter with EVR-CP in MPC-HC 1.7.8 where this issue should have already been resolved. XySubFilter always sends PGS bitmaps at original size (1920x1080 for BD), at which point it is up to the subtitle consumer to decide how they are scaled to target resolution.

Another problem is that if I use XySubFilter, the PGS didn't match the movie's original time code, the PGS is faster than the movie nearly 5s. And if I use PotPlayer/MPC-HC without XySubFilter, everything is fine...
I would need a sample which can reproduce that if you are talking about internal/embedded PGS subtitles.

[Neroldy]

Only MPC-HC and recent MPC-BE 1.4.4.65+ nightly builds support XySubFilter with EVR-CP. If you are sure you've disabled the ISR, yet XySubFilter still doesn't load with EVR-CP but does with madVR, you should ask in the MPC-HC thread (http://forum.doom9.org/showthread.php?t=166689) and see if someone can help you. There is no reason that should be happening.

Potplayer does not support XySubFilter with EVR-CP.



This isn't our issue, so you'd need to take this up with madVR or use XySubFilter with EVR-CP in MPC-HC 1.7.8 where this issue should have already been resolved. XySubFilter always sends PGS bitmaps at original size (1920x1080 for BD), at which point it is up to the subtitle consumer to decide how they are scaled to target resolution.


I would need a sample which can reproduce that if you are talking about internal/embedded PGS subtitles.

:thanks:
You are right, the XySubFilter works well with MPC-HC + EVR-CP.
In the second problem, the PGS is not embedded in the video file, it is just at the same folder with the video. And I make a test, if I use mkvtoolnix to mux the video and PGS into one mkv file, the problem will not happen. But if I extract the PGS subtitle track from mkv file, for example movie.mkv + movie.Chs.sup, then the problem will happen again.

Finally, I find that if the PGS is not in the mkv file and I do not jump to any time, just watch the video from begin to the end, everything will be fine. But if I jump to some scenes, the PGS maybe faster than than the video even the PGS is disappeared until I open this mkv file again. Because if I mux the PGS into mkv file and situation will not happen again, I can't upload sample. I think you can extract the PGS track from mkv file using mkvextract and try my step, maybe it will happen again.

Anyway, XySubFilter is really a great subtitle filter. I hope it can be better and better.
:thanks:

[cyberbeing]

That sync issue when seeking external PGS subtitles is actually a known issue which was reported to us soon after it was implemented in XySubFilter back in 2013. Unfortunately, our external PGS support was a somewhat naive implementation, with our developer having only minimal knowledge of how the PGS parser/render code from MPC-HC actually functioned. It wasn't until a year later that MPC-HC got around to implementing proper external PGS support themselves, but at that point our developer had gone pretty much inactive. I haven't forgotten, we just haven't had anyone around which is capable of fixing this for quite awhile.

If you decide you want to disable use of external PGS with XySubFilter, you can remove sup from the HKCU\Software\Gabest\XySubFilter\General\load_ext_list registry key.

[Neroldy]

That sync issue when seeking external PGS subtitles is actually a known issue which was reported to us soon after it was implemented in XySubFilter back in 2013. Unfortunately, our external PGS support was a somewhat naive implementation, with our developer having only minimal knowledge of how the PGS parser/render code from MPC-HC actually functioned. It wasn't until a year later that MPC-HC got around to implementing proper external PGS support themselves, but at that point our developer had gone pretty much inactive. I haven't forgotten, we just haven't had anyone around which is capable of fixing this for quite awhile.

If you decide you want to disable use of external PGS with XySubFilter, you can remove sup from the HKCU\Software\Gabest\XySubFilter\General\load_ext_list registry key.

Thank you ~~
:):)

[Neroldy]

Maybe I find a little bug?
In the style settings of the subtitle renderer, the MPC-HC built-in is Angel (z,°)
14638
But the XySubFilter is Angel (z,?
14639

[cyberbeing]

Only a Cosmetic issue, but we could certainly fix that. It looks like the issue was introduced way back in 2011 when our Chinese developer used Visual Studio to re-save the resource file which caused a bogus conversion from English encoding to Chinese encoding.

[Neroldy]

Only a Cosmetic issue, but we could certainly fix that. It looks like the issue was introduced way back in 2011 when our Chinese developer used Visual Studio to re-save the resource file which caused a bogus conversion from English encoding to Chinese encoding.

Thank you ~

[Sm3n]

o/ Oy cyberbeing,

thx for keeping it updated.


I saw this: http://bugs.madshi.net/view.php?id=253

I also noticed an issue and maybe it's related.
Dunno if the Relative output height feature (I asked you to release, remember?) is to resize or keep the 1080p scale no matter the resolution of the video you are watching, but everytime a cropped or a resized video is playing, the size of my srt is changing. And no matter the resizing mode I apply using avisynth.


Screen:

No Avisynth:
http://i.imgur.com/drrQck6.jpg

Upscaled using Avisynth:
http://i.imgur.com/T5rNBmA.jpg

Same sub on real 1080p uncropped:
http://i.imgur.com/pMG3SQ1.jpg


You see? Is it possible to set a size for all the situations? so we don't need to configure a "2nd value" for cropped movie.



Hope you'll get what I meant and a fix is easily possible.

[cyberbeing]

I saw this: http://bugs.madshi.net/view.php?id=253

I also noticed an issue and maybe it's related.
Completely unrelated. That issue is specific to PGS subtitles only.

Dunno if the Relative output height feature (I asked you to release, remember?) is to resize or keep the 1080p scale no matter the resolution of the video you are watching, but everytime a cropped or a resized video is playing, the size of my srt is changing. And no matter the resizing mode I apply using avisynth.


You see? Is it possible to set a size for all the situations? so we don't need to configure a "2nd value" for cropped movie.

If you are talking about that "Relative output height" test build, I only vaguely remember the specifics. Though I believe that SRT should always have the same relative font size based on video height by default with even a normal build. The test build only readjusted shadow & borders sizes. Your scaled images are not the same output height. Your first and second screenshots have an output height of 339px, while your third one is 449px. That is why the subtitle size is ~33% larger. It sounds like what you are asking for is more like "Relative output width" rather than height.

[Sm3n]

oh OK I understand.

Well, I believe there is no such feature yet... :)

May I ask you if is it something perhaps you can/want/would work on?
Would be awesome for sure. But if I'm the only one asking for it, no need to waste your time I guess. ^^'


thx for your time


ps: once again sorry for my basic english, folks

[cyberbeing]

After a few hours of trial and error, I think I finally figured out a way to do 'relative size' instead of only 'relative height' or 'relative width'. Yet since I'm more of the project manager and not an experienced programmer, I wouldn't be surprised if this implementation had bugs or performance issues.

Use the following test build at your own risk:
XySubFilter_Relative_Output_Size_Test3 [Removed]
This build contains a major bug which causes display issues with styled ASS subtitles even without overriding styles, unless this feature is set to "original video" (disabled).
The build has been removed.

[ryrynz]

Both BE and HC are displaying ASS subtitles differently from XYSubfilter. Could you look into what's going on with them?

Also I'd like to know how/why BE/HC have different shadowing on the subtitles, I tried changing the what I thought were respective settings, but there was no change.
I do prefer less shadowing, so if you could let me know what needs to be changed or even change the defaults (do Be and HC have it correct?) that'd be grand.

I think consistent results should be seen ideally between all three subtitle renderers.

Screenshots (http://postimg.org/gallery/2sz77s28/), Source file (http://www.filedropper.com/hitsujithemelancholyofharuhisuzumiyaspecialendingh264vorbis)

[cyberbeing]

VSFilter 2.39, MPC-HC VSFilter, MPC-BE VSFilter, xy-VSFilter, XySubFilter, and Libass (mpv) are all handling that sample correctly and consistently.

As for what MPC-HC ISR and MPC-BE ISR are doing wrong, it's probably a combination of not handling anamorphic scaling of layout in a vsfilter compatible way, along with not scaling \be to match the visual appearance of VSFilter output when scaled.

I do prefer less shadowing, so if you could let me know what needs to be changed or even change the defaults that'd be grand.
There isn't any shadowing on that sample, only a 2px border and \be. If you reduce the border size in the script styles (HaruhiEDKan, HaruhiEDRo, HaruhiEDTL), it will result in a thinner outline appearance.

[Sm3n]

After a few hours of trial and error, I think I finally figured out a way to do 'relative size' instead of only 'relative height' or 'relative width'. Yet since I'm more of the project manager and not an experienced programmer, I wouldn't be surprised if this implementation had bugs or performance issues.

Use the following test build at your own risk:
XySubFilter_Relative_Output_Size_Test3 (https://www.mediafire.com/?51050y9i9awju7x)

Guess what? You're my man! You made my day so thank you so much.

We only have to remember that it only displays correctly on video with square pixels.
4:3 for instance (non-square pixels) doesn't display like we expect :/
Am I right?


Do I watch lot of 4:3? Nope :) (if needed, we can try the Scale y/x. That's right?)


Cheers :thanks:

[cyberbeing]

Guess what? You're my man! You made my day so thank you so much.
Maybe not. :( I just discovered a major issue with that build which can cause display issues with styled ASS subtitles, even when not using style overrides... It looks like the Test1 & Test2 builds had the same issue, but I never noticed. That shouldn't be happening, so I've pulled the dl links for all the Relative Size Test builds until a solution is found. It should be fine with SRT and other non-styled subtitles for the time being, if that's all you watch. But you'd need to remember to disable the feature to not get unexpected behavior with some ASS scripts.

We only have to remember that it only displays correctly on video with square pixels.
4:3 for instance (non-square pixels) doesn't display like we expect :/
Am I right?

For subtitle display on anamorphic video without requiring Scale y/x compensation in the script, you need to set "Render Layout Options" to "Use AR Adjusted Video Size" in XySubFilter options. That this is still required on SRT seems to be an oversight, since I thought we were going to ignore that option on SRT and other non-styled subtitles. Either we forgot, or that change got lost somewhere.

If this is not what you are talking about, you'd need to give me an image example or sample.

[Edit: Nevermind, I think I see what you mean. You were probably talking about normal 4:3 video displayed on a 16:9 monitor like your older post (http://forum.doom9.org/showpost.php?p=1683653&postcount=537), where subtitles size would be smaller at 1440x1080 (horizontal padding) then they are at 1920x1080. I never noticed this, since I actually use a 4:3 CRT. So for example, when I watched fullscreen with a display size of 1920x1440, both 16:9 (1920x1080) & 4:3 (1920x1440) would have the same subtitle size with that build. Which also happens to be the reason that test build kept a constant size with your earlier vertical cropping example. It seems what is needed is probably a user toggle to easily switch between relative width and relative height behavior, since I'm unsure if there is any practical way to do this automatically while also supporting constant size on cropped video. I'll put some thought into it.]

[Edit2: You could somewhat workaround this in that Relative Size Test3 build by using FFDShow to always pad your 4:3 videos to 16:9 to match your display. Except then you'd potentially have long subtitle lines displayed within the horizontal padding, which you may not desire.]

[Sm3n]

Yep that's it, cyberbeing. :) You 100% understood what was my thought. (And I know how it's hard for you guys to get all my brain is trying to translate. I do my best. huhu)

I'll look into FFDShow. I thought about that to be honest and I think I might deal with that. So thx for the confirmation.


Well you know, I only use srt file anyway. I can easely costumize it, not too much. Just what it needs. :) It's a pretty good small sub's extention (maybe the best).


For instance, I'm a big BluRays sup's hater.


Cheers again. You do great job!

[cyberbeing]

New relative size build, refactored to resolve the issue which was causing unintended display issues with some ASS subtitles when enabled. Otherwise not much different in behavior to the previous Test3 build, other than it now just having a just a simple enable/disable toggle. Originally I had planned to add a second option with a modified version of vsfilter's default 'relative height' behavior which functioned similarly to my 'relative width' option, but I was unsuccessful in making it do exactly what I wanted. Unlike our developer, I'm just not familiar enough with how all the srt scaling logic interacts with each other.

So unfortunately Sm3n, you'll just need to disable the option when you require constant size with horizontal padding. I have modified the 'relative size' option to produce identical output at 1920x1080 display with and without the option enabled, which should at least make switching between the two a bit easier in that scenario.


XySubFilter_Relative_Output_Size_Test4 (https://www.mediafire.com/?g2t13bqwcg437gp)

[Sm3n]

That's very nice of you. I'm gonna give a try right away.

thx

[cyberbeing]

XySubFilter_Relative_Output_Size_Test5 (https://www.mediafire.com/?4lpklb7qo9hx11j)

Okay Sm3n, I think I've now finally gotten both your requests working, as well as some automated handling. I still need to simply the code significantly, but here is a preliminary new test build which adds the following 'Relative Output Size' modes for SRT and other unstyled subtitles:

'Display' = Maintain constant size in fullscreen.
This mode currently only functions with madVR, since it's the only consumer which reports the optional displayModeSize parameter. If using MPC-HC/MPC-BE/MPDN, the behavior reverts to 'Disable'.

'Width' = Scale determined by output width.

'Height' = Scale determined by output height.

'Disable' = VSFilter default behavior. Similar to 'relative height', except border & shadow size varies with video resolution.

[Eamon]

Hi guys,

I've got a bit of a newbie question here. Basically, I've been using aegisub for some typesetting effects to hardcode onto video.

I've always been using VSFilterMod for both aegisub and for hardcoding (I use Hybrid (http://www.selur.de/) program ver 2014.12.23.1).

But I have a problem. In Aegisub, when I rotate subtitles on the x and y axis (to give them depth), it shows up well on Aegisub but not so well when hardcoded. The end result is instead of text rotating into/out of the screen, it kinda slants on the z axis instead.

I'm not sure if this is a problem with the entire hardcoding process or just the filter I'm using in it.

So I tried using xysubfilter but Hybrid doesn't seem to like it. I keep getting a message about framerate node and that it'll ignore the stream. Btw, I use an avs script to load up everything.

Does anyone have any ideas?

[vivan]

Check script resolution (subtitle -> resample resolution in aegisub). If it's different from video resolution it will explain differences in rendering.

[Eamon]

Check script resolution (subtitle -> resample resolution in aegisub). If it's different from video resolution it will explain differences in rendering.

Checked. Both are 1280x720.

[cyberbeing]

I've always been using VSFilterMod for both aegisub and for hardcoding
If your issue with VSFilterMod only, I'm unable to easily help you. VSFilterMod contains a lot of unique tags and transform behaviors which aren't VSFilter compatible. If you authored your script with VSFilterMod, you must use VSFilterMod to hardsub it. Unless you require some of the special tags or functionality which VSFilterMod provides, I'd suggest just using xy-VSFilter for both authoring and hardcoding. Scripts authored with xy-VSFilter should be compatible with legacy VSFilter 2.39, MPC-HC VSFilter, and of course xy-VSFilter itself for hardcoding purposes.

But I have a problem. In Aegisub, when I rotate subtitles on the x and y axis (to give them depth), it shows up well on Aegisub but not so well when hardcoded. The end result is instead of text rotating into/out of the screen, it kinda slants on the z axis instead.
If this occurs when using xy-VSFilter for both authoring and hardcoding as well, I'd suggest you take some screenshots of the difference you are seeing.

I'm not sure if this is a problem with the entire hardcoding process or just the filter I'm using in it.

If your results in Aegisub appear differently than your subtitles when hardcoded, it is something wrong with your hardcoding process.

So I tried using xysubfilter but Hybrid doesn't seem to like it.
...
Btw, I use an avs script to load up everything.
If you are hardcoding, you need to use xy-VSFilter not XySubFilter.

That said, if you are already using an avs script to load and filter your video, the normal procedure for hardcoding subtitles is to then load them via TextSub (available when vsfilter.dll is loaded as plugin). As long as the video loaded in aegisub, the script playres, and the video you are hardsubbing are all the same resolution, you shouldn't have any unexpected display issues.