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

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

 

Go Back   Doom9's Forum > General > Subtitles

Reply
 
Thread Tools Search this Thread Display Modes
Old 20th July 2013, 05:04   #41  |  Link
andybkma
Registered User
 
Join Date: Sep 2006
Posts: 183
Quote:
Originally Posted by cyberbeing View Post


Zoom Player does not yet support use of XySubFilter with SmartPlay. Disable SmartPlay and embedded subtitles should display properly.

Is this something that Zoom Player has to fix or is it the fault of xySubFilter? Thanks...
andybkma is offline   Reply With Quote
Old 20th July 2013, 06:24   #42  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Zoom Player would need to fix it. They have special handling of subtitles and manually load and connect VSFilter to the graph in Smart Play mode. So they would actually need to add an option to use XySubFilter instead of xy-VSFilter. In a future version of the subtitle interface, we'll likely offer a way for players to disable madVR auto-loading XySubFilter, to make support for manual graph building such as SmartPlay easier.

Last edited by cyberbeing; 20th July 2013 at 06:27.
cyberbeing is offline   Reply With Quote
Old 20th July 2013, 07:05   #43  |  Link
thewebchat
Advanced Blogging
 
Join Date: May 2009
Posts: 483
The performance scalability of scripts in XySubFilter confuses me. I have two essentially equivalent scripts:

http://pastebin.ws/1f27q4
http://pastebin.ws/787m8p

The first script executes with nearly zero overhead as measured by CPU load. The second one uses 100% CPU on fullscreen (2560x1600) and causes massive stuttering. Looking at the tags, I can't see any obvious reason one would be slower than the other. If anything, the first one should be slower since it uses a wider blur and has a secondary layer.
thewebchat is offline   Reply With Quote
Old 20th July 2013, 09:32   #44  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Which queue in madVR drops first?

Do you have any Flush & Wait settings enabled? If so, try setting all to "Don't Flush".

What CPU, GPU, OS?


I'm not seeing anything particularly abnormal as far as CPU usage on the second sample on my System.
704x480->853x480 = 1% CPU Usage by XySubFilter
704x480->2560x1440 = 3% CPU Usage by XySubFilter

The first sample likely just caches well by chance.
Just to make sure, I'll have our dev double check that nothing strange is going on with second sample.
cyberbeing is offline   Reply With Quote
Old 20th July 2013, 10:41   #45  |  Link
wanezhiling
Registered User
 
Join Date: Apr 2011
Posts: 1,169
Now xysub is always loaded when using madVR even you play a file without any sub... madVR should just let the player decide everything.
wanezhiling is offline   Reply With Quote
Old 20th July 2013, 11:02   #46  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by wanezhiling View Post
Now xysub is always loaded when using madVR even you play a file without any sub... madVR should just let the player decide everything.
It's still currently under debate, but it seems likely the next update of the new subtitle interface will allow players to disable auto-loading of Subtitle Providers (i.e XySubFilter) by the Subtitle Consumer (i.e. madVR) in some fashion. Beyond that we need feedback from developers, particularly media player developers, about any specific changes they desire from the current revision of the subtitle interface. Currently we've heard from MPC-HC only. Any developer is welcome to contribute to the ongoing discussion here about the future of the subtitle interface. We are open to ideas and suggestions, and would like to resolve any major issues or roadblocks to adoption within the next month.
cyberbeing is offline   Reply With Quote
Old 20th July 2013, 13:52   #47  |  Link
Moragg
Registered User
 
Join Date: Jun 2013
Posts: 22
Here's some feedback from me:

My "benchmark" for subtitles was Commie's Shingeki no Kyojin ep1v2 - roughly 100K line of typesetting in 7 seconds.

With xyvsfilter and a queue of 128 I got a second of playback (at best) before the whole thing froze and skipped 10secs.

With xysubfilter and a queue of 128 I get 0 dropped/delayed frames (not optimising for performance) at original res (720p)
If I also playback at fullscreen (1440p) then some dropped frames do happen - with optimising for performance I get 10 dropped, without I get 17 dropped.

So a massive performance boost. Certainly much more than I was expecting. Thanks!
Moragg is offline   Reply With Quote
Old 20th July 2013, 14:41   #48  |  Link
Soukyuu
Registered User
 
Soukyuu's Avatar
 
Join Date: Apr 2012
Posts: 169
Moragg, curious, which CPU do you have? That's the same sample my CPU can pass with a queue of 64.

edit: xy-VSFilter vs xySubFilter: 5/64 and 11/64 for subtitle queue respectively, so not that much of a difference.

Also, about multithreading, wouldn't it be possible to say, split the screen in 4 subpictures and let each thread render one of them? I know multithreading isn't that easy from my tries to implement it for a much smaller project, but it would really be a huge benefit to have it. Especially for AMD users, since multithreading is where their CPUs excel at.

Last edited by Soukyuu; 20th July 2013 at 14:46.
Soukyuu is offline   Reply With Quote
Old 20th July 2013, 14:41   #49  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
@Everyone: The "opaque black box" problem should be fixed in the next madVR build for 99.9% of all DX9 GPUs (I hope).

Quote:
Originally Posted by Moragg View Post
Here's some feedback from me:

My "benchmark" for subtitles was Commie's Shingeki no Kyojin ep1v2 - roughly 100K line of typesetting in 7 seconds.

With xyvsfilter and a queue of 128 I got a second of playback (at best) before the whole thing froze and skipped 10secs.

With xysubfilter and a queue of 128 I get 0 dropped/delayed frames (not optimising for performance) at original res (720p)
If I also playback at fullscreen (1440p) then some dropped frames do happen - with optimising for performance I get 10 dropped, without I get 17 dropped.

So a massive performance boost. Certainly much more than I was expecting. Thanks!
That sounds very good, actually I'm surprised that it performs this well.

How about you other users? How does XySubFilter + madVR compare on your PCs in terms of performance and quality to other solutions like VSFilter, xy-VSFilter and the internal MPC-HC ISR?
madshi is offline   Reply With Quote
Old 20th July 2013, 15:16   #50  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 5,013
There does not seem to be an elegant solution for the auto-loading problems, and most suggested workarounds involve assistance from the player. So I suggest to keep things as simple as possible: give the player complete control of loading a subtitle provider (when needed) and limit the interface to the communication between providers and consumers.

In other words:
* A consumer does not do anything related to loading. It only communicates with providers.
* A provider should not attempt to auto-load itself unless it is able to load itself for external subs (which implies it connects to the video pin). This means that a filter like XySubFilter should have a merit equal to MERIT_DO_NOT_USE.
* The player is responsible for loading (non-video handling) subtitle providers such as XySubFilter. All players that are capable of using a non-standard video renderer are already customizing the graph building, so it should be rather trivial to add for player developers.


It is theoretically possible that multiple providers are in the graph. In case of external subs, this means a sub file could be loaded twice. This could be prevented by letting the (first) provider setting a mutex, signaling to other providers that a file is already loaded (and thus should be skipped). The mutex could be for example "MadSubInterface" + HashOf(subtitle_filename). The reason for mutexing individual files, is because providers might only support a subset of all formats, or use different auto-loading rules and source locations.


I suggest adding a function to XySubFilter (or maybe all non-video handling providers) that allows the player to instruct it to add an external subtitle file. This could be used by for example MPC-HC to load a downloaded subtitle file, or a file that is added through drag&drop. Such a direct function would not require any dynamic DirectShow graph handling (and the complexities that implies). Then XySubFilter could be used as a full ISR replacement in the case where madVR is used as video renderer.
clsid is offline   Reply With Quote
Old 20th July 2013, 15:37   #51  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by clsid View Post
There does not seem to be an elegant solution for the auto-loading problems, and most suggested workarounds involve assistance from the player. So I suggest to keep things as simple as possible: give the player complete control of loading a subtitle provider (when needed) and limit the interface to the communication between providers and consumers.

In other words:
* A consumer does not do anything related to loading. It only communicates with providers.
* A provider should not attempt to auto-load itself unless it is able to load itself for external subs (which implies it connects to the video pin). This means that a filter like XySubFilter should have a merit equal to MERIT_DO_NOT_USE.
* The player is responsible for loading (non-video handling) subtitle providers such as XySubFilter. All players that are capable of using a non-standard video renderer are already customizing the graph building, so it should be rather trivial to add for player developers.
All of that could be achieved by my suggested modification of the new subtitle header. Media players who prefer your suggested behaviour would simply have to call "EnableSubtitleAutoLoading(false)" before building the graph.

The problem with following your suggestion by default is that auto-loading would stop working for every single media player out there, until they manually add support for it. And that is a situation I don't like at all. If a media player is willing to add support for the new subtitle interface, then it should be easy for the media player to call "EnableSubtitleAutoLoading(false)" before building the graph. And that would fulfil most (all?) of your wishes.

Adding a video input pin to XySubFilter is a bad idea, IMHO, because it wouldn't be used for any purpose (other than to get loaded), and it would add complication to XySubFilter development, and maybe harm DXVA decoding compatability.

Quote:
Originally Posted by clsid View Post
It is theoretically possible that multiple providers are in the graph. In case of external subs, this means a sub file could be loaded twice. This could be prevented by letting the (first) provider setting a mutex, signaling to other providers that a file is already loaded (and thus should be skipped). The mutex could be for example "MadSubInterface" + HashOf(subtitle_filename). The reason for mutexing individual files, is because providers might only support a subset of all formats, or use different auto-loading rules and source locations.
Yes, that sounds like a useful addition. Instead of explaining the mutex logic in the header, I'd prefer to add a little helper function, though, to make things easier for the media player devs.

Quote:
Originally Posted by clsid View Post
I suggest adding a function to XySubFilter (or maybe all non-video handling providers) that allows the player to instruct it to add an external subtitle file. This could be used by for example MPC-HC to load a downloaded subtitle file, or a file that is added through drag&drop. Such a direct function would not require any dynamic DirectShow graph handling (and the complexities that implies). Then XySubFilter could be used as a full ISR replacement in the case where madVR is used as video renderer.
Yes, that would be useful. It would be nice to have this as part of the interface, though, so that it isn't XySubFilter specific but could also be used by/with other providers.
madshi is offline   Reply With Quote
Old 20th July 2013, 16:13   #52  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 5,013
Quote:
Originally Posted by madshi View Post
All of that could be achieved by my suggested modification of the new subtitle header. Media players who prefer your suggested behaviour would simply have to call "EnableSubtitleAutoLoading(false)" before building the graph.

The problem with following your suggestion by default is that auto-loading would stop working for every single media player out there, until they manually add support for it. And that is a situation I don't like at all. If a media player is willing to add support for the new subtitle interface, then it should be easy for the media player to call "EnableSubtitleAutoLoading(false)" before building the graph. And that would fulfil most (all?) of your wishes.
The players that are currently capable of using madVR (the only existing consumer atm) will all have to deal with the new situation one way or another. Most have an ISR and/or smart graph building. They all should have situations in which they need to block the interface to prevent handling subs twice.

Opt-out:
[-] Players might show subs twice until player is capable of blocking the use of the interface.

Opt-in:
[+] Simpler interface.
[-] Player can't use the interface until it adds support for loading a provider.

I don't expect much problems getting the players to implement the loading functionality. XySubFilter is still in early beta stage, so there is plenty of time. MPC-HC and MPC-BE will be able to add it very quickly. PotPlayer and KMPlayer will no doubt 'borrow' that code as they usually do. The ZoomPlayer dev (Blight) is Doom9 member, so I expect no problems there either.

Quote:
Originally Posted by madshi View Post
Adding a video input pin to XySubFilter is a bad idea, IMHO, because it wouldn't be used for any purpose (other than to get loaded), and it would add complication to XySubFilter development, and maybe harm DXVA decoding compatability.
I wasn't suggesting to add a video pin. I think you misunderstood/misread.
The MERIT_DO_NOT_USE idea is for the subtitle pin. To prevent it from loading itself for embedded subs.
clsid is offline   Reply With Quote
Old 20th July 2013, 16:30   #53  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by clsid View Post
Opt-out:
[-] Players might show subs twice until player is capable of blocking the use of the interface.

Opt-in:
[+] Simpler interface.
[-] Player can't use the interface until it adds support for loading a provider.
You didn't list the key advantage of Opt-in, though, which is:

[+] Makes external subtitle tracks work automatically with every media player.

Please don't under-estimate that. Maybe some day madVR will work in media players which don't explicitly support it. Maybe LAV Video Decoder will become a subtitle consumer and thus make the use of XySubFilter possible in all media players. Furthermore I think it's easy enough in most (all?) media players to simply disable the internal subtitle rendering engine, so the disadvantage of "Opt-out" you mentioned is a simple configuration issue the end-user can take care of himself.

I very much understand your point of view, though, and if the majority of developers prefers removing auto-loading in its current form, I will bow to the majority. I just think it really needs to be carefully considered. And my suggestion to support disabling of the auto-loading by the media player still stands. Actually, I've just released madVR v0.86.10, which already supports my suggested method to disable auto-loading...
madshi is offline   Reply With Quote
Old 20th July 2013, 17:20   #54  |  Link
xabregas
Registered User
 
Join Date: Jun 2011
Posts: 119
SO i use mpc int subtitle renderer and xysub filter doesnt yet support srt subtitles to be rendered outside the movie window. Can i use xy-vsfilter with extend to 16:9 option and still have better performance than with MPC internal subtitle renderer?

TIA
xabregas is offline   Reply With Quote
Old 20th July 2013, 17:21   #55  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 5,013
Well, I suppose since either solution requires at least some effort from player developers, your opt-out solution would be fine too. But perhaps a mutex would be much simpler for players to implement?

I think it would be best to change the auto-loading of the providers by the consumer from a requirement to a recommendation. Then at least a consumer has the freedom to decide if auto-loading is desired in any given situation. The function/mutex to disable auto-loading is of course mandatory.

Perhaps consumers should also create a mutex to signal their presence. Suppose that LAV Video becomes a consumer in the future. Then for example (xy-)VSFilter could check for such a mutex and decide to refuse to join the graph.

Speaking of mutexes, they should contain a unique ID of the current graph. Otherwise undesirable behavior might occur with multiple simultaneous graphs.
clsid is offline   Reply With Quote
Old 20th July 2013, 17:24   #56  |  Link
clsid
Registered User
 
Join Date: Feb 2005
Posts: 5,013
Quote:
Originally Posted by xabregas View Post
SO i use mpc int subtitle renderer and xysub filter doesnt yet support srt subtitles to be rendered outside the movie window. Can i use xy-vsfilter with extend to 16:9 option and still have better performance than with MPC internal subtitle renderer?
Yes. However, the subtitles will be rendered at the resolution of the video (expanded to 16:9) while the ISR can render at the resolution of your screen. So subs may be a bit less sharp for low resolution videos.

@cyberbeing
Can an "expand to 16:10" option be added to xy-VSFilter? Many people have monitors with such an AR.

Last edited by clsid; 20th July 2013 at 17:27.
clsid is offline   Reply With Quote
Old 20th July 2013, 17:49   #57  |  Link
DarkSpace
Registered User
 
Join Date: Oct 2011
Posts: 204
Nice work on the Beta so far!
However, I get a crash on certain files. I have not yet been able to create a sample which reproduces the crash, so I hope that uploading the Debug Log and Crash Report from madVR helps solve the issue. If you need more information or a sample file, I'll be happy to provide more information and I can upload a file after the weekend (unless I manage to create a small sample that reproduces the issue in the meantime), but right now, my Internet is slow.
Could the crash maybe related to Issue 153? I made sure to have all the Debug Symbols in the respective filters' directories when creating the logs.
The crash happens with both madVR 0.86.9 and 0.86.10.
DarkSpace is offline   Reply With Quote
Old 20th July 2013, 17:59   #58  |  Link
thewebchat
Advanced Blogging
 
Join Date: May 2009
Posts: 483
Quote:
Originally Posted by cyberbeing View Post
Which queue in madVR drops first?

Do you have any Flush & Wait settings enabled? If so, try setting all to "Don't Flush".

What CPU, GPU, OS?


I'm not seeing anything particularly abnormal as far as CPU usage on the second sample on my System.
704x480->853x480 = 1% CPU Usage by XySubFilter
704x480->2560x1440 = 3% CPU Usage by XySubFilter

The first sample likely just caches well by chance.
Just to make sure, I'll have our dev double check that nothing strange is going on with second sample.
Change flush does absolutely nothing. I see the subtitle queue instantly drop to 1 as soon as the first subtitle event activates. I observe average 8% CPU usage windowed and 30% CPU (one core completely saturated) in fullscreen.

CPU: Intel Ivy Bridge M @ 2.3 GHz
GPU: Nvidia GT650M
OS: Windows 8

Regardless of my hardware, the subtitle renderer should never cause the video renderer to drop frames. If the subtitle renderer can't meet its deadlines, it should drop *subtitles* instead of causing unwatchable video.

Edit: I don't observe any performance problems when pre-scaling the subtitles to 2560x1440 using Aegisub. The example file http://www.sendspace.com/file/iybf50 plays without any issues while the original file chokes Xy.

Last edited by thewebchat; 20th July 2013 at 18:16.
thewebchat is offline   Reply With Quote
Old 20th July 2013, 18:28   #59  |  Link
Moragg
Registered User
 
Join Date: Jun 2013
Posts: 22
Quote:
Originally Posted by Soukyuu View Post
Moragg, curious, which CPU do you have? That's the same sample my CPU can pass with a queue of 64.

edit: xy-VSFilter vs xySubFilter: 5/64 and 11/64 for subtitle queue respectively, so not that much of a difference.

Also, about multithreading, wouldn't it be possible to say, split the screen in 4 subpictures and let each thread render one of them? I know multithreading isn't that easy from my tries to implement it for a much smaller project, but it would really be a huge benefit to have it. Especially for AMD users, since multithreading is where their CPUs excel at.
My CPU is a PhenomII 1055T - 2.8Ghz 6 core, so not very good at single threaded stuff.

While I would like multithreading "just because" it'll only make any difference on stupidly heavy typesetting, so I'm not sure it's really worth the effort.

Quote:
Originally Posted by madshi View Post
That sounds very good, actually I'm surprised that it performs this well.
Appears I was badly mistaken, previous attempts to play this with xy-vsfilter got the result I mentioned, but a retry gets only 22 dropped frames with xy-vsfilter. xy-subfilter is still better at ~10 dropped frames though.

One thing I am confused about: why should the size at which I playback affect the subtitle queue? With no upscaling/downscaling I get perfect playback, but playing back at fullscreen gives me dropped frames.
Moragg is offline   Reply With Quote
Old 20th July 2013, 18:41   #60  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,494
Quote:
Originally Posted by Moragg View Post
One thing I am confused about: why should the size at which I playback affect the subtitle queue? With no upscaling/downscaling I get perfect playback, but playing back at fullscreen gives me dropped frames.
Since XySubFilter renders at the target resolution (by default) it will have more work to do in fullscreen compared to rendering for only a small target window, I guess?
sneaker_ger is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


All times are GMT +1. The time now is 17:47.


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