Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing [Archive] - Page 13

CharlieCL

20th January 2012, 17:10

Ever since my decoder was integrated into ffdshow's official builds (a few months back), I've set the default codecs to their original values (mostly libavcodec). If you install ffdshow on top of an existing version, you're settings are not touched. So you need to configure ffdshow only once and updates will not touch this.
Disabling windows codecs has nothing to do with ffdshow or my decoder. I don't know what problems you have and why you need to disable them again and again. This doesn't occur on my PC and I didn't receive complaints from other users.

Since there are many ffdshow distributions I do not know which one is official :-( I have tried one and found that there is a doubt trojan horse before.

BTW Are your setup program in open source?

There is a program called Win7DSFilterTweaker which allows you to configure your preferred DirectShow filters in Windows 7. FFDshow does not change the priority of filter in Windows 7. Actually I am testing QuickSync in Windows 8 Preview. In the case of automatic match filters just added codec will not be selected in ffdshow.

egur

20th January 2012, 18:20

adaptively changing kernels for downscaling/upscaling :)
do you have any numbers of the raw speed of the Asic just for jaw dropping effect ;)

Changing state for upscaling/downscaling is the responsibility of the driver (works per direction BTW).
I don't know the exact performance numbers and they probably vary depending on GPU clock speed and memory subsystem utilization, but it should support multiple 1080p@60 streams so no problem here. This is for the entire video processing pipeline.

egur

20th January 2012, 18:29

Since there are many ffdshow distributions I do not know which one is official :-( I have tried one and found that there is a doubt trojan horse before.

BTW Are your setup program in open source?

There is a program called Win7DSFilterTweaker which allows you to configure your preferred DirectShow filters in Windows 7. FFDshow does not change the priority of filter in Windows 7. Actually I am testing QuickSync in Windows 8 Preview. In the case of automatic match filters just added codec will not be selected in ffdshow.

I don't have setup at all. FFDshow (http://ffdshow-tryout.sourceforge.net/) has one and so does LAV filters (http://forum.doom9.org/showthread.php?t=156191). Downloads from these sites are safe, they are the official sites.

My decoder is just a DLL, not a DirectShow filter so it's not a standalone product.

I don't have any experience with win8 ATM so I can't comment on the matter. I personally used the Win7DSFilterTweaker tool so I can't use ffdshow (or LAV decoder) under Windows Media Center. I didn't see a problem when upgrading either LAV or ffdshow versions. Maybe win8 is somehow different. Anyway within ffdshow or LAV, my decoder will not affect the way it connects to the renderer or how it's enumerated by DirectShow. Maybe I'm missing something, anyway else had issues?

RBG

20th January 2012, 23:26

egur

I usually use YV12 as avisynth input doesn't accept NV12, but it doesn't matter, when I mentioned SB hw scaling in my previous post, I was thinking about how it will work in future. So lets imagine, that you have already implemented SB hw scaling inside ffdshow decoder, can you clear some things up for me.:) Ordinary video is 4:2:0 Y'CbCr, it has full luma resolution and a half of chroma resolution, for you to be able to watch video on computer display, render upscales or downscales chroma and luma to match monitor resolution and converts it to RGB. From how I understand the SB hw scaler technology, it resamples standard 4:2:0 to match display resolution in both chroma and luma, and that means that output will be full 4:4:4. Ffdshow in this case needs to know when internal scaling is turned on, and automatically output AYUV(or RGB) not to ruin picture quality archived by SB scaler. Correct me please, if I am wrong?

BTW Have a good vacation.:)

tremens

23rd January 2012, 09:41

starting with version 0.21.0.0, the option for use of this decoder on my atom n280/945gm eeepc is disabled. i realize its unstable and this is probably why its disabled, but its the fastest h264 decoder for this lowly netbook and its use is worth the occasional crash for me. anyway to override?

nevcairiel

23rd January 2012, 09:54

For some reason the later versions don't function on non-SandyBridge hardware anymore, there currently is no way to override it.
I hope egur can look into it at some point again, to allow usage on older hardware, even if its less efficient.

namaiki

23rd January 2012, 10:48

That's pretty weird. I thought that the 945gm doesn't have H.264 hardware video decoding but starting with the Intel 4 series chipset which is about 2 generations later.

nevcairiel

23rd January 2012, 11:53

Its not 100% clear from documentation, there is contradicting documentation out there.
Easiest way to check is just to use DXVA Checker.

Without doubt, the first chip to support everything properly is the X4500HD in the G45 chipset, any previous chips may offer some support, but nothing i would rely on.
The argument still stands however, Erics decoder doesn't work on a X4500HD or Intel HD Graphics with ClearVideo HD - only on QuickSync enabled CPUs.

I hope this can be fixed, somehow.

tremens

23rd January 2012, 16:46

the 945gm does not support any real hardware h264 decoding, nevertheless, this decoder plays 720p files on this netbook that everything else stutters. libav, coreavc, divx...

namaiki

23rd January 2012, 16:56

Just curious, but could you please post a screenshot of the 'Info' tab in 'ffdshow video decoder' when you are playing back a video in the last version which seems to work with the Quicksync decoder?

tremens

23rd January 2012, 18:28

yes, it appears you're right. now as far as i can tell, i'm using libav no matter which is selected. so perhaps it was just placebo combined with updating ffdshow for the first time in a while? but i could of sworn i saw a clear indicator i was using it and i was definitely seeing occasional kernel panics that i had not normally experienced. ill keep trying older revisions but as of now i can't reproduce any of it...

Blight

23rd January 2012, 19:22

CruNcher

23rd January 2012, 19:38

egur:
I would prefer that deinterlacing be handled within the ffdshow framework.
If ffdshow's 'deinterlace' option is enabled, your code should check if ffdshow is set to the QuickSync deinterlace mode and if it is, it should deinterlace, otherwise, you should leave the frame as-is and even let ffdshow use a different deinterlacer.

With regards to image scaling. I have no problem if it only switched the QS scaler on fullscreen.

yep it definitely should be chose able between Render Deinterlacing,ffdshow implementations, and direct Quicksync copy back Deinterlacing
chosing between Render Deinterlacing and Software works fine allready Quicksync Deinterlacing just has to be nicely put as adddition into this by directly including it to the Software Deinterlacing list but mark it as Intel GT1/GT2/GT3/GT4 Hardware Deinterlacing ?
Most devs of ffdshow wouldn't accept it otherwise anyways im pretty sure (because consistency is a major goal between different devices and Windows OS) :) Also this makes it needed i guess that all these IMSDK features are only enabled on Vista/7 and doesn't appear on pre NT 6 (so their needs to be a @ least a OS detection for these Quicksync features maybe even allowing to select them but resulting in a message box that NTs bellow 6 (Vista/7/8) aren't supported). A good thing would be also to use the IMSDK decoder(pp) given frame informations and send them back to the ffdshow OSD as well :)

http://img4.imageshack.us/img4/9942/ffdshowquicksyncdeinter.png

Just a good note VLCs Quicksync playback became more stable their on a good way (just some artifacts now but not the whole green screen problems anymore on most bitstreams) :) (lots of motion artifacts now but @ least you can identify stuff, wrong frame decoding orders,blocks in between ;) ) Cool thing it also works on the OpenGL Renderer (glwin32) :)

pulbitz

24th January 2012, 06:09

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn

CruNcher

24th January 2012, 07:38

wow that mkv lets my explorer crash (parser or decoder) ;) whatever tries to render the thumbnail crashes it :P other mkvs work fine rendering the thumb

pulbitz use lav splitter and there should be no problems with this mux or try to remux it (mkvmerge,haali) if you want 100% interoperability :)

pulbitz

24th January 2012, 08:45

You are right.
But I tested original file. (1.28GB avi file)

magnet:?xt=urn:btih:d1d9e7f7fc8145594d7ad7d06f3013ee10adec04

ms avi splitter + ms dtv-dvd decoder OK.
ms avi splitter + ffdshow libavcodec OK.
ms avi splitter + ffdshow quicksync fails.
mpc avi source + ms dtv-dvd decoder OK.
mpc avi source + ffdshow libavcodec OK.
mpc avi source + ffdshow quicksync fails.

CruNcher

24th January 2012, 08:50

hmm i guess with lav splitter as avi source it works ? did you also tried with lav video (quicksync)
H.264 inside .avi is also not really recommended if you don't know what you do encoding parameter wise :)

pulbitz

24th January 2012, 09:04

lav splitter + lav quicksync is OK.

In Korea, many video files are being released in H.264 .avi. Why? I don't know. :(

CruNcher

30th January 2012, 03:48

My first yadiff vs Intel (deinterlacing 25i->50p) result (upscaling intel SD->HD) (including intel sharpening)

Source = http://www.mediafire.com/?mbuq1zevy5lv59u

lav video intel + intel scale = http://www.mediafire.com/?0kwgpv0xxexwya3
lav video yadiff + intel scale = http://www.mediafire.com/?03v2adyrp3uplt9
lav video intel + intel scale/sharp = http://www.mediafire.com/?v16x8em9ye7e28u
lav video yadiff + intel scale/sharp = http://www.mediafire.com/?pd1i5s19e945756
lav video yadiff + billinear + chroma + sharpencomplex2 = http://www.mediafire.com/?rvewg1sd0d58j55
lav video yadiff + madvr + ffdshow unsharp = http://www.mediafire.com/?f0pcapl3251wmj8

Intel Deinterlacing/Scale:

http://img84.imageshack.us/img84/2817/inteldeinterlacing.th.png (http://img84.imageshack.us/img84/2817/inteldeinterlacing.png)

Yadiff Deinterlacing Intel Scale:

http://img215.imageshack.us/img215/66/yadiffdeinterlacing.th.png (http://img215.imageshack.us/img215/66/yadiffdeinterlacing.png)

Yadiff Deinterlacing + Intel Scale/Sharp (Automatic) 4% CPU/16% GPU

http://img267.imageshack.us/img267/8233/yadiffintelsharpautomat.th.png (http://img267.imageshack.us/img267/8233/yadiffintelsharpautomat.png)

Intel Deinterlacing Intel Scale/Sharp Automatic 1.50% CPU /16% GPU

http://img268.imageshack.us/img268/4481/intelintelscalesharp.th.png (http://img268.imageshack.us/img268/4481/intelintelscalesharp.png)

Yadiff Deinterlacing + Billinear (7% GPU) + Chroma (13% GPU) + Sharpen Complex 2 (19% GPU) (No Intel Upscaling,Sharpening, heavy shader load) 4% CPU/58% GPU Billinear CPU = 4%/51% GPU EVR Custom load = 18%

http://img16.imageshack.us/img16/7449/yadiffbillinearchromash.th.png (http://img16.imageshack.us/img16/7449/yadiffbillinearchromash.png)

Yadiff Deinterlacing + Madvr (Billinear) + ffdshow Unsharp 8% CPU/22% GPU

http://img337.imageshack.us/img337/4069/yadiffmadvrbillinearuns.th.png (http://img337.imageshack.us/img337/4069/yadiffmadvrbillinearuns.png)

There is a slight position difference between EVR (intel scaling) and MPC-HCs EVR Custom and MadVRs Billinear Shader scaling

egur

30th January 2012, 16:03

egur

30th January 2012, 16:19

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn
I'll check it out.

yep it definitely should be chose able between Render Deinterlacing,ffdshow implementations, and direct Quicksync copy back Deinterlacing
...

I'm not sure what the logic should be in ffdshow's deinterlacing tab. Adding the Intel HW deinterlacer (iGPU only) without the QS decoder is complex. What happens then if the QS decoder isn't used because of unsupported surfaces (e.g. 4:2:2 or >8bit) or unsupported codecs?

An option is to add a new field in the deinterlacing tab called Auto. I can check if it's checked and use it. Another option is to add a check box with "Use HW deinterlacing when possible".

I'm open for ideas. I'll also need to ask for approval on the ffdshow dev thread so I'll cause as little trouble as possible :)

CruNcher

30th January 2012, 17:32

Adding the Intel HW deinterlacer (iGPU only) without the QS decoder is complex.
I thought that's what you wanted todo so that it is independent of the decoder used :)

Also i might have an answer for some people for that Quicksync fails Haalis splitter seems to fail in certain situations with it and falls back to libavcodec actually it seems to always fail and im pretty sure because it uses the CCV1 fourcc and ffdshow quicksync doesn't recognizes this as AVC1

A note that the new Haali defaults to passing any H.264 video to the play with the FourCC CCV1 so that CoreAVC can be used in WMP and WMC. This can be disabled in Haali's options if it causes problems.

Output->Use custom Mediatype for H.264 (NO)

see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

egur

30th January 2012, 21:07

I thought that's what you wanted todo so that it is independent of the decoder used :)

Also i might have an answer for some people for that Quicksync fails Haalis splitter seems to fail in certain situations with it and falls back to libavcodec actually it seems to always fail and im pretty sure because it uses the CCV1 fourcc and ffdshow quicksync doesn't recognizes this as AVC1

Output->Use custom Mediatype for H.264 (NO)

see https://forum.doom9.org/showpost.php?p=1554770&postcount=8655

Fixed the CCV1 issue, will release in a few days.
I'm also tweaking the frame copy function some more. Managed to get another 1% speedup so far with reordering of the load/store operators.

Regarding the post processing. If I create a separate component it would mean that the source will be copied to the GPU and the double frame rate output will be copied back, causing - probably needing surface conversions on both sides. This is very heavy lifting. My first try will be to always enable the DI when needed and see how this works. At a later stage I'll add post processing without decode. Since video post processing is a part of the MSDK I didn't use before, I'd like to do things in small steps.

nevcairiel

30th January 2012, 21:21

Regarding performance -

There also seems to be a performance regression from 0.22 to now with the multi-threaded copying.
If i enable multi-threading, and multi-threaded copying, but not multi-threaded decoding, its significantly slower then 0.22 was on the same settings.

Only if i enable multithreaded decoding as well (default settings), it'll be close to 0.22 performance.
Since 0.22 didn't even have multithreaded decoding, shouldn't the performance remain the same?

Is that something you can explain by some changes?
Was truly odd behaviour.

I can try provide some solid test cases, if you need them.
Its only really obvious if multi-threaded decoding is disabled, though, so a default setup of ffdshow doesn't really expose the problem.

egur

30th January 2012, 22:22

QuickSync decoder can't decode this file.
http://www.mediafire.com/?awac8rbwi3e55wn

Fixed. An initialization bug on my part. Actually, I didn't check height/width being mod16.

egur

30th January 2012, 22:32

rsd78

31st January 2012, 16:46

vivan

31st January 2012, 17:29

rsd78,
what's your intel HD Driver version? If .2559 - try downgrading to .2509...

CoolerKing

31st January 2012, 17:38

Hi Eric,

I did some very informal testing of your great decoder on a couple of my HTPCs (running i3 2100T). For some reason (I tried a few different h.264 MKVs) on all my machines it would do a very odd stutter effect, like it was repeating skipping back or forward a few frames. I was using Shark's tools, but I tried by enabling Quicksync via Ffdshow directly as well (but made sure to turn off the ffdshow version) via Lav decoder. I know I tried it with Haali splitter, and I think Gabest. I can't recall if I tried it with Lav splitter, but unfortunately for me I won't use Lav Splitter because it's not compatible with the Media Control plugin which I need. I don't know if this helps you very much, but maybe I missed something obvious.

Thanks

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).

Intel(R) HD Graphics 3000

Driver Version: 8.15.10.2559
Operating System: Windows 7 Service Pack 1(6.1.7601)
Default Language: Dutch (Netherlands)
DirectX* Version: 10.1
Physical Memory: 7912 MB
Minimum Graphics Memory: 256 MB
Maximum Graphics Memory: 1760 MB
Graphics Memory in Use: 140 MB
Processor: Intel64 Family 6 Model 42 Stepping 7
Processor Speed: 3292 MHz
Vendor ID: 8086
Device ID: 0112
Device Revision: 09

* Processor Graphics Information *

Processor Graphics in Use: Intel(R) HD Graphics 3000
Video BIOS: 2104.0
Current Graphics Mode: 1920 by 1200

edit: I tried rolling back the driver to .2509 and the issue persists. Hope someone can post a solution to this problem.

Here's a example picture showing the corruption: http://i.imgur.com/2Sbic.png

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

TPoise

31st January 2012, 18:15

Just wondering, any reason why you aren't doing the x64 builds anymore?

I still really appreciate highly what you're doing here. This simple plug-in has changed my computing habits for the better. For those that travel a lot know what I mean. My battery thanks you.

nevcairiel

31st January 2012, 19:51

If you a have specific clip that shows a performance gap, please share.

http://xhmikosr.1f0.de/samples/2160p/ParkJoy/ParkJoy_1080p50.x264.CRF23.mkv

Default settings, i get around 292 fps with the current version
When i disable MT Decode and MT Processing, i get ~255 fps.

With 0.22, and the same settings, its also 292 fps (but of course, MT Decode and MT Processing didn't exist yet).

It seems that somehow the settings of MT Decode and MT Processing are linked with MT Frame Copy, or there really is a performance regression.

Omel

31st January 2012, 19:51

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).

Intel(R) HD Graphics 3000

Driver Version: 8.15.10.2559
Operating System: Windows 7 Service Pack 1(6.1.7601)
Default Language: Dutch (Netherlands)
DirectX* Version: 10.1
Physical Memory: 7912 MB
Minimum Graphics Memory: 256 MB
Maximum Graphics Memory: 1760 MB
Graphics Memory in Use: 140 MB
Processor: Intel64 Family 6 Model 42 Stepping 7
Processor Speed: 3292 MHz
Vendor ID: 8086
Device ID: 0112
Device Revision: 09

* Processor Graphics Information *

Processor Graphics in Use: Intel(R) HD Graphics 3000
Video BIOS: 2104.0
Current Graphics Mode: 1920 by 1200

edit: I tried rolling back the driver to .2509 and the issue persists. Hope someone can post a solution to this problem.

Here's a example picture showing the corruption: http://i.imgur.com/2Sbic.png

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

Hi
I'm a novice in this. but i had the same issue but this was when using cyberlink pdvd11 codec and when i switch over and used LAV video the issue disappear

I dont know if this will help you in any way

Regards

Omel

egur

31st January 2012, 19:57

Hello,

I think I'm having the same problem with my i5-2500K ever since I first tried.. When I play h264 .mkv files with quick sync enabled, the video is constantly jumping frames back and forward fast, and also shows corruption occasionally. It happens both with LAV and recent FFDShow versions (tried early FFDShow builds before and they would only give me the corruption issues that some other people reported, but not the skipping frames back and forward IIRC).
...

Also, when I close MPC-HC after playing, the process keeps running (could be related to the problem)

Let me know if I can test anything or supply additional logs.

Jumping back and forth was happening on my personal machine when Lucid Virtu was installed. Only affected 64 bit version. I don't know if they fixed the problem or not because I stopped using it. I also couldn't find a way to report this bug directly to Lucid.

Frame corruption that occurs frequently (many clips) is a weird driver install issue. This was reported by several users in the past and all of them reinstalled the driver to overcome this. Some installed an older one and then the latest version. I personally didn't see this effect or know what's the root cause.

Just wondering, any reason why you aren't doing the x64 builds anymore?
...
I always build 64 and 32 bit.
For your convenience here's a link to the file folder on my homepage http://sourceforge.net/projects/qsdecoder/files/ffdshow_builds/
BTW, you can get newer builds from ffdshow's official download area: http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/

FYI, the large green link on the QS decoder homepage is generated by SourceForge, underneath it, you have a link to browse all file.

CoolerKing

31st January 2012, 19:59

Hi
I'm a novice in this. but i had the same issue but this was when using cyberlink pdvd11 codec and when i switch over and used LAV video the issue disappear

I dont know if this will help you in any way

Regards

Omel

Thx for the suggestion, but as I already mentioned, LAV and FFDShow both give the same problem (I just tested LAV 0.45 again).. guess they are using the same QuickSync decoder.

Jumping back and forth was happening on my personal machine when Lucid Virtu was installed. Only affected 64 bit version. I don't know if they fixed the problem or not because I stopped using it. I also couldn't find a way to report this bug directly to Lucid.

Frame corruption that occurs frequently (many clips) is a weird driver install issue. This was reported by several users in the past and all of them reinstalled the driver to overcome this. Some installed an older one and then the latest version. I personally didn't see this effect or know what's the root cause.

I've never heard of Lucid Virtu.. how can I check if it's installed, and how can I remove it?

Thanks

CruNcher

31st January 2012, 19:59

these are more likely parser decoder interoperability issues (with that specific stream) then driver problems
, its still problematic to mix up different dshow frameworks because they react most of the times totaly different to issues and combined then you get strange results ;)
see my recent .ts satellite bad stream exploration i tested different combinations on 1 specific test case and get very different results ;) https://forum.doom9.org/showpost.php?p=1554770&postcount=8655
Though in the quicksync case its always the same issue with any combination and that's unsync for this case.
Also MPC-HC and Lav Splitters parser are almost twins (except the bug count which is higher for MPC-HC)

nevcairiel

31st January 2012, 20:01

these are more likely parser decoder interoperability issues then driver problems

no, its a driver problem (or a problem with Lucid Virtu, take your pick)

CruNcher

31st January 2012, 20:06

then i would say lucid virtu as egur said as i yet have to see that issue myself with 2559 on GT1 but im not yet @ .mkv ;)

egur

31st January 2012, 20:06

http://xhmikosr.1f0.de/samples/2160p/ParkJoy/ParkJoy_1080p50.x264.CRF23.mkv

Default settings, i get around 292 fps with the current version
When i disable MT Decode and MT Processing, i get ~255 fps.

With 0.22, and the same settings, its also 292 fps (but of course, MT Decode and MT Processing didn't exist yet).

It seems that somehow the settings of MT Decode and MT Processing are linked with MT Frame Copy, or there really is a performance regression.

I'll take a look.

Update
I installed my own build that used v0.22 (32 bit - ffdshow_rev4227_20120107_egur.exe).
Setup:
Window 7 64 bit. Latest drivers.
Screen connected to Radeon HD 6950.
GraphStudioNext 32 bit. NULL renderer. 5 runs. All are release (non debug) builds.

0.22 - avg 260. max 273.
0.24 (r30) no MT decode - avg 270, max 282
0.24 (r30) all MT tricks enabled (default) - avg 273, max 288.

BTW, when Chrome is open, the numbers go down to avg-260.
I'll try a few more clips and report again.

CoolerKing

31st January 2012, 20:06

rsd78

31st January 2012, 20:15

I can add all the 3 of my machines that showed this issue are 32 bit Win 7. So I'm guessing perhaps a driver issue. I'll have to check what version I'm using but its probably 6-9 months old at least.

CruNcher

31st January 2012, 20:21

Well, I've tried both .2509 and .2559.. I never heard of Lucid Virtu before, so unless it's bundled with other software, I don't think I have it. Really hoping to fix this issue, so I'd be happy to provide any logs or try anything necessary (except maybe a full OS reinstall ;)) to fix this issue.

@CruNcher, so you have a file that I could test? couldn't find one linked in your post

Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

nevcairiel

31st January 2012, 20:26

Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

Its a driver problem, accept it already. :p
No sample or change in filters is going to help

Quite alot people described the exact same problem in the LAV thread, and in all cases installing a different driver helped.

CruNcher

31st January 2012, 20:28

ok ok if its a specific problem of how quicksync handles that bitstream and you sure of it, could be that i didn't reached such a problematic bitstream yet, though currently im testing also more your DXVA copy back then quicksync direct ;)

Its a driver problem, accept it already. :p
No sample or change in filters is going to help

Quite alot people described the exact same problem in the LAV thread, and in all cases installing a different driver helped.

Yes but what if they also had Lucid Virtu in use @ the same time ;)
i mean i surely should have hit that issues in ffdshow quicksync when testing it (or the time testing lav video quicksync) but i never experienced a wrong frame order issue like described here.

Also this lucid issue might explain why Intel reverted the 2559 driver and pushed back to the 2509 as lucid is a not so uncommon usage case on SB (MBM sponsored) ;)
Though for their own Mainboards also with Lucid support they still push 2559 very weird this driver policy ;)

Though wondering where Synergy got stuck @ btw (guess we will see it with Kepler arriving as a feature MBM sponsored thing again) ;)

egur

31st January 2012, 20:29

Well, I've tried both .2509 and .2559.. I never heard of Lucid Virtu before, so unless it's bundled with other software, I don't think I have it. Really hoping to fix this issue, so I'd be happy to provide any logs or try anything necessary (except maybe a full OS reinstall ;)) to fix this issue.

@CruNcher, so you have a file that I could test? couldn't find one linked in your post

It's usually bundled with the OEM (or MB manufacturer) SW pack. Look in the "Programs and features" section.

CoolerKing

31st January 2012, 21:38

It's usually bundled with the OEM (or MB manufacturer) SW pack. Look in the "Programs and features" section.

Nope, I've looked everywhere, and also searched the registry, but it's not installed.. Could some BIOS setting be causing it?

Also, which driver should I install if .2559 isn't good? (both the .2559 and .2509 drivers that I was using were the ones supplied by windows update.. not sure if that matters)

Cooler King that's a different issue in your case try a complete lav video chain (lav splitter->lav audio->lav video (quicksync)->EVR) does the problem persist ?
If it does please post a sample :)

I've tried your 720p.mpg sample with only LAV as filters, but it's still skipping back and forth.. so whatever the problem is, I think it's purely QuickSync related (maybe some BIOS setting or problem with 2509/2559 WHQL driver).

CruNcher

31st January 2012, 21:57

that sample causes the DXVA2 copy back to fail i would be carefull with it ;)

egur

31st January 2012, 22:27

Nope, I've looked everywhere, and also searched the registry, but it's not installed.. Could some BIOS setting be causing it?

Also, which driver should I install if .2559 isn't good? (both the .2559 and .2509 drivers that I was using were the ones supplied by windows update.. not sure if that matters)
...

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

amtm

31st January 2012, 22:59

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

That's silly. Intel, and many other manufacturers, push their drivers out through Windows Update. If downloading the WHQL drivers from Windows Update is a bad idea, you need to tell Intel to fix it because that means they've done something stupid.

CoolerKing

31st January 2012, 23:52

Don't ever install drivers from Windows update (for any HW!).
Download the drivers from Intel and install them. I had no issues with either 2509 or 2559. They behave exactly the the same regarding video playback.

So if the drivers (they should be identical whether obtained from windows update or the intel website), windows version (rsd78 is running 32bit and me 64bit) or lucid virtu (not installed) all aren't causing the problem, what could be? rsd78 said he's having the problem on 3 of his machines? So I'm quite surprised that only a few people mentioned having the back/forward skipping issue.

NikosD

1st February 2012, 00:35

I have no problems at all with latest drivers from Intel, but they were installed on a clean system, first and only drivers.

It's clear to me that Intel's drivers lack the maturity of ATI/ Nvidia drivers and may have problems after updating/ uninstalling previous versions.

Maybe you could try to use a driver uninstaller, for a full uninstallation.

Just for a last try, use PotPlayer with internal DXVA codecs or Quicksync decoder from the same program.
It may play OK.