Here is a new version with chapter marks for disks: https://rationalqm.us/misc/DGDecNV_tormento.zip Note on current behavior : When you open a disk and click on the timeline, you will likely notice that the cursor settles at a point different than the location of the click. The reason for this is a ...

OK, I found the bug and now have a reliable timestamp for the frame on display, in the same space as the chapter marks. So, a little clean-up and regression testing and I'll have a test version for you. Then later come chapter navigation and demuxing. This hullabaloo was an unavoidable prerequisite ...

That's the whole point. It's not accurate period, not just visually. I mean it's not a display issue; it's a matter of getting the correct timestamp for the video frame on display. I'm very close so keep being patient.

I've added it in my local build. But there is an issue with accuracy of the marks versus the displayed GOPs (for TS), i.e, if you navigate on the timeline to a chapter mark it is close to but not exactly at the intended video. The reason for this is that the chapter marks specify times and they are ...

Try checking skip first M2TS in the options.

I knew you'd ask for that.

Re-download again and update DGIndexNV. Fixed another MKV 'GOP back' bug that led to a very busy tight loop for some unlucky streams.

Seems real good now.

Please re-download again to get chapter marks on the timeline for MKV.

May add that for other containers in the future. Also, may support XML chapters file for the other containers. I'd like to get this version released first.

Please re-download for the next test version. It eliminates the need for mkvextract to extract chapters by doing it internally. The old MKV parser library previously did not parse chapters and that's why I used mkvextract. So I bit the bullet and added chapters parsing to the library. Gonna need it ...

First things first.

Not supported but there's no reason it couldn't be supported if NVDec is happy with it. All I need is a sample.

In general right now, we have AVC, HEVC, MPEG2, and VC1 all in 4:2:0.

Maybe we could do lossless now too.

Cool, thank you.

I encoded Baywatch without issues. Well, there was one issue but not mine. Apparently x265.exe wants mod 8.

Also put Reverse() at the end of several scripts to test random access on every frame. No issues.

I might do chapter marks on the timeline next.

Please re-download and, as Sherman would say, report your success. See? The code is so maintainable now that the bug was easy to find and fix. ;) EDIT: Oops, give me a minute before downloading. I forgot to make the change for HEVC. EDIT2: OK, good to go! EDIT3: If you could test Vapoursynth that wo...

Hmm, that's annoying. Shouldn't be too hard to fix though. Thank you for the testing and report.

You lost me on that one. I'm gonna assume you meant that the test build is OK (so far). Squirrels are not good at reading between the lines. We are very literal, if not very literate.

Here you go:

https://rationalqm.us/misc/DGDecNV_tormento.zip

Update both components and don't try to re-use existing DGI files.

Let's see how much stuff got broken.

Time for my siesta.

Stands for 'what the french toast'!

I'll put up a test version right now and reply back when it is up.

Good to hear. I'll leave this thread open to remind me that it would be nice to have in DGDemux too.

After I got forward stepping working reliably I found that backward stepping was hosed. Reliable GOP navigation is important to set accurate project ranges, of course. Anyway, I just got that fixed this morning and as I mentioned in another post will release a candidate version very soon, maybe today.

I've got the new generation indexing completed (I hope). It all stemmed from this MKV delay issue that got me investigating. I found that the MKV support was a gigantic kludge and so decided to revamp it. That had implications outside the MKV code so it became a massive testing effort. Think about i...

Turns out this is not related to successive IDRs with the same idr_pic_id, and I imagined that it was fixed. Nevertheless that should be fixed. The real reason was very complex and difficult to find but I found it!

We're all still alive and the AC is running fine. So I'll mark this resolved.

Great! Thank you for the update.

For some MKV streams a GOP step produces a corrupted picture. We have a workaround for streams with successive IDR frames with the same idr_pic_id, but this was being applied only for ES streams. When applying it to all container types, the problem is fixed. I will release this along with the MKV re...

I ran a test with pools 12:

no prefetch: 31.92 fps
prefetch 2: 29.5 fps

Hoping for clarification from your side on the 100% claim.

EDIT: OK, just saw your post above.

Will mark resolved.

MKV re-design is proceeding well, BTW.

You initially wrote: "I have found, strangely, that adding a simple prefetch (2) at the end of the AVS script increases my fps by almost 100%." But the table you subsequently gave shows (for pools 12) an increase from 7.66 fps to 8.56 fps. How is that 100%? Such a small difference can be accounted f...