DGIndexNV - My video is 9seconds shorter despite correct fps rate

[De-M-oN]

I capture with my Datapath capture card my computer games.
While in TMPGEnc 7 the file keeps all the 280254 frames, it loses 9.1 seconds somewhere of the video with DGIndexNV.
This happens with any capture.

Mediainfo of the source

https://paste2.org/WLHgAzcy

You can see it is 1:17.50 long with constant framerate at 60fps and 280254 frames.

DGIndexNV detects correct framerate as well, but it comes out with 9.1 seconds less. It has just 279808 frames left over.
I assume its random frames in the video, because start and end of video are still intact.

Log:
https://paste2.org/ZObIC1fs

dgi file:
https://paste2.org/cCxsH2v6

Any idea what's going on?

[videoh]

Your DGI is missing the SPS/PPS. Please try again with build 215, as there is a fix for that. It happens when you save the project twice without closing DGIndexNV.

[De-M-oN]

I actually did save it only once.
I've deleted the dgi now for the update.
I updated now to 215, but I still have just 279808 frames :(

The dgi is also bit-identical to 210.

edit: Seems to be correct behavior for MKV files

The data section of a DGI file contains the indexing of the AVC video stream. The syntax for each keyword line is as follows:

SPS n: A new Sequence Parameter Set (SPS) is located at offset n (decimal) in the source file. Note that repeated identical SPS's are not new and so are not indexed. For Matroska streams, SPS's are not indexed because they are stored in metadata in the Matroska file.
PPS n: A new Picture Parameter Set (PPS) is located at offset n (decimal) in the source file. Note that repeated identical PPS's are not new and so are not indexed. For Matroska streams, PPS's are not indexed because they are stored in metadata in the Matroska file.

edit2: Ok thats really weird now

I've remuxed the file with MKVToolnix and got now this Mediainfo:

https://paste2.org/jGyL9f0J

So apparently something of the file is 59.94 only? Or where does the 59.94 come from???
Apparently the 279808 represents 59.94 fps.

This is super weird, because I definitely captured in CFR 60:

ffmpeg -rtbufsize 2147M -f dshow -framerate 60 -thread_queue_size 1024 -probesize 10M -pixel_format bgr24 -i video="Datapath VisionSC-DP2 Video 01":audio="Wave (ASUS Xonar HDAV Audio Device)" -f dshow -thread_queue_size 64 -i audio="Line (AudioBox 22VSL)"
-map 0 -map 1 -vcodec h264_nvenc -pix_fmt yuv420p -rc:v vbr -b:v 0 -qmin 1 -qmax 16 -preset hp -acodec pcm_s16le -audio_buffer_size 80 "%fullpath%\%filename%.mkv"

I'm really confused now.

[videoh]

Sorry, didn't notice it is MKV.

Sometimes the MKV container framerate and the elementary stream (AVC) frame rate do not agree. Apparently your file has 60 for the MKV container and 59.94 for the elementary stream. What is the real rate? You'll have to process it both ways (use AssumeFPS() in your script), and see which is in sync towards the end of the file. When you remux'ed it, the elementary stream frame rate was used. I guess that setting frame rate to 60 on your command line can only change the MKV framerate; it doesn't change the frame rate of the captured stream.

[De-M-oN]

I tried around a bit
I tried a test capture with 75fps and got after remux a 74.905
I tried 50fps and got 49.something

My assumption is that the following happens:

Elementary stream is apparently stored with Variable Framerate.
Container gets a constant framerate (not exactly sure if audio is timestamped to stream or container though)

MKVToolnixGUI then uses the Elementary Stream Framerate and thus container is written with its info too. So a VFR then.

Now in the ffmpeg documentation I found this:

-vsync parameter
Video sync method. For compatibility reasons old values can be specified as numbers. Newly added values will have to be specified as strings always.

0, passthrough
Each frame is passed with its timestamp from the demuxer to the muxer.

1, cfr
Frames will be duplicated and dropped to achieve exactly the requested constant frame rate.

2, vfr
Frames are passed through with their timestamp or dropped so as to prevent 2 frames from having the same timestamp.

drop
As passthrough but destroys all timestamps, making the muxer generate fresh timestamps based on frame-rate.

-1, auto
Chooses between 1 and 2 depending on muxer capabilities. This is the default method.

I've added

-vsync cfr

into my ffmpeg commandline for the output and now I get a 60 CFR elementary stream even after remuxing it.
So it should be solved now.

Thank you very much for your help :)

[videoh]

Always my pleasure to help a fellow thinker, channeling divine energy.