Note: this article has nothing to do with video, releases or whatever else you usually care about, I’m going to talk about typesetting. If you don’t know what it is or don’t care – stop reading right now.
As you might know, there’s the haruhichan guide to 10bit, which is apparently one of the most popular playback guides lately. It’s more or less right but there’s one problem – the author (nand) suggests you to use internal MPC-HC renderer (ISR for short) to get the most awesome 10bit playback.
After getting a couple of complains about our bakemonogatari typesetting and reading some derping about broken TS on different forums, I decided to at least explain things to nand since he seemed adequate and might want to update his guide. I joined CGi channel and showed him two test samples on which ISR used to fail.
“If you’re analpained about test cases, aspect ratios or watch anime with shitty typesetting, use a different subtitle renderer like xy-VSFilter. Be warned though, the subtitles will be very blurry as a result. I recommend waiting until it supports madVR’s overlay hooks like MPC-HC does. Alternatively, don’t use subtitles (thanks tp7 for the suggestion)”
…What? I was a bit surpised with this stupid update and figured I’ll explain things to you myself.
Nowadays, there are three major subtitle renderers:
- Libass (mplayer2).
- VSFilter and its forks (threaded-vsfilter, xy-vsfilter).
- Internal MPC-HC VSFilter, which is essentialy original VSFilter with some modifications.
But let’s start with some theory.
In a simple case, your video playback routine looks like this (1920×1200 monitor, 720p video):
Note that there’s one important difference – subtitle renderer works before video renderer in the case of libass/VSFilter, while ISR works after video is rendered. What does it mean? Quite much.
Libass and VSFilter most likely merge subs into video while it still has its original resolution and non-RGB colorspace (this works like described unless you’re converting your video to RGB in the decoder or use ffdshow’s resize functions. You shouldn’t do it – this is a renderer’s job and madvr does it perfectly). Then renderer resizes your video without caring about subtitles being on it and converts it to RGB.
Note: this is completely true only for xy-vsfilter. Original VSFilter still converts the video to RGB, renders the subs and then converts it back to YV12. This doesn’t affect any of the following comparisons, though.
ISR, however, works on a resized (if resolution of your screen != resolution of the video) video with black bars added (if aspect ratio of your screen != AR of the video), which is already converted to RGB. Thus it needs to resize subtitles to your screen resolution and renders them in RGB to correctly blend them with video. And this is where all the fun starts.
First of all, I won’t speak much about libass. It’s good and all, but has its own problems and AFAIK there’s not a single one fully working DirectShow realization. Just look at the OP pic and you’ll get the idea how awesome libass works with UTW’s Amagami SS Plus Ep01.
Not all ass tags are resizable (or at least easily resizable). Here is a sample video that shows you how ISR fails to resize \fry and \frx (basic 3d-rotation tags). Just run it with ISR and see for yourself.
But well, according to nand I’m being “analpained about test cases” so here are some more examples. From our PPD release:
Original ISR | Resized ISR | Resized VSFilter |
Again, ISR is broken.
But but but… maybe it’s just our shitty typesetting? Okay, possible. More fails:
- UTW’s Ano Hana, Ep03 (typeset by __ar):
Original ISR
Resized ISR
Resized VSFilter
- Chibiki’s The Idolm@ster, Ep25 (typeset by Daiz):
Original resolution ISR
Resized ISR
Resized VSFilter
One more time:
Original ISR
Resized ISR
Resized VSFilter
If you still think that it’s only about shitty typesetting – please, find me someone better than these guys (Note: I’m not sure if it’s possible).
I hope you got the point – many of 3d rotations will be broken for you with ISR.
One more problem about resizing – anamorphic video. VSFilter, so as libass, applies subs to the video before it’s resized to display resolution, while ISR goes its own way and does the same thing after. The result is different horizontal scaling of subtitles:
ISR | VSFilter |
Yet again, this can easily break all typesetting if the subs were typeset with VSFilter behavior in mind (REC for some reason doesn’t have any typesetting and I don’t have any other anamorphic video right now, so no _real_ examples).
But that’s not all. You can notice that on the second resized ISR screenshot of iM@S some letters are placed outside the video frame. And this is yet another problem with this broken piece of software – it can’t clip subs to the original picture resolution, so it actually renders subs even if they’re outside the video frame. Here’s a sample from our Maria Holic release, and one more example of __ar’s Ano Hana typesetting:
Original resolution | Resized ISR |
And no, your favourite argument about “Position subtitles relative to the video frame” setting in ISR won’t work – it doesn’t help in this situation.
I wish I could stop here, but there is one more problem. I didn’t mentioned RGB conversion for nothing, it’s yet another thing that works differently in VSFilter and ISR. Here’s a sample of qIIq/THORA bakemonogatari typesetting, or some screenshots from it:
ISR | VSFilter |
As you might know, there are basically two different colormatrices which are used during YUV->RGB conversion: Rec601 and Rec709. First one is almost always used for SD content, second one – for HD video. The problem lies in when this conversion happens – in the case of correctly configured playback, it is done in a video renderer (e.g. MadVR), thus VSFilter (so as libass) applies subs to original YUV stream, and then renderer does its job (converting both subs and original video as a single frame using one colormatrix), while ISR merges subs with the final RGB picture. This is important for HD content: if the subs were typesetted to Rec601 video – they’ll work just fine with VSFilter while ISR will give you wrong colors since it doesn’t care about colormatrices and uses the colors exactly how they were defined in the subs.
Note: this is a little funny, but Aegisub with ffvideosource video provider outputs HD video using Rec709 colormatrix – thus colors will actually work right in ISR, but end up broken in libass/VSFilter. However, I think most of typesetters know this problem and use one of the ways to get Rec601 video even for HD stuff (like, opening the video via avisynth script with ConvertToRGB(“Rec601″) line in it, or using patched ffms2 builds). This was already reported to ffms2 and Aegi devs and I hope will be changed in the future.
But there’s one important thing – since VSFilter applies subs in video resolution before it was resized to your screen resolution, the subs will have lower resolution compared to ISR, in other words: will be blurry. This, for some reason, seems to bug a lot of people, but I actually don’t see any problems here. The sharpness highly depends on your video renderer’s resizer, and as a wise guy said – most subtitles might look too sharp if rendered at 1080p when the video is 720p. Here’s a simple comparison made by Daiz:
Sure, this is somewhat more important for SD content, but yet again, it depends on many factors – your video renderer, used fonts, border and background colors. And I guess this was the main reason why Nyaa nowadays allows 576p upscales of DVD content (not to mention that typesetting of 480p video is a little painful).
tl;dr
- If you’re fine with broken 3d rotations, broken clipping, broken colors, lags on some heavy typesetting but want your subs to be sharp as much as possible – use ISR. But don’t recommend it to others and don’t complain – not a single typesetter in his right mind would guarantee compatibility of his typesetting with ISR. Again: not a single one.
- If you want subs to actually work right – use VSFilter. The best of available forks is xy-vsfilter (the one author of this article uses, so as many other cool guys :) ). It’s basically VSFilter with some great speed improvements.
- You should stfu about subtitle renderers if you know nothing about typesetting
, nand.
Note: here’s one interesting thread about the new subtitle renderer interface, so things might actually change in the future and hopefully ISR will finally die.
Stop being analpained about test cases, aspect ratios or watch anime with shitty typesetting.
January 18, 2012
at 12:17 pm
Well fucking said.
January 18, 2012
at 12:27 pm
also
>taking the opinion of any coalgirls member seriously
January 18, 2012
at 12:28 pm
I installed the xy-vsfilter.dll correctly but and ran mpc-hc on a couple shows with heavy karaoke effects. The characters that were originally kanji now only show up as boxes. This has happened to me before but the problem went away by itself for some reason. Any ideas?
January 18, 2012
at 1:08 pm
1. Fansubbers forgot to include the font they used for kanji and you don’t have it installed. Demux the script, find kanji style and check if its font is presented in the mkv. This is most likely not the case since you have this problem with multiple shows, though.
2. You forgot to run regsvr32 command on xy-vsfilter.dll
3. You’re using Windows XP. I don’t remember the solution for this case, except hurr durr stop using Windows XP.
I don’t remember any other solutions since I’ve never had this problem.
January 18, 2012
at 1:20 pm
Thx for the help. I ended up just reinstalling some stuff and it somehow magically fixed itself, though knowing my luck it’ll probably break again for no apparent reason >_<
January 18, 2012
at 6:37 pm
Just to clarify, what you write about libass really depends on what video output you pick in mplayer. The default one (direct3d or something) may work like that, but wiith -vo gl subtitles are clearly applied last, as they’re rendered at desktop resolution and you can turn them on and off while the video is paused.
January 18, 2012
at 1:30 pm
Yeah, torque mentioned it yesterday.
Still, does it resize those samples/convert to rgb correcty?
January 18, 2012
at 3:05 pm
nand here, thanks for writing it up so I don’t have to, I’ll just link this post.
I wanted to clarify why I said “shitty typesetting”. I don’t mean “shitty” as in “type-set by people with low amounts of skill”, I meant “anime that has fucking over the top styled SSA/ASS bullshit everywhere”.
To me, anime is about content, and I endorse simplistic typesetting that gets the point across instead of layering lots of 3D effects on top of gaussian blurs and whatnot. I have big words across my screen in the first place, whether or not signs neatly fit into the source video or not doesn’t change that. The immersion is still broken. I think it’s unnecessary to be perfectly honest.
I’ve *never* come across a single anime release in my personal viewing since writing that guide where the subtitles become a problem or unreadable as a result of ISR on a 16:10 screen, it’s just test cases sent to me by others. And to me, I’d much rather have decent, READABLE, sharp 1080p subs than blurred, sub-pixeled 360p crap that “fits into the video”.
January 18, 2012
at 4:17 pm
Well, the problem is not whether you like typesetting or not, the problem is that it does exist, and recommending people to use something that cannot render it right is just wrong. It doesn’t matter if it’s still readable or not – wrong 3d rotation and clipping are wrong and actually disturb me (and I assume almost all users) on playback. If you’re fine with it – it’s just you.
Anyway, what sub-pixeled 360p crap you’re talking about? Don’t tell me that you meant chroma resolution, it’s more than just wrong (may as well say that there’s no 1080p video since it’s actually 540p one). And I don’t see how VSFilter made something UNREADABLE on any of screenshots above. Sure less sharp but you won’t even notice the difference in most cases, unless you watch anime on 2560×1440, looking at the screen from 10cm distance.
Also this additional blurring sometimes comes from the fact that \blur behavior depends on subtitles resolution. And this is, yet again, ISR’s fail since it actually displays subs not in the way it was intended by a typesetter.
January 18, 2012
at 4:33 pm
Here’s an example from the last Anime I watched
http://img109.imageshack.us/img109/3433/subcompare2.png
Top is ISR, bottom is VSFilter. I can’t read it without getting a headache.
January 19, 2012
at 4:49 am
Personally, I think the ideal solution would be to split subtitles into two tracks: One for signs, bitmaps and other in-frame content, the second for dialogue.
Then, we can use xy-VSFilter for signs and such which would most likely be transformed/blurred/styled to match the video frame, while using ISR for the actual dialogue.
January 19, 2012
at 4:52 am
What’s the source/renderer?
Because as I said, it depends too much: I don’t get such bad result even on anamorphic 480p (and there can’t be anything worse, really, unless you watch some VHS encodes or something), not to mention 576p. Also as you could probably notice, ISR line on 576 screenshot looks too weird since the lineart on the background is blurred.
Moreover, if you want your subs SHARP even with SD content, you still can resize video in ffdshow or change subtitle resolution in vsfilter. I assume you’re using postprocessing anyway, since most of SD anime is too blurry, it won’t be difficult.
BTW, your idea about using two tracks is possible. You just need to open a script it in aegisub, sort it by style, save signs/dialogue to separate tracks, load signs with vsfilter (active by default) and then drag-n-drop dialogue subtitles to your mpc windows. ISR will load them and you’ll get 2 renderers working at the same time.
January 19, 2012
at 6:28 am
>What’s the source/renderer?
Source is bakabt’s recommended release of Millennium Actress, renderer was ISR for top and xy-vsfilter for bottom.
About your 576p screenshot, I honestly think the top looks way better than the bottom. It’s not weird in the slightest. The bottom gives me a headache.
>Moreover, if you want your subs SHARP even with SD content, you still can resize video in ffdshow
There’s no good software rescaler though, I can’t live with anything but madVR. To clarify, I require fully linear light spline64, using Mitchell-Netravali for chroma content beforehand. I haven’t seen anything but madVR offer that, let alone linear light scaling – furthermore, ffdshow’s limited precision is horribly limiting in this regard, and it doesn’t even support P016 output in the first place (let alone dither as well as madVR). I simply can’t use software rescaling as a compromise.
>BTW, your idea about using two tracks is possible. You just need to open a script it in aegisub, sort it by style, save signs/dialogue to separate tracks, load signs with vsfilter (active by default) and then drag-n-drop dialogue subtitles to your mpc windows. ISR will load them and you’ll get 2 renderers working at the same time.
Great! Now if every fansubber started doing this life would be so easy.
I’m still waiting for https://code.google.com/p/xy-vsfilter/issues/detail?id=40 to be implemented before culling out every last mention of ISR from the guide.
January 19, 2012
at 6:42 am
Spline 3-taps vs. spline 4 taps + linear light.
Why in the world would you want it?
January 19, 2012
at 6:56 am
Simply put, linear light is the only correct scaling behavior – images are not supposed to be scaled in gamma compressed space. It can cause problems in a lot of situations involving high contrast patterns, a very good example is the following image comparison:
http://img715.imageshack.us/img715/2231/upscalecomp.png
The inset shows the original colors, while the top two are compressed light scalers (the madVR screenshot was before the linear light option was added. I took these for the sake of convincing madshi)
The bottom screenshot shows a linear light scaler I wrote for the purpose of demonstration. You’ll notice that the colors get preserved much more accurately in the linear light scaler.
January 19, 2012
at 7:09 am
And then he’s calling me “analpained about test cases”.
Okay.y4m
January 19, 2012
at 7:25 am
judging by the picture, LLS is for extremely rare shitcases and I wonder if its effect is mostly visible on cheap TN-monitors with limited color gamut (6-bit dithered to 8).
January 19, 2012
at 11:12 am
I could easily be wrong, but I believe the major problem may be that ISR is ignoring the PlayResX and PlayResY
January 18, 2012
at 7:26 pm
If you want subs to actually work right – use VSFilter. The best of available forks is xy-vsfilter (the one author of this article uses, so as many other cool guys :) ). It’s basically VSFilter with some great speed improvements.
regsvr32 *.dll and all? or what?)
January 18, 2012
at 7:55 pm
>speed improvements
No, it’s a fork with a lot of cpu-heavy features disabled to reduce the load. It’s faster because it’s crippled.
January 20, 2012
at 9:23 am
Where is it crippled?
January 20, 2012
at 9:29 am
Okay, crippled might have been an overstatement, and a big one at that, but some rendering algorithms have been altered to simpler versions that reduce load. This might cause typesets that render not in line with how the typesetter meant it in the first place and for reasonably complex TSes might even break them just enough to bother you (for example just not covering the original or being just out of boundaries). But I’m more worried how xy-VSFilter handles internal render settings; I don’t know this for sure, but I suspect that it is too much optimised for speed and poorer computers that high-end computers will needlessly simplify the typesets and end up settling for something worse than they bargained for. In the end, I’m worried about those few pixels that only 0.1% of the audience cares about.
How I wrote it was seriously much stronger language than I intended. I blame the Internet.
January 20, 2012
at 12:13 pm
Examples please, examples. I’m using it for a few months already, and noticed a problem with typesetting only once (and it was mostly my stupid mistake).
January 20, 2012
at 12:20 pm
@lexi
You’ll need to open an Administrative Command Prompt, navigate to where you’ve extracted and plan to store xy-VSFilter’s VSFilter.dll on your hard drive, and run:
regsvr32 VSFilter.dll
@Gyzome
No matter how much xy-VSFilter is optimized, the goal has always been to remain frame-by-frame pixel identical to VSFilter with zero regressions. Code has been optimized, but nothing has been simplified to lower quality or accuracy as you seem to suspect. All complex typesetting and karaoke should render identically to VSFilter. If it doesn’t, please report a bug on GoogleCode so it can be fixed.
The two biggest things which make xy-VSFilter faster are caching (eliminating redundant calculations), and only alpha-blending dirty areas of the frame (i.e. if only 320,000px change there is no reason for quality or otherwise to alpha-blend the entire 2,073,600px frame like VSFilter does). The other improvements and optimizations like rendering in AYUV 4:4:4 instead of ARGB 4:4:4 are rather minor by themselves, but there are enough little things that they begin to add up to significant gains.
Don’t forget that while xy-VSFilter does narrow the gap rather significantly, it is still slower than Libass. There is still plenty of potential left for improvement in xy-VSFilter, some feasible yet time consuming, others impossible since they would break perfect VSFilter compatibility. You can still see the extreme slowness of the VSFilter rendering core, which is maintained within xy-VSFilter for compatibility, by setting all caches to 0 or 1.
January 20, 2012
at 1:31 pm
Well to be honest most of my opinion on xy-VSFilter was based on a guys rant that I somehow found credible, but since you seem to be a lot more familiar to the project, I see no reason keep thinking like that. Hell, if what you said is true, then I’m switching over. One thing I am curious about, though: the original VSFilter (haven’t used it in a while now) possessed the option to automatically pad video to screen size, allowing the subtitles to be moved under the image when viewing 21:9 material (and if I’m not mistaken, it would only do this for unstyled subtitles like SRT as to not fuck up ASS styling). Does xy-VSFilter still have this option?
January 21, 2012
at 8:27 pm
xy-VSFilter has been a very fast moving project up to this point. Depending on how long ago someone tested, xy-VSFilter may have had issues worthy of criticism. Yet the developer xy has been awesome, and has really earned the much needed break he is taking currently. Over the course of two months between September and November he has fixed all known regressions, counting no less then 50. Trust me when I say, speeding up the extremely fragile VSFilter codebase while retaining identical output and functionality has been no easy task, but I’ve long since swayed the developer into understanding the importance of maintaining perfect compatibility with VSFilter style rendering and quirks.
Ever since the first stable build was released at the beginning of December, there are no known rendering bugs, and none have been reported since. We’ve reached a point that we feel confident recommending xy-VSFilter 3.0.0.1 for widespread adoption. The burden is now on the users to identify and fansubbers to try to break xy-VSFilter with complex or odd-ball scripts, and report any remaining issues found. We’re also in need of any realistic script samples which don’t run in real-time in xy-VSFilter (i.e. complex karaoke/typesetting scripts which were so slow that they needed to be hardsubbed), to help with future optimization ideas.
The Vertical Padding setting is one of those legacy features which does still exist in xy-VSFilter, but it’s never been thoroughly tested by us. If you find behavior changes compared to VSFilter 2.39/2.40, please report them. Feature requests for expanding or changing the behavior of the Vertical Padding functionality are best directed at the MPC-HC project. Ultimately, Issue #40, which will act as a replacement for the ISR in MPC-HC, is expected to resolve anything lacking in VSFilter’s ability to move subtitles below the video frame if desired.
There is one known issue stemming from the hackish nature of that feature which you need to be aware of. Bugs in FFDShow and various other decoders will cause them to crash when xy-VSFilter requests Vertical Padding when doing a format change on reconnection. CoreAVC has a related bug with YUY2+Haali Renderer only which will cause the video to be padded with green bars instead of black. Hopefully someone will report these issue to the FFDShow and CoreAVC devs and they will get fixed, but for the time being we recommend that all users of the Vertical Padding setting migrate to the LAV Video decoder from the LAV Filters package, since it doesn’t have either of these bugs.
January 21, 2012
at 11:46 pm
> to try to break xy-VSFilter with complex or odd-ball scripts, and report any remaining issues found.
Okay. :)
January 22, 2012
at 1:09 am
Well, I would never expect scripts like below can be rendered in real time, but if you would really prefer a try:
[Foasis][EVA][1.11][ED].7z
January 22, 2012
at 8:34 pm
I think you’re thinking of vsfilter-threaded, not xy-vsfilter. The former did exactly what you describe, by rendering shitty versions of effects such as blur or shadows for faster speed.
January 21, 2012
at 1:01 am
The only tag in threaded-VSFilter that differs from VSFilter 2.40 is \be. In cases where \be is used with a large number of passes (i.e. >5), threaded-VSFilter uses an approximately equivalent Gaussian blur by reversing the method described by Kovesi. \be normally uses a 3×3 box blur and repeated applications of a box filter will eventually approximate a Gaussian filter anyway so I didn’t see it as too much of a compromise between compatibility and performance.
I don’t know what you’re talking with regards to shadows.
January 21, 2012
at 7:31 am
There WAS no way to use DXVA along with vsfilter, forcing many people use ISR instead. Now LAV Video supports decoding video using DXVA, and copy the decoded contents back from GPU, so that post-processing like FFDShow/DirectVobSub can be applied after DXVA. Then I think there is nothing to be complained about vsfilter, especially fast and 10-bit rendering capable xy-vsfilter.
January 18, 2012
at 10:02 pm
>Now LAV Video supports decoding video using DXVA, and copy the decoded contents back from GPU
Note that this feature has been around in potplayer for ages. It’s basically impossible to use on most AMD cards since AMD has such poor VRAM <-> RAM bandwidth, you’ll get lots of stuttering and frame drops when attempting to copy a 1080p frame from the GPU back to RAM and then back to the GPU. It’s mostly viable for nVidia cards, but if you have one, why not just use CUDA in the first place?
January 19, 2012
at 4:42 am
Indeed, but one could not use this copy back mechanism out of PotPlayer before LAV supports it. And I’m not sure if your conclusion of AMD cards is generally true or not, as DXVA2(copy back) works pretty well for me on my 6770M. The speed is not fast but at least no noticeable frame drops occurs when decoding 1080p videos at 24000/1001 fps.
January 20, 2012
at 11:22 pm
Potplayer has had it before I was even aware LAV existed; it was called DXVA (renderless) which basically meant it didn’t get rendered by DXVA but got copied back into the video pipeline.
I’m using a HD4890.
January 21, 2012
at 12:59 am
У меня достаточно давно такая схема:
720р – ffdshow spline resize to 1080p – threaded-VSFilter_08062011
И да, поздние версии этого мода VSFilter – говно, в которых убито отображение многих тегов. Собственно, единственное для меня преимущество над VSFilter из CCCP – они не мигают (принцип автор описывал). BTW, MPC-HC VSFilter – мигающее подвисающее Г.
Проблема xy-VSFilter – он основан на древней версии VSFilter 2.39, и тормозит на i7-860 на 1080p. Про убитое оформление я молчу.
January 19, 2012
at 7:47 pm
Я имел ввиду ISR, а не сам MPC-HC VSFilter. MPC-HC VSFilter как раз годный – и буферизация и анимация одновременно. Добавили бы ещё (опционально) anti-flickering patch из сборки threaded.
P/S/ Чем не скейль сабы 720p, всё равно будут тошнотворно-замыленные, ИМХО.
January 20, 2012
at 1:29 am
Pingback: [轉載] 10bit視頻編碼——特性及全面播放方法介紹 [五之四] | 安樂淨土
OMG thank you very much for leading me to xy vsfilter. When Coalgirls released their version of Macross Frontier, various parts of the soft karaoke were laggy and buggy, sometimes even just disappearing. I realized later than only VLC’s libass was able to handle it properly, and once I installed the new vsfilter it completely fixed my problems.
January 22, 2012
at 12:29 pm
Haven’t read everything, but what you say about libass is wrong. You have been corrected somewhere, but here’s the full story:
First, libass is a library and can be used by mplayer2, mplayer, vlc, xbmc, gstreamer, and probably others. libass itself doesn’t actually render anything on the screen or on video, it just outputs a list of subtitle images. It’s up to the player to do something to render these. It’s worth noting libass always uses RGB colors. For simplicity, you can assume libass outputs RGBA images. (Actually alpha images + blended RGBA color.) It’s not really clear what colorspaces these video renderers use, but at least mplayer2 attempts to use Rec601 for SD resolutions, and Rec709 for HD.
At least mplayer and mplayer2 provide various ways to render the libass generated images. With the vdpau or gl renderers, the libass images will essentially be rendered as RGBA directly on the screen, using screen resolution. There are no colormatrices involved. If you use the xv renderer (which is still the default on mplayer2, unless vdpau is available), the vf_ass.c video filter will be used. The ass video filter renders the libass images into the video stream, using video resolution, converting the RGBA colors to Rec601. Even if the video is actually rendered as Rec709.
That is all.
January 23, 2012
at 9:09 am
I know what libass is and what images it outputs. Since I don’t really care about mplayer2, vlc and others, I was simply speaking about how a correct DirectShow libass-based filter would work.
But thank you for clarifying mplayer2 rendering, anyway.
January 23, 2012
at 9:16 am
Pingback: Anonymous
xy-vsfilter is the bees-knees, it’s like I bought a new computer when I installed it
January 30, 2012
at 10:59 am
VLC 2.0 (which uses libass iirc) does render in the viewing resolution instead of the video resolutions, however 3d rotations appears to work fine. (1920×1200) Clipping also looked fine. Couldn’t test anamorphic and the color space test finishes before I can tell what is going on. (I think there was a pause on last frame option, but I can’t find it.)
It is probably not perfect however the point is that the issue is not that the viewing resolution is used, but that it does not take in account the differences this makes.
So it will be possible to achieve the sharpness of ISR without having these issues, it is just a matter of doing it right. VLC is actually doing it better than ISR as it renders in the viewing resolution and not the screen resolution. So if you are viewing a 720p video in windowed mode, it renders in 720p and not like ISR which continues to render in 1080p and then downscales to 720p which results in the text blurring a little bit. It is not too bad, but I found it annoying nevertheless.
(I’m not saying VLC is the holy grail though, as it has some banding issues with Hi10p content, but I definitively like how it is scaling the subtitles now.)
If there really are videos out there which are only upscaled only to make softsubs render in a higher resolution I will cry…
February 1, 2012
at 8:41 am
Yeah, libass actually does it right on my tests, but the problem is still in the fact that libass is not a directshow filter. Switching from the lovely MPC to mplayer/VLC is not an option for :everyone:.
Moreover, if libass makes its way to DirectShow as an external filter, it’ll still work the same way as vsfilter right now, i.e. at video resolution.
February 1, 2012
at 9:03 am
I apologize if I simply missed it somewhere, but is it possible to use MadVR with VSFilter for subtitles or is ISR the only subtitle option for MadVR? I gave it a shot, but couldn’t get MadVR/VSFilter working and am not sure if I’m simply doing it wrong.
February 2, 2012
at 2:59 am
Yes, it is possible.
You can use VSFilter on any renderer(unlike the ISR). Set DirectVobSub(not the auto loading version) as “Prefer” on External Filters in MPC-HC.
February 2, 2012
at 3:19 am
It doesn’t seem to work for me even after having done that. I thought it was a problem with MadVR because when I set MPC-HC’s Output to EVR-CP, VSFilter loads normally. As soon as I switch the Output to MadVR, VSFilter no longer loads at all.
I’m using the latest versions of MPC-HC, MadVR, LAV Filters, Haali Media Splitter, and xy-VSFilter. Again, everything works perfectly under EVR-CP. I’m stumped.
February 2, 2012
at 3:34 am
Disable the internal h264 decoder on madVR.
February 2, 2012
at 4:17 am
Ah, that did it.
Many thanks for your help.
February 2, 2012
at 5:11 am
Just dropping by to say I use mplayer2 now. I won’t be updating the guide you linked anymore.
February 4, 2012
at 12:17 am
Why not?
February 5, 2012
at 6:43 am
Pingback: Configurando codecs no Windows (Atualizado) « Tecnologia e etc.
libass subs with mplayer/mplayer2′s gl output will render at native resolution
February 7, 2012
at 7:07 am
Forgive me if this is the wrong place to ask for help with this problem; I’m not sure if this bug is caused by my subtitle renderer or not.
It appears that when a video’s subtitle file contains characters with macrons, these characters are replaced with about three underscore’s worth of blank space.
Here’s a screenshot example where “Hāfez” was replaced with “H fez”:
http://img543.imageshack.us/img543/3728/tormaidlastexileginyoku.png
Any ideas on the cause? Thanks in advance for your help.
February 7, 2012
at 7:45 am
My educated guess is that it’s a problem with the font, which might not contain the ā glyph. If that’s the case you should report it to the fansubber, which in this cas would be Tormaid.
Also, what ever happened to actually releasing stuff, tp7?
March 8, 2012
at 6:58 pm
RL happened, mostly.
March 8, 2012
at 7:31 pm
Ah… I suppose that, as fansubbers, we’ve all been there. Take it cool, no need to rush; we’re not your clients and there are no deadlines to your product.
Another question though, if you don’t mind: are you pulling through with Denpa Onna?
March 11, 2012
at 10:39 am
We’re finishing it kinda soon. If you really want the latest info – visit our IRC channel, Sutai’s asking about it like every day.
March 11, 2012
at 10:50 am
Please tell me your still going to finish the blurays of Steins;Gate. Seems people are dropping it left and right.
Always hated the unspoken rule of licensing = abandonment of project. That rule still bugs me. Why can’t other see that this rule hold value many years back when fansubbers and industry still respected each other. Nowadays the industry looks down on fansubbers and sometimes even sues them. IOW the rule has lost it meaning and should be forgotten.
Please tell me your not like that and you will finish Steins;Gate. Your pretty much my only hope T.T
March 17, 2012
at 12:23 pm
The only reason I can drop it – it won’t look good / require too much (way too much) effort to be done right, I don’t care about licensing and w/e people might care about.
Though, I’m still busy doing random SHAFT shows and I haven’t touched S;G yet, so who knows what will happen.
March 17, 2012
at 12:36 pm
Pingback: Acchi Kocchi Episode 3 « Tsumiki Fansubs
You guys dead?
May 1, 2012
at 5:38 pm
Не вижу Соредемо и Аракаву. Неужели будет 10битная замена?
May 7, 2012
at 6:40 pm
JanWillem32′s builds of MPC-HC seem to make the first half of your article no longer relevant.
May 9, 2012
at 8:10 pm
Yeah, but handles \blur, anamorphic video and colors wrongly, and it’s still slow compared to xy-vsfilter. Also doesn’t seem to be very stable and popular.
May 9, 2012
at 8:14 pm
Hate to post like this, just curious if we have to join an irc channel to get an update on shows you may be doing? Or if you could just make a post about it.
May 29, 2012
at 1:37 am
IRC is the only way to go. I decided to stop posting any plans/updates because I usually promise stuff that doesn’t happen.
May 30, 2012
at 10:45 pm
too bad that xy-VSFilter isn’t also available for 64bit players…
August 12, 2012
at 7:37 am
There isn’t a single reason to use 64bit players. Why do you care?
August 12, 2012
at 9:19 am
There is a single reason: your obsessive compulsive disorder makes you unable to use anything that is not 64 bit. I can’t imagine any other reason, tho.
August 16, 2012
at 8:27 am
typical n00b answer…stop trolling…
August 19, 2012
at 4:27 am
First of all – performanceJust see this guy post https://code.google.com/p/xy-vsfilter/issues/detail?id=72 – I have similar resultsor just test by yourself 1080i60 Blu-ray content (yadif+deband+resize+sharpen+subtitles+RGB32HQ(with dithering is optional…), it’s highly visibleAlso why only compile 32bit builds, when you can also do 64bit?It’s magic for me… same as these 64bit haters… it’s probably too hard to compile the 64bit for them, because of lame hardcoding…
August 19, 2012
at 4:47 am
Now it’s also 64bithttps://code.google.com/p/xy-vsfilter/issues/detail?id=72#c11
November 23, 2012
at 7:35 am
xy-VSFilter Scale Test Build 1 is now available:http://code.google.com/p/xy-vsfilter/issues/detail?id=97#c10Test it out, leave feedback @ Google Code link above.3D transforms, \clip gradients, animation, positioning, anamorphic video, and all other ASS tags (except \be to a minor extent) should be scaled perfectly with none of the issues of the MPC-HC ISR or Libass. If no bugs are found, next up will be working with madshi to get the new subtitle interface implemented with madVR. The new interface will remove the need of manually input the layout resolution, and allow the video renderer to resize the video instead of the video decoder.
September 11, 2012
at 12:12 pm
Pingback: MPC-HC für maximale Qualität einrichten « 2sek's Blog
Hey i have tried to mess with the vsfilter and its still showing that there is no subtitles.its saying my ffdshow has English subtitles but when i click on it it does nothing. im trying the 1080 version of Ore no Imouto.
March 13, 2013
at 11:51 pm
Would it be too much to ask what shows you’re still doing? I don’t mind being let down if they don’t meet a dead line. It’s not like I have a gun to your head ;)Worst case, could you email me if you don’t wanna say in a reply or post. I can’t use iirc from my situation.
March 20, 2013
at 3:03 am
It’s only a problem of 16:10 aspect ratio screens, isn’t it? Probably you should just write that it’s only applicable to non-16:9 screen users, for 16:9 everything should be (and is) fine.
March 23, 2013
at 3:34 am
not always my 16:9 screen gets broken Tsing without something like xy-vsfilter is being used.
April 2, 2013
at 1:54 pm