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]

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? :D
Use DGindex, it doesn't rely on CUDA (or NVidia) at all.

[Groucho2004]

Of course, why a tool optimised for a task should disable its advantage? :D
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. :rolleyes:

[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]

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

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

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]

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.
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.

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).