- August 9, 2012
- 2,721
- 2,074
- Home Country
-
Germany
v226 with test3 dshowhelper.
No change with Copy Back and long stop times TVS vid stopped ca 10:07 in attached log.
No change with Native and 4k playback log at ca 10:12
Also sorry
but both before and after I added the test 3 Dshow. I noticed a new TV zapping problem with Copy Back only, when switching from a SD channel to HD channel vid will either freeze on SD channel or show a black screen, a further zap either to an HD or SD channel returns video OK, SD to SD zap and HD to HD zap seems OK. See log from 10:17. Native does not have this problem but pq of SD TV is awfull both with Madvr and EVR.
UPDATE
The zapping problem with Copy Back does not happen if I select the option "Use EVR for Live TV",
so as a workarround that is what I have done for now, SD pq with EVR is anyway better than Native and Madvr. BTW I forgot to mention it but the audio during the zapping problem does switch to the new channel.
it is just the video that does not.
AMD driver version 16.10.3 is available and was used for this testing.
UPDATE2:
I have refined the long stop problem area down somewhat, if I deselect h264 from the codecs to use for HW Accel. in LAV filters, then stop times in TVS and OLV come down to ca 5secs even when Copy back is selected it also seems to have resolved some severe stuttering problems (video only) I was seeing on some 23hz video material. The advantage of this is that I can again use Madvr with Copy Back for TV. HD HEVC TV is not effected and the CPU usuage for regular TV is much the same but the PQ is much better than with Native. I have also reverted back to v222 and the zapping problem, reported earlier, seems to be resolved or at least improved but not sure if that is v222 or deselection of h264.
I get the distinct feeling that all is not well with the RX 4xx implementaion of H264 HW Accel. AMD have acknowledged a number of issues with it but there are many more reported on the Internet and historically they have not always been very open about problems even when a solution is implemented in a driver update. I suspect and hope we will be seeing a fairly rapid release of new drivers over the comming months to resolve issues and stabalise this new range of GPUs. In retrospect I maybe should have gone to Nvidia for HEVC HW accel. but they have such a horrible history with 3D.
No change with Copy Back and long stop times TVS vid stopped ca 10:07 in attached log.
No change with Native and 4k playback log at ca 10:12
Also sorry
UPDATE
The zapping problem with Copy Back does not happen if I select the option "Use EVR for Live TV",
AMD driver version 16.10.3 is available and was used for this testing.
UPDATE2:
I have refined the long stop problem area down somewhat, if I deselect h264 from the codecs to use for HW Accel. in LAV filters, then stop times in TVS and OLV come down to ca 5secs even when Copy back is selected it also seems to have resolved some severe stuttering problems (video only) I was seeing on some 23hz video material. The advantage of this is that I can again use Madvr with Copy Back for TV. HD HEVC TV is not effected and the CPU usuage for regular TV is much the same but the PQ is much better than with Native. I have also reverted back to v222 and the zapping problem, reported earlier, seems to be resolved or at least improved but not sure if that is v222 or deselection of h264.
I get the distinct feeling that all is not well with the RX 4xx implementaion of H264 HW Accel. AMD have acknowledged a number of issues with it but there are many more reported on the Internet and historically they have not always been very open about problems even when a solution is implemented in a driver update. I suspect and hope we will be seeing a fairly rapid release of new drivers over the comming months to resolve issues and stabalise this new range of GPUs. In retrospect I maybe should have gone to Nvidia for HEVC HW accel. but they have such a horrible history with 3D.
Last edited: