Atomatic switch to DXVA Copy-back

[GoogleCodeExporter]

It would be nive to implement a small checkbox, which will turn on the ability 
of Video Decoder to switch to DXVA Copy-Back mode, if DXVA Native was selected 
and player's video processing filter is enabled

Original issue reported on code.google.com by ivanwhee...@gmail.com on 27 Mar 2012 at 10:35

[GoogleCodeExporter]

Personally I don't think this is very useful. Maybe its just me but DXVA 
copyback is no way slower. So as classic DXVA offers no benefits over copyback, 
why not just use it all the time?

On the other hand I'd lie to have such fallback from QuickSync to DXCAcb. 
Because I use Quicksync through VirtuMVP in "i" mode and its not always 
available.

Original comment by yakits...@gmail.com on 22 Jun 2012 at 9:18

[GoogleCodeExporter]

Nev, I wrote one patch to add an option to try DXVA2(native) first, and fall 
back to
 other HW decoders if fails.

This patch removes DXVA2 (native) in IDC_HWACCEL drop-down-list, and adds a 
check-box to set whether DXVA2 native is enabled, as shown in the attached 
image.

Another thing I changed is make CheckHWAccelSupport returns BOOL, dropping 
2="Currently running", as active decoder is already displayed and there is 
little point in showing it again and again, for two HW decoder options. So 
IDC_HWACCEL_AVAIL won't show the codec is active or not, only available or 
unavailable.

Actually I do not really understand CPP, so I just make it work for me within 
limited tests, but there are several points you might want to change completely:

1. the options in the configuration GUI is probably a little bit ugly. Maybe I 
should have moved the check-box below, and probably add another label showing 
whether DXVA2 (native) is available or not;

2. I'm not quite sure how m_bHWDecoderFailed works. Was it used to prevent some 
decoder initializing loop or something else? I simply removed it in the 
if-condition of fall-backed hardware decoder construction, without finding an 
issue. But I think it must be there for some reason which I have not 
realized....

There might be some other request like #1. I personally thinks DXVA2 native -> 
other HW decoders -> SW decoders is more reasonable for normal playback, and it 
is just what I need, so I didn't implemented anything else.

Original comment by astrat...@gmail.com on 23 May 2013 at 4:30

Attachments:

• LAV-HW-Polling.png
• 0001-Add-an-option-to-try-DXVA2-native-first-and-fall-bac.diff

[GoogleCodeExporter]

Updated to allow to select HW format/res when only DXVA2(native) is checked.

Original comment by astrat...@gmail.com on 24 May 2013 at 6:39

Attachments:

• 0001-Add-an-option-to-try-DXVA2-native-first-and-fall-bac.diff

[GoogleCodeExporter]

m_bHWDecoderFailed is what signals that the hardware decoder refused to decode 
the stream, for example if its 10-bit or something like that, so it must still 
be used - and native DXVA should probably indicate if it failed because it 
didn't get D3D interfaces, or the format was deemed incompatible (so you can 
avoid trying the other HW decoder and speed up init)

I also don't really like how the options are handled at all, to make it sane 
and easy to understand, the whole hw decoder option block should probably be 
refactored.

Personally, i would probably just fold the two DXVA2 options into one, try 
native first, CB if it fails, and do that all internally in the DXVA2 decoder, 
instead of outside - but of course that means you can't use DXVA2 native and 
QS/CUVID as fallback, but then again, it may not be something thats really all 
that useful.

Well anyway, as it is now, i'm not liking how its implemented, there are many 
odd cases that may need more attention.

Original comment by h.lepp...@gmail.com on 24 May 2013 at 8:19

[GoogleCodeExporter]

OK, then I should have changed HW failed flag to indicate three status.

Yes, I agree that the options are messed up. I just didn't find out a good way 
to describe the fallback logic in the limited GUI area, so I only did minor 
changes instead of making it even confusing:P

Anyway, the patch itself is probably quite useless, since xy-vsfilter is 
implementing its new interface, one might never need such a fallback in the 
near future....

Original comment by astrat...@gmail.com on 25 May 2013 at 2:50