Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JEEB]

I would not use libbluray for PGS rendering, tbh.
Personally, i'll either use ffmpegs PGS rendering (maybe after some patching), or implement it myself, if i want the challenge (i have the spec at hand). It really is not that complicated of a format, its just a plain old RLE format with some meta-commands in between.

Not sure when i'll get to my subtitle plans though, probably will still be a while.

I did ask if anyone had comments on libbluray and PG rendering, but I didn't see any comments on it >_> And it seemed like a small'ish codebase with an already done "pg decoder".

As for libavcodec's PG rendering, I still remember how ffplay at least had a "nice" sudden on-off effect on the subtitles back when I was testing it out with the Gundam Unicorn blu-rays I had at hand. This was quite a while ago, though -- and it's ffplay. If mplayer(2) is using libavcodec's PG rendering I would say that one works fine when used in a proper context.

And yes, the format in itself isn't really that complicated in the RLE sense, but oh boy is the spec convoluted

[JEEB]

The ISR should keep working as long as the functionality of the interfaces in \src\SubPic\*.* remains the same. Can you poke xy about that? Porting any changes from MPC-HC in that folder to xy-vsfilter should simplify a future merge.

The only other important change missing in xy-vsfilter is x64 support.

Most of the remaining changes in MPC-HC's VSFilter are cosmetic. Like astyle code formatting. A bunch of compiler warning fixes. All stuff that could be redone if necessary after a merge/replace. There might be a couple of bug fixes that haven't been ported to xy-vsfilter yet. But making a list of those shouldn't be much of a problem when going through the SVN history. I could do that if needed.

clsid was interested in xy-vsfilter as well on Doom9, with a remark on the internal renderer on how to bork/make it work. Also, regarding IRC, I think Freenode had some FAQ on how to access it from the other side of The Wall. I don't think Rizon has such, but on the other side I think Rizon still isn't fully blocked there?

[cyberbeing]

xy-VSFilter 3.0.0.8 Stable Build has been released

• Bug Fix: \iclip animation
• Bug Fix: Multiple instances of simple fade
• Bug Fix: Vector drawing inside text
• Bug Fix: \h tag displays incorrectly with GB2312
• Bug Fix: Purple fringing on some VOBSUBs
• Bug Fix: Crash in the parser with unclosed parentheses and invalid use of \t
• Change: Merge the MPC-HC fixes to reduce Visual Studio 2010 MFC Bloat

[cyberbeing]

xy-VSFilter 3.0.0.41 Stable Build has been released

• Performance: High memory consumption with \clip gradients
• Performance: Refactored Cache stack and introduced three new Caches
• Bug Fix: Secondary Color animation effect corruption
• Bug Fix: Multi-byte to Wide character translation with certain codepages
• Bug Fix: Crash when drawing sub-pixel value vector shapes (VSFilter 2.39 Bug)
• Bug Fix: 8x8 (bilinear) subpixel positioning option causing crashing in xy-VSFilter 3.0.0.40
• Change: Support sub-pixel drawing of vector shapes (WARNING: Unsafe to use outside of hardsubbing. VSFilter 2.39 will crash. VSFilter 2.40/2.41 won't display anything.)
• Change: Add option to hide tray icon
• Change: Auto-versioning support. Requires using build_vsfilter.sh when compiling xy-VSFilter. Read 'Usage' for advanced build options.
• Change: Include minor version number and GIT commit hash (short SHA1) on xy-VSFilter About tab.
• Change: Record version info into registry, to enable better handing of default setting changes.
• Change: Support PC level range (0-255) YCbCr subtitle output.
• Change: Rename 'Auto-Guess' (guess matrix by resolution) to 'Guess'.
• Change: Support [Script Info] 'YCbCr Matrix' in ASS scripts. Aegisub 3.0 will add support for tagging 'YCbCr Matrix' based on video bitstream info.
• Change: Add a new default setting 'Auto' for honoring 'YCbCr Matrix' script tagging, with automatic fallback to TV BT.601 for legacy scripts.

Supported 'YCbCr Matrix' Values:

[Script Info]
YCbCr Matrix: TV.601
YCbCr Matrix: TV.709
YCbCr Matrix: PC.601
YCbCr Matrix: PC.709
YCbCr Matrix: None

'YCbCr Matrix' as well as override settings in the GUI, only have an effect on YCbCr subtitle output. The video is always untouched.

TV.601 = Output BT.601 with 16-235 YCbCr level range
TV.709 = Output BT.709 with 16-235 YCbCr level range
PC.601 = Output BT.601 with 0-255 YCbCr level range
PC.709 = Output BT.709 with 0-255 YCbCr level range
None = Output BT.601 or BT.709 with 16-235 YCbCr level range based on video resolution

If 'YCbCr Matrix' is missing from a script, xy-VSFilter will use TV.601 for legacy script compatibility.

It is highly recommended to leave the GUI settings at their defaults of Auto|Auto for 'YCbCr level range'|'YCbCr matrix'.
The Auto settings obey the 'YCbCr Matrix' tag (if present), else fallback to TV.601 as decribed above.

[cyberbeing]

xy-VSFilter 3.0.0.42 Bug Fix has been released

• Bug Fix: Corruption resulting from draw border routine running when not needed

[cyberbeing]

Last month I fielded x_xy_y2 the possibility of fixing yet another VSFilter legacy limitation which hurt quality. Incorrect chroma placement.

As some of you may remember, VSFilter has always used MPEG-1 centered chroma placement. This is a problem since nowadays MPEG-2 & H.264 default to left chroma placement. YCbCr->RGB conversion by the video renderer, which assumes incorrect YCbCr chroma placement, results in misaligned chroma with significant bleeding outside the luma.

It's looking positive that the next xy-VSFilter build will have MPEG-2/H.264/HEVC compatible left chroma placement implemented, which should hopefully hold us over into the foreseeable future. x_xy_y2's initial implementation appears to be working correctly, from my testing so far.

F.Y.I: Libav|FFMPEG (swscale) appears to default to outputting RGB->YCbCr outputs MPEG-1 chroma placement, while it's YCbCr->RGB assumes MPEG-2 chroma placement which ironically is the same problem VSFilter had. Word to the wise, don't use swscale (ffdshow|lav filters|mplayer2) to sub-sample RGB -> YCbCr. VirtualDub offers the highest quality 'correct' RGB->YCbCr chroma placement if you value detail and artifact-free chroma sharpness. AviSynth 2.6 is also 'correct' but the quality is mush, with it significantly blurring the chroma by default, and creating artifacts with sharper chroma resampling kernels. Only really relevant to people who do YCbCr->RGB->YCbCr or some such for filtering before encoding. Most people should never encounter this swscale limitation under normal circumstances, since all renderers accept RGB input. Likely the reason they never fixed it?

[barca]

Suggestion for the Colors tab:
Remove it and always use order of upstream filter. Most decoders already provide options to force specific colorspaces, so no need to duplicate that in vsfilter. This simplifies vsfilter and avoids compatibility issues.
- or -
Allow custom order only for a whitelist of upstream filters (LAV Video) and disallow for incompatible decoders (ffdshow + Xvid) which crash if also using Expand feature.

There is a typo in the Subpixel Position list: "vsfiler"
I notice no significant quality difference between NONE and 8x8. Is it perhaps only noticeable with specific effects? What kind of performance effect does this setting have on slow CPUs?

[cyberbeing]

Colors tab...Remove it

We have no intentions to remove or make any further changes to the Colors tab. It exists to allow advanced troubleshooting when 'Follow preferred order of upstream filter' fails to give the desired behavior because of a buggy decoder, and said decoder doesn't allow configuration of output formats.

There is a typo in the Subpixel Position list: "vsfiler"

Noted.

I notice no significant quality difference between NONE and 8x8. Is it perhaps only noticeable with specific effects? What kind of performance effect does this setting have on slow CPUs?

The lower you set the subpixel position setting below 8x8, the more animation effects and movement will stutter.

When I had my dual-core 2.4Ghz AMD X2 4800+ (939), it had a negligible to non-existent effect on performance. The only time you should consider changing it from the default setting of 8x8, is if you notice performance problems whenever there is subtitle movement.

[ryrynz]

JanWilliem over @ Doom9 said he'd made some improvements to the MPC subtitle renderer of which some SSE stuff might be able to be ported across.. worth a look?

http://forum.doom9.org/showthread.php?p=1581656#post1581656

Probably an idea to consider packaging this with an installer considering all the improvements that have been made. It really shouldn't be living in DirectVobSub's installer shadow any longer.

[x_xy_y2]

JanWilliem over @ Doom9 said he'd made some improvements to the MPC subtitle renderer of which some SSE stuff might be able to be ported across.. worth a look?

http://forum.doom9.org/showthread.php?p=1581656#post1581656

Probably an idea to consider packaging this with an installer considering all the improvements that have been made. It really shouldn't be living in DirectVobSub's installer shadow any longer.

Thank you for the message and the suggestion.

[cyberbeing]

xy-VSFilter 3.0.0.53 Stable Build has been released

Installer for xy-VSFilter 3.0.0.53

• Performance: Increased the size of Clipper cache from 8 to 48 to improve cache hits
• Bug Fix: Sub-pixel positioning for the CSRI API was inadvertently set to NONE when it should have been 8x8.
• Change: xy-VSFilter now uses *correct* MPEG-2/H.264 left chroma placement, unlike VSFilter 2.39/2.41 which uses *incorrect* MPEG-1 center chroma placement. This should eliminate the problem of chroma bleeding and misaligned chroma which plagued VSFilter for years. As side-effects, perceived sharpness and quality after upscaling should also be improved slightly.
• Change: Support non-integer values of \fcsx \fcxy. Fixes yet another longstanding VSFilter limitation. We highly recommend typesetters make use this increased precision for future scripts, and migrate away from the Libass breaking workaround of scaling tiny font sizes with insane values of \fcsx \fcxy when \fax \fay are also being used.

xy-VSFilter 3.0.0.111 Test Build has been released. This build is a work-in-progress for beta testing only. Please report any bugs and performance regressions found.

• Performance: Introduce new algorithm to improve the performance and quality of Border rendering. 4-6x speed-up on the Issue #95 BigBorders.mkv which uses \bord6.  1.6-2x speedup on BigBorders.mkv using \bord2 instead of \bord6. 7-11x speedup on BigBorders.mkv using \bord20 instead of \bord6.
• Bug Fix: Crash in 3.0.0.111 (git 3aafdc9) when \xbord0 is used with \ybord value >0
• Change: Introduce an experimental Bitmap cache for SSA/ASS subtitles.
• Change: Initial commits to prepare for implementation of xy-VSFilter's new subtitle interface.

[JEEB]

BTW, I noticed on the site that xy-VSFilter seems to need SSE2 (which would mean that it doesn't have alternative C(++) code paths for CPUs without SSE2). Is this still true, and would it be possible to get an alternative C(++) code path for SSE-only CPUs? If not possible, would it be possible to get a map of the SSE2-only parts, which then could be patched to get a C(++) code path + CPU capability check?

Let's just say that while I'd love to use xy-vsfilter in the next CCCP, I'm not sure if I want to either limit CCCP to SSE2+ CPUs, or add the "standard" VSFilter in just for SSE-only users. There's plenty of SSE-only CPUs (esp. on the AMD area) that could still be useful for SD-720p resolution playback, and even x264 only limits itself to SSE by default (everything else is decided on runtime).

[x_xy_y2]

BTW, I noticed on the site that xy-VSFilter seems to need SSE2 (which would mean that it doesn't have alternative C(++) code paths for CPUs without SSE2). Is this still true, and would it be possible to get an alternative C(++) code path for SSE-only CPUs? If not possible, would it be possible to get a map of the SSE2-only parts, which then could be patched to get a C(++) code path + CPU capability check?

Let's just say that while I'd love to use xy-vsfilter in the next CCCP, I'm not sure if I want to either limit CCCP to SSE2+ CPUs, or add the "standard" VSFilter in just for SSE-only users. There's plenty of SSE-only CPUs (esp. on the AMD area) that could still be useful for SD-720p resolution playback, and even x264 only limits itself to SSE by default (everything else is decided on runtime).

It is not a hard work to add CPU capability check and C++ code path for those SSE2 parts. But part of the work duplicates some of the patches already commited to the experimental branch. This experimental branch is not likely to finish soon. Should I create an extra branch from the master for you? And use version info like "xy-vsfilter 3.0.0.53 mod" to avoid conflicting with our future builds?

[JEEB]

Should I create an extra branch from the master for you? And use version info like "xy-vsfilter 3.0.0.53 mod" to avoid conflicting with our future builds?

If it's not just simple patches that I could cherry-pick from the experimental branch, sure. Suits me. Could be marked 'ssecompat' or whatever. You could then just rebase it at need (annotated git tags come in handy for saving old repository statuses).

[cyberbeing]

JEEB, does CCCP have a beta tester with a non-SSE2 CPU who's readily available?