MPC-HC tester builds for internal renderer fixes

[Hera]

Subtitle issues only happens with renderers not being worked on by JanWillem.


Happens if you resize the window. Should be fine on the first opening size.


Works fine here in Windowed mode. Amusingly, trying to use Exclusive mode simply results in a crash for me.

Well EVR: Sync is even more broken.
EVR:CP, as of 1.5.3.3571, doesn't show many subtitles.
Those that are shown are properly positioned.

Resizing Haali Doesn't help. The subtitles are blow up and unusable with Haali Renderer.
EDIT: Or smaller, or fully missing somewhere. Positioning and Size for Haali seem broken.
Touhou bad apple the animated khanjii shows up smaller and more to the center for example.
It is weird.

D3D:FS works just fine for me. When Windowed mode is like "Nah man, Nah, your CPU is teh sux" D3D:FS is like "Challenge Excepted"

[ikarad]

Good morning,
What are the differences between janwillem32 build and standard build about subrenderer?

[JanWillem32]

@CiNcH: Older versions of MPC-HC used A8R8G8B8 for 8-bit textures, that caused the issue. Using converted RGB before the mixer causes quite a few problems, apart from the inherent precision loss compared to the working surface types that have better precision than8-bit.

@ForceX: I didn't edit any parts of the DirectX 7 subtitle renderer, so breaking VMR-7 r. is pretty odd. I also didn't edit many things for the external renderers this time.
I've set the rendering engine to not reset more than once every half a second, to prevent multiple resets when resizing a window. I can lower it a little bit, but not much, else it tends to crash a lot.
Is the crash in exclusive mode a new development?

@Hera: Des the initialization of the video rectangle on opening a video in windowed mode work now? I've added specific detection code inside the renderer for detecting the rendering rectangle area this time. (But I'm not sure it will work when extra toolbars like the playlist are visible.)
Do you get more than 3% deviations in the frame rate during normal playback? I've set the the main renderer to reset the subtitle renderer every time the frame rate changes more than 3% above or below the previous value.

@liquidsmoke: Older versions of Winrar can't unpack LZMA2 compressed files in 7z archives.

@ikarad: I've mostly been trying to get the timing for generating a subtitle texture and its blending phase corrected. I've also written code for blending the texture in at a specific phase in the rendering process, to allow color management and dithering on it.

[Hera]

Windowed Mode Pixelation,
http://i1221.photobucket.com/albums/dd467/QueenHera/EVRCP.jpg

Subtitles not showing up (except for the ones on the right),
http://i1221.photobucket.com/albums/dd467/QueenHera/EVRCP_SubsIssue.jpg

Haali Subtitle Placement Issue,
http://i1221.photobucket.com/albums/dd467/QueenHera/Haali_SubsIssue.jpg

EDIT:
Media that has subtitles that are not animated (no visual difference at all with "Allow Animation When Buffering")
- checking the "Allow Animation When Buffering" decreases performance by a lot.

Increasing Subtitle Resolution effectively made subtitles crispy for Haali renderer as well, with bright jaggy edges
- is that because I have AA forced off?

[CiNcH]

@CiNcH: Older versions of MPC-HC used A8R8G8B8 for 8-bit textures, that caused the issue. Using converted RGB before the mixer causes quite a few problems, apart from the inherent precision loss compared to the working surface types that have better precision than8-bit.
At least the surfaces I was creating for the samples have always been X8R8G8B8 and I was also suffering from skipped chroma interpolation.

Can you name the problems when setting the output type to RGB?

Do you know in which case the media type attributes 'MF_MT_YUV_MATRIX' plays a role? I guess only if I set the output type to RGB?

[ForceX]

The crash for Fullscreen Exclusive seems to be related to enabling the 10 bit RGB output option. It works when in Windowed mode but crashes for FSE. I never actually use FSE so it's no big deal. Vanilla MPC-HC gives a D3DERR_NOTAVAILABLE error and falls back to the default Video Renderer in a sort of an exclusive mode, which is rather silly.

This is what happens with Haali:
First open, http://i.imgur.com/jXQWw.jpg
Maximize window: http://i.imgur.com/257ta.jpg
Restore: http://i.imgur.com/p2KYm.jpg

Same thing happens with VMR7 Renderless, but it also gets some random black lines: http://i.imgur.com/aQZPE.jpg

None of these subtitle problems occur with the vanilla MPC-HC r.3577

[ikarad]

@ikarad: I've mostly been trying to get the timing for generating a subtitle texture and its blending phase corrected. I've also written code for blending the texture in at a specific phase in the rendering process, to allow color management and dithering on it.
Thanks.
I though that you had made a new subrenderer or correct the bugs of subrenderer of MPC-HC.

[JanWillem32]

@Hera: Still the same thing with failing to initialize video and window rectangles, I see. I wonder which one of the dozens of functions in the code is failing in these cases. (Which are also shared between all the renderers.)
The GDI font rasterizer has basic software anti-aliasing. Other than that, the subtitles are resized by a bilinear filter if not desktop-sized already.

@CiNcH: RGB input to the mixer disables most internal EVR filtering stages (those are meant for Y'CbCr). Deinterlacing often fails. One of the typical problems is that the mixer will fail converting 8-bit RGB to another RGB format, resulting in a rainbow of colors everywhere. Setting the decoder to output RGB will cause precision loss if it has to convert to RGB. (I haven't seen any that can convert to the normal floating-point types yet.) From another point of view, if the output is ditherered, setting a lot of video filters afterwards is a disaster because of the added type of noise.
For making xvYCC work with the default EVR mixer, input must be a xvYCC type and the output must be a floating point type (as output is generated beyond the normal [0, 1] color intervals).
If the decoder is of a DXVA type, I also wouldn't know if chroma would be filtered if you forced X8R8G8B8 instead of NV12, or if any type of filtering stage inserted after the decoder would be handled properly for that matter. (I haven't seen any DXVA implementations support more than these two surface types yet, but it's technically possible.)
The MF_MT_YUV_MATRIX attribute is usually set upstream (like most items, actually). For regular work only bt.601 (SD formats) and bt.709 (HD formats) matter. For what I've seen from the normal get function, I never have to set it myself. Many formats for video streams include a marker for this item, VMR and EVR can use that. Else, it's set by estimation from the video size.
The mixer code in the trunk still includes commented out code to force the usage of one of the matrices, along with some other items.

@ForceX: Nvidia video cards expose 10-bit RGB output capability, but refuse to actually set it in most cases. It's an annoying issue. I can't disable the setting based on the detected hardware brand, as the Nvidia Quadro cards can accept it. I've written five different detectection methods already, and none of them work unfortunately. (Note that only the exclusive mode can set 10-bit RGB display output.)
I indeed have to do something about the error message handling. Informing the user about that a setting failed and what to do is more reasonable than that simple message. I also very much dislike that another renderer is started if the selected one fails.
It's not a sort of exclusive mode, by the way. Windowed messages like that can't display in exclusive mode. What you saw was a regular windowed fullscreen.
The common problems with the geometry aside, the lines for the VMR-7 r. are caused by the orientation of a texture. DirectX 7 requires a single pixel offset to the top left, DirectX 9 doesn't. I intentionally removed the adaptation, as it causes a wrong positioning of subtitles in DirectX 9. (The code is shared.)
I've requested removal of the DirectX 7 custom renderer and subtitle renderer in January. It will take some time and some discussion with the development team.

@ikarad: The GDI software renderer isn't exactly my cup of tea. I'd love to implement the standard DirectX 11 font renderer, though. The introduction pages on it are very nicely done, and the code seems easy enough: http://msdn.microsoft.com/en-us/library/ff729481%28v=vs.85%29.aspx
I don't really know what to do with the problems reported with bitmap subtitles. Both for blu-ray and HD-DVD support isn't what it should be.

A lot of work for me this time, it seems. At least I can replicate the problems with the subtitle geometry this time, so I can debug that.

[ForceX]

PotPlayer seems to use gdipp (http://code.google.com/p/gdipp/) for smooth font rendering.

[Hera]

I might have fixed the subtitles not showing up issue (not the pixelated issue or the Haali subtitle issue) by restarting.

Still, I don't see why performance should degrade significantly when enabling animation for non-animated subtitles. :confused:
More of an issue with things like MS DTV-DVD & LAV CUVID type codecs and non D3DFS.

[JanWillem32]

I've tried to tweak a few minor settings, solve the subtitle positioning problem, and replace the window detection mode. If this detection method actually works, please tell me.

[ForceX]

The subtitle issues with other renderers seem to be fixed now. :) The only issue I could find was that with VMR 9 renderless the subtitle in this file: http://www.fileserve.com/file/JKY5wZe seems to twitch a lot more than it should, compared to EVR Custom/Haali.

Oh and when in non-exclusive full screen, putting the cursor at the bottom to bring out the seekbar results in the video to get shrunk, instead of the seekbar appearing layered on top of the video.

[JanWillem32]

I'll take a look at that file's internals, thank you. I know that the fullscreen windowed mode has a problem with all toolbars. It's because the fullscreen windowed mode causes the player to only report the full screen size area, and not the working area to the renderer. This issue doesn't happen in the regular windowed mode, so I think it should be easy to solve.

edit: The sample file has ASS subtitles inside. It has text shifting for every frame where a subtitle is active (not the normal type that uses karaoke tags). Naturally, this is pretty taxing on the subtitle renderer.
I wonder why you would have a specific issue with VMR-9 r.. EVR CP and VMR-9 r. use the same renderer, only the mixers are different. There's a bit more processing for timing items with EVR CP, but that shouldn't matter too much.
Another thing I've noticed was the frame rate. It's set to 23.95502 Hz, which is very unusual, and too low for EVR CP to lock it to 24/1.001 Hz.
Enabling VSync also causes dropped frames, late frames and a very high jitter statistic, even on my PC.

[Hera]

Yes that detection method seems to work much better.

[JanWillem32]

Well, finally one part of the geometry problems fixed. :)
I've also just added some code for detecting off-target frame rates for EVR CP, it seems to work okay with that video sample.

[ForceX]

Well the subtitle twitching/jumping in VMR9-r problem doesn't exist on your 3557 or your previous 3571 build. I think the positioning code just can't keep up enough with this type of subtitle which repositions in every frame, and therefore causes the twitching while it tries to correct itself. Why it only happens with VMR 9 r and not EVR-CP, I don't know. It doesn't seem to be a GPU load issue, though. I turned off all shaders, Vsync and used Bilinear resizer and it still happens. It doesn't seem to be a driver issue either, as I just tried it with integrated Intel graphics and it's the same thing.

BTW, do the options 10 bit Output and Half/Full FP processing affect VMR9r or are they just for EVR-CP? Because I just tried those with VMR9r on the Intel graphics and the video works but EVR-CP fails horribly. xD

[JanWillem32]

The subtitles are rendered by a single CPU thread that exports it to a texture on the video card once done. The video card only copies subtitles to a post-resize surface, with the option of bilinear resizing for if the source doesn't match the target window size. For EVR CP and VMR-9 r. I've forced text renders to always use the window size, so resizing only matters with bitmap subtitles. In essence, only bitmap subtitles can be affected by any video card settings.
I changed the a part of the ordering in the code for detecting the requirements for a device reset. I can make a few variant builds to see if some other type of ordering solves it.

The VMR mixer allows more software emulation for when the GPU can't do certain video operations. EVR demands that all image processing is done on the GPU. It's logical with the rendering layout, EVR has more render stages and is a bit more complex.

[JanWillem32]

A build of the x64 version this time, it only lacks language files. (I didn't have time to update them all.)
The x86 builds broke after I merged in the subtitle fixes from the trunk.

Improvements:
-I increased the efficiency and accuracy of the geometry math by a lot.
-The problems with the CM have been solved. Because of changed settings (and because I accidentaly put the time stamp in reverse order before), new 3DLUT files have to be generated. You can delete the old ones in the user root folder.

Bugs:
-The internal software codecs sometimes use up 100% CPU time of a single thread. I don't know why, but this is a newly introduced problem.
-Resizing by using "double size" and then zooming further to 2.25× crashes on all resizers for me.
-The initial synchronization bug is back. It was introduced in the trunk build.
The audio renderer starts immediately after opening a file, ignoring the initialization time for the slower video renderers.
The effect is that audio plays normally with a black screen, until the video renderer is ready. Once the video renderer is ready, video is played back at the absolute maximum speed, and locks out user commands until done.
(I noticed it when I was rebuilding some test 3DLUT files, which take while.)

[Jtacdf]

Hi JanWillem32, just tried out your 3600 x64 build. Would like to report some stuff and feedback.

1) I can confirm the cms issue is finally fixed. No more weird out of gamut colors.
2) Forcing text to render at window size is not such a good idea IMO. E.g watch a anime with complex softsub ass in D3DFS at 2560x1440, it choked my pc at some point since subtitles are only rendered on a single thread.

3) Since 3423 where you included subtitles in the cms and dithering pipeline, enabling full/half fp causes ass subtitles with black outline to appear like this:
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/WrongOutlines.jpg

Disabling fp or using 3329/3391 with fp enabled, it would be rendered correctly like this:
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/RightOutlines.jpg
Heres a sample.
http://www.mediafire.com/file/2wtnxuy0ae9zp9w/%5Bgg%5D_Ao_no_Exorcist_-_06_%5B26E1DD02%5D%20Sample.7z

4) Timing of ass subtitles seems to be a little off. It's more apparent on sample like this that is timing sensitive:
http://www.mediafire.com/file/6b0fgpbvet7bbfe/%5BDoki%5D%20Suzumiya%20Haruhi%20no%20Yuuutsu%20%282009%29%20-%2008%20%281920x1080%20h264%20BD%20FLAC%29%20%5B79EC4B68%5D%20Sample.7z
Again it only works correctly on 3329 and 3391.

Sorry if the post seems a little long. I wanted to be as detailed as possible.

[JanWillem32]

I can't undo the binding of the resolution to window size with a dynamic backbuffer size and frame swap queue. (When I first enabled that, subtitle blending broke, so I solved that with some custom geometry and some other code.) Any optimizations will have to be done inside the subtitle renderer (or replace it). It can be made lighter by disabling the animation while buffering function. (It doesn't update every frame in that case.)
I can't replicate the failed alpha blending at all. What happens with colored items? What is indicated in the subtitle styles menu during playback? Does disabling the post-resize shaders, the dithering and color management help? (That places the blending step in about the same place as it was before.) Does blending on 10-bit working surfaces work? (With dithering or color management enabled.)
Timing of subtitles has become more problematic with the 4-frame render queue (it used to be only 1) and the failing internal clock that only seems to push the audio renderer correctly (recent development in the trunk build, I'm not happy with it). I think I should change some fundamentals in the interface to and from the subtitle renderer, but with sharing the subtitle renderer with 5 others, that will be tricky. (I've broken geometry and blending for other renderers a lot of times already.)
If the subtitles seem to be shifted forward or backward constantly by an exact number of frames, I can correct it by applying a timer shift. That will need some testing.

I have a request for testing this time. I've been updating the mixers of the shared renderer for a while now, and I was wondering if there's any difference in the behavior between the EVR, VMR-9, RealMedia and Quicktime mixers. The DirectX 9 RealMedia and Quicktime mixers are pretty underdeveloped, but should still show something on x86 builds. Could someone look at the specific problems of these two?

[Jtacdf]

Well, good thing that the subs are not slowly drifting away. They only appear slightly ahead of time constantly.

Hmm. Strange that you can't replicate the problem even though someone before me had reported it.
http://forum.doom9.org/showpost.php?p=1514770&postcount=207

Anyway, here are more screenshots with stats.

With FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/WithFP.jpg

With no FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/NoFP.jpg

Nothing, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/Nothing.jpg

But the problem goes even further then that. Overwriting the ass sub with mpc-hc internal default shows that FP also breaks the border style settings.

With opaque box, no FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/OpaqueBoxNoFP.jpg

With opaque box, FP, no shaders
http://i197.photobucket.com/albums/aa315/Jtacdf/MPC-HC%20samples/OpaqueBoxWithFP.jpg

[JanWillem32]

That the subtitles are a bit early is understandable. The subtitle renderer asks for the current difference in time between frame 0 and the the one projected to in the queue. The internal timer currently synchronizes only properly with the audio renderer, so it's set to a pretty absolute "now". For the video renderer which creates frames for a future present, I have to add a guess value of the difference between now and when that frame should be presented in the future. The amount of frames ready in the queue is dependent on the rendering workload, it varies from 1 to 4 frames. Estimating the future presentation time is pretty difficult.

Does the failed alpha blending seem to happen on any other color than black?

I've tried to set up a few rendering states, hoping it helps for this case. Variant 1 changes one small thing, variant 2 adds a few other alpha blending states.

[Jtacdf]

Both s1 and s2 fix the sub alpha issues. Thanks!
Now only the sub timing issue is left.

EDIT: After doing more testing on the sub timing sample, VMR-9 renders it perfectly fine. So the timing only affects EVR-CP.

[JanWillem32]

Good to hear that, I'll revert the changes made for variant s2 and keep those stated in s1. There are 92 states that I can possibly declare, if I remember it correctly, and there are multiple targets for those, too... It could have been a bigger problem to find the right solution.
ForceX has a problem with VMR9 r. and subtitles, Jtacdf has a problem with EVR CP and subtitles, and as usual, I can't replicate any problems at all. Back to some more guesswork, then. :p

[ForceX]

My subtitle twitching issue in VMR9r is mostly gone in your 3600 x64 build. It still happens, but much less frequently.

[tetsuo55]

Hey Janwillem,

Which trunk regressions are you talking about? what revisions?

[CruNcher]

How to get the decoder displayed in the OSD ? also the newest builds fail here seems to be a scaling issue (input gets extremely huge) VMR9 Renderless Bicubic and XP (touch from inside)
The last test build that works ok is mpc-hc SSE(2) tester dfr3329 all the newer ones show this extreme huge scaling issue (zoom)

[JanWillem32]

@tetsuo55: I've tried to find the reason of the failing timer. A quick glance over some past revisions didn't help. I might find a solution later, but can't really work on the program code now. I'm staying over at my parents' house, so I can visit my grandmother in the hospital a few times.

@CruNcher: The decoder name is reported by EVR CP in the stats screen. I only wonder why the current system was chosen. Normally, decoder information is given by the graph builder, not the mixer. The normal overview on all filters is in "View", "Filters".
The intermediate build in #261 seemed to work well for Hera: http://forum.doom9.org/showthread.php?p=1518095#post1518095 . That one doesn't work for you?

[CruNcher]

Nope i either see no Video @ all and the current background mirrors itself or i see a Video playing back extremely zoomed (VMR9 Renderless,YUV Mixing)
Yeah i wish someone would include it directly in the Debug OSD by reading it from the Graph it's a pain to allways need to click through the menu to see it :(
Also that 1 Dialog blocks the whole player interaction is a pain sometimes

[JanWillem32]

Okay, I'll just try method number 6... (Only included in the SSE2 version, and I'm not really sure if it will work.)

I've decided to have a go with AVX. I didn't write any packed AVX code yet, but it might be interesting to try if MPC-HC reacts well to the AVX compiling arch on a base level.
Little CMS was updated from the main code. The most notable change is the handling in the part for the white point adapt state (only used with an absolute colorimetric rendering intent).
The timing problem has been fixed.
I've made some great performance fixes this time. If the window size detection method works, I can move on to merging more code with EVR Sync.

[CruNcher]

immediately crashes on execution :( (Sandy Bridge) XP

[ForceX]

For whatever its worth, the AVX build also crashes on Win 7 x64 (however, my CPU does not have AVX support). The SSE2 build crashes when trying to display subtitles with external renderers. SSE build works ok.

However, subtitle positioning on the Bad Apple video breaks if you resize the video window. Subtitles are rendered over the window surface instead of on the video surface. Also, subtitles currently being animated also stop animating after a resize until the next line appears. Does not happen with other renderers or vanilla branch VMR9r/EVR-cp.

[nevcairiel]

AVX instructions are only supported on Win7 with SP1, it'll never work on XP - and i guess there are no checks if the CPU even has it. :p

[Jtacdf]

Well, the avx/sse/sse2 version works for me. Still awaiting on the sub timing issue. However, I'm experiencing crashes with all the latest build after 3391. With 10-bit RGB output enabled, trying to open a new file causes mpc-hc to crash. Works fine on all version with it disabled.

[ForceX]

I'm experiencing crashes with all the latest build after 3391. With 10-bit RGB output enabled, trying to open a new file causes mpc-hc to crash. Works fine on all version with it disabled.
Confirmed.

[JanWillem32]

A few little changes:
-added decoder name to the stats screen in VMR-9 r.
-improved frame rate detection, and linked that to the subtitle timers
-added subtitle geometry reinitialization after a device reset
-made the exit sequence a bit shorter, maybe it helps to prevent crashes
-ranked AYUV with merit 0 for EVR CP, to prevent activation of the EVR software emulation mixer

[Jtacdf]

3652i fix the sub timing issue for me.

EDIT: Still experiencing crashes upon trying to open a 2nd file. With everything off in the renderer settings and no shaders, does not crash at all.

[TheElix]

I'm currently back to the primary builds until some things get better. For example,
1) VSync is worse in new builds, I can't get stable 3:2 pulldown. And even 1:1 doesn't work as smooth as before. =(
2) It takes a lot longer for new builds to load video. It searches videos slower (even with super-fast AVSplitter). Some performance issues when changing window size (or changing between window-fullscreen).
3) Subtitles with thin outlines and no shadows. (I don't know if it was fixed in the latest version)
4) Occasional crashes.
Overall, it doesn't look like a step-up from the primary builds for me anymore. Please, don't get upset with my words. I know you're trying to build some things anew and in order to do that you must break some old things to the ground. It's just that for some reasons I can't tolerate those things that I mentioned. But I'm constantly viewing this topic and I'll definitely be back with some testing. =) Thanks for your efforts!

[Jtacdf]

@TheElix
If you read the previous posts, the issues with subtitles is already fixed.

[JanWillem32]

VSync will be a bit of a problem. The original code clashes a lot with the queue. I've only had stable results while using the video card's standard (pretty much absolute) VSync in exclusive mode, or with that of the desktop composition (in both cases meaning that the three internal VSync modes are disabled). I wonder how well the Sync clock in EVR Sync reacts to it once first-level code integration is done. Pulldown should not have any relation with the VSync functions, though. Dropping the duplicate frames for pulldown (+deinterlace) is a mixer task.
The longer loading time is because of the difficult relationship with the graph builder. Priorities are set up a bit wrong, and gapless playback is made impossible by it. (All renderers are closed and re-opened with every new file.)
The performance issue with window resizing is by choice. I only set up checking for changed settings twice per second (includes changed window sizes). I've set up the parameters during a normal rendering loop to be set up once, and be re-used after that, as that's the normal state for a renderer. For configuring custom window sizes and resizing settings some preset mode could be made to switch things at once. (Maybe for positioning the window, too.)
I've verified that some crashes happen when resizing. The link to some external renderer functions and subtitle renderer host has a memory corruption problem that causes it.
I can't replicate the problem with crashing on switching files. With how the graph builder treats the video renderers during a switch, I'm not surprised it does, though.

I'm glad that the subtitle timing is okay again. It's not an easy task to edit code that shares functions for 5 renderers. (Soon a few less, I hope.)

[JohnLai]

Hmm... question, how do cubic B-spline4, Mitchell-Netravali cubic4, Catmull-Rom spline4, cubic B-spline6, Mitchell-Netravali cubic6, Catmull-Rom spline6 perform in term of quality and speed compared with default bi-cubic -1.00?

Quality = color, sharpness, blur etc
Speed = gpu utilization especially on low end gpu

[CruNcher]

Hmm the whole VMR9 is unstable here it either crashes on load of the Video or shows this mirroring of the Desktop effect, switching to VMR7 Renderless and it plays fine :( (maybe because i have everything Vsync related disabled ? )
Reset to default Rendering Settings and Optimal Settings also has 0 effect on this crash and mirroring issue (seems also it doesn't activate Vsync @ all) so still tester dfr3329 is the last version that works with VMR9 for me (XP) (Nvidia Geforce GTX 460)

[Hera]

Crashing between files is probably due to all the worthless re-initializing...

[ForceX]

Reinitializations are extremely disruptive and adds frustration to user experience. Nothing beats smooth, constant playback, regardless of resizing and whatnot. General people will notice responsive seeking and smooth playback more than a shift in colors. If at all possible, you should try to eliminate all reinitializing.

Moving on, in 3525i subtitle scaling is messed up after resizing the window.
Non-resized: http://i53.tinypic.com/10s6ttu.png
Resized: http://i56.tinypic.com/2r5xhc4.png

[CruNcher]

Crashing between files is probably due to all the worthless re-initializing...

Its not crashing between files here its rather a random thing on load it either crashes or shows this mirror effect of the desktop in the Video Playback Window (instead of the Video content) before that in the previous test builds it showed the Video extreme zoomed in but at least it didn't crash it only seems to happen on a VMR9 surface VMR7 seems not affected.
I guess the problem is something NT 6 specific and doesn't work on NT 5 or some problem with the 460 GTX

[Jtacdf]

It crashes when switching files for me, it crashes at random for CruNcher. At any rate, it still crash :p

@JanWillem32
Will this be a main priority for you to fix? Seems to be quite a major issue.

[janos666]

Just a tip for plasma TV users:

I had fears that the aggressive dithering of my PDP (these panels have very few real color shades) may interfere with the dithering noise added by the renderer.

The most noticeable banding comes from the range expansion, and I guessed the TV doesn't really mind if it works from limited or full range input (everything is processed and dithered anyway, but it happens with fairly high quality...), so I used the [0,255]->[16;235] shader and re-calibrated my TV for limited range RGB input.

The rounded 10-bit limited RGB gives me slightly better result than dithered 8/10-bit full RGB (it's most noticeable on dark shades which are always noisy, and some lighter shades looks a bit less noise now).
I guess it's something like "you can't paint a designed-to-be-random noise with another and different designed-to-be-random noise".

---

It reminded me...
@JanWillem32: Did you talk with the team about asking that nonstandard YCC driver mode from AMD?

[TheElix]

The most noticeable banding comes from the range expansion, and I guessed the TV doesn't really mind if it works from limited or full range input (everything is processed and dithered anyway, but it happens with fairly high quality...), so I used the [0,255]->[16;235] shader and re-calibrated my TV for limited range RGB input.Can you explain how the same exact colors/shades of grey can give you less dithered (read: noisy) picture if it's on the same panel? Because I can't. I tried using TV levels as video output range with [16, 235], [16, 240], [16, 240] to full range for SD&HD video input shader. And saw no differences on my calibrated plasma. Maybe you were anticipating good results?

[janos666]

@TheElix

The near-black shades look a little bit more distinguishable from each other and the shades around ~20% looks a little bit less noisy (I guess they are just more distinguishable as well).

The TV uses noise to visualize the missing color shades but that doesn't mean it was intended to be recognizable by humans. The same applies for the dithering in the renderer. The dark color shades need heavy internal dithering, so it's doubtful if the TV can paint a nice noise pattern with it's noise. I think I got something noisy with ~8-bit effective precision (after distorting the original dithering from the renderer), but that's not enough for the expanded levels, so it wasn't too smooth.

I saw and calibrated the same plasma model for somebody who had a desktop media player with YCC output option. I noticed his set produces slightly better near-black scale than mine. Now, with limited range, they are closer (hard to tell without seeing them next to each other, though...).

[TheElix]

On a properly calibrated PDP you will generally see more clean/less noisy images (especially in darker grayscale patterns) because the red, green and blue components are mixed equally. On a non-calibrated plasma you may take a picture of pure black screen with 1/600 shutter speed and see how much red/green/blue dots are appearing in the picture whereas there should be none.
The method you're talking about may affect positively some shades of gray while introducing even more noisy picture for other shades of gray (because of different methods (video card processing and shaders) of levels expansion, I assume). It would require extensive testing to get objective comparisons. Otherwise, you just have to believe in it or not.