Log in

View Full Version : MPC-HC tester builds for internal renderer fixes


Pages : 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

JanWillem32
6th July 2011, 07:16
That's very convenient. I was already planning to release a new revision, the fix for the "double tap" bug is a nice addition.

Anyway, I didn't get to integrate all fixes for the subtitle section and I still have to experiment a bit with the color management.
The new revision has an almost completely revised vertex setup and rendering loop. In my tests I saw quite good performance gains (it will be hard to get such dramatic performance increases like with previous versions, though).
Apart from the interaction with the subtitle and OSD renderers, the main renderer is in a pretty good condition now. I can start updating EVR Sync soon with some luck.

TheElix
6th July 2011, 09:52
Great! I'm eager to try out the new version. Should we expect an increase in FPS everywhere?

JanWillem32
6th July 2011, 10:52
I mostly saw a lower peak load with both CPU and GPU. It's because I removed and re-ordered some items that caused lagging in the rendering chain. The average load was only slightly less overall. Results can vary, of course. I mostly test the heaviest of settings, else my GPU will only nap most of the time during rendering. It also tends to crash if I try to set clocks below idle speeds, so I can't really simulate low-end video cards, or even IGPs. I generally just assume that if I get good results with my regular heavy rendering chain, every other setup benefits as well.
I also tweaked some of the timing items, but it's hard to see the effect of those. (My computer isn't a difficult case with VSync, lagging, buffering and such.)

TheElix
6th July 2011, 13:16
Reducing those peaks means one will have less rangom lags or stuttering during playback on a borderline sufficient hardware?
By the way, did you have the chance to look into a problem of saving Autochange fullscreen monitor mode settings?

JanWillem32
6th July 2011, 18:40
Borderline sufficient hardware should benefit form every little optimization, but it will be impossible to create something that has the same performance as the overlay renderer.
The autochange function for the exclusive mode is ready for integration once the link with the menu is formed. Editing the menus is rather time-consuming, so it will take some time before both changes are made for saving the options when the base autochange function is disabled as well as the making the function work in exclusive mode.

Qaq
7th July 2011, 21:20
Jan, I got system message "StackHash_0a9e" every time right after D3D close for last build. Win7, EVR CP.

TheElix
7th July 2011, 22:08
So the new version's out and I missed it! Jan, you could've reposted your link in the body of your message!
~gone testing~
Edit 1: Confirmed, crash on player's exit after D3D mode. Luckily after exit. :) Using SSE2 version.
You're doing tremendous job, Jan! The playback is as smooth as ever!
Doubling commands seem to be fixed!
Edit 2: About this new perlin smootherstep resizer. It seems to be introducing blockiness on edges. What's its purpose?

Hera
8th July 2011, 05:59
This is nice and smooth.
No crashes so far.

I have no idea what the new scalers are so I just switched back to bilinear...

Video is very smooth while panning, zooming.

JanWillem32
8th July 2011, 07:27
@Qaq: I've never seen errors with "StackHash_0a9e" before, but after a quick search they seem to be common. It seems to happen with some combinations of active programs. I've tried a few that were listed, but I can't reproduce the problem. I've used internal filters only, with both software and DXVA decoders on SSE2 and x64 versions.
Can anyone post a minidump, a copy of the error in the system event log (run "eventvwr"), or test what background programs conflict?
@TheElix: The Perlin Smootherstep was a proof-of-concept of a bilinear variant: http://en.wikipedia.org/wiki/Smoothstep .
I just liked the graph it makes, but I'm not very sure it's the most ideal for image interpolation. I just needed to get rid of one of the bilinear types and insert a single-pass resizer (nearest neighbor and bilinear are single-pass as well).
@Hera: All resizers have partially been re-written to require a bit more CPU and GPU resources at initialization, but require no external input data for scaling and positioning while running anymore. I've also updated the two-pass resizers to skip a stage if only anamorphic correction is applied. For choosing the right scaler, just try "View", "Frame", "Double Size" and a few times "Pan&Scan", "Increase Size" (or numpad 9). That will show most of a resizer's characteristics for general usage.

G_M_C
8th July 2011, 11:15
Jan, I got system message "StackHash_0a9e" every time right after D3D close for last build. Win7, EVR CP.

[...]
Edit 1: Confirmed, crash on player's exit after D3D mode. [...]

@Qaq: I've never seen errors with "StackHash_0a9e" [...]

I have not seen this error, neither on my primary screen (computer monitor) nor using my secondary (TV/external processor).
Using HPC-HT, SSE2, 32 bit on win64.
Currently using MS Windows build in video-decoders [DXVA], streaming audio to receiver/processor thu ffdshow tryouts (no audio processing done by MPC-HT, except formats not recognized by receiver).
Options: D3D full screen, 1080p, 'force 10 bit output'=on, Full floating point processing, your 'optimized shaders' 1,2 and 3. No color management/Litttle CMS disabled.

This latest version seems error-free to me, the CTRL-J problem is resolved, and i have not noticed other problems.

I can only find points that could be inproved;
- The 'CTRL-J" stats-screen could be better. The red text in the stats-screen is too small on my 1080p screen, i have to approach my screen to read it. Also the text on stats-screen has a shadow-outline that is too large imho; readabillity suffers because of it.
- Maybe the subtitle renderer could be improved, playback seems smoother without subtitles, but i cant put my finger on how or what exactly.

Hera
9th July 2011, 03:35
XP rig - EVR:CP (I have .NET installed),
I get to see (semi-corrupted) remnants of the previous video at the beginning of the new video.
If no previous video, just some odd corruption stuff.

Haali Renderer + Show OSD + Subtitles = Transparent Subtitles with white square background covering the video...

JanWillem32
9th July 2011, 11:14
@G_M_C: I'll take a look at the Stats screen again. I believe I can scale the text a bit, but the shadow is somewhat fixed (the font renderer is rather minimalistic). I'll have a try with the colors, like with the OSD and seek bar back in January.
I'm already editing the subtitle renderer, but I could use a lot of help with it. The output lag when rendering a new rectangle to fill is extreme with the subtitle renderer. Where the main renderer takes a few hundred of nanoseconds to respond to a cycle, the subtitle renderer will very often take more than 50 milliseconds to respond. That's enough to drop a complete frame every time. There's a lot of work to do to make it properly. For starters, I've recommended to split the bitmap and vector-based subtitle renderers up, as they are fundamentally different, and I think people would like some options other than the standard bilinear resizing (without gamma correction) for bitmap-based subtitles.
@Hera: That's caused by the graph builder. If the renderer is busy outputting the last frame, and the graph builder decides to dump the renderer, the half-rendered image corrupts. Until the first new frame is presented, the output tends to look like that. I've heard that disabling desktop composition may help. Presenting corruption during the first initialization of the renderer is odd, as the allocator-presenter will never call a present to the back buffer while the rendering engine is still busy. It might be a driver thing. You don't have any issues once first frame is presented, I assume?
I've indeed been editing the subtitle renderer a bit already to make it compatible with the new rendering path. There are special extra steps for the external renderers, and I guess I need to edit those some more. The problem with the Haali renderer is that I need to guess what settings it needs, there's no documentation or further development on it.

Hera
10th July 2011, 02:12
Ok, so I noticed this with an AVI on NV66 XP rig - MKVs worked fine... on NV ION W7 rig, I think I am getting double picture with everything.....
Note: I use Haali Media Splitter for everything...

Haali Renderer + .AVI = Screen seems split in center in four (more or less) equal parts, top right and top left show the (blurry) video (or... two copies of the video to be more precise... TOP LEFT CORNERS of the videos that is), bottom right and bottom left are corruption (Lines and *** on NV66 and Green on ION).

http://i1221.photobucket.com/albums/dd467/QueenHera/OddHaaliIssue.png

JanWillem32
10th July 2011, 08:28
How nice, I've exposed a bug with the internal decoders. I've used the new rule set to never convert 8-bit 4:2:0 Y'CbCr to 8-bit 4:2:2 Y'CbCr before the mixer, but always fall back to 8-bit RGB output if YV12, I420/IYUV and NV12 fail. The trunk build still allows a very ugly conversion to YUY2. The rule set I applied is similar to the one used in ffdshow tryouts. The default settings for any recent ffdshow tryouts build will correctly output "RGB32" by default to the Haali renderer (can be seen in the renderer's OSD).
The problem is, for some reason the Haali renderer sees YUY2 input with the internal codecs, but is served YV12 instead. I wonder why the internal codecs won't force "RGB32".

G_M_C
10th July 2011, 10:16
How nice, I've exposed a bug with the internal decoders. I've used the new rule set to never convert 8-bit 4:2:0 Y'CbCr to 8-bit 4:2:2 Y'CbCr before the mixer, but always fall back to 8-bit RGB output if YV12, I420/IYUV and NV12 fail. The trunk build still allows a very ugly conversion to YUY2. The rule set I applied is similar to the one used in ffdshow tryouts. The default settings for any recent ffdshow tryouts build will correctly output "RGB32" by default to the Haali renderer (can be seen in the renderer's OSD).
The problem is, for some reason the Haali renderer sees YUY2 input with the internal codecs, but is served YV12 instead. I wonder why the internal codecs won't force "RGB32".

You might want to report this to the developers, maybe coss-post also in the 'regular' MPC-HT thread ?

TheElix
11th July 2011, 23:14
Hm, your latest build (I'm using SSE2 version) is apparently conflicting with LAV Audio Decoder on bluray content (.bdmv). No audio and fast-forwarded playback. Everything's normal with in-built audio decoder. It also plays normal with LAV a.d. on the latest standard build.

TheElix
11th July 2011, 23:22
Also, green screen on this video:
General
Complete name : F:\ANIME\Rurouni Kenshin\Rurouni Kenshin 02.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 272 MiB
Duration : 23mn 34s
Overall bit rate : 1 613 Kbps
Writing application : VirtualDubModRus 1.5.10.2 (build 2540/release)
Writing library : VirtualDubMod build 2540/release
Video #0
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.2
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Codec ID : h264
Duration : 23mn 34s
Bit rate : 1 150 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.156
Stream size : 194 MiB (71%)
Writing library : x264 core 64 r994M b35a044
Encoding settings : cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x113 / me=tesa / subme=7 / psy_rd=0.6:0.0 / brdo=1 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=6 / nr=0 / decimate=0 / mbaff=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=0 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=1150 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=0

JanWillem32
15th July 2011, 01:14
I've taken a look at the problems with the interaction with the Haali renderer, it will take time to get it fixed. This isn't my area of specialization, and others didn't know how to correct it quickly, either. I think I fixed the problem with the Haali renderer's OSD+subtitles, but it could use more testing.
The problem with the LAV audio decoder is a complicated one, I could only reproduce it with the internal splitters, not with LAV splitter active. It deserves additional inspection.
A moment ago, I've uploaded tester build dfr3391. There are a few nice improvements to rendering speed, but the initialization speed is now much lower when resizing the active window. I've updated the stats screen to render fullscreen white text. I'll try to make it faster next time. There's a minor bug with the fullscreen windowed screen. When the player bar is showing, the view is compressed vertically with nearest neighbor scaling. In it's normal invisible state, there's no problem.

Hera
15th July 2011, 04:03
Ah you mean
"With experimental build 3391, new video files are opening pixelated and very upscaled and a bit to the right - to fix this resize window"

JanWillem32
15th July 2011, 04:54
Ah, in your case the renderer initializes faster than other parts under the filter graph... The renderer receives data on what the size of the current window opening is from other parts. I don't know if I can optimize those, but I can probably fit in a pause function while the window size item is still undefined. It won't happen with the exclusive mode, as that one always spans the full screen.

Hera
15th July 2011, 19:15
Wow, you weren't kidding about needing to make the stats screen "faster next time" - O.o
In my opinion, the previous version was easier to read and looked better.

JanWillem32
15th July 2011, 20:19
Making the text adaptive to the window width and changing bold text for a bit wider text when the horizontal resolution is below 1120 works very well in my opinion. On the other hand, I don't know if the white text with a black outline and shadow is optimal, either. I'd rather use one obnoxious color, so that it doesn't have to draw the two parts for the outline and shadow anymore.

TheElix
15th July 2011, 20:40
In my opinion, the previous version was easier to read and looked better.I dunno, the new version looks better for me than the previous one, in my opinion.
http://rghost.ru/14668731/thumb.png (http://rghost.ru/14668731.view)
I've found another problem. D3DFS + Autochange fullscreen monitor mode = crash on player's closure. It happens when the player tries to restore previous resolution.

JanWillem32
15th July 2011, 21:15
The coupling of the D3DFS + Autochange fullscreen monitor mode function is still wrong. It's currently handled by an item hosted by the main menu, instead of natively in the renderer. It's pretty high on my to do list, but this menu section isn't easy to edit.

cca
15th July 2011, 21:32
Have to pass on ver. dfr3391, keeps hanging while trying to open the video and takes too long to switch to windowed full screen. The statistics screen is so slow that causes the video to lag some times too.

Hera
15th July 2011, 21:51
It makes sense if you are far away from the screen, large font is good. But up-close, information is presented better when it is smaller - more compact.

Have to pass on ver. dfr3391, keeps hanging while trying to open the video and takes too long to switch to windowed full screen. The statistics screen is so slow that causes the video to lag some times too.

The statistics screen has always had influence on the performance - which could be noted by the graph in the bottom right, now it is more pronounced - I get ~11 FPS on ~24 FPS video with the full statistics for example.

G_M_C
15th July 2011, 22:24
I dunno, the new version looks better for me than the previous one, in my opinion.
http://rghost.ru/14668731/thumb.png (http://rghost.ru/14668731.view)
[...]

I think it looks better too, it is much more readable (the dark red wasn't very readable on black background, something that happens often on movies with aspect-ratio other than 16:9)

Thanx Jan Willem for looking into my wish for this :)

JanWillem32
15th July 2011, 22:42
I wish I could use a DirectX 10/11 font renderer. That would also make it possible to use translated Unicode strings for rendering, on top of the efficiency. The current stats screen is drawn by rendering the ASCII table of a font in software mode, and then make the video card render a list of mini-textures. Anyway, I can probably edit some parts. For efficiency I can set one draw operation for the text only, and remove the black outline and shadow. What color should I use for the text? Or does someone have a clever idea for a better stats screen?

Hera
15th July 2011, 23:08
Subtitles seem a lot sharper in this build for me, is the maximum texture resolution setting still functional?

JanWillem32
16th July 2011, 00:32
No, it isn't. I've made the vertex management of the subtitle engine compatible with the main renderer. The resolution setting and the rounding to a power of 2 setting won't work anymore, else the subtitles would become scaled by nearest neighbor. The old method is still in place to serve as compatibility mode to other renderers only, until these are updated. Work on the subtitle engine is slow, but I've at least gotten this to work. There were two passes active of bilinear filtering, disabling one is a very good start.

Something I totally forgot to tell: I've added the two Mitchell-Netravali cubic resizers. http://de.wikipedia.org/wiki/Mitchell-Netravali-Filter (Sorry, I can't find a quick overview with pictures naming the 3 main BC-splines in English.)

cca
16th July 2011, 05:21
Another regression I forgot to mention, I can no longer play DVDs with the latest build. The video is completely distorted, it appears like it displays only a zoomed part of it.

Qaq
16th July 2011, 07:07
VMR9r chain is broken - black screen, zeros in filter properties. For xvid at least.
Should I use mixer option for VMR9r? Playback seems more jittery with that option enabled.

mindbomb
16th July 2011, 07:38
Another regression I forgot to mention, I can no longer play DVDs with the latest build. The video is completely distorted, it appears like it displays only a zoomed part of it.

i tried with a 1080i h264 video file and got a similiar effect, maybe it has something to do with interlacing?

cca
16th July 2011, 09:24
i tried with a 1080i h264 video file and got a similiar effect, maybe it has something to do with interlacing?

That's probably it, a similar thing had happen with an older build some time ago but was fixed later.

tetsuo55
16th July 2011, 09:39
To be on the safe side, did you guys reset the MPC-HC settings?
So much has changed on this build that an old setting might be messing around.

mindbomb
16th July 2011, 09:58
i didnt.

cca
16th July 2011, 10:53
Me neither, but it is easy to do so if needed, I keep them in an .ini anyway.

Qaq
16th July 2011, 12:11
To be on the safe side, did you guys reset the MPC-HC settings?
Done. Now VMR9r (XP) shows the picture in windowed mode but changing to fullscreen freezes the player no matter of selected scaler.

JanWillem32
16th July 2011, 18:39
It's busy in here today... I'll take a look at the list of problems, but for what I've seen on the main thread, the trunk r3391 also had some problems. If a few of those problems are fixed, I'll gladly upload a new tester builds set.
I believe I've just solved that old problem with black screens on exit. It does need more testing, but if it works, I can finally set the 10-bit mode to activate automatically if the video card allows it.
I think I can make the stats screen faster by drawing only the white text and using the background of the jitter graph to darken the entire screen. Is that a good idea (for only the full stats screen)?

TheElix
16th July 2011, 19:54
The coupling of the D3DFS + Autochange fullscreen monitor mode function is still wrong. It's currently handled by an item hosted by the main menu, instead of natively in the renderer. It's pretty high on my to do list, but this menu section isn't easy to edit.Guys like Underground78 and Aleksoid1978 in MPC-HC thread are pretty knowledgeable about the menu thing. I am pretty sure they won't mind lending you a hand (or advice at least) in this matter. I'm sure they'll be happy to hear your thoughts on autochange fullscreen monitor mode function (if your methods are applicable on the base version in this case).

I think I can make the stats screen faster by drawing only the white text and using the background of the jitter graph to darken the entire screen. Is that a good idea (for only the full stats screen)?I think, why not. Ctrl+J screen isn't made for movie viewing purposes anyway and VSync graph uses it, so...
And thanks for the new resizer, it's my favourite now. :)

JanWillem32
19th July 2011, 03:36
I've finally had some success with one part of subtitle section. The subtitle renderer is still very heavy in CPU usage, but it's now much better timed. Because the blending stage for subtitles is now included in the actual video renderer code, subtitles are now included with the color management and dithering stage.
For bitmap-based subtitles, I still need to fix a few things before the regular resizers can be used on them. Currently all bitmap-based subtitles are scaled by a bilinear filter.
I'm also very satisfied with the changes I made to the stats screen. The performance is now a lot better.
About the internal codecs and splitters, these are currently being improved in another branch of MPC-HC. So, I'll review problems with the internal splitters and codecs in by builds for after those have been renewed in the main code.
I've updated the status for the normal VSync items in the OP:
- I broke the three regular VSync functions (they can even crash the player when enabled). A sort of VSync in windowed mode without desktop composition can still work with the "Flush GPU Before VSync" and "Wait For Flushes" functions enabled.
Windowed mode with desktop composition enabled and the exclusive mode will VSync perfectly well on their own. Some statistics generated previously by the VSync code parts are broken, as well.

Hera
19th July 2011, 06:12
Crashes 100% of the time with D3D fullscreen enabled (opening a file - I do not use V-Sync) on ION rig, investigating...

Yep with brand new settings as well. D3DFullScreen + Nvidia ION = More or less instant crash.

Love the CTRL-J performance though and I am now testing with subtitle animation enabled.


Problem signature:
Problem Event Name: APPCRASH
Application Name: mpc-hc.exe
Application Version: 1.5.2.3423
Application Timestamp: 4e24c5a1
Fault Module Name: mpc-hc.exe
Fault Module Version: 1.5.2.3423
Fault Module Timestamp: 4e24c5a1
Exception Code: c0000005
Exception Offset: 005154a6
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt

JanWillem32
19th July 2011, 07:00
I did change two initialization items specific to the exclusive mode, so I can build versions without one of those two once I have some time to spare.

TheElix
19th July 2011, 10:34
Hm, refresh rate in statistics screen seems to be broken: http://rghost.ru/15053711/image.png
Why do you turn off VSync and all its options and flushes by default? Because you 'broke' it?

janos666
19th July 2011, 13:13
And because they seem to be optimal for the exclusive mode (and the exclusive mode seems to be optimal for playback)?

JanWillem32
19th July 2011, 17:54
Enabling the VSync options on my main system locks up initialization half of the time, and makes (re-)initialization very slow. The statistics generated by the VSync threads have been off for a while. On top of that, the functions don't work for me anymore. With the normal VSync options enabled, I get tearing in windowed mode with desktop composition enabled and in in exclusive mode. (Those two can simply use the system timers to VSync by default, anyway.) The windowed mode without desktop composition also keeps tearing in my case unless I set it to wait for flushes.
For the initialization problem with the exclusive mode, this might work: ---. It's an edited SSE2 version, I can adjust the other two versions as well, if this one works.

TheElix
19th July 2011, 19:34
Strange, I have no tearing (here are my renderer settings http://rghost.ru/15053711/image.png).
Jan, I've been wondering, why don't you include your shaders in your build? It sucks to be inputting your shaders anew so often.

JanWillem32
19th July 2011, 20:15
If the output refresh rate closely matches the input fps, VSync doesn't have to do much, either. In my case, it has to deal with 24/1.001 to 80 Hz. It used to work, but not anymore.
I'll have to make a selection of what shaders to add.
In the mean time, you can simply use REG EXPORT to make a backup of any registry item, and also subfolders of it.
REG EXPORT "HKCU\Software\Gabest\Media Player Classic\Shaders" "%USERPROFILE%\Desktop\shaders.reg"
REG EXPORT "HKCU\Software\Gabest\Media Player Classic" "%USERPROFILE%\Desktop\settings.reg"
(%USERPROFILE% is a system variable, you don't have to fill it in yourself.)
The resulting .reg file can simply be executed to add items to the registry. You can also review and edit some of its contents in notepad. I've done this often to transfer or backup settings.

TheElix
20th July 2011, 05:27
Chroma interpolation is a must. Some variants of sharpen complex too.

JanWillem32
20th July 2011, 08:20
I'll see what I can implement after talking to the rest of the team. I'll certainly remove all the present ones at least. Another problem is that quite a few shaders are to be installed in the renderer, as options in a menu.

Can anyone with an nVidia video card that had crashes before, when activating both the exclusive mode and 10-bit output test this build? ---
It should successfully initialize with a 10-bit backbuffer and an 8-bit display format. (10-bit display output on an nVidia card should only work with recent Quadro models and a DisplayPort connection.)