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. |
27th December 2015, 02:42 | #1701 | Link |
Registered User
Join Date: May 2008
Posts: 211
|
I ran into another ,what I think is a rather unique problem. I just upgraded from a Compaq TFT circa 2007 16:10 (1440x900) monitor to a BenQ GW2255 VA 16:9 (1920x1080) monitor (this is relevant). The problem is whenever I use any post-processing shader when playing any 1080p content the subtitles when in fullscreen, doesn't matter if it's Windowed FS or D3DFS, don't get resized properly when using the ISR. In fact the subtitles usually take up the entire screen and totally obscure the image. This never happened with my old 16:10 monitor because with the default resolution I was always downscaling 1080p content. This also doesn't happen when using an external subtitle renderer like vobsub.
__________________
Intel i5 3470, EVGA GTX 1050Ti SC ACX 2.0, Windows 10 Pro 64 bit, 16 GB 1600 mhz DDR3 RAM |
27th April 2017, 09:48 | #1704 | Link |
Registered User
Join Date: May 2008
Posts: 211
|
Well it's been well over a year since JanWillem32 has even posted anything so I suppose it is no longer being developed. I suppose MadVR just made this render seem pointless.
__________________
Intel i5 3470, EVGA GTX 1050Ti SC ACX 2.0, Windows 10 Pro 64 bit, 16 GB 1600 mhz DDR3 RAM |
28th April 2017, 12:59 | #1705 | Link |
Registered User
Join Date: Oct 2010
Location: The Netherlands
Posts: 1,083
|
Sorry that I haven't posted in quite a while.
When I offered to help out with the internal renderers (but mostly EVR CP), I encountered a renderer in such dismal state, that I couldn't bother to try to fix any of its core issues. I made this clear to the development team from pretty much the beginning. I went on to replace the renderer with one I wrote and I continued expanding it. In the mean time I advised on some parts of the main player and made a few patches for some other issues. A few of those were accepted, some were rejected. After a few years of developing, I supposed the renderer section was stable enough to replace the old code in the main player. I stopped making big changes and consulted with the dev team. The subtitle sections could go in as a first patch, then the huge patch changing the internal video renderers and then minor other patches of things I edited along the way. As per usual, I said I don't mind style changes or other minor alterations, but the core video renderer code I worked hard on to get it optimized and organized the way I'm used to will have to go in as is. I asked the dev team to stop making changes to the subtitle and video renderer code and so pave the way for full integration of the new sections. I was ignored. For now, the video renderer and subtitle renderer code I wrote is pretty much stable, but due to fact it probably will not be integrated in the main player it is not in active development anymore. I went on designing and coding other things like I have been for many years already. If the MPC-HC team needs my code, my invitation still stands. Other than that, I'm planning to give the video pixel shader pack an update. It's been a long time since I last took a look at it. If anyone needs me for anything, I'll be available.
__________________
development folder, containing MPC-HC experimental tester builds, pixel shaders and more: http://www.mediafire.com/?xwsoo403c53hv |
29th April 2017, 10:37 | #1706 | Link |
Registered User
Join Date: Dec 2008
Posts: 1,959
|
@JanWillem32
Can you make a standalone video renderer? Like Haali Video Renderer, but open source.
__________________
MPC-BE 1.6.11 and Nightly builds | VideoRenderer | ImageSource | ScriptSource | BassAudioSource |
29th April 2017, 12:53 | #1708 | Link |
*****
Join Date: Feb 2005
Posts: 5,642
|
I honestly think the chances are better now to get it integrated. The player is pretty mature now, and development has slowed down. It would be interesting to see a build that is based on current MPC-HC code. With just the core changes and new renderer(s) with same basic featureset as EVR-CP (and VMR9). Then everyone can test it for a while and give their opinion and feedback. Any new and advanced features that you have added should go in at a later stage.
|
29th April 2017, 23:12 | #1709 | Link |
Registered User
Join Date: Oct 2010
Location: The Netherlands
Posts: 1,083
|
v0lt, I wouldn't mind making the video renderer section separate, but I do depend a lot on the changes in the custom interfaces for the video renderers.
For example, the pixel shaders in the trunk build were always compiled sequentially in the renderer because of the limitations in the src\SubPic\SubPicAllocatorPresenterImpl.h, CSubPicAllocatorPresenterImpl{}, SetPixelShaders() interface. The version I wrote looks like this: Code:
struct SetPixelShadersInput { wchar_t const* pwcShader; size_t upShaderLen; wchar_t const* pwcLabel; size_t upLabelLen; }; // note: SetPixelShaders() guarantees all previous shaders will be cleared, there is no need to call ClearPixelShaders() beforehand // note: setting 0 shaders in total is legal, but setting pLists to nullptr is not (use ClearPixelShaders() for that purpose) // note: the caller may completely invalidate pLists and all pointers inside the array immediately after the call // returned value: 0 for success, 1 for an out of memory error, 2 for not implemented, else the failed shader's SetPixelShadersInput const* from the input array virtual __declspec(nothrow noalias) uintptr_t SetPixelShaders(SetPixelShadersInput const* pLists, size_t upPreResizeCount, size_t upPostResizeCount) {... In fact, I changed every single one of the custom interfaces to suit my needs (there were only 15 anyway, so it was easy). So I would need a custom renderer socket for functions like these. However, I prefer regular integration. Coexistence with the current set of renderers is a bit pointless; I used the original mixer code and added my renderer to it. In the mean time I solved countless of issues, added some functions and tried to solve peoples issues (in this thread, on the tracker an on the MPC-HC IRC channels). https://trac.mpc-hc.org/query?status...order=priority https://trac.mpc-hc.org/ticket/3115 https://trac.mpc-hc.org/ticket/2292 Lastly, I would love to see the Haali Video Renderer or another DirectShow video renderer code for its mixer parts, so I wouldn't need VMR-9 or EVR anymore to do the mixing. I always struggled to get a grip on the DirectShow interfaces to get custom mixing parts right unfortunately. burfadel, it's indeed good to have options. I wouldn't design my video renderers the same way as madVR, and I agree it's good to have some variety. (I did have quite few chats of course with madshi over the years. We certainly don't program in a similar way.) clsid, it's good to hear that things might have changed since I last checked up upon the MPC-derived dev teams. Maybe I could still be useful after all. About the renderer features; it's do or die. I did not keep around much of the old renderer code, and all I programmed is pretty much incompatible with the old set of renderers. The "new and advanced features" are integral parts of what I've written and will not be a patch of some sort.
__________________
development folder, containing MPC-HC experimental tester builds, pixel shaders and more: http://www.mediafire.com/?xwsoo403c53hv |
30th April 2017, 01:21 | #1710 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,341
|
The main reason anyone would be reluctant to just accept your "contributions" are simple:
You require yours to replace everything thats there without question. Its not a "new" renderer next to the others, it entirely replaces everything. One huge code dump, not incremental changes. Such a process has a huge impact on the player and all its users. If there would've been incremental improvements over time that would've been far easier to integrate, but as such just replacing everything with something entirely unknown to the other developers will likely not attract many supporters, and I would hope any developer would understand why. There was no need to "fix" the old renderers if thats not something you wanted to do, but in that case a new renderer should have been capable to exist side-by-side with the old ones, so it can be compared and tested without potentially breaking all the things.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 30th April 2017 at 01:24. |
Thread Tools | Search this Thread |
Display Modes | |
|
|