AMD AMF H.264 applies an unexpected one-frame DTS offset when B-frames are disabled

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

32.2.1

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/oa1b7rwf0bqVY0Kz

OBS Studio Crash Log URL

No response

Expected Behavior

When B-frames are disabled and both B_PIC_PATTERN and MAX_CONSECUTIVE_BPICTURES are 0, OBS should not take the branch that sets dts_offset to b_frames + 1. The dts_offset should remain 0, and the RTMP stream should remain connected to Amazon IVS without triggering B_FRAME_PRESENT.

Current Behavior

When publishing multiple resolutions with OBS Multitrack Video on an AMD GPU system, the configuration returned by IVS GetClientConfiguration selects h264_texture_amf with bf=0. The OBS log also shows b-frames: 0 for every video track. The AMF encoders are initialized successfully, and both the RTMP connection and streaming start successfully. However, shortly after video transmission begins, Amazon IVS reports B_FRAME_PRESENT and terminates the publishing session. OBS then logs WriteN 10054 and Disconnected, followed by repeated reconnection attempts.

Source-code analysis indicates that when retrieval of the AMF B-frame properties succeeds, OBS executes dts_offset = b_frames + 1 even if the retrieved values are 0, which may result in dts_offset being set to 1. This suggests a possible relationship between this timestamp handling and the B_FRAME_PRESENT detection by Amazon IVS. Under the same conditions, changing only the video encoder to obs_x264 allows the stream to remain connected normally.

Steps to Reproduce

1. Run OBS Studio 32.2.1 on Windows 11 25H2 with an AMD Radeon RX 6600.

2. Use an OBS Multitrack Video configuration returned by IVS GetClientConfiguration. The configuration selects h264_texture_amf for three video tracks and sets bf=0.

3. Start publishing through RTMP to an Amazon IVS Real-Time Stage.

4. Confirm in the OBS log that every Multitrack Video encoder reports b-frames: 0. The AMF encoders are initialized successfully, the RTMP connection succeeds, and Streaming Start is logged.

5. Shortly after video transmission begins, observe that Amazon IVS reports B_FRAME_PRESENT and terminates the publishing session.

6. Observe WriteN 10054 and Disconnected in the OBS log, followed by repeated reconnection attempts.

7. Change only the video encoder type from h264_texture_amf to obs_x264 while keeping the same PC, OBS version, RTMP endpoint, stream configuration, resolutions, frame rates, bitrates, and keyframe intervals.

8. Start publishing again and observe that B_FRAME_PRESENT does not occur and the publishing session remains connected.

Anything else we should know?

Environment

• Windows 11 25H2, Build 26200.8875
• OBS Studio 32.2.1
• AMD Radeon RX 6600
• AMD driver 32.0.21045.1000

Source-code analysis suggests that the current AMF AVC path can set dts_offset=1 when bf=0, because it calculates dts_offset = b_frames + 1 after successful property retrieval without checking whether B-frames are enabled.

Relevant code:
https://github.com/obsproject/obs-studio/blob/32.2.1/plugins/obs-ffmpeg/texture-amf.cpp#L1718-L1727

An independent FFmpeg A/B test also showed that PTS=DTS remained connected, while adding an approximately one-frame PTS/DTS offset caused the same IVS ingest path to close the connection.

I have not been able to test a patched OBS build because I do not currently have access to an AMD GPU system and am unable to obtain suitable hardware for testing. I would appreciate any assistance with runtime validation on AMD hardware.

Start in plugins/obs-ffmpeg/texture-amf.cpp around lines 1718-1727 and trace how AMF B-frame properties determine dts_offset. Reproduce the bf=0 Multitrack Video configuration and compare AMF with obs_x264 using the provided OBS log and Amazon IVS endpoint. Done means the zero-B-frame AMF path keeps the expected timestamp relationship and the IVS session remains connected, validated on AMD hardware.