[RESOLVED] DGDecNV + Overlay = glitches

[Nick007]

Hello. I'm having some trouble with glitches using DGDecNV, when I use in the script Overlay. It's some kind of tearing (frame repeat/skip, or part of frame is moved a bit in some direction).

It happened on another BD source too when using similar overlay to correct ugly lines. It happens throughout the whole movie every now and then. It doesn't happen when I use FFMS2 for decoding. Using latest Nvidia driver (GPU GT 220 M), latest x264 r1732, latest DGDecNV 2027. It doesn't happen if I remove the Overlay part. And it wasn't happening (at least with the encodes I did) with DGDecNV 2.0.0 beta3 that I was using until recently. I think it doesn't happen for 1080i50 in TS container too, only for 1080p H.264 from Blu-ray (both 23.976 and 24.000 fps).

I think the problem can be easily reproduced by using the same script, just for another source.

Here's a sample of how the glitches look:
http://www.mediafire.com/?dix40b62le465v6

- 3 frames skiped between frames 219-220, glitch on 219 bottom
- frames 429-432 incorrectly repeated as 430-432

Script I used:

DGSource("Fantomas.mkv")
ConvertToYV12()

a=Crop(0, 130, 0, -130)

b=Crop(a, 0, 0, 0, 6).ConverTToRGB24().Crop(0, 0, 0, -5)
c=Crop(a, 0, 0, 0, 6).Tweak(cont=1.15).ConverTToRGB24().Crop(0, 1, 0, -4)
d=Crop(a, 0, 0, 0, 6).Tweak(cont=0.99).ConverTToRGB24().Crop(0, 2, 0, -3)
e=Crop(a, 0, 0, 0, 6).Tweak(cont=1.1).ConverTToRGB24().Crop(0, 3, 0, -2)
f=Crop(a, 0, 0, 0, 6).ConverTToRGB24().Crop(0, 4, 0, -1)
g=Crop(a, 0, 0, 0, 6).Tweak(cont=1.04).ConverTToRGB24().Crop(0, 5, 0, 0)
h=StackVertical(c, c, d, e, f, g).ConverTToYV12()
i=Overlay(a, h)

j=Crop(a, 0, 814, 0, 0).Tweak(cont=1.04).ConverTToRGB24().Crop(0, 0, 0, -5)
k=Crop(a, 0, 814, 0, 0).Tweak(cont=1).ConverTToRGB24().Crop(0, 1, 0, -4)
l=Crop(a, 0, 814, 0, 0).Tweak(cont=1.1).ConverTToRGB24().Crop(0, 2, 0, -3)
m=Crop(a, 0, 814, 0, 0).Tweak(cont=0.99).ConverTToRGB24().Crop(0, 3, 0, -2)
n=Crop(a, 0, 814, 0, 0).Tweak(cont=1.15).ConverTToRGB24().Crop(0, 4, 0, -1)
o=Crop(a, 0, 814, 0, 0).ConverTToRGB24().Crop(0, 5, 0, 0)
p=StackVertical(j, k, l, m, n, n).ConverTToYV12()
Overlay(i, p, y=814)

Spline36Resize(1280, 546, 0, 1, 0, -1)

So I wonder, do you have any experience with this kind of error? What could be the cause? It's annoying as hell, because FFMS2 is quite slower...

[admin]

I can't open that MKV with anything. Nevertheless I will try to duplicate this.

[admin]

Hey, wait a minute, your input is MKV and not M2TS!

How did you rip it from the BluRay?

[Nick007]

That file above is the encode, not the source. You can't open that encode? It opens fine with mpc + haali splitter + coravc/ffdshow.

I remuxed m2ts to mkv with eac3to.

Here's the source sample in M2TS container (cut with tsMuxer) and also remuxed to MKV:
http://www.mediafire.com/?jn19t94h7vv6xt3
http://www.mediafire.com/?5bb84dzveb3sdkp

I don't think it depends on the source because I got those glitches with two completely different sources.

[admin]

I do not see any issues with your M2TS sample and your script. Have you tested with the M2TS? If so, please specify where you think the problems are *with that sample*.

Please test it by opening the script in VirtualDub, not by making an encode.

[Nick007]

The problem doesn't occur when previewing the script, only when encoding

I haven't tested with m2ts, I'll test it tomorrow when my current encode finishes. Do you think it could be because of Matroska? Sometimes it's not possible to use m2ts, because of seemless branching for example...

Strange is, that I encoded the sample at least 4 times (well not this sample, it was the whole indexed source trimmed from 14000 to 15500) and the glitches were always there, in the same spot. I'll test more and prepare specific source sample and script that does this error, so you can test it yourself.

[admin]

I tried the Matroska version and it was fine too.

Awaiting a stream to duplicate the issue...

[Nick007]

Okay, I wasn't correct, it doesn't show only during encode, but in previewing also.
I indexed both source samples I posted above, M2TS has 480 frames, MKV has 478 frames (strangely). And I compared them frame-by-frame with the script above.

Everytime I open the script, the error is in different place. It never appeared in M2TS source, only in MKV source (with and without the overlay part of the script). I got frame skipping/repeating between frames 294-305 several times.

When I opened both M2TS and MKV scripts simultaneously and seek to frame 230 in AvsP, they differ (frame skipping). This is the only thing that can be repeated every time.

I guess this explains a lot, because I never got an error with M2TS or TS, only recently with these remuxed MKVs from BD. Oddly, FFVideoSource works without problem with these remuxed MKVs. And it also wasn't happening with DGDecNV 2.0.0 beta 3.

If you won't be able to replicate it, I guess I'll just have to remember to use M2TS...

[admin]

Thanks for your test results. I confirm two issues with MKV: 1) two frames are missed at the end (480 vs. 478), and 2) failures of random access.

I'll fix this ASAP.

[Nick007]

So is it fixable? I'm glad I could help. I would be sorry if I couldn't fully use such an awesome tool

[admin]

Of course it's fixable.

[admin]

OK, on the first issue regarding missing frames at the end when comparing the M2TS with the MKV:

I extracted the ES from the M2TS with Manzanita Muxer and from the MKV with mkvextract, and then compared them. The ES from the MKV is missing one frame at the end. Then because that produces an out of order POC at the end, DGDecNV deletes an additional one. So the problem there is with the MKV muxer or what you fed to it. No problem found with DGDecNV.

Now I will investigate the random access issue...

[admin]

On the second issue, there is a problem in timecode seeking in the MKV parser code I got from Haali. That code is pretty complicated and not well commented so I made a workaround in DGDecodeNV. It appears to fix the problem. I want to spend a little more time trying to figure out what's going on in the MKV seek code before I release a build, hopefully by the end of this weekend.

EDIT: Released build 2028 with the fix.

[Nick007]

I'll try it tomorrow and report back if it's okay. As for the number of frames issue, it's really not a problem, just an observation. Hope the out-of-order frames will be no more

[Nick007]

Seems to be fixed, hurray! I'll report back, if it'll manifest itself in the future, but I hope not. Thanks again!