[RESOLVED] Corrupted frames when trimming (BBC One HD)

[Vippe]

Hello

I'm having problems with corrupted frames using DGDecNV when I want my video to start from a certain frame in a capture from BBC One HD.
I'm using DGDecNV 2038, and using the latest certified nVidia drivers 266.58 (WHQL) in Windows 7 x64, also tried the newest beta drivers 270.51.

The problem is that the file plays fine with CoreAVC or VLC players, and odly enough the frames giving problems are decoeded fine when using DGAVCIndex, but using DGDecNV i always get corrupted frames when trying to trim my encode.

I have made som sample files for you to test with that you can download here http://offriders.com/stuff/bbconehd_fra ... n_trim.rar
In this file there are 2 .ts files.

• "test.ts" is cut from the broadcast file to start at the point i want it to. Indexing with DGDecNV gives corruption seen below, DGAVCIndex, CoreAVC & VLC no corruption. Use "test.avs" to test.
  "test_trim.ts" is cut from the same broadcast file but starts way earlier to resemble indexing the full file and using Trim() in the avisynth script. Using DGDecNV and Trim() gives the same corruption as before, but without Trim() it plays through the problem part without errors Use "test_trim.avs" to test. This plays fine in VLC and with CoreAVC as well.
  "test_trim_dgavcindex.avs" is the test_trim.ts file indexed with the old DGAVCIndex and using Trim() to start at the point I want, and this works for the part that gives problems with the new DGDecNV.

Hope you can help.


Here is how it looks when DGDecNV decodes the video in an avisynth script.

[dansus]

Does this happen for all your BBCHD caps?

See if i can recreate the same error as i have the same material from a different source and will try yours too.

This your file indexed locally, no visible errors.(XP x86 SP3)



This is using my cap, with errors. This is not unusual, i often get errors in the first 50 frames or so.

[Vippe]

Well hello dansus, wierd that you don't have any visisble corruption on your end, did you use test.ts or test_trimmed.ts?
Also what gfx do you have? I have an XP installation for my computer also, maybe I should try on win xp when I get home.

Btw I have 2 nVidia gfx card in the computer. A GTX 275 & 8800 GTS (512).

[dansus]

I tested everything you posted with the same results, no errors.

Im using a GeForce 240 GT, 257.21 drivers.

[Vippe]

Ok I have now found out after lots of testing today that this issue is 100% related to the driver version of nvcuda.dll. Tested 8 different drivers for win7 x64 and found that 266.35 and higher (file version 8.17.12.6635) gives this corruption.

admin could you please forward this information to nVidia, as it seems they broke something in the driver. Btw Win 7 SP1 includes nVidia 266.58 driver witch has this error, so lots of new computers will have this version installed by default.

Here is a compilation of my test results.

Code: Select all

Driver version:  CUDA version:  nvcuda.dll ver:  Result:
257.21           3.1.1          8.17.12.5721     OK, no corruption at all on either test.ts or test_trim.ts with Trim()
258.69 (beta)    3.1.1          8.17.12.5869     OK, no corruption at all on either test.ts or test_trim.ts with Trim()
258.96           3.1.1          8.17.12.5896     OK, no corruption at all on either test.ts or test_trim.ts with Trim()
260.89           3.2.1          8.17.12.6089     OK, no corruption at all on either test.ts or test_trim.ts with Trim()
260.99           3.2.1          8.17.12.6099     OK, no corruption at all on either test.ts or test_trim.ts with Trim()
266.35 (beta)    3.2.1          8.17.12.6635     Fail, clearly visible corruption on both files.
266.58           3.2.1          8.17.12.6658     Fail, clearly visible corruption on both files.
270.51 (beta)    4.0.1          8.17.12.7051     Fail, clearly visible corruption.

[Vippe]

Just tested with the newest WHQL 270.61 drivers releases yesterday and they also have the same errors.

[laserfan]

Win 7 SP1 includes nVidia 266.58 driver witch has this error, so lots of new computers will have this version installed by default.

FWIW I installed W7 SP1 and this was not installed. I don't recall making any special exclusions when I let WU install the SP.

[Vippe]

It's default driver if you use the Windows 7 installation dvd with integrated SP1. It's an updated dvd from Microsoft that is available on MSDN for example.
But it doesn't change the fact that all the new driver versions have this error.

[admin]

Sent to Nvidia for analysis.

[admin]

Nvidia has sent me a fix. Man, I love Nvidia! I think I'll slipstream it into 2039 and upload it later tonight after some regression testing.

So I'll mark this resolved. Thank you, Vippe, for bringing it to my attention and for your clear and complete problem data.

Analysis from Nvidia:

This is indeed another case of an unclean edit point messing
up the gaps_in_frame_num logic when combined with adaptive reference
picture marking. In this case, attempting to recover the missing
entries actually makes things much worse that not doing anything at
all. Unfortunately, not doing anything at all will break other streams
(though probably not as bad)

A workaround would be to mark all the entries in the dpb that
have not_existing=1 as non-references (used_for_reference=0).
We'll try to come up with
something more robust so that at least any side effect will be
contained in the very first few frames rather than having non-existing
references that stay in the dpb until frame_num wraps around.