Question / Help Regarding duplicated frames and audio timestamps.

D

defterOG

New Member
hello,

i was wondering if duplicated frames and audio timestamps (behind target timestamp) should be of concern. i do remember a few days ago i encountered an issue where OBS was showing a black/greyed out square on the bottom right hand corner of the window instead of the usual green square.

if anyone knows what these 2 items would mean, i'd very much appreciate it.

here is the log:
Code: 
18:01:04: =====Stream Start: 2014-02-04, 18:01:04===============================================
18:01:04:   Multithreaded optimizations: On
18:01:04:   Base resolution: 1920x1080
18:01:04:   Output resolution: 1280x720
18:01:04: ------------------------------------------
18:01:04: Loading up D3D10 on NVIDIA GeForce GTX 670 (Adapter 1)...
18:01:04: ------------------------------------------
18:01:04: Audio Format: 44100hz
18:01:04: Playback device {0.0.0.00000000}.{1f1a8a5a-102d-41df-9a26-297a0b3b6349}
18:01:04: ------------------------------------------
18:01:04: Using desktop audio input: Line Out (2- Forte)
18:01:04: ------------------------------------------
18:01:04: Using auxilary audio input: Line In (2- Forte)
18:01:04: ------------------------------------------
18:01:04: Audio Encoding: AAC
18:01:04:     bitrate: 128
18:01:04: Using graphics capture
18:01:04: Scene buffering time set to 400
18:01:04: Using custom x264 settings: "opencl=true"
18:01:07: ------------------------------------------
18:01:07: Video Encoding: x264
18:01:07:     fps: 60
18:01:07:     width: 1280, height: 720
18:01:07:     preset: veryfast
18:01:07:     profile: high
18:01:07:     keyint: 120
18:01:07:     CBR: yes
18:01:07:     CFR: no
18:01:07:     max bitrate: 3400
18:01:07:     buffer size: 3400
18:01:07: ------------------------------------------
18:01:07: SharedTexCapture hooked
18:01:07: Audio timestamp for device 'Line In (2- Forte)' was behind target timestamp by 3302309
18:01:08: Using RTMP service: Twitch / Justin.tv
18:01:08:   Server selection: rtmp://live-lax.justin.tv/app
18:01:08:   Interface: Intel(R) 82579V Gigabit Network Connection (ethernet, 1000 mbps)
18:01:08: Completed handshake with rtmp://live-lax.justin.tv/app in 47 ms.
18:01:09: SO_SNDBUF was at 65536
18:01:09: SO_SNDBUF is now 65536
18:01:11: GraphicsCaptureSource::NewCapture:  eliminating old capture
18:01:11: SharedTexCapture hooked
18:01:12: GraphicsCaptureSource::NewCapture:  eliminating old capture
18:01:12: SharedTexCapture hooked
18:10:48: RTMPPublisher::SocketLoop: Increasing send buffer to ISB 131072 (buffer: 0 / 451584)
18:17:14: Total frames encoded: 58003, total frames duplicated: 452 (0.78%)
18:17:14: Total frames rendered: 58000, number of late frames: 11 (0.02%) (it's okay for some frames to be late)
18:17:14: RTMPPublisher::SocketLoop: Graceful loop exit
18:17:15: Average send payload: 22381 bytes, average send interval: 50 ms
18:17:15: Number of times waited to send: 0, Waited for a total of 0 bytes
18:17:15: Number of b-frames dropped: 0 (0%), Number of p-frames dropped: 0 (0%), Total 0 (0%)
18:17:15: Number of bytes sent: 426681077
18:17:15: 
18:17:15: Profiler time results:
18:17:15: 
18:17:15: ==============================================================
18:17:15: video thread frame - [100%] [avg time: 0.713 ms] [children: 40.5%] [unaccounted: 59.5%]
18:17:15: | scene->Preprocess - [0.14%] [avg time: 0.001 ms]
18:17:15: | GPU download and conversion - [40.4%] [avg time: 0.288 ms] [children: 7.43%] [unaccounted: 33%]
18:17:15: | | flush - [5.19%] [avg time: 0.037 ms]
18:17:15: | | CopyResource - [1.96%] [avg time: 0.014 ms]
18:17:15: | | conversion to 4:2:0 - [0.281%] [avg time: 0.002 ms]
18:17:15: Convert444Threads - [100%] [avg time: 0.391 ms] [children: 98.7%] [unaccounted: 1.28%]
18:17:15: | Convert444toNV12 - [98.7%] [avg time: 0.386 ms]
18:17:15: encoder thread frame - [100%] [avg time: 0.899 ms]
18:17:15: ==============================================================
18:17:15: 
18:17:15: 
18:17:15: Profiler CPU results:
18:17:15: 
18:17:15: ==============================================================
18:17:15: video thread frame - [cpu time: avg 0.081 ms, total 4750 ms] [avg calls per frame: 1]
18:17:15: | scene->Preprocess - [cpu time: avg 0 ms, total 15.625 ms] [avg calls per frame: 1]
18:17:15: | GPU download and conversion - [cpu time: avg 0.015 ms, total 921.875 ms] [avg calls per frame: 1]
18:17:15: | | flush - [cpu time: avg 0.011 ms, total 640.625 ms] [avg calls per frame: 1]
18:17:15: | | CopyResource - [cpu time: avg 0.001 ms, total 78.125 ms] [avg calls per frame: 1]
18:17:15: | | conversion to 4:2:0 - [cpu time: avg 0.001 ms, total 62.5 ms] [avg calls per frame: 1]
18:17:15: Convert444Threads - [cpu time: avg 0.228 ms, total 26437.5 ms] [avg calls per frame: 2]
18:17:15: | Convert444toNV12 - [cpu time: avg 0.226 ms, total 26234.4 ms] [avg calls per frame: 2]
18:17:15: encoder thread frame - [cpu time: avg 0.156 ms, total 9093.75 ms] [avg calls per frame: 1]
18:17:15: ==============================================================
18:17:15: 
18:17:15: =====Stream End: 2014-02-04, 18:17:15=================================================
 
It typically means the drivers for whatever device you're using aren't outputting time data properly.
 
hmm alright, i haven't seen the audio timestamp issue so far but, i was fine-tuning DRAM voltages/timings in the BIOS which must've caused it. thanks.

any input for duplicated frames? are duplicated frames something that can occur when everything is running normally or should i not be seeing any amount of duplicated frames? i do remember a log file i skimmed over a few weeks back had something around 17% duplicated frames.
 
You get duplicated frames if OBS can't process a frame in time for it to be encoded, which causes it to just duplicate the previous frame instead to maintain constant frame rate. The log you posted didn't have much of an issue with duplicated frames (0.78% is pretty low, but if it gets much higher it would be worth trying to fix). The typical fix is to look for sources that could be taking a long time to capture (lower your resolution on webcams, avoid Monitor capture on Windows 7, etc.) and also lower resolution/FPS.
 
Duplicated frames are fine in small percentages like what you're seeing. I wouldn't start worrying until you're at the 2% or more mark.

The much more important bits are late frames and skipped frames.
 
thank you all for the explanations.

i ended up lowering the CPU preset to superfast and this has shown a vast improvement in streaming stability. although i'm still seeing a high percentage of duplicated frames about once a day (usually the first stream after a cold boot), the percentage is much more lower compared to the veryfast preset.

a little off-topic but, i wanted to try an see if using MSI Afterburner's video capture would further help this. is it possible to use the video capture implementation from Afterburner and live stream it through OBS? (kinda like using Dxtory and OBS together)

thanks again guys, much appreciated.
 
No. OBS's capture methods are already as good as you can get, and MSI Afterbuerner tends to get in the way of OBS anyway.
 
You must log in or register to reply here.
Back
Top