Closed cs9kc closed 2 years ago
flaeri
commented
2 years ago is this one needed to produce the issue? RateControlSkipFrameEnable=true
Not sure its a good idea to have the encoder skip set up to skip frames in this scenario.
Tried both, and GOP is consistently correct for me on 4500u APU (driver: 30.0.21023.1015)
cs9kc
commented
2 years ago Let me expand a bit on how the issue manifests. With PA enabled:
This issue occurs when PA is enabled, regardless of rate control method, regardless if B-frames are used, and regardless of whether I have modified individual PA settings or not.
The included screenshot is using 2 b-frames, but again, the issue occurs with and without b-frames.
flaeri
commented
2 years ago It would have been really nice to have a log from the session this was recorded in, in order to know whether there was any render or encoder lag present.
I think this is a bit of a misnomer. I'll go by displayed order. The first 3 frames decode fine and normal, then you have 25 repeats of that final frame (the first coded p-frame, (zero indexed, coded 1, display 3). There is data there, but they they all just refer back to the previous frames, as there is no change.
On display frames 29 (coded 30), we finally get data that is updated, and all is well for 2 frames, and then it starts repeating that frame again (display 30, coded 28).
Almost seems like the encoder never got any new frames in time, or there was a large amount of lag. Things do improve towards the 2nd half of the GOP, and looks or less normal before the next GOP even starts.
The actual coded output seems fairly sane, so I do wonder what is happening prior, and is normal after the first GOP. You never really responded to whether it was happening without RateControlSkipFrameEnable. I'm also curious if this happens on balanced and speed quality presets.
Again, would have loved to see the log from that session, or a new log where you reproduce the issue with the bare minimum required (only PA, balanced/fast, no b-frames etc).
cs9kc
commented
2 years ago I think this is a bit of a misnomer.
I admit, I was generalizing for the sake of brevity.
Ah, to clarify further: RateControlSkipFrameEnable had no perceived affect on the output, though I did not do a frame-by-frame comparison of the output with PA, both with and without RateControlSkipFrameEnable.
OBS Studio does consider the lost frames as "Encoder Lag", and with PA enabled, it registers anywhere from 50 to 120 lagged frames with PA enabled, all of which occur at the very start of the video file.
Again, logs will be private-only for now.
On display frames 29 (coded 30), we finally get data that is updated, and all is well for 2 frames, and then it starts repeating that frame again (display 30, coded 28).
Semi-related, this is similar to the behaviour that I see when using 3 b-frames over in ticket #6835; that is to say, the third B-frame is a repeat of the one before it, resulting in every fourth frame in the output being identical to the one prior, a behaviour that I didn't notice when using TranscodeHW.exe.
The two observations above are what lead me to believe that the issues are OBS Studio-related.
cs9kc
commented
2 years ago I believe this to be normal behaviour of the PreAnalysis Component as it initializes, as it still reproduces now that #6835 has been resolved.
Operating System Info
Windows 11
Other OS
No response
OBS Studio Version
Git
OBS Studio Version (Other)
Master branch; build 27.2.0-f6f6690cc-Win-x64
OBS Studio Log URL
N/A
OBS Studio Crash Log URL
No response
Expected Behavior
Expected behaviour using H264 with the new AMD AMF encoder from the former obs-amf branch are as follows... when using the following settings, output is expected to be CBR, 7Mbit bitrate, with a small number of ancillary parameters set, and the PreAnalysis Component is disabled here. The resulting video is as expected, 60fps 1080p with no dropped frames and a constrained bitrate, ideal for streaming. Results were the same with BReferenceEnable=false as well.
RateControlMethod=1 Profile=100 ProfileLevel=42 QualityPreset=2 IDRPeriod=120 TargetBitrate=7000000 VBVBufferSize=14000000 MaxNumRefFrames=4 FillerDataEnable=true EnforceHRD=true DeBlockingFilter=true HighMotionQualityBoostEnable=false EnableVBAQ=false
These settings achieve the above stated goal.
Current Behavior
The observed behaviour when the exact same settings are used, but the PreAnalysis Component is enabled, which results in the first GOP being almost completely consumed by the encoder (the I-frame and perhaps one or two P-frames make it into the video output. Starting with the second IDR/I-frame, the encoder begins to sort itself out, and after the third IDR/I-frame, the output video works as expected, with smooth, consistent 1080p60 video.
RateControlMethod=1 Profile=100 ProfileLevel=42 QualityPreset=2 IDRPeriod=120 TargetBitrate=7000000 VBVBufferSize=14000000 MaxNumRefFrames=4 FillerDataEnable=true EnforceHRD=true DeBlockingFilter=true HighMotionQualityBoostEnable=false EnableVBAQ=false EnablePreAnalysis=true RateControlSkipFrameEnable=true PASceneChangeDetectionEnable=false
Windows 11 22H1, 5800X, RX 6900 XT
Steps to Reproduce
Similar to #6835, I believe this to be an issue with OBS Studio and how the PreAnalysis Component is implemented into the encoder.
Anything else we should know?
Thank you all again for your hard work, especially @jp9000. Logs can be provided upon request, though I will only do so privately