Bad artifacts in GBPVR, fine in GraphStudio - VMR9 problem?

[sgilani]

I'll have to give 9.4 a try.. 9.2 certainly had its fair share of problems with true interlaced 60i material, so it's not right to say it was perfect, but 9.5 certainly was far worse. thanks for the find.

[stustunz]

I live in the US (60Hz). Drop back to 9.4 or earlier. Here's a quote from renethx over on AVS:

i can see where you live i was wondering where sgilani lived because he said about the ticker tape and thats normally because you have it set to the wrong refresh rate although been a ati card it could be anything

[sgilani]

I'm in the U.S. too.. everything set at 60hz. The tickers are smooth, no jitter.. but using the vector-adaptive makes the edges of the letters very rough and edges overall are rough and not well-defined. Motion-adaptive makes tickers and edges better, but there are other problems.

definitely looks like serious driver issues from ATI.

however, playback works perfectly with the "Video Renderer" that GraphStudio/GraphEdit loads up when I render the file.. which makes this very frustrating. maybe sub can explain if my assumption of VMR7 being used in that case is correct? (both lastgraph.grf and the rendered graph look identical with "Video Renderer" but all I can think of is VMR7 other than VMR9)

[whurlston]

lol. Sorry. I didn't realize it was you asking. I thought he was asking me.

[whurlston]

I'm in the U.S. too.. everything set at 60hz. The tickers are smooth, no jitter.. but using the vector-adaptive makes the edges of the letters very rough and edges overall are rough and not well-defined. Motion-adaptive makes tickers and edges better, but there are other problems.

definitely looks like serious driver issues from ATI.

however, playback works perfectly with the "Video Renderer" that GraphStudio/GraphEdit loads up when I render the file.. which makes this very frustrating. maybe sub can explain if my assumption of VMR7 being used in that case is correct? (both lastgraph.grf and the rendered graph look identical with "Video Renderer" but all I can think of is VMR7 other than VMR9)

Yeah, it's most likely VMR7

[sgilani]

so I guess we are at AMD/ATI's mercy since VMR7 isn't an option for us.

yikes.

[hoborg]

Guys, it is not about renderer, or catalyst settings (deinterlacing in CCC only afects SW deinterlacing).
You need DXVA capable decoder to use hardware deinterlacing.
For MPEG2, PDVD decoder (CLVsd.ax) is good choice. But be sure you enabled DXVA (it is little problematic, need to be done in registry).

[sgilani]

I think you're a bit confused.. it's a myth that you must use DXVA to have hardware deinterlacing.. you don't. the CCC settings affect the deinterlacing that gets done by the video card in it's pixel shaders (which we can call 'hardware deinterlacing'). You simply need to output in NV12 colorspace and have a stream which is flagged as interlaced. this is why using a software decoder (non-DXVA) like Dscaler still works great since the card is doing deinterlacing (no software deinterlacing at all, the card is doing the work). Try it out.

There are lots of bugs in the catalyst drivers, which is why we see the reports such as the one whurlston copy/pasted from avsforums. Also, I can confirm that at least with my MSI branded card, VMR9 and EVR result in some artifacts and display corruption, but using VMR7 has no problems.

[hoborg]

Yes, you are right about NV12 output.
I personaly prefer DXVA deiterlacing - wich is really looking and working great and it is independent of any kind of catalys bugs/settings, etc.

[sgilani]

think I've found the bug... the inverse telecine (pulldown removal detection) is hosed in the catalyst drivers. turning it off makes everything solid in VMR9 and EVR, but obviously you lose the feature of inverse telecine.

really disappointing since it's relatively simple to look for a telecine pattern and either reconstruct the progressive frames from it, or consider it true interlaced and then de-interlace. a few lines of an avisynth script can do it, yet their drivers can't.