Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
10th August 2020, 14:43 | #1 | Link |
Registered User
Join Date: Apr 2012
Location: Germany
Posts: 153
|
DGIndexNV - My video is 9seconds shorter despite correct fps rate
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? |
10th August 2020, 15:23 | #3 | Link | |
Registered User
Join Date: Apr 2012
Location: Germany
Posts: 153
|
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 Quote:
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: Code:
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" Last edited by De-M-oN; 10th August 2020 at 15:59. |
|
10th August 2020, 17:06 | #4 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
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. Last edited by videoh; 10th August 2020 at 17:14. |
10th August 2020, 23:41 | #5 | Link |
Registered User
Join Date: Apr 2012
Location: Germany
Posts: 153
|
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: Code:
-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. -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 |
|
|