That's a good one! Thanks for bringing it to my attention. The stream has a packet boundary within the start code for the first IDR frame (and more like that elsewhere in the file): ... 00 00 [packet boundary] 01 65 88 ... My indexer does not handle this correctly [causing me to miss the first slice...

One donation covers both of them. You do not have to choose.

What kind of glitch? Screenshot? One frame or a bunch of frames? You'll need to give me a stream that I can use to duplicate the issue. You say just opening the script in VirtualDub causes no issue. Therefore, we need to look at your encoding process. Maybe it is making some nonlinear requests that ...

That's really beyond the purpose of my tools, and in any case, I have no time to implement anything like that. However, you can find numerous options for achieving this using other tools, several of them freeware. Begin your search at Google with the search string "MPEG2 stream verifier": http://www...

TiberiusT wrote:I don't see the delay in the log file

That's because it's at the bottom of the DGI file.

BTW, I'd appreciate you starting a new thread about your bitrates and performance, as it is OT in this thread. Thanks.

A VP5 engine will probably give a speed bump. I'll be getting one soon for some testing and also to implement selectable CUDA/CUVID for each video type. We know for example that MPEG2 is faster with CUDA on VP4 and below but is faster with CUVID on VP5. Since there is no way to query the VP engine v...

Thank you for your test results. The delay arises because demuxing elementary streams may not hit the same PTS values for the audio and video at that point in the stream. There is no guarantee in a stream that access units for audio and video with the same presentation times will be close together. ...

I put a test version here:

http://rationalqm.us/misc/TiberiusT.zip

Use -ad instead of -a to use filenames based on the DGI filename.

Please let me know if this is working for you.

Not all situations are as clean as yours. I could write the delay into the DGI file. OK, I'll do that and give you a CLI option for the audio filename. Will that be sufficient for you?

You're welcome. If you need a method to determine the field order to choose AssumeTFF() or AssumeBFF(), have a look at the FAQ at my website (first two questions):

http://rationalqm.us/faq.html

Email sent.

The clip is TFF. So you need to add an AssumeTFF() line after the source filter. With AssumeTFF(), all three of DGDecNV, DGAVCDecDI, and DGAVCDec serve correct TFF video. If you find an issue please describe the exact process to demonstrate it. BTW, always use AssumeTFF() or AssumeBFF() as needed, r...

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

I downloaded this. It is again all zeros.

I've uploaded 2021.

http://rationalqm.us/dgdecnv/dgdecnv2021.zip

I'm sorry but I just don't have the time to go back and try to figure out what version might work for you. It's complicated because the security scheme changed (so there is no online generator for the previous scheme and I'd have to recreate my key generation manually), CUDA kernels got implemented ...

Earliest supported driver is 196.21. If you can't run a later version all I can do is offer you a refund.

@slomorbo Thanks for your test utility. I don't understand why you bring x264 into this. It adds another variable (of which there are already many) and the results will be different for pretty much every processor. +1 Nvidia reports there is no way currently to query the VP engine version, but it ma...

There are two executables. The released one uses CUDA for MPEG2 and VPU for everything else.

The debug one here:

http://neuron2.net/board/viewtopic.php? ... t=10#p1455

...uses VPU for everything.

Groucho2004 wrote:I meant the short MPEG-2 clip with 173 frames you uploaded.

I know what you meant. I'm just pointing out that the small clip was not intended for performance testing, but just to test that the decoding bug was fixed in current driver versions.

slomorbo wrote:hope it's help

It's very helpful, thank you! What are the percentages in the table? Also, your table should show VP5 for the 520.

I have never used AvsMeter but will look into it to see if there is a reason for the anomaly you noted.

His original clip used for his performance results was 7:43. I can't believe CUDA is so close to VPU on the 460 for MPEG2. My testing doesn't agree with that. Maybe flyordie accidentally picked up the same DGDecodeNV.dll when doing the testing?

Your hint is to read the DGDecNV performance threads, both here and elsewhere.

VP5 (520, 4200) is currently the fastest VPU.

To summarize my previous post and group them by type of encode to better compare the different cards: Plain Script (Average FPS) CUDA VPU GT 520 101.71 fps 190.76 fps GTX 460 240.49 fps 241.98 fps GTX 560 Ti 260.67 fps 260.58 fps I think something must have gone wrong with your testing. On my 460, ...

If you re-enable VPU would you allow the end user to switch between the two? Perhaps a DecodeEngine=1 or something in the AVS call? I plan to detect the VPU version if possible and choose based on that. I thought it was strange the GTX 560 Ti had virtually the same results for CUDA and VPU. Did tha...

There is currently no fix possible. You'll have to continue using your workaround.

BTW, your link is dead.