Print

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

[cyberbeing]

Connecting to something that isn't supported isn't a good thing. So hopefully that issue can be fixed when x_xy_y2 is back.

xy-VSFilter isn't connecting to something which isn't supported, it's failing to connect because it's unsupported, and the only reason it's failing to connect is because MPC-HC is forcing it into the graph with an unsupported decoder. The same thing happens with VSFilter 2.39/2.40 but it never re-connects and will fail on the first connection attempt. xy-VSFilter always connects twice, first a dummy connection to query the decoder's supported formats, and second a real connection which would fail, same as VSFilter.

This sounds like a MPC-HC graph building / dxva decoder issue which they've since fixed. You'll need to reproduce this behavior outside of MPC-HC using standard directshow graph building (no Gabest magic, no forced/preferred/internal filters, no smartplay, etc.) with another media player or GraphEdit/GraphStudio, before I'll have x_xy_y2 look into it. We're to a point where the xy-VSFilter reconnection logic will only be changed as a last resort. It would take a major system-wide DXVA decoding regression compared to VSFilter 2.39/2.40, before we'd seriously consider making any changes.

I noticed the size of xy-vsfilter is double that of regular vsfilter. Have you ported the MFC fixes from MPC-HC? That should help shrink it with at least 1 MB.

Originally I was writing off the bloat as being caused by xy-VSFilter's use of the Boost and log4cplus libraries, but I just went through and applied the MFC bloat fixes surprisingly xy-VSFilter is now 1.19MB which is 0.03MB smaller than VSFilter 2.40.

Test build: http://www.mediafire.com/?f6jkbpd31x9iezr

[kirakami]

Originally I was writing off the bloat as being caused by xy-VSFilter's use of the Boost and log4cplus libraries, but I just went through and applied the MFC bloat fixes surprisingly xy-VSFilter is now 1.19MB which is 0.03MB smaller than VSFilter 2.40.

Test build: http://www.mediafire.com/?wjd0d3549gskojy

it won't cause any issues with performance & features, ne
http://connect.microsoft.com/VisualStudio/feedback/details/569068/massive-mfc-code-bloat
http://tedwvc.wordpress.com/2011/04/16/static-mfc-code-bloat-problem-from-vc2010-is-now-in-vc2008-sp1security-fix/

[cyberbeing]

It shouldn't, but I won't be pushing such a build to GoogleCode until x_xy_y2 reviews and commits the changes (which were basically just copy/paste from MPC-HC). Please test it anyways to make sure there really are no performance/functionality regressions.

Updated the download link, no code changes, just rebuilt after applying a couple VS2010 updates.

[barca]

That MFC fix just prevents linking in unneeded stuff. Shouldn't have any bad side effects at all.

MPC-HC doesn't load vsfilter on Win7 unless it is set as a preferred filter. It is a 'feature' of Win7 to try to connect things to the renderer as soon as possible. How can MPC-HC even force something into a graph? If a filter properly refuses a connection, it won't connect. It really seems to me there is a bug. If a reconnect is tried, connection can still be refused again if the mediatype is incompatible, or am I wrong?


A simple idea to fix wrong positioning when using the expand functionality:
- scale against the original video size instead of the output size
- calculate the height of the black bars, use that height as a vertical offset for coordinates.
Then subs that require accurate positioning are placed correctly, while plain subtitles can be placed below video.

[barca]

Bug: unchecking "follow preferred order of upstream filter" on the colors tab causes a crash.

[cyberbeing]

MPC-HC doesn't load vsfilter on Win7 unless it is set as a preferred filter.

That is a MPC-HC bug/limitation. Other media players on Windows 7 which use standardized DirectShow graph building, unlike MPC-HC, are able to auto-load VSFilter just fine without doing anything special.

It is a 'feature' of Win7 to try to connect things to the renderer as soon as possible. How can MPC-HC even force something into a graph?

MPC-HC doesn't build DirectShow graphs in the standard Win7 way. How does MPC-HC force something into a graph? It creates a custom graph with VSFilter + a incompatible DXVA decoder using its internal merit system and lets it it fail.

If a filter properly refuses a connection, it won't connect. It really seems to me there is a bug. If a reconnect is tried, connection can still be refused again if the mediatype is incompatible, or am I wrong?

The first connection is always 'accepted' since that is the only way xy-VSFilter can be aware of the formats supported by the Decoder and adapt it to the formats supported by the video renderer. This isn't going to change, but the problem is likely caused the the fact that in xy-VSFilter only the '2nd connection' will be refused/fail.

You'll need to ask the MPC-HC devs why this behavior causes graph building with their internal DXVA decoder to break. It would sound like either they are initializing DXVA too soon, or MPC-HC is only capable of recovering a DXVA graph if the first connection fails. Though as I mentioned, the latest versions of MPC-HC automatically fallback from the internal DXVA decoder to the internal Software decoder, so they may already be aware of the problem and that is their solution.

The only thing I'm curious about is why all version of VSFilter 2.39/2.40/xy are detected as supporting Any_type/Any_type in MPC-HC external filters. I'll have x_xy_y2 look into why that happens and if it's needed in xy-VSFilter, since removing it appears to avoid the issue with MPC-HC's internal DXVA decoder.

Bug: unchecking "follow preferred order of upstream filter" on the colors tab causes a crash.

Are you using the Vertical Padding setting with either FFDShow or the XVID decoder? If so, neither of these decoders support the vertical padding setting when xy-VSFilter reconnects with a non-default colorspace as decribed here. If you must use the Vertical Padding setting, you'll need to use it with a decoder which properly supports it on format change like LAV Video.

If this happens even with Vertical Padding set to Original Height, please provide more details about the filters and versions being used.

OS
Media Player (any internal decoders enabled which support your video?)
Decoder (which output formats are enabled/preferred?)
Splitter (forced VSFilter auto-loading enabled/disabled if supported? custom media type enabled/disabled?)
Renderer (if madVR, any internal decoders enabled which support your video?)
GPU Brand (NVIDIA, AMD, Intel)
Native color format of the video (YV12, YUY2, RGB, etc.). 8-bit or 10-bit?
xy-VSFilter version (3.0.0.1 both 2.4MB and 1.2MB version?)
If changed, please list your custom color preference order in xy-VSFilter + any disabled formats.

[barca]

Yes, vertical padding was enabled.

[CatBus]

I don't mean to hijack the thread (too much...), but you seem to have the expertise I'm looking for, so...

I'm working on a project that uses easySUP, which in turn uses vsfilter.dll to render subtitles.  I would like a way to drop in a modified vsfilter.dll to get some specific functionality it currently lacks.

Specifically, I'm looking for a way to have vsfilter automatically do "center-left" justification.  It's the same same as centered, except multi-line subtitles line up nicely along their left sides (the text block is centered, while the text is left aligned within that block, if that makes sense).  I also want this ability to be triggered on a subtitle-by-subtitle basis, based on markup within that subtitle (i.e. lines beginning with "<center-left>" or something).  This should be usable with subtitles without any built-in formatting/positioning information, such as simple SRT files.

I've taken a look through the guliverkli2 source code and I haven't the foggiest idea where to start, or even if it's a realistic possibility.  Any pointers?  FWIW I dropped your vsfilter.dll into easySUP and it doesn't render any subtitles at all--but that may not be relevant because your mod is for completely different purposes.  If you want to incorporate this behavior into your mod that would be great but I'm really thinking this is more likely to be a one-off custom build.

[cyberbeing]

@CatBus

Why not just open all scripts in Aegisub, set a Style for all the auto-wrapped lines, and create a LUA script which triggers on the Style name to do this center-left justification operation?

I quick google search bought up a lua script posted by Quarkboy which does something similar to what you want over on the Aegisub forums.

After messing with it a bit through trial and error, I ended up with the following which I assume does exactly what you want without any modification required to VSFilter.

Version A: Center-left justification applied to auto-wrapped lines using the centerleft style

Code: [Select]

    include("karaskel.lua")

    script_name = "Center Left Justified Style Triggered"
    script_description = "Convert Text to Left/Center Justified Triggered by Style"
    script_author = "Sam Pinansky & Cyberbeing"
    script_version = "1.3"


    function center_left_justify_style_triggered(subtitles, selected_lines, active_line)
       local meta, styles = karaskel.collect_head(subtitles, false)
       for i = 1, subtitles.n do
          local line = subtitles[i]
          if line.class == "dialogue" and line.style == "centerleft" then
             local lineback = line.text
             if lineback then
                karaskel.preproc_line(subtitles, meta, styles, line)
                if line.width>meta.res_x then
                   line.margin_l = line.left+line.width/4
                   line.text = "{\\an1}" .. lineback
                   subtitles[i] = line
                end
             end
          end
       end
       aegisub.set_undo_point("Center-Left Justify Style Triggered")
    end

    aegisub.register_macro("Center Left Justified Style Triggered", "Convert Text to Center-Left Justified Triggered by Style", center_left_justify_style_triggered)
Version B: Center-left justification applied to all auto-wrapped lines

Code: [Select]

    include("karaskel.lua")

    script_name = "Center Left Justified"
    script_description = "Convert Text to Left/Center Justified"
    script_author = "Sam Pinansky & Cyberbeing"
    script_version = "1.3"


    function center_left_justify(subtitles, selected_lines, active_line)
       local meta, styles = karaskel.collect_head(subtitles, false)
       for i = 1, subtitles.n do
          local line = subtitles[i]
          if line.class == "dialogue" then
             local lineback = line.text
             if lineback then
                karaskel.preproc_line(subtitles, meta, styles, line)
                if line.width>meta.res_x then
                   line.margin_l = line.left+line.width/4
                   line.text = "{\\an1}" .. lineback
                   subtitles[i] = line
                end
             end
          end
       end
       aegisub.set_undo_point("Center-Left Justify")
    end

    aegisub.register_macro("Center Left Justified", "Convert Text to Center-Left Justified", center_left_justify)
After some quick tests it seems to work as expected as long as the script doesn't have any \N line breaks. If you need something like this which deals with line breaks, look at Quarkboy's original script. Anyway this is way off-topic for this thread. The xy-VSFilter developer is not going to be around for the next few months, so unfortunately you came at a bad time and there will be nobody in this thread who can offer advice about the VSFilter codebase for quite awhile. If you need further help with LUA scripting in Aegisub, I'd recommend asking for help in the Aegisub forums rather than here.

[CatBus]

@CatBus

Why not just open all scripts in Aegisub, set a Style for all the auto-wrapped lines, and create a LUA script which triggers on the Style name to do this center-left justification operation?

Because I'm not doing this for myself, I'm creating a workflow to be used by others outside my supervision (and I like a click-and-drool for that reason).  I can't even be sure what's in the SRT files, so assuming auto-wrap is not safe.  I can and probably will use a solution just like this for myself (if I can't find a more automated way), but that's not where my real problem is...

[kirakami]

No problems with MFC test2 build

[cyberbeing]

Because I'm not doing this for myself, I'm creating a workflow to be used by others outside my supervision (and I like a click-and-drool for that reason).  I can't even be sure what's in the SRT files, so assuming auto-wrap is not safe.  I can and probably will use a solution just like this for myself (if I can't find a more automated way), but that's not where my real problem is...

For SRT files you could just do a find/replace to remove the \N line breaks which Aegisub may create on import, but I understand what you are saying. I didn't realize you were actually trying to create a general-purpose workflow for others to use, but it now makes sense why you would want to put forth effort to hack this functionality into VSFilter for your purposes. It's too bad Aegisub has yet to add batch support or a cli interface.

No problems with MFC test2 build

Good to hear.

[CatBus]

Thanks for the pointers, cyberbeing.  Much to my surprise, I've managed to make a modded vsfilter.dll that does what I want.  And surprise doesn't quite cover it, I know nothing about programming!   

[barca]

If you guys are interested in fixing the stride issues with ffdshow, search the ffdshow code for "DVOBSUB". You will find a workaround for normal vsfilter. Solution would be to add a version check for vsfilter.dll to that code, so that it is only used for old vsfilter.

[cyberbeing]

vsfilter does not align the stride at all. If ffdshow does not take the bug into account, the picture is messed up.
I think it is not wise to fix vsfilter now, because filters that have the workaround gets broken again.

Won't do any good unless Haruhiko Yamagata (currently the sole developer for FFDShow-Tryouts) changes his mind. Have you brought up this crash on reconnection with a non-default colorspace issue when VSFilter requests vertically padded frame to him? I'm not even positive this problem is stride related at all. If he believes this is something we could fix without breaking his workarounds, we'll consider it.