AMF
AMF copied to clipboard
GPUOpen-LibrariesAndSDKs
[Bug]: Reported # of reference frames used is accurate in 22.2.3; only ever reports 1 or 2 in 22.3.1 and later drivers
Describe the bug This is regarding the H264 (and presumably H265) encoder using reference frames, and how they are being reported in MediaInfo.
There is the impression around the internet, among those familiar with AMD AMF encoding, that "MediaInfo will always just report 1 reference frame, regardless of settings. AMD said this is normal/okay, that reference frames are being used properly". I have found this impression to be untrue, and wanted to bring it to the attention to the AMF team while they are working on bug 325, 326, and 327.
During the testing of mine that uncovered the aforementioned bugs: Driver version 22.2.3 when using H264 encoding, MediaInfo actually reported 4 reference frames when I set PreAnalysis to enabled, level to "4.2", and "MaxNumRefFrames=4", using the new OBS Studio with the new AMF texture-based encoder. This tells me that the impression that people have is incorrect, and the encoder will use reference frames properly when PA is enabled.
When testing with driver 22.3.1 and newer using H264, MediaInfo only ever reported 1 or 2 reference frames (PreAnalysis off and on, respectively), regardless of other settings.
TL;DR: My concern is that in 22.2.3 and earlier (AMF 1.4.23), the encoder is properly using reference frames with PreAnalysis enabled, but in driver 22.3.1 and newer (AMF 1.4.24), it is not using PreAnalysis and reference frames properly.
To Reproduce Steps to reproduce the behavior:
- Encode in H264 using PreAnalysis, with the maximum # of reference frames set for the encoder level's capability (ex: Level 4.2; 4 ref. frames)
- Do the same for driver 22.3.1 or later, and compare the two media files in MediaInfo.
Setup (please complete the following information):
- OS version: Windows 11 21H2 22000.708
- Adrenalin driver version: WHQL 22.5.2
- GPU: AMD Reference RX 6900 XT LC
- Which component has the issue: H264 Encoder
Expected behavior H264 should use "up to" the maximum number of reference frames that a user sets (so long as that # is within the encoder level's capability.
Additional context I want this discrepancy between driver versions to be documented in hopes that it too is corrected in a future driver/AMF update. Apologies for forgetting to file this bug when I filed past bugs.
On 22.6.1 with Oculus Link using AVC, it reports MaxNumRefFrames at 4:
---- AMD H264 Current Properties set ----
DeBlockingFilter = 1
QPI = 22
FrameSize = (2880x320)
ScanType = 0
VBVBufferSize = 752640
ColorBitDepth = 8
FrameRate = (90x1)
MaxQP = 51
Usage = 0
MaxNumRefFrames = 4
ProfileLevel = 42
Profile = 256
RateControlPreanalysisEnable = 0
FullRangeColor = 1
AspectRatio = (1x1)
MaxOfLTRFrames = 1
HalfPixel = 1
LowLatencyInternal = 1
QualityPreset = 1
HighMotionQualityBoostEnable = 0
InColorProfile = -1
OutColorTransferChar = 0
OutColorProfile = -1
SlicesPerFrame = 1
InColorTransferChar = 0
BPicturesDeltaQP = Fail with error [4]
ReferenceBPicturesDeltaQP = Fail with error [4]
EnforceHRD = 1
IntraRefreshMBsNumberPerSlot = 255
FillerDataEnable = 1
BPicturesPattern = 0
EnableVBAQ = 0
QuarterPixel = 1
InitialVBVBufferFullness = 64
MaxAUSize = 0
MinQP = 0
QPP = 22
QPB = 22
TargetBitrate = 40000000
PeakBitrate = 40000000
RateControlSkipFrameEnable = 0
RateControlMethod = 1
HeaderInsertionSpacing = 0
BReferenceEnable = 0
IDRPeriod = 0
CABACEnable = 2
NumOfTemporalEnhancmentLayers = 1
On 22.6.1 with Oculus Link using AVC, it reports MaxNumRefFrames at 4:
It looks like we're looking at the settings that it is sending to AMF. My issue is how many are actually being reported as being used in the resulting complete media file after encoding is done.
On 22.6.1 with Oculus Link using AVC, it reports MaxNumRefFrames at 4:
It looks like we're looking at the settings that it is sending to AMF. My issue is how many are actually being reported as being used in the resulting complete media file after encoding is done.
I wouldn't give too much credit to mediainfo. It shows 4 reference frames under format settings with x264 even though ref=1 is being used in OBS and also shown under "Encoding settings" within mediainfo.
As an update to this, I do believe this ticket could be based on my misunderstanding of exactly how AMF implements and uses short-term reference frames. Possibly.
MaxNumRefFrames=4 seems to make no difference when using OBS Studio with the new AMD AMF texture-based encoder. I appreciate that the above parameter is based on H264/H265 level, and is a maximum, not an absolute, but I still never see the H264 encoder report more than two reference frames, both with and without B-frames, and with and without B-frames as reference frames.
Over the past two days, I pulled up the H264 encoding reference manual to see if it had more information. What I found was that the way the AMF encoder acts, is correct in that it will use one reference frame unless B-frames are used, at which point it will use two reference frames.
If @rhutsAMD has a few free moments:
- It appears that the AMF encoder is working properly based on the H264 standard
- If that is correct, it is unclear to me what effect the "MaxNumRefFrames" setting has on encoding
- At level 4.2, 1080p60 encoding has a maximum of 4 reference frames; level 5 maximum is 13 reference frames
I think my question is, what affect should setting MaxNumRefFrames to its maximum @ the level, have on the encoder and its output? And how would that work along-side B-frames and their ability to reference other frames, especially when BReferenceEnable=true?
I appreciate your time and help! Thanks!
I believe I am beginning to wrap my head around how all of this works. After reading over parts of the H264 specifications again, I can see how it relates to the behaviour that I see in the output from AMF.
When using B-frames without B-frame reference enabled:
- Each P-frame will refer to the last P-frame
- Each B-frame will refer to the prior two P-frames
When using B-frames with B-frame reference enabled:
- Each P-frame will refer to the last P-frame
- Each B-frame will refer to the most recent P-frame and the most recent B-frame
I suppose where I'm lost is: Is the decoder only using/keeping two frames in the DPB expected behaviour for the output of the encoded video, regardless of the MaxNumRefFrames setting? I can make the encoder use up to five reference frames by using the various ways of LTR enablement/management, of course, but is it normal to only use two reference frames without LTR, using AMF in its current state?
I suppose my TL;DR: question is:
Is AMF only using two reference frames normal behaviour when using common features (when LTR is disabled)? If so, should users even bother with settings MaxNumRefFrames/HevcMaxNumRefFrames when not using LTR?
The comparison is the QSV H264 hardware encoder that will often have 2-3 frames in the DPB.
I feel that I should have submitted this as a question rather than a bug report; my apologies.