MPC-HC tester builds for internal renderer fixes

[JanWillem32]

I've just taken a look at the changes made for the subtitle renderer in general, and there were indeed some changes to the code in recent revisions. I did notice something for optimizing the subtitle texture management in the video renderer, so I quickly added that for a next release. I've already changed the order for constructing the subtitles and presenting frames back to what it was a few versions ago. I wonder if it's something else I've changed or that an revision in the trunk build messed up things in your case. I couldn't find traces of worse performance with my latest build with the typical samples I have. I'm getting perfectly normal readings from the stats screen for the subtitle renderer's queue, too. Could you explain the details of your problem a bit further or provide a basis for comparison?

The stats screen doesn't use much GPU power to render. It does add a lot to the command queue, though. My paint times are about 6 times higher with the full stats screen enabled. You're probably noticing the effect of the cache options I set up for the stats screen font. The original version was a lot more conservative with using video memory.

[XRyche]

I don't know if it's just me or if it's the last 2 builds but I can't use the Haali or the madVR renderers without MPC-HC crashing. I was able to use any renderer I had installed previous to the last 2 builds. Any ideas?

[JanWillem32]

I don't test external renderers/filters for intermediate builds. That simply takes too much time. I've probably broken one of the interfaces again. That happens a lot, and is usually quite easy to fix. I doubt I'll have time for something like this this week, and the first priority is the old synchronized initialization bug. (It's when audio renderer forces the graph to play while the video renderer is still initializing. An annoying thing, and even a potential hazard for crashing or freezing the player on initialization.)

[Hera]

Not sure what else is there to explain.

Well lets say someone says "DERP DERP DOOP DOOP" over some time. First I see "DERP DERP" which stays on the screen long enough for me to read it, then it is replaced by "DOOP DOOP" which also stays on for some time. For me "DERP DERP" is the first line followed by the second line "DOOP DOOP".

Lets also assume that someone sings "DERP DERP" so the font animates a bit (the "EEEE" part in "DEEEERP" for both "DERPS"s).

The stuttering (which is reflected by a spike in the graph) happens when "DERP DERP" shows up and when "DOOP DOOP" shows up - at that very moment.

The animation performance is iffy too, but if short enough it doesn't cause stuttering. That Tohou (sp?) sample MKV some pages back used to play just fine with basic kareoke subtitles... now the the graph divides by zero and sutters...

[XRyche]

Thanks for answering my question JanWillem32. At least now I know what it is and know how to temporarily fix it for the time being. I'm still using MPC-HC experimental renderer all the time but, I like to keep my options open.

[Hera]

Not sure which thread to report,

AMD Laptop,
I noticed that the default MPC video codec causes some videos to be unplayable (graph skyrockets, EVR cuts out sound and skips, graph get back to normal... repeat forever).
Microsoft codec works just fine and doesn't cause that issue.
Not a subtitle issue.

[JanWillem32]

@Hera: Thanks for mentioning that Tohou video, it's a very good example of the problem. I'll take a look at selectively reverting items introduced after dfr3751, as that version doesn't seem to have this issue.

Apart from the support device for DXVA, there's only very little influence of the renderer on the decoder. I think this issue is more something to report on trac, where developers with knowledge of the codecs can take a look at it. Please explain in detail, with for example MediaInfo logs and a small video sample.
Now that I think of it, some decoders could force a weave deinterlacer, or bob on interlaced video. These two methods are much lighter on resources than adaptive deinterlacing. That could explain bad performance for a renderer with interlaced video.

@XRyche: I'll try to make time to fix things next week.

[CruNcher]

Jep on EVR CP for example Cyberlinks Decoder uses their own Software Deinterlacing (they also have their own chroma upsampling though that gets only used in Software mode not DXVA) as it has no access to the Hardware Deinterlacer :)
Though for Intel Hardware EVR-CP seems to be a bad thing i tested so many scenarios yet and especialy IVTC and Deinterlacing on EVR is much much better the adaptivenes of Intels Hardware implementation (Driver, bitstream containter flag independence) can fix many issues (Realtime) that would go undetected in EVR-CP (or fallback to Software) though (i still believe their must be a way to force it also on EVR-CP as it is doable via the EVR Controll Panel (Microsoft) manualy).

[JanWillem32]

Deinterlacing is a difficult thing. Apart from being an obnoxious inheritance from legacy analog TV formats, digital interlacing is bad for encoding efficiency. Deinterlacing itself is usually also badly implemented in both hardware and software.
The optimal spot for a deinterlacer in the filter chain is right after chroma up-sampling, colorspace conversion, optional custom pixel shaders, and right before resizing. While using a decent colorspace and quantization for both input and output. So far I've seen most deinterlacers output garbage, with the typical form of 8-bit 4:2:0 Y'CbCr (YV12, I420/IYUV, NV12) for both in- and output. Without even mentioning the intermediate processing quantization and filter program code of those, most deinterlacers are fundamentally flawed.
I'll ignore the bob method, as that's not a real deinterlacer. The most basic deinterlacer is the weave type.
The weave deinterlacer simply interleaves individual scan lines from two fields to one frame (the field rate is double the frame rate). Because of that, it won't work on 4:2:0 sources, as those simply don't have individual scan lines for chroma. Up-sampling partially in this case is often used (to 4:2:2), and is a very bad practice. When chroma geometry is transformed in a filter, the output should always be 4:4:4 and stay that way throughout the entire rendering chain. Using one filter to up-sample chroma vertically (to 4:2:2) and another in a later stage is bound to lower color quality. (Who would want to use two different filters to up-sample chroma vertically and horizontally anyway?) It's even worse if the output is down-sampled again to 4:2:0 (which often happens).
A weave deinterlacer doesn't change actual color information, as it only re-orders the scan lines. However, the chroma up-sampling required before deinterlacing does alter it. A basic bilinear filter adds exactly 2 bits to quantization (it's a pixel1*.25+pixel2*.75 blend), in both vertical (to 4:2:2) and horizontal (to 4:4:4) passes. More complex forms of scaling use fractional values that often can't be described in exact bits like that.
Deinterlacers that do more than just weaving (I'll just skip the "blend deinterlacer" for now) are usually called adaptive. These forms interpolate frames from fields (the field rate is equal to the frame rate). That kind of interpolation depends on methods based on linear scaling of the internal values in the data pool. In the cases of data pools containing typical Y'CbCr and R'G'B' surfaces, only Cb and Cr (chroma channels) are somewhat linear, the rest really isn't. I won't go in detail on this point right now, but when interpolating using colors, both Y'CbCr and R'G'B' greatly lack linearity and colorimetric range. (Linear RGB is only a little bit better, though.)
Adaptive deinterlacers require a well-processed input to allow proper interpolation. As such, the quality of the in- and output surface format should be pretty good as well.

For the VMR-9 and EVR mixers, I'm not happy with the current position and implementation of the currently available deinterlacers. The output quality of the surfaces used in the mixer can luckily be controlled quite well, but it's not an ideal situation.
The mixer doesn't allow manipulation of the raw fields by the renderer. It always forces progressive RGB as output. On top of that, the deinterlacing code is vendor-specific (inside the graphics driver). Once possible, custom internal deinterlacers should do a better job than that.

As a side-note, it's too bad that many video streams are badly marked in terms of interlacing flags. Cinematic video on TV usually needs a weave deinterlacer, but is usually marked as TV content (50 or 60/1.001 Hz field rates, interlaced from 50 or 60/1.001 Hz frame rates). See for example a few pages back in this thread, the "Evil Trees" sample.

[G_M_C]

Just saw this in the madVR thread, might be useful for you too:

Just a heads-up for anybody who cares.

The latest version of xy-VSFilter (http://code.google.com/p/xy-vsfilter/) (a VSFilter 2.39.x fork for performance) now supports both 4:2:0 10-bit (P010) and 4:2:0 16-bit (P016) input/output.

[ForceX]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive. I could just disable animation on my regular VSFilter if I needed that.

[JanWillem32]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

[Keiyakusha]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive. I could just disable animation on my regular VSFilter if I needed that.

How about checking yourself before saying that? Animated subtitles is the purpose xy-vsfilter exists for.

[ForceX]

How about checking yourself before saying that? Animated subtitles is the purpose xy-vsfilter exists for.
I did. Neither the subs from Bad Apple video nor Tori no Uta was animating with the filter.

[Keiyakusha]

I did. Neither the subs from Bad Apple video nor Tori no Uta was animating with the filter.
Then something went wrong for you... Maybe you should investigate then and report some bug

[ForceX]

I'm gonna need confirmation from someone that those two files actually work as intended for them. Maybe those specific types of animation are not supported. Don't know else it could be, the http://code.google.com/p/threaded-vsfilter/ project which also works with caching works fine for the files.

[Keiyakusha]

ForceX
Can you upload subtitles from these files somewhere? Including fonts if there any. I do have these videos but not sure if subtitles are the same.

EDIT: btw do you know that you can't replace old vsfilter with xy one? you need to remove old ones and cleanly register xy for it to work properly.

[XRyche]

Just a heads up. ASS subtitles stay on screen until another line of subtitles with tester dfr3787rri, regardless of timing.

[G_M_C]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

x86 SSE: http://www.mediafire.com/?7b8v024m4fu0av9
x64: http://www.mediafire.com/?m79alqofg5k6kp5

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?

[golagoda]

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?

Considering these builds are based off of MPC-HC trunk builds it would be kind of silly calling them stable no matter what is done to them and it would probably confuse a lot of people, saying which builds work the best so far would probably work better :p

[cyberbeing]

That doesn't even seem to support animated subtitles, and that's the kind of subtitles which would actually require performance enhancement, so that's kinda counterproductive.

Should be fixed in the next version (Edit: Fixed in xy_vsfilter_test_20111101), since faster rendering of heavy subtitles animation/karaoke/typesetting are the main reasons for using xy-VSFilter. If you ever find any more bugs, report them on GoogleCode so they can get fixed quickly. The goal is to have zero regressions from VSFilter 2.39.x functionality, but occasionally things sneak in only to get fixed shortly after. That said, all the builds with _test or _mru appended too them can be considered Beta builds potentially with experimental changes.

[Hera]

Nice to see progress on that part. If it works out well, we might be able to merge some parts of the code.
Anyway, I've fixed conversion to NV12 from P010 for the internal codecs.
The performance of the subtitle renderer is still bad with complex subtitles. (The scheduler doesn't compensate enough for the huge delays that can occur because of the subtitle renderer.)
I've improved the efficiency of the timer code for x64 (the original code was really bad). I don't know if I can improve it a lot for x86.
I've removed "Reinitialize when changing display", as I've improved detection for multihead adapters. (Resets will still be forced when changing from one physical adapter to another.)
I'll try to implement some real features, fix some things and update the main revision next time, when I have more time.

x86 SSE: http://www.mediafire.com/?7b8v024m4fu0av9
x64: http://www.mediafire.com/?m79alqofg5k6kp5
Aaaaand you broke subtitles on x64 for me. Same goes for the information at the top which appears when seeking / modifying volume.

Sometimes both are corrupted - broken down into segments and reassembled wrongly. Sometimes the screen goes black.

[JanWillem32]

@XRyche: I've noticed. The subtitle texture allocator is a bit sensitive. It's been like that since I split it into a part for external renderers and the internal one. This really isn't the first time that that bug appeared. Oh well, I've fixed some things today in this regard. The complex subtitles in the "Touhou - Bad Apple!!" video seems to render quite properly again for me with the alpha version I made today.

@G_M_C: I'll integrate the latest revision from the trunk version once I've sorted out some code that's incompatible with some of the latest changes. I'll see if I can make time to do the full sweep of alpha testing things after that, and release a non-intermediate. Integration of smaller patches to the trunk is possible, but the bigger parts of the video and subtitle renderer are mostly (or completely) re-written code and a lot more difficult to finalize.

@Hera: x64 specific? That's new to me.The status messages and the the bottom bar in the exclusive mode are rendered by the OSD renderer. (It actually has pretty much the same fundamental issues as the subtitle renderer, so I might change it to something more like the font renderer for the stats screen.) A black screen now and then is usually caused by a corrupt texture produced in the subtitle renderer. I've tried to improve this part of the code today, so I hope I've fixed most of these types of issues.

[Hera]

Not sure if 64bit specific, maybe will test later.

[janos666]

My problems with mpc-hc SSE2 tester dfr3787rri


- Black screen if I try to play 1080p24 Blu-Ray VC-1 movies in full screen 1920x1080p resolution (refresh doesn't matter).
There is picture in windowed mode but it disappears if I go to full screen windowed mode. (It reappears if I move the cursor down to make the GUI show up on the screen and disappears again if I move it back up...)
D3DFS starts with black screen and it seems frozen (there is no GUI if I move the cursor down on the screen + see later...).


- Crash if I try to pause/resume or seek Blu-Ray AVC movies (producible both with internal splitters + internal DXVA decoder and LAV splitter + FFDShow software decoder).


- 23.967fps playback is smooth (as much as it can be) with 60Hz display refresh in D3DFS mode and Alternative V-sync turned OFF. But V-sync is completely broken with 23.976Hz display refresh. (Very strange because it sounds easier to sync 23.976fps to 23.976Hz than 23.976fps to 60.000Hz...)
Alternative V-sync only makes everything wrong (23.976 display refresh is still unusable but 60.000Hz refresh is broken too) but this is not a new thing.


Edit:
I went back to 3740.
No more 23.976Hz V-sync problem with most of the video formats, but VC-1 videos (in m2ts) aren't smooth (and I get black screen with DXVA decoders).
And I am still unable to seek AVC videos (in m2ts), it must be a general problem.

[RGold]

I see same thing when using optimal render settings - 32 bit floating point. Reset to default works ok for now.

My set up:
ATI5450, LAV audio& video - All internal codecs are disabled. Also using 24Hz auto change frame rate.

[JohnLai]

Oh my, Catalyst 11.10 WHQL totally breaks mpc-hc DXVA into black screen.

Anyway, bug report with dfr3787rri = when fast forward and fast backward non stop, then let the video plays normally, somehow, the video will 'run' slower than audio.

[JanWillem32]

I've managed to get some things a lot more stable this time. I didn't have time to test everything, including external filters, but it's a good start.

-added a modified version of watchman's code to the subtitle parser, thanks again :)
-changed the method for calculating scheduler frame rate compensation, based on jitter comparison;
updated presenter modes: constant frame interpolator, Windows 7 and onwards in windowed mode with Aero enabled, Windows Vista and onwards in exclusive mode
-revised EVR CP initialization, no longer the big "hiccup" at the start, but it's still slower than VMR-9 r.
-revised subtitle allocator;
it now supports quick mode changes for for example resizing a window
resource management has been changed for better efficiency and a lot less crashes when reinitializing or closing
-optimized the renderer's internal pixel shader compiler handler, it's a lot faster now

[janos666]

I've managed to get some things a lot more stable this time. I didn't have time to test everything, including external filters, but it's a good start.

It is indeed a lot more stable. I can seek the video as often as I want and I can quit without appcrash.

V-sync with 23.976Hz refresh is also fine now (D3DFS).


But I still can't play AVC1 videos with this version (which is weird since the encoding format shouldn't matter when I use external software decoders :confused:).
Same as I reported before: windowed mode works but D3DFS crashes and full screen windowed mode gives me a black screen unless I keep the seek-bar on top.

[ChronoReverse]

I'm gonna need confirmation from someone that those two files actually work as intended for them. Maybe those specific types of animation are not supported. Don't know else it could be, the http://code.google.com/p/threaded-vsfilter/ project which also works with caching works fine for the files.

In 32 bit mode, the newest one (http://code.google.com/p/xy-vsfilter/) as of this posting time does animation for me. Without killing my CPU too.

[Hera]

Very quick notebook tests w. D3DFS on two files: Seems to work just fine.

EDIT: Also still crashes with ALT-F4

[golagoda]

Is it just me or in the r3801 build do you have to resize the MPC-HC window for the video to show? It can be the smallest change, but it needs to be changed to see the actual video, don't know if it's meant to be like that but that's happening to me at least. If you don't it just stays as a black screen, not even the OSD will show if you press ctrl+j

Also wasn't able to use this build with madVR either :( last one I could use is 3753 (Tried all the tester/intermediate builds you posted but didn't put into the original post), but I managed to make EVR look decent so I just use that now anyway, once again thanks for these builds.

EDIT: Turns out last working build for me for non-EVR renderers was actually dfr3755i not 3753

[Hera]

netbook performance kinda regressed though, now it stops for up to half a second and then resumes.

Stops happen before the subtitles appear now and during the subtitles - yes before subtitles are loaded there is stopping.
Tohou video with basic kareoke now stutters but renderer doesn't drop frames left and right to keep up with kareoke (aside from minor stopping all the time) and kareoke effect for a certain line goes through like 70% then is gone - it doesn't finish - so it is like renderer now instead of dropping frames drops the subtitles.
Allow Animation When Buffering seems broken - it does nothing.

The stats screen in windowed mode is broken too - the stats are tiny and unreadable, but the graph is fine if not too big.
In windowed mode subtitles also suffer this fate - they are too tiny - unreadable.
This can be fixed by resizing.
This doesn't appear in D3DFS.

Disabling subtitles does not effect the occasional stopping -the stopping or renderer maybe renderer going back and forth between frames is repeated at equal intervals - red like down, green line up type of an effect.
It is at the same parts too, first being when the apple is bitten the first time - stop, mountain on graph, resume.

Play Button does not work anymore. If I paused in Windowed mode, then I have to resume video by seeking... actually it just started playing again.. so there is some unbearable delay between there.
This also exists in D3DFS - Space, PAUSE, video starts playing.


Playing Planet_Earth_From Pole_to_Pole_1080p_sample.mkv I got delays of... well.. a second. Video stopped for a second. Graph and all stats also stop. Resume and the graph has divided by 0...

Also I got D3DFS seekbar in normal EVR...

Trying to use Haali crashes MPC.

[JanWillem32]

@janos666 & golagoda: It seems that it was caused by the resizer section. The skip conditions were wrong for handling equal video and screen sizes.

@Hera: I'll try a few other computers than mine for debugging the Alt+F4 problem. It's been there for a while, but I can't replicate it on my PC.
"Animation When Buffering" seems to work properly for me. It's not intended to do anything when a buffer of 0 is set, by the way.
The bug with the wrong sizes sounds like the one a few hundred revisions ago, where window sizes were initialized wrong. (Mostly when the window was resized immediately after opening. The menu bars often cause this.)
Delays of over a second are somewhat extreme. It's no doubt caused by a scheduler part. A large peak and valley in the jitter graph usually means that the mixer is flushed and all pending samples are immediately dropped frames. The scheduler will do that once the mixer buffers are exhausted, EVR won't respond anymore and the video is many frame times late. A minor version of that action is used when seeking.
The vanilla EVR type does indeed get the wrong OSD type. I'll take a look at fixing the main window organization later on.

I'll debug external filters later on when I have more time.
For now, I've tried to fix a timing issue that could cause dropped frames, and the resizer section.

[Hera]

I am a few NV driver versions behind (due to their bad reputation) - although I doubt that matters?

[CruNcher]

Wow i didn't yet tested the r but already 3801 is amazing 0 jitter when changing on the fly, i mean except the change time itself but immediately after it it stays stable (no matter changing from windowed to fullscreen and back forth) very nice (no issues while switching as well not 1 brake in sound and video) very good work Jan, though still closing it holds the last frame captured :)

[G_M_C]

JanWillem, do you have an estimation on when you will reach the point of releasing 'a (relatively) stable' ?


[...]
@G_M_C: I'll integrate the latest revision from the trunk version once I've sorted out some code that's incompatible with some of the latest changes. I'll see if I can make time to do the full sweep of alpha testing things after that, and release a non-intermediate. Integration of smaller patches to the trunk is possible, but the bigger parts of the video and subtitle renderer are mostly (or completely) re-written code and a lot more difficult to finalize.
[...]

Seems like you've granted my wish for 'a (relatively) stable' after all :p

Thx Jan !

[CruNcher]

yup 3081r doesn't lose that stability very nice now more stuff can be tested (3081r as the current would be also my fav build now after dfr3752i) :)

Though this is something strange im not sure how that could be explainable, but i get a black screen with dfr3752i now where 3081r works perfectly fine very strange as dfr3752i worked before and driver didn't change, or was it just executing 3081r killed dfr3752i video output (i have to restart though and clean system state to be sure it's actually 3801r execution killing 3725i video output for every further run) (but im running Firefox in the background as well with some flash player instance, though not rendering actively and should be suspended)

[Mercury_22]

@JanWillem I think you should put a big warning somewhere asking people to RESET their settings with every new build and to never use your builds at the same time with the trunk builds unless they use an ini file for the settings cause this may cause a lot of false bug reports for your builds and for the trunk

Just my 2c :)

[JanWillem32]

@Hera: I personally don't know. At my parents' house there's a HTPC with an older nVidia IGP, but I haven't been tracking driver issues for revisions lately. Maybe someone else knows?

@CruNcher: The revision was only minor. The main method remained unchanged for the scheduler. The still picture on exiting is indeed a bit nasty, and I really don't know why it happens. The log from the DirectX debug runtime doesn't indicate any resources leaking, so I wonder what part is keeping the surface. I can force the window to clear to black on closing, but that's not a very elegant solution (the logo screen should be used). I don't know what part could break older revisions. I most certainly didn't change any registry/.INI settings other than the limited range output setting the last few revisions.

@G_M_C: Attaining relative stability with a new renderer core is always a bit hard when working with the legacy DirectX 9 forms. (I started with only DirectX 10.0 programming two years ago, DirectX 9 still annoys me with not requiring a decent minimum feature set for video cards.) The demands for keeping compatibility are very high, the code for various operating systems and video cards is very diverse. Two weeks ago, I was happy to find out that at least one of the compatibility modules seems to work: http://sourceforge.net/apps/trac/mpc-hc/ticket/1808 . Note that I couldn't test it by myself, so I was lucky, I guess. I don't have that type of hardware. It just shows that in a few ways my version of the renderer is starting to get more stable than the trunk version.

@Mercury_22: Indeed, I've changed so many settings. I'll try to update the OP today to include a notice.

Two minor notes;
The revision for the resizers gave one minor issue, so I added an error message for that: "linear gamma, both custom pixel shader and resizer passes are disabled, for frame interpolation in combination with EVR to work, at least one is required". As it's a rare condition, and VMR-9 r. doesn't have this issue, I won't fix this.
Little CMS was updated recently. I've seen some support modules for handling types of V4 profiles, along with other changed code. I would appreciate feedback on changes, as I might need to change settings again. (Think of the color clipping to green from a while ago, that required some work to fix.) 3081 is broken in this regard, 3081r had a small fix that I forgot to point out.

[janos666]

Yes, black screen and other reported problems are fixed in dfr3801r. It's usable now.
But I still have sync problems with a VC-1 AP@L3 Blu-Ray video. The GUI reports improper and fluctuating average frame rates (no matter if FTC is ON or OFF) in both windowed and D3DFS mode.

[JanWillem32]

What type of video is it exactly? Maybe I can find a similar sample to test. The two VC-1 sample videos I just tried work fine.
I'm glad that the black screen issue seems to be fixed. It's a bit hard to write code for the compensations involved with skipping the resizing section completely.

[ForceX]

The color clipping seems still to be happening if you enable Black Point Compensation. It goes away if you enable White Point Adapt state to Full. I don't remember this particular behavior in previous builds. Also, I thought BPC was only supposed to work for absolute colorimetric mode.

Also, really great work with these builds. Last few builds started struggling greatly even on 720p content with Light Random dithering. It's much better now.

[CruNcher]

Jan Willem32 its not a super big issue either but it seems on load of the video playback the video surface @ first gets full zomed in the same issue i remember some very very long time ago though it didn't fixed itself (res change) back then in this newer builds though it happens again but it fixes itself after i just guess its 1 second :) though the time is enough to make it obvious (like the new resolution change on switch itself is pretty obvious in the end might distract even, no one is really used to this i guess not all will find it whatever benefits it brings nice @ all compared to the static res change in trunk)
But this is entirely a perception kind of thing and different playback scenarios would also make it invalid of course (it highly depends,on the general usage).

[RGold]

3801r looks stable if I use default render. For optimum render setting I get black screen with sound on. When I move the mouse down to the seek bar the image comes back and will disappear as soon as the seek bar hide itself. Using external LAV filters.

[JanWillem32]

@ForceX: I just tested, with neither my profile nor the one janos666 posted a few months back I've seen the clipping issue. What settings are you using? Can you upload your profile? Maybe the color management is having trouble with a different kind of profile this time.
As far as I remember, White Point Adapt State is for absolute colorimetric mode only. Black point compensation is forced enabled for perceptual mode and forced disabled for absolute colorimetric mode. The option once only worked for saturation and relative colorimetric modes. That could have changed over time, though.

@CruNcher: I haven't seen that yet. Can you elaborate a bit? Does it happen in exclusive mode? (As exclusive mode is less susceptible to problems involving window size issues.)
The checklist for resetting the renderer is passed every .75 seconds, including a window size check for windowed mode (it would be useless for exclusive mode, of course). An immediate reset after initialization is possible. (Just enable the "View", "Statistics" bar. It invades the video area directly after opening. I have no idea how to fix that thing, same as the bar for the fullscreen windowed mode.)
Can you describe "zoomed in"? The default window resolution is a square of only 1×1 pixel. If the entire window area is painted in one color, it could be that the window size initialization is skipped.
Maybe I can whip up a tracing debug build to see if a session log reveals problems when initializing the player on your system. It could be something trivial to fix, for all we know. (As usual, I can't replicate the problem on either of my computers.)

@RGold: Which of the two seek bars do you mean? (Exclusive mode or fullscreen windowed mode?) Is the video you were testing exactly the same resolution as your monitor? What video card do you use? In the video settings tab of the video card's control panel there are options for various filters. Many of those are well known to cause a black screen when the renderer uses better surfaces than 8-bit RGB. Can you try again with all of those disabled?
(I really could use the help of a DirectShow specialist to help get rid of the current mixers. Even if the renderer detects that a video card is capable of processing a certain surface format, there's no guarantee that the mixer won't output plain black surfaces with it.)

[ForceX]

It seems to have been an incompatibility issue of the lut3d files. I deleted my existing ones and the issues are fixed. I guess the reason why it seemingly worked when I turned on Full White Point Adapt State is because I didn't have an existing lut3d file for that. -_-

[janos666]

Here is a small sample: click (http://www.mediafire.com/?4dn1l97jan6x1cb) (I chose this moment because this scene was uploaded countless times everywhere anyway :D).

[CruNcher]

@ Jan
Sure give me a special debug build and ill record it :) here is first a visualization of this http://www.mediafire.com/?zbplbg7tp8csnv3 (i love to play with this as you see hehe, finally i can visualize my on screen experience and bug reports ultra fast (no transcoding))

Here is a complete switch test http://www.mediafire.com/?ifkvvtet0ylg409 (including above issue on the OSD @ init)

[RGold]

Jan,
I took Mercury_22 advise and saved all setting into INI file since I also have the truncated version. Now 32-bit RGB works fine. However I have problems with interlaced AVC material where NV12 output is doing well and RGB just stutters with any both LAV and internal filters. I'm using ATI 5450 video card and Windows 7. Here is the file: http://www.mediafire.com/?oz9w2cl7xesi1i1