DGIndexNV - block artifacts in DVB-S2 H.264-stream

[illCP]

Hello,

I'm pretty sure this is not concerning DGIndexNV directly (more to that below), but as it bothers me the most here:


I'm experiencing block artifacts in a h.264-TS when decoding it with DGIndexNV 2044. It's a DVB-recording from BBC HD (Astra 28.2E) a couple of months ago, recorded with yaVDR 0.4. I've uploaded a small sample containing the affected position (cut from the original VDR-TS with TSDoctor):

http://www.mediafire.com/?rb59vbubam4an44

The problem appears from frame 114 to 121, mainly in the left bottom corner - see attached screenshot. I admit it's not a huge disaster because it's barely noticeable, but it points to a decoder problem.

At first I assumed it might plain and simple be an error in the stream, caused by bad satellite reception, the VDR itself or whatever, but I wondered why TSDoctor didn't report an error or a warning. Then I noticed some DirectX-filters/-decoders are showing the scene without any error. I did further checking on that and discovered the following pattern:


OK, no artifacts:

- MainConcept 8.5.0.53.657 on MPC-HC 1.5.1.2903
- LAV filters 0.56, CUVID disabled on MPC-HC
- CoreAVC 3.0.1, CUDA disabled on MPC-HC
- VLC 2.0.5 (as far as I know VLC uses its own decoders and no DirectShow-filters?)


Error, artifacts:

- DGIndexNV 2044
- LAV filters 0.56, CUVID enabled on MPC-HC
- CoreAVC 3.0.1, CUDA enabled on MPC-HC


So it seems the problem appears whenever CUDA is involved, software-based decoding seems to be fine. My problem here: As a matter of principle DGIndexNV is not designed to turn off CUDA...


My System:

Windows 7 x64
nVidia GTX 550 Ti (two of them to be precise) with driver version 314.22 (just updated yesterday to be on the safe side)


Any ideas?

[Selur]

same happens with GTXC 660 and 314.22 drivers

[Ghitulescu]

Originally Posted by illCP

My problem here: As a matter of principle DGIndexNV is not designed to turn off CUDA...

Of course, why a tool optimised for a task should disable its advantage?
Use DGindex, it doesn't rely on CUDA (or NVidia) at all.

[Groucho2004]

Originally Posted by Ghitulescu

Of course, why a tool optimised for a task should disable its advantage?
Use DGindex, it doesn't rely on CUDA (or NVidia) at all.

Good call. Now tell us how to get DGIndex to parse AVC streams.

[Groucho2004]

I can also confirm the artifacts with DGNV using a simple script loaded in VDub (GT240, driver 275.33).
FFVideoSource works fine with this clip.

[Ghitulescu]

Originally Posted by Ghitulescu

Use DGindex, it doesn't rely on CUDA (or NVidia) at all.

Originally Posted by Groucho2004

Good call. No tell us how to get DGIndex to parse AVC streams.

Sorry, I meant DGAVCindex.
I do not use them so I am not that familiar with their names and versions.

[kypec]

Yup, this sample looks like an ideal candidate for testing nVidia CUVID decoder issues. I confirm that blocking artifacts occur with DGDecNV 2044 32-bit on my GT520 & GeForce drivers 301.42 whereas VLC plays it just fine.
Perhaps neuron2 could make use of his nVidia connections and poke them a bit with this sample - provided the stream is indeed 100% error-free.

[illCP]

Originally Posted by Groucho2004

FFVideoSource works fine with this clip.

With this cutout it's OK, but FFVideoSource fails when trying to use it for the whole stream: The frame structs vary between MBAFF and Fields (TFF), it seems FFVideoSource can't handle that.

Originally Posted by Ghitulescu

Sorry, I meant DGAVCindex.

Apart from the fact that you can't officially download it for some time now and neuron2 pretty much abandoned it for several reasons: It also seems to have problems with altering frame structs within a stream. DGAVCDecDI on the other hand seems to work fine except for some artifacts at the beginning of the (complete) stream.

BTW: LAV set to "DXVA (copy-back)" shows the same error, "DXVA (native)" seems to work fine.

Originally Posted by kypec

Perhaps neuron2 could make use of his nVidia connections and poke them a bit with this sample - provided the stream is indeed 100% error-free.

That's what I was hoping for

[Overdrive80]

I have open sample with avidemux and playback properly.

[Sulik]

The stream isn't compliant: it is flagged as num_ref_frames=4 (and doesn't use more than 4), but requires more buffering due to frame reordering (it violates its specified level_idc value).