Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[Trib]

Is the 2712 driver still password protected?

[egur]

How long will it survive 103C :D and how much can it cool down with throttling ?

Not sure how long, at 105C it would shut off so it wouldn't burn so this was close.
Throttling is lowering frequency for a certain amount of time, this happens above 100C if I remember correctly.

[Octo-puss]

Eric, do you indirectly confirm that stock Intel coolers are useless and crappy then? :)
103° under 85% load is pretty damn bad. Or don't tell me it was under 30%, that would be too bad.

[NikosD]

Good news:
* Managed CrowdedRun (4K@50fps, ~122mbps) with 30% CPU@3.2GHz using both ffdshow and LAV. libavcodec (ffdshow) took 85% CPU@2600 (jumps to 2700).
* This clip is the worst case scenario - very high bitrate, high resolution, high frame rate - stresses all the subsytems (memory, decoder, CPU). Most 4K clips have 1/4 of the bitrate and half the frame rate.



Eric,

the clip you mention is a "medium" one.
Not at all worst case scenario.

Please try:
http://xhmikosr.1f0.de/samples/2160p/OldTownCross/OldTownCross_2160p50.x264.CRF24.mkv

It has twice the bit rate of the sample you tested at the same frame rate and resolution.

Of course there are some even worst case scenarios :)

Also it could be useful to test native DXVA LAV quicksync decoder, removing the restriction of 1080p

Thanks

[wanezhiling]

http://xhmikosr.1f0.de/samples/2160p/DucksTakeOff/DucksTakeOff_2160p50.x264.CRF24.mkv
This clip is the worst case scenario.:)

[egur]

Eric, do you indirectly confirm that stock Intel coolers are useless and crappy then? :)
103° under 85% load is pretty damn bad. Or don't tell me it was under 30%, that would be too bad.

It was a rather expensive TEC cooler - this is lab equipment not consumer stuff. The fan had a poor contact with the CPU because of old thermal paste and polymer surface.

I actually like the Intel coolers - they are very quiet and cost nothing.

[Octo-puss]

The good stuff must be only on new CPUs then. Im sure my wife's Core i3 BOX cooler is worse than anything on this planet :P
I'd be interested in temperature with fixed cooling. Can you possibly try again when you have some extra time?

[egur]

The good stuff must be only on new CPUs then. Im sure my wife's Core i3 BOX cooler is worse than anything on this planet :P
I'd be interested in temperature with fixed cooling. Can you possibly try again when you have some extra time?

I'll try the other clips on Sunday.

[CharlieCL]

Good News. I finally be able to test the exclusive Full Screen with QS, LAV splitter, and LAV 0.50.2 on Windows 7 64-bit, it worked fine now.

[wanezhiling]

http://software.intel.com/en-us/articles/vcsource-tools-media-sdk/

http://registrationcenter-download.intel.com/akdlm/irc_nas/2597/w_MSDK-2012_pu_3.0.015_R2.zip

:)

[CruNcher]

No release notes for R2 nothing i guess it's just the IVY update to 1.3 API, like it was floating around in the beta driver :)

[egur]

No release notes for R2 nothing i guess it's just the IVY update to 1.3 API, like it was floating around in the beta driver :)

There's a release notes document with the MSDK download.
Changes from the 2012 gold version are:
* Three new H.264 profiles and 6 (all defined in standard) constrained flags were defined. This change should simplify Media SDK usage by providing direct access to constrained flag configuration.
MFX_PROFILE_AVC_CONSTRAINT_SET0/1/2/3/4/5
MFX_PROFILE_AVC_CONSTRAINED_BASELINE
MFX_PROFILE_AVC_CONSTRAINED_HIGH
MFX_PROFILE_AVC_PROGRESSIVE_HIGH
* View output mode was added for MVC encoder mfxExtCodingOption::ViewOutput. This flag instructs encoder to output each view in separate bitstream buffer and format them according to Blu-ray* and AVCHD* Format requirements.
* MVC encode now supports interlace coding mode.

[nevcairiel]

Hey Eric,

i found a sample with quite an odd behaviour today.

http://files.1f0.de/samples/h264-qs-timestamp-issue.mkv

When i play this file with LAV in QS mode, it plays too fast (should be 24p, plays at 30p), running out of sync.
I checked the timestamps of the file, and they are fine. Plays fine with software or other hardware codecs too.

For some reason, the QS decoder insists on changing the timestamps, even though i turn off the timestamp mangling flag that you expose.

I'm running driver 2696, happens both on my Ivy and Sandy systems.
I just tried 2656, and the problem does not occur anymore.

The driver dependency makes me believe its the MediaSDK itself causing this, and not your code directly.
Can you maybe check if its something you can turn off, or maybe if the problem is just gone in a newer driver which i don't have yet? :)

Edit:
2712 is also showing the problem.
Either its a bug in the newer MediaSDK libraries which you should forward, or its a feature thats on by accident?

[egur]

Hey Eric,

i found a sample with quite an odd behaviour today.

http://files.1f0.de/samples/h264-qs-timestamp-issue.mkv

When i play this file with LAV in QS mode, it plays too fast (should be 24p, plays at 30p), running out of sync.
I checked the timestamps of the file, and they are fine. Plays fine with software or other hardware codecs too.

For some reason, the QS decoder insists on changing the timestamps, even though I turn off the timestamp mangling flag that you expose.

I'm running driver 2696, happens both on my Ivy and Sandy systems.
I just tried 2656, and the problem does not occur anymore.

The driver dependency makes me believe its the MediaSDK itself causing this, and not your code directly.
Can you maybe check if its something you can turn off, or maybe if the problem is just gone in a newer driver which i don't have yet? :)

Edit:
2712 is also showing the problem.
Either its a bug in the newer MediaSDK libraries which you should forward, or its a feature thats on by accident?

Odd behavior - managed to reproduce. Still no root cause. I'll update when I have a fix.

I've root caused the problem:
* H264 SPS header doesn't contain a frame rate (num_units_in_tick = time_scale = 0).
* If I manually set the frame rate for the MSDK to 23.976 it will behave correctly.
* This happens even when VPP is off and no time stamp calculation/manipulation.

Nev, make sure the version of the MSDK HW DLL is 368 (from 2696) not 369 (from 2712).

I've committed a patch that also fixes some DI issues along with a workaround for the above issue (r51).

Here's my commit log:

Experimental build - not stable enough for production SW.
* Update to MSDK 2012 R2.
* Workaround for MSDK bug - zero frame rate in H264 SPS header would cause a wrong frame rate.
* Deinterlacing now works on frames stored as progressive but marked as interlaced content (many PAL TV broadcasts).
* Telecined content not supported by DI (yet).

[NikosD]

I'll try the other clips on Sunday.

Eric,

if you try the 4K clips posted by Wanezhiling and me, you can use PotPlayer's internal built-in codecs, because it has an option to "force" HW decoding above 1080p.

The tab key shows CPU utilization of PotPlayer process alone and overall CPU utilization at the same time, separated by a "/".

This is in case you want to check playback performance, not benchmarks of course.

PotPlayer has an extra advantage:
It has direct/ native internal DXVA playback and your QS decoder as an option, too.

So you can check both (direct DXVA and QS decoder) in an easy way, until Nevcariel fixes LAV filters playing 4K in direct mode.

[egur]

Tested 5 4K clips using LAV and ffdshow.
LAV and ffdshow showed very similar results so I just wrote LAV-QS score.
The CPU% is how much the player's process took, not the entire system. All clips maxed out turbo at 3.4GHz. Performance wasn't constant during playback as the clips varied in bitrate - OldTownCross ran at 280mbps, peaking at 500 (!) mbps which is outside H264 spec.

CrowdedRun 29% (up to 34%)-3.4GHz
DucksTakeOff 36% (up to 42%) -3.4GHz
InToTree 32% (up to 36%) -3.4GHz
OldTownCross 36% (up to 42%) -3.4GHz
ParkJoy 29% (up to 31%) -3.4GHz

LAV DXVA-CB – half the CPU% of QS but drops a lot of frames (visually, EVR reports everything is OK). Clips are not playable.
LAV DXVA-native – not working – uses libavcodec, maxes out CPU.

[nevcairiel]

LAV DXVA-native – not working – uses libavcodec, maxes out CPU.

Native DXVA is limited to 1080p right now, because there are quite some issues with DXVA of 4K on AMD and NVIDIA.
Need to re-visit this in a while when everything has new drivers. Its not like 4K content is important right now.

I probably should improve the logic to allow Intel, but will do that in one go when i check it again.

[egur]

Native DXVA is limited to 1080p right now, because there are quite some issues with DXVA of 4K on AMD and NVIDIA.
Need to re-visit this in a while when everything has new drivers. Its not like 4K content is important right now.

I probably should improve the logic to allow Intel, but will do that in one go when i check it again.

I'm considering 4K video a preview to a new technology - give us and the HW makers time to clean up the act before it becomes mainstream.

[hajj_3]

4k video will probably be using HEVC codec though, i'm not sure if we'll see much 4k video in h.264. I'm hoping that Intel adds dedicated hardware in Haswell for HEVC hardware decoding.

[nevcairiel]

4k video will probably be using HEVC codec though, i'm not sure if we'll see much 4k video in h.264. I'm hoping that Intel adds dedicated hardware in Haswell for HEVC hardware decoding.

Doubtful that it'll be in Haswell already.
The HEVC standard isn't even finalized yet, and content providers will take years to adopt it anyway.

[hajj_3]

there is already an ARM chip that has HEVC support and that chip was released a while back. The final draft spec is out in july and ratified in january. Chip makers already have chips that can do HEVC hardware decoding such as qualcomm snapdragon and ziilabs: http://www.youtube.com/watch?v=vZfsULKG2Zo http://www.eetimes.com/electronics-news/4236490/ZiiLabs-samples-stem-cell-Android-SoC

So i'm pretty sure that intel could have support in haswell if they wanted to.

Yes it will take a while for software support for HEVC but if they have hardware that can support it then your pc will be future proofed (video-wise) with a haswell cpu.

[egur]

Doubtful that it'll be in Haswell already.
The HEVC standard isn't even finalized yet, and content providers will take years to adopt it anyway.

Let me correct that, not doubtful - impossible. Spec closes in 2013 about the same time Haswell hits the market...
Intel would need a time machine to pull this off :)

there is already an ARM chip that has HEVC support and that chip was released a while back. The final draft spec is out in july and ratified in january. Chip makers already have chips that can do HEVC hardware decoding such as qualcomm snapdragon and ziilabs: http://www.youtube.com/watch?v=vZfsULKG2Zo http://www.eetimes.com/electronics-news/4236490/ZiiLabs-samples-stem-cell-Android-SoC

So i'm pretty sure that intel could have support in haswell if they wanted to.

Yes it will take a while for software support for HEVC but if they have hardware that can support it then your pc will be future proofed (video-wise) with a haswell cpu.

This ARM SoC has a DSP processor to do the decoding. DSPs are programmable so it's not an ASIC solution. This is not far from CUVID in concept. They can always rewrite the DSP code. It will suck a battery dry in no time...

[NikosD]

New intel beta drivers for Windows 8, for both Sandy and Ivy.
They work also for Win 7 (I tried 32bit version with Core i5 and Win 7 SP1 x86)

They include OpenGL 4 drivers for Ivy.

You can download the HD Graphics driver v2927 (15.28.0.64.2729 (9.17.10.2729)) from this page

64bit:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21180&lang=eng

32bit:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21235&lang=eng

[CharlieCL]

Some GPUs of Ivy Bridge Core i5 are HD3000, can it play 4K?

[nevcairiel]

Some GPUs of Ivy Bridge Core i5 are HD3000, can it play 4K?

Ivy Bridge is either 2500 or 4000, none are 3000.
Both 2500 or 4000 should be able to play 4K.

[CruNcher]

does it also fit performance wise 2000(GT1),2500(GT1),3000(GT2),4000(GT2?) ;) ?

i doesn't looked @ a compare of 2500 (Ivy,GT1) vs 3000 (SB,GT2) yet

though actually Ivy bridge has been renamed back to GT1 in that line so i guess it doesn't fit to continue the GT naming indeed as we talking about 6 (2500) vs 12 EUs (3000) ;) and getting the same performance with half the EUs i doubt that (on the 3D part).

And the speculation about Haswell also sound a little crazy 40 Eus with the Performance of what ;) 80 or even 160 of the current EUs ;)


New intel beta drivers for Windows 8, for both Sandy and Ivy.
They work also for Win 7 (I tried 32bit version with Core i5 and Win 7 SP1 x86)

They include OpenGL 4 drivers for Ivy.

You can download the HD Graphics driver v2927 (15.28.0.64.2729 (9.17.10.2729)) from this page

64bit:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21180&lang=eng

32bit:
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21235&lang=eng


Outch
Normally i don't give much about Benchmarks but Microsofts Performance Index Shows a Performance Decrease of 1.1 Points on my HD 2000 for the Game Graphics Value before it was 5.8 (Aero Performance result stayed the same @ 5.2) that's a heavy drop before this drop it was constantly going up per driver release climaxing @ 5.8 with 2719 with 2729 now it dropped down to 4.7 (and becomes the final system result now compared to 5.2 before).

This might indicates some big change here (maybe IQ wise ?)

Have todo some real Engine tests to see if there is something realizable outside of Benchmarks

I could swear Aero feels even snappier (this also constantly improved over driver releases) though (lower latency) even showing no real Benchmark improvement in the Performance Index.

Yep definitely a good latency test is the Aero to Windows Basic change it's much much faster then it was in every previous driver (the mode change is almost fluid now, though Win 8 will be totally fluid WDDM 1.2 ) :)

@egur

Both Lav Video Quicksync as well as FFdshow Quicksync stopped working (DXVA works)

[egur]

Windows 8 drivers have either broken MSDK DLLs or they are missing altogether. The Win8 drivers are beta and not fully functional.

[diizzy]

Hi,

I might be completely off in this matter but I can't enable QS on my i7-3770 (non K) and I can't find out why, LAV Filters lists it as "Not available" and it doesn't show up in ffdshow at all.

Motherboard: MSI Z77A-GD65
OS: Windows 7 Pro 64-bit SP1
Driver: 8.15.10.2712 (link: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21135&ProdId=3442&lang=eng&OSVersion=Windows%207%20%2864-bit%29*&DownloadType=Drivers )
ffdshow: ffdshow_rev4441_20120430_xhmikosr_icl12.exe (I can give your build a go if you want to)
LAV Filters: 0.50.2

Does it require lucid or something?

//Danne

[wanezhiling]

Using PotPlayer latest version and ATi hardware in DXVA mode I couldn't play both of them at the signature system.

Playback of the MPEG-2 clip is awful - I can't see even one frame correct.

Playback of the H.264 file is better - the only problem is a green horizontal stripe at the top of the film.

BTW, WMP12 plays both clips perfect in DXVA mode.

PotPlayer 1.5.33425 should have fixed both.:)

[egur]

Hi,

I might be completely off in this matter but I can't enable QS on my i7-3770 (non K) and I can't find out why, LAV Filters lists it as "Not available" and it doesn't show up in ffdshow at all.

Motherboard: MSI Z77A-GD65
OS: Windows 7 Pro 64-bit SP1
Driver: 8.15.10.2712 (link: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21135&ProdId=3442&lang=eng&OSVersion=Windows%207%20%2864-bit%29*&DownloadType=Drivers )
ffdshow: ffdshow_rev4441_20120430_xhmikosr_icl12.exe (I can give your build a go if you want to)
LAV Filters: 0.50.2

Does it require lucid or something?

//Danne

You need Lucid if you don't have a display connected to Intel GPU. Direct3D/DXVA requires a display for GPUs to be enumerated. You can also try faking a connected display. See a previous post (http://forum.doom9.org/showthread.php?p=1532786#post1532786)

[diizzy]

I see, the thing is though that I'm only using the IGP. Is QS detection perhaps based on driver version?
//Danne

[egur]

I see, the thing is though that I'm only using the IGP. Is QS detection perhaps based on driver version?
//Danne

If it's not detected, it's a driver problem. try installing a newer driver (Intel download center or from OEM). IvyBridge drivers are also fine (same driver installation). FYI, don't install drivers from windows update.
You may need to reinstall ffdshow as it checks for compatibility during installation.

[NikosD]

PotPlayer 1.5.33425 should have fixed both.:)

Indeed, it did.

[CruNcher]

NikosD and wanzehiling could you check if MPC-HC have fixed them before Potplayer did, or is MPC-HC still showing the same issues on your ATI Cards ?
MPC-HC actually showed these changes for me i think before Potplayer was updated (or did i miss that Potplayers guys contribute back now ????).
If both show the same results now im pretty sure Potplayer guys just updated and you should thx aleksoid i guess ;)

[Atak_Snajpera]

@cruncher
when was the last time you used periods in sentence? ;)

[CruNcher]

ehmm look again ;D

Windows 8 drivers have either broken MSDK DLLs or they are missing altogether. The Win8 drivers are beta and not fully functional.

they're there C:\Program Files\Common Files\Intel\Media SDK\s1\2.0\libmfxhw32(64)-s1.dll is there and updated 3.12.3.30/3.5.28112.40659 (Trunk MS MVC for HSW) Package Contents: Intel® Media SDK for IVB Win8, though i guess then they're broken will try to place them per application (maybe only the dispatching is broken, or needs a different API call 104 ?) and with older ones and see what happens or installing the R2 makes them magically work ;)


i wonder why they package the trunk SNB ones in the Installer if they don't work though maybe they work with 2712, strange encoding works with the updated (libmfxhw32-s1.dll) on the "Win8 Driver" only Decoding seems to make problems (though also only Quicksync, DXVA works fine with these Drivers), the Driver as mentioned works on Win7 and shows WDDM 1.1 as Driver Model (except the Qicksync API Decoding broken @ least no Quicksync API using Application works, Mirillis Splash Player,Lav Video Quicksync, FFDshow-Quicksync, Potplayer-Quicksync, Arcsoft), and the lower Windows Performance Index Game Benchmark Value it seems to work pretty normal) ;)

So it seems the only thing that's broken is Quicksync API Decoding for SNB (@ least you get a black screen from applications that use it @ playback and no loaded libmfxhw32-s1.dll) though the Quicksync API Encoding works normal (via libmfxhw32-s1.dll).

This way you can also find out which ISV is using indeed Quicksync API for Decoding in Native mode directly or DXVA if you aren't sure and dunno how to analyze this ;)
Mirillis and Arcsoft are both using the Native Quicksync Decoder API (no DXVA for Intel, H.264).

1 good news the 2 DXVA crashes in the Driver seem history in 2729 (gonna check the same with the updated libmfxhw32-s1.dll on 2712) :)

[wanezhiling]

NikosD and wanzehiling could you check if MPC-HC have fixed them before Potplayer did, or is MPC-HC still showing the same issues on your ATI Cards ?
MPC-HC actually showed these changes for me i think before Potplayer was updated (or did i miss that Potplayers guys contribute back now ????).
If both show the same results now im pretty sure Potplayer guys just updated and you should thx aleksoid i guess ;)

http://i.imgur.com/KjoUG.png
MPC-HC 4643

Actually PotPlayer 1.5.33227(27.04.2012) had fixed the H264 DXVA issue.:)


PotPlayer 1.5.33425(07.05.2012) just fixed another MPEG-2 clip.:)

I can't test the MPEG-2 clip on MPC-HC now because you know 4650M doesn't support MPEG2_VLD. Yesterday I'll test on HD6850 again.
Edit: MPC-HC 4644 on HD6850 http://i.imgur.com/Fn0DZ.jpg



And you need not doubt that, PotPlayers Codec just updated from MPC-HC, they always have the same DXVA issue.:)
http://forum.doom9.org/showpost.php?p=1564276&postcount=19047
http://forum.doom9.org/showpost.php?p=1568536&postcount=19212

Besides, http://forum.doom9.org/showpost.php?p=1570072&postcount=19283
http://forum.doom9.org/showpost.php?p=1572770&postcount=19456
http://forum.doom9.org/showpost.php?p=1572156&postcount=19427

But PotPlayer devs fixed these issues first before I posted in MPC-HC thread.:)

[CruNcher]

Thx wanezhilling

btw i get more Video Rendering problems now with the 2729 driver on Win7 the more i test different things the more issues show up ;) (currently Adobe Flash Player 11.3 fails rendering some strange things together ;) )so yeah Beta seems to mean Beta here i go back to 2712 and try my luck with the new Decoder there ;)

Though maybe i got the driver to much under pressure with the Quicksync Rendering test that he now only shows Garbage, though i have a funny idea lets see what happens when... ;)

ahh btw if you remove or rename the hardware dll from the dispatcher dir you can provocate that Lav Video Quicksync and FFdshow Quicksync fallback to libmfxsw (though questionable why anyone would want that instead off avcodec ;) )

[egur]

CruNcher,
If I understand correctly, you couldn't get the 15.28.0.2729 driver to work (with QS) under windows 8 at all? If not, can you give me a full system description.

I should get a Win8 system soon so I can start testing it myself.

[nevcairiel]

He tried the Win8 driver on Win7, and then complained it wasnt working. :p

[nevcairiel]

I've root caused the problem:
* H264 SPS header doesn't contain a frame rate (num_units_in_tick = time_scale = 0).
* If I manually set the frame rate for the MSDK to 23.976 it will behave correctly.
* This happens even when VPP is off and no time stamp calculation/manipulation.

[...]

I've committed a patch that also fixes some DI issues along with a workaround for the above issue (r51).


Hi Eric,

i finally managed to test, and it does work indeed.
However, the Media SDK is still modifying the timestamps, which it really shouldn't be doing. (MKV timestamps are 41ms/42ms aparts because of missing precision, MSDK outputs timestamps 41.711/41.700 apart)
Because we feed it the proper fps now, there is no wrong behaviour anymore, however its still bad that it touches the times at all. The H264 SPS header value does not have to match the actual video timestamping.

Did you raise this issue with the MSDK developers? I would really love to go back to previous behaviour and get the same timestamps out that i put in.

[egur]

Hi Eric,

i finally managed to test, and it does work indeed.
However, the Media SDK is still modifying the timestamps, which it really shouldn't be doing. (MKV timestamps are 41ms/42ms aparts because of missing precision, MSDK outputs timestamps 41.711/41.700 apart)
Because we feed it the proper fps now, there is no wrong behaviour anymore, however its still bad that it touches the times at all. The H264 SPS header value does not have to match the actual video timestamping.

Did you raise this issue with the MSDK developers? I would really love to go back to previous behaviour and get the same timestamps out that i put in.

Hi Hendrik,
I raised the issue but I don't know yet when it will be fixed (yet).

Does it change the time stamps on other clips or just the problematic one?

There are other issues:
Had to remove progressive flags from frames to force the DI to work - happens a lot in PAL TV broadcasts.
Telecined content is not handled well. This something I can probably fix (given I had some time).
It also seems that 2:2 pulldown isn't working. 2:2 content (50i) will output 50fps after the DI deinterlaces it - regardless if the source was progressive.

What about the HDMI RGB levels issue (from your thread), anything to add?

[nevcairiel]

Does it change the time stamps on other clips or just the problematic one?

I don't think so. The only other things i see are probably inaccuracy from the timebase conversion. Like, sometimes it changes from a duration of 420000 to 419888, and from 410000 to 410112 on the next frame, balancing each other out, which i'll just blame on the conversion onto a different time base.

Only for those files where i gave you a sample earlier, it seems to completely rewrite the timestamps.



What about the HDMI RGB levels issue (from your thread), anything to add?
I just know that the HDMI setting will not "stick" for me, anytime i reboot or even the resolution is changed, it resets. Apparently its a known issue already.
Another thing was that changing it did not change the image at all for me, but i'm not sure why that was, might be some unrelated factor. I'm now using a dGPU again, anyway.

[egur]

I just know that the HDMI setting will not "stick" for me, anytime i reboot or even the resolution is changed, it resets. Apparently its a known issue already.
Another thing was that changing it did not change the image at all for me, but i'm not sure why that was, might be some unrelated factor. I'm now using a dGPU again, anyway.

OK, but why change it in the first place, does it actually output a limited RGB range? Because like I reported, the levels were fine.

[nevcairiel]

OK, but why change it in the first place, does it actually output a limited RGB range? Because like I reported, the levels were fine.

Mine outputs limited range, which seems to be the default when it detects a TV.
Movies are fine (once player settings were adjusted accordingly), however the desktop looks weird in that mode, which is why i want full range, and my TV is also calibrated to that end.

[egur]

Mine outputs limited range, which seems to be the default when it detects a TV.
Movies are fine (once player settings were adjusted accordingly), however the desktop looks weird in that mode, which is why i want full range, and my TV is also calibrated to that end.

No calibration is needed for the TV if you use HDMI. The levels calibration (contrast/brightness) was meant for analog connections.

If your TV has such settings, set HDMI input levels full and disable 16:9 overscan.

Set brightness to zero and contrast to 100% which is 1x gain (or lower if it's too bright for you). For proper TVs 100% means that white goes to the brightest white the display can output. Bad TV might do over-contrast - light grays will become white, effectively losing detail in the light areas.

Saturation should be at default (1x gain) and there's no reason to touch Hue/Tint.
If your TV allows you to modify Gamma curves (RGB tables), leave them at default.
The desktop should look perfect at this point. This is your starting position.

If you've done this, does the desktop still look bad in the default driver settings?

[nevcairiel]

If you've done this, does the desktop still look bad in the default driver settings?

No matter what i configure, the desktop is supposed to be full range, and if the HDMI connection is run at limited range, the desktop will have crushed blacks and whites.

[egur]

No matter what i configure, the desktop is supposed to be full range, and if the HDMI connection is run at limited range, the desktop will have crushed blacks and whites.

That's incorrect. The control panel entry for full/limited control the display pipeline which is not part of the video pipeline. The display pipeline basically outputs the desktop (always RGB), apply color corrections (ICC LUTs), optionally compress levels (to output 16-235) and optionally color space conversions (e.g. for digital YCbCR output or S-VHS/composite).
If your system's desktop looks bad, 99% that your TV is set up wrong.

If by "crushed" you mean that dark grays become black and light grays become white (over contrast) it means that your TV is expecting a limited RGB range and it receives a full range.

If by "crushed" its the other way around: black becomes gray and white becomes light gray, this means that the PC is outputting a limited range and the TV is expecting a full range.

All these check must be done when the TV contrast/brightness is at defaults.

If you can't make the desktop look OK, this is very serious quality issue. It means you'll get excessive color banding due to quantization. It will also strengthen noise.

Nev, I really like to help, but I need to know the exact conditions before I file a report. Especially since I can see proper levels on my own system (but levels are reversed and setup doesn't stick).
Also, please remember that I'm not a native English speaker and a clear detailed explanation will help (words like crushed can have multiple meanings).

[nevcairiel]

That's incorrect. The control panel entry for full/limited control the display pipeline which is not part of the video pipeline. The display pipeline basically outputs the desktop (always RGB), apply color corrections (ICC LUTs), optionally compress levels (to output 16-235) and optionally color space conversions (e.g. for digital YCbCR output or S-VHS/composite).
If your system's desktop looks bad, 99% that your TV is set up wrong.

I just run apps on the desktop that just look bad when they are compressed into limited range.
I simply want full range. I can get full range with NVIDIA and AMD, but Intel fails, because it resets to Limited all the time. Hence, a bug on Intels side. My motivation is irrelevant. I just want Intel to give me what i had all those years before as well. End of discussion.
Not that i care, i use a dedicated GPU anyway now because Intels drivers still suck, in my opinion they haven't really changed much since SNB release.

The bug is defined very clearly, the levels dropdown is reseting all the time, and apparently for some people even reversed.

Note that i calibrated my TV for the previous GPU with a colormeter, but since i couldn't even get the blacklevels right i didn't bother to do that for the Intel GPU.
I just got a new TV this week, too, need to calibrate the new TV with the new GPU this weekend.

[aufkrawall]

Is there a chance that there will be WMV3 decoding somewhen? :)