Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[diizzy]

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

[egur]

Originally Posted by diizzy

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]

Originally Posted by wanezhiling

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

Originally Posted by egur

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]

Originally Posted by 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

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?...ostcount=19047
http://forum.doom9.org/showpost.php?...ostcount=19212

Besides, http://forum.doom9.org/showpost.php?...ostcount=19283
http://forum.doom9.org/showpost.php?...ostcount=19456
http://forum.doom9.org/showpost.php?...ostcount=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.

[nevcairiel]

Originally Posted by egur

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]

Originally Posted by nevcairiel

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]

Originally Posted by egur

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.

Originally Posted by egur

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]

Originally Posted by nevcairiel

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]

Originally Posted by egur

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]

Originally Posted by nevcairiel

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]

Originally Posted by egur

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]

Originally Posted by nevcairiel

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]

Originally Posted by egur

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?