Question / Help Audio Freezing Momentarily

So the audio freezes for no apparent reason this didn't happen before i started recording minecraft it worked with bf4 Skyrim sniper elite 3 etc. but not with this any help?
you need to post your logfile. click help button in OBS and upload the latest logfile. post the link to github here.
 

I see nothing directly related to audio delaying or freezing, but...

Code:
Number of frames skipped due to encoder lag: 11400 (60.74%)
encoder thread frame - [100%] [avg time: 12.655 ms
fps: 60
15:25:23: width: 1920, height: 1080
15:25:23: preset: fast
15:25:23:     CFR: no

keyint: 250 (key frames needs to be 2 (not auto)

1080@60 on fast preset is very taxing on your CPU. Minecraft(java) is not an optimized game for multithread from my understanding so it uses up alot more cpu/gpu time than other, more graphically intensive games.

I would lower your preset to faster or even veryfast and just raise your bitrate to compensate. this is based on the number of frames skipped and the cpu time spent on encoding based on the 12ms per frame its taking you to encode.

1080@60 should be more like 50000 bitrate (not 8000) to get full quality since you are recording local

turn on CFR which will help with a more constant frame rate if you will be editing your video at a later time.

Set your key frame interval to 2
 
I see nothing directly related to audio delaying or freezing, but...

Code:
Number of frames skipped due to encoder lag: 11400 (60.74%)
encoder thread frame - [100%] [avg time: 12.655 ms
fps: 60
15:25:23: width: 1920, height: 1080
15:25:23: preset: fast
15:25:23:     CFR: no

keyint: 250 (key frames needs to be 2 (not auto)

1080@60 on fast preset is very taxing on your CPU. Minecraft(java) is not an optimized game for multithread from my understanding so it uses up alot more cpu/gpu time than other, more graphically intensive games.

I would lower your preset to faster or even veryfast and just raise your bitrate to compensate. this is based on the number of frames skipped and the cpu time spent on encoding based on the 12ms per frame its taking you to encode.

1080@60 should be more like 50000 bitrate (not 8000) to get full quality since you are recording local

turn on CFR which will help with a more constant frame rate if you will be editing your video at a later time.

Set your key frame interval to 2
Ok will test wen i come back home. and what dos keyframe intervals do?
 
Ok will test wen i come back home. and what dos keyframe intervals do?
key frames aka IDR posts a refresh, clearing P and B frames from referencing. Its basically an I frame, a full picture that can stand on its own but it also tells the encoder not to reference any frames prior. P and B frames are a made based off the changes from previous or future frames via search windows. This search windows reference pieces of the picture from I frames and other P frames.
after the refresh, the IDR, the cycle starts over with new P and B frames.

the reason we need them is when a new viewer starts watching from a already started stream, he'll be able to get an IDR frame every so often to start this cycle. Without the IDR. the viewer will only see P and B frames which will only be small references of frame search windows.
local recordings also need idr to seek video based on the same concepts. If the IDR takes to long the picture will eventually start to look bad from packet loss or momentary missed p or b's. To many and the stream cant be encoded as much and will also look bad. A healthy balance is every 2 seconds. Which is a key frame interval of 2
 
key frames aka IDR posts a refresh, clearing P and B frames from referencing. Its basically an I frame, a full picture that can stand on its own but it also tells the encoder not to reference any frames prior. P and B frames are a made based off the changes from previous or future frames via search windows. This search windows reference pieces of the picture from I frames and other P frames.
after the refresh, the IDR, the cycle starts over with new P and B frames.

the reason we need them is when a new viewer starts watching from a already started stream, he'll be able to get an IDR frame every so often to start this cycle. Without the IDR. the viewer will only see P and B frames which will only be small references of frame search windows.
local recordings also need idr to seek video based on the same concepts. If the IDR takes to long the picture will eventually start to look bad from packet loss or momentary missed p or b's. To many and the stream cant be encoded as much and will also look bad. A healthy balance is every 2 seconds. Which is a key frame interval of 2
What do you think is the problem with the audio?
 
Back
Top