inconsistant video seeking from OBS studio records

[Golem]

Just started using OBS Studio and whether I record in x264 or NVENC H.264 I can not get consistent seeking to work for the resultant videos. I've input keyframe intervals from 0(auto) and also 1 through 10 (seconds) in one second increments. The best result I've been able to produce is to have seeking (be it 2sec or 20sec) work instantly, as expected, for the first use but each subsequent use will take longer and longer for the seek to process. By the time I get to the 10min mark the recorded video will average 90sec to seek 2sec. If I have a 30min recording and attempt to jump directly to the 15min mark it could take as long as 5 minutes to resume. Makes no difference if it's a 10min or 1hour long 10Mbps or 20Mbps bitrate recording. It seems as if keyframes continually and gradually widen over the length of the video. Multiple viewers provide the same result.

I have thousands of videos I've either recorded myself using different software/hardware or downloaded from the internet and only a number, countable on one hand, have had poor seek performance, usually attributed to super wide keyframe intervals. With OBS, as noted, I've tried a myriad of keyframe values, additionally I attempted different FPS/B-frames/bitrates/resolutions/etc. I'd really like to continue use of OBS Studio so a solution would be greatly welcomed.

[Selur]

Never used OBS, but is there an option for closed/open gop, if there is try using closed gop.

[Golem]

Appreciate the reply!

Although I can't access OBS right now I'm 99.9% confident there's no GOP close/open check box option. On the other hand, pretty sure there's the ability to add script which might allow this. Will look into it as a test. My scripting is rusty, haven't used it for over 10 years since I stopped using VDub.

[KarMa]

What container are you using? .TS is naturally not going to seek well.

[Golem]

Thanks for the question.

Using MKV container. I'm not sure if the following test sample is from an"auto" or designated (1 or 2sec) keyframe interval.


[Attachment 48612 - Click to enlarge]

[KarMa]

With that mediainfo, it looks like you have a hard 1 second GOP. So GOPs above 1 second should be impossible if the M=3 N=59 is honored. So seeking times should be fast. What are you trying to seek in, what program?

Edit: You are going to want to change your Matrix Coef to BT.709, instead of BT.601. 709 for 720p and above, 601 for SD. Generally. This can be changed in OBS.

[Golem]

Thanks again!

My go-to viewer is ZoomPlayer (VLC & MPC in the wings).

Yea, seek is instantaneous within the first minute of timeframe but degrades progressively throughout the remainder.

Matrix Coefficient is an unfamiliar standard to me. A quick bit of research confirms I should definitely change that option which looks to be under the "advanced" tab (not currently using the OBS comp).

[KarMa]

I've honestly never heard or used Zoomplayer. Personally I just use VLC and MPC-HC. VLC will jump to a desired frame but might take a moment or two depending on the encoding. MPC-HC will pretty much instantly jump to the closest I-frame on the timeline, this gives instant decoding but won't be frame accurate. I-frames are at the start of every GOP and are self-contained frames with no need for any other frame, which is why they decode so fast.

[Golem]

Thanks heaps for the urging...that is, urging to update MPC. I've been using ZoomPlayer for in excess of 15 years and only on very rare occasions pulled up MPC or VLC. Because of this these latter two were pretty out of date. I just updated to MPC-HC and seeking works perfectly. Now that I'm not chasing red herrings I can get back to quality tweaking. In that vein, I did change Color Space to 709 (all my records are HD or UHD) and, while there, noticed Color Range was "partial", she's at "full" now.

Appreciate the effort to get me back on track!

[KarMa]

In OBS, keep the range "partial" unless you really need "full". Just about every video player is going to expect partial, aka limited. Most players are simply going to assume partial, when it's really full and then it's not going to look right. If you are just recording for yourself then "full" will retain more luma gradient information, just remember to set your player accordingly. Youtube is certainly go to mess up with anything other than 709/partial.

[Golem]

Much appreciate the additional insight KarMa!

Interesting about the partial vs full Color Range option. I'm recording strictly for archival and personal playback purposes while looking to get the best image but still at a reasonable biIrate (approx. 8GB/hr). Sound like "full" should be applicable to my needs?

Took some time last evening and this afternoon to run quite a few tests. This included 5min records of the same media segment using CQP with variables being CQ Level (18-20), Keyframe Intervals (seconds, 1-5, 0(auto)) and Max B-Frames (0-4). Interestingly, as seen in the CQP-20 series of tests, the file size results weren't always linear. I'd also have to say visual quality was indistinguishable throughout the entire test. The noticeable difference was absolutely in seekability. The worst was when keyframed "auto" followed by "5". The sweet spot looks to be "3". Pair that with a Max B-frame of "3" and CQ of 19 I think I have most of my settings sussed.

While I have your attention
Through my research I come across a suggestion that when using a TV as a monitor (59" UHD) it would be advantageous to set both the recording device and display driver to 59.94 Hz/FPS. I believe 60Hz is supposed to introduce an extra frame stutter, would it be perceptible, I doubt it. While OBS allows for this the NVIDIA driver options 60Hz and 59Hz. I chose NVIDIA's 59Hz as I understand it's supposedly a rounded-down 59.94. Any opinions on the 60Hz/59.94Hz debate?

[jagabo]

Through my research I come across a suggestion that when using a TV as a monitor (59" UHD) it would be advantageous to set both the recording device and display driver to 59.94 Hz/FPS. I believe 60Hz is supposed to introduce an extra frame stutter, would it be perceptible, I doubt it.

The difference will be noticeable if that stutter occurs in the middle of a smooth panning shot. The stutter will occur about once every 16.7 seconds.

[Golem]

Thanks jagabo!

So noticing it would be hit-n-miss as scene conditions are a factor. My testing has been with 59.94/59 and haven't yet noticed it. I'll test 60 but might as well ask -- Is there validity to setting 59Hz/FPS when using a TV as a monitor to screen record streaming video?

[jagabo]

Yes. NTSC broadcast is 59.94 (60000/1001) fields or frames per second. Of course, the source should be 59.94 fields per second if you're going to record at that rate. Otherwise your recording will be jerky and it will playback jerky regardless of what frame rate you play at.

[Golem]

Thanks jagabo!

I guess what I'm not sure of (and ultimately asking) is -- Since my recording is not from an NTSC broadcast, but instead internet streamed video (e.g. Amazon, Netflix, etc.), does the 59.94 still come into play? In this capture scenario I was thinking record rate setting would be determined only by the refresh rate I choose for the monitor. When I do capture NTSC via either my MDP-100 or Colossus capture cards those files are recorded at 29.970 FPS as expected.

[jagabo]

Since my recording is not from an NTSC broadcast, but instead internet streamed video (e.g. Amazon, Netflix, etc.), does the 59.94 still come into play?

Sorry, I missed your reference to streaming earlier. Online streaming makes the situation much more complex. Streams may be 23.976 fps, 24 fps, 25 fps, 29.97 fps, 30 fps, 50 fps, 59.94 fps, 60 fps, or some other frame rate. Of course, when you watch them on a 60 Hz monitor they are converted to 60 fps by duplicating the streamed frames. If you don't plan on post processing to restore the original frame rate (for example, a 29.97 fps stream is most likely made by deinterlacing a 29.97i source, which in turn was most likely made from a 23.976p source) then your best bet is to capture at the refresh rate of your monitor.

[Golem]

Appreciate the info and clarification jagabo! Looks like I'll input 60Hz/FPS (for most captures) in effort to remove any possible discrepancies.

Luckily for me intention is to archive as recorded to HDD with playback being via HDPC. That's one reason I have high hopes for OBS Studio as it allows capture in the desired codecs which then require no transcoding upon simple trimming procedures using VideoRedo.