[RESOLVED] Weird glitches

[jsj]

Hi there,

I've been using DGDecNV for a while now and are quite happy with it, but from time to time I've noticed some weird glitches in my encodes, and I finally took a bit of time to track down the problem.

It appears to be related to DGDecNV, or at least that's how I see it. I hope you guys (admin maybe? can shed a bit of light on this, and hopefully get the problem resolved.

This is one of the glitches that appears when encoding and playing the resulting mkv afterwards. Or if I open the avs in vdub and either next-frame (right arrow) through it or play it.


The funny thing is if I open the avs in eg. vdub and scroll up to around the glitch point (frame 233) everything looks just fine!


It doesn't matter if I use cuda to deinterlace and/or resize or if I just leave it as the original 1080i

I'm guessing some kind of buffer exhaustion, or ???

I'm using dgdecnv2038 at the moment and here is an example of the simple avs script that produces the error.

loadplugin("C:\Rip\_Tools\dgdecnv2038\DGDecodeNV.dll")
DGSource("How Stuffs Made - Steel Reinforced Ropes - cut.dgi")

I have uploaded a sample .ts here that I can reproduce the glitches with http://www.megaupload.com/?d=SR8BJ8X0 so maybe you could have a look at it as well and see if you can reproduce the same glitches?

[admin]

This looks like an Nvidia decoder issue. I will send it to Nvidia and see what they think.

[jsj]

Ok, thanks.

I suppose NVIDIA would like to know what GFX card and stuff I'm using, so here goes.

Windows 7, 64bit
GeForce GTX 460 (MSI N460GTX Hawk) with driver version 260.89

[jsj]

I noticed I didn't run the latest drivers, so I've just updated to 266.58 but the glitches are still there.

[laserfan]

Windows 7, 64bit
GeForce GTX 460 (MSI N460GTX Hawk) with driver version 260.89

My W7 x64 setup has a 9600GT with 260.99 and same bizarre glitches fwiw.

[jsj]

Did NVIDIA by any chance report back yet? Since then I've run into 4-5 other .ts h264 clips with the same issue.

[admin]

Please be patient. Can you give me the other broken streams?

[jsj]

Ok.

I'll PM them in a bit.

[admin]

Here is the analysis from Nvidia. The resolution is still pending. Given the final comment, it appears that a solution will be forthcoming. At least with the zippers sample you uploaded, you can workaround it by cutting the first GOP, although if there are more instances of the problem later in the full stream, that will not be sufficient.

-----
I'll try to take a look before the end of the week. From a preliminary analysis, the stream uses B-pyramid, field pictures, and custom mmco reordering which is relatively rare, so I would tend to suspect an issue in the in the parser related to dpb reordering, but it's too early to tell.
-----
It's definitely a parser issue, though I still need to exactly figure out if this is a true parser bug or a side effect of a bad cut (in which case it becomes more of an error resilience issue):

Here is what is happening:
1. The problem actually occurs almost right away in the stream, the picture with frame_num=2 to be exact, though the symptoms are invisible until much later.
2. This stream uses B-pyramid, which requires the encoder to explicitly mark the B-frames as non-reference before decoding the next P-frame using MMCO commands.
3. The bug: frame_num #2 is missing its MMCO eviction command and always stays in the DPB, causing an incorrect reference picture list to be used for all subsequent pictures.
4. Because the stream only uses 1-2 references with num_ref_frames=4, the problem never shows up because picture #2 always ends up last in the reference picture list (unused)
5. At field #982 in decode order, frame num hits 512 and wraps around, shortly after, we end up with two frames with the same frame_num value, and things get messy -> corruption starts until the 'good frame_num #2' gets evicted.

I need to run a few more tests to see how to best deal with that, and see why frame_num #2 never got evicted from the dpb in the first place.
-----
Alright: I need to consult with other local h.264 experts, but from what I can tell, it seems that the bitstream is not compliant, as it did not properly mark the 1st frame with frame_num=2 with adaptive_ref_pic_marking=1, so it is never being evicted because subsequent pictures bypass the normal short-term reordering (it certainly doesn't seem like intended behavior).

What happens after the frame_num wraparound is afaik undefined behavior, but in all cases a fix should be trivial.
-----

[admin]

@jsj

This appears to be the result of a cutting application doing things wrongly. Can you please advise ASAP what tool you are using to cut these streams. Thank you.

[jsj]

@jsj

This appears to be the result of a cutting application doing things wrongly. Can you please advise ASAP what tool you are using to cut these streams. Thank you.

I was kinda suspecting this after the comments from Nvidia.

I'm using VideoReDo TVSuite v4.20.6.614

[admin]

Here is some further analysis from Nvidia:

-----
I think it may be a side effect of a video editor that was used to cut the stream
(as it's most likely extracted from a continuous broadcast, and the cutting tool
removed reference b-frames, which happens not to be safe in this particular case),
so the mmco command most likely failed to work the 1st time around.
More specifically, it violates the following section of the spec:
a) There shall not be any previous field or frame in decoding order that is
currently marked as "used for short-term reference" that has a value of frame_num
equal to any value taken on by the variable UnusedShortTermFrameNum in the
following:
UnusedShortTermFrameNum = ( PrevRefFrameNum + 1 ) % MaxFrameNum
while( UnusedShortTermFrameNum != frame_num ) (7-23)
UnusedShortTermFrameNum = ( UnusedShortTermFrameNum + 1 ) % MaxFrameNum

I'll try to dig a bit deeper to see the most generic way to deal with this in the
parser (ideally we'd want to deal with the problem at frame #2).

In the meantime, it's possible to work around this problem in the app by detecting
the duplicate frame_num values and modify the dpb entries accordingly, but it's not
trivial.
-----
I now understand exactly what happens: there is a huge gap of 256 in frame_num
values at the 12th picture or so, so the stream is not cut at a clean point
(explains why everything is fine the 2nd time), and the frame_num values for the 1st
12 picture or so are off by 256 (fortunately, because the error is already detected,
we just need a minor tweak to the logic used to fill-in the blanks)

To summarize: there is no problem with the original BBC streams or the decoder: this
is just a side effect of cutting the stream at a non-idr picture without adjusting
the frame_num values (This is really a problem with the editing tool, but similar
issues could occur when seeking, so I'll try to get in a workaround so we deal with
this more gracefully ~ hopefully in time for the next driver update)
-----
I was looking at a potential workaround, but found that we already do the right
thing in nvcuvid to deal with these sort of unclean cuts.

The problem definitely appears to be with the cutting tool that this user is using
(it would be interesting to know which one). The frame_num values are 9-bit in the
slice header (log2_max_frame_num_minus4=5), but it looks like they were truncated to
8-bit when the cutting tool tried to modify the startup frame_num values to make the
cut point seem like a clean cut.
-----

@jsj

If this is important to you, the right thing to do now is to feed this information back to the VideoReDo guys. You could point them to this thread and ask for their response. Getting a few bad frames at a cut is one thing, but getting bad frames unpredictably later in the stream is a big problem.

[admin]

@jsj

One more thing...

If that is not the latest version of VideoReDo can you possibly test again with the latest version?

[admin]

More from Nvidia:

-----
There is indeed something we can do in nvcuvid, which is to compare 8-bit-truncated frame_num values of reference frames and change the frame_num values of the reference frames to what they are supposed to be.

It's ugly and not compliant (and very much application specific), but if it's a popular editing tool, which I'm guessing it is ~ I asked because I thought maybe the user wrote his own ~ it may be worth adding it for the next driver update: the risk is fairly low, since the hack is within an error handling section (no impact on good streams), and I verified that it fixes the corruption.

Let me know if you think I should put that in, though we may want to also check if the problem repros with the latest version of VideoRedo (in case it's already fixed on their side).
-----

Obviously I recommended to put it in. Nvidia then sent me an nvcuvid.dll to test and all the broken streams worked fine. I can't re-distribute that but it will be in the next 270.xx release. More excellent support from Nvidia!

I'll mark this as resolved. Feel free to re-open it if the next release is not OK.

[jsj]

Very very nice, thank you very much for all your work. Please let my thanks go out to Nvidia as well, GREAT work guys.

I'll check up on VideoReDo if I'm using the latest version etc. and/or let them know about this thread.