Timestamp issues with OBS / QSV encoder

[kingprawn22]

Which version are you using?

v0.19.2

Which operating system are you using?

• [x] Linux amd64 standard
• [ ] Linux amd64 Docker
• [ ] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm7 Docker
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

Describe the issue

I run a platform that has multiple streamers connecting to the streaming server in order for a central OBS to schedule them. In order to standardise the setup for all streamers, I'm looking to make a guide, sent to each streamer, on how to configure OBS on their side.

At the moment, using the 'auto-configuration wizard' seems to work for the majority of streamers, but there is one that has the error "(DTS is greater than PTS)" when they stream. This streamer connects via Windows 10 (as do all the other streamers), although they use 'QSV' encoder instead of 'x264' or the nVidia / AMD alternatives. From their side, it looks as if the stream is working (connected, no frame drops), but on the side that accepts the incoming stream, the stream starts for a split second then dies. This is also the case when playing the stream via other software on other machines (such as VLC's 'network stream').

If they switch from the 'QSV' encoder to 'x264', the stream works as it should. For this user, x264 results is much higher resource usage for much lower quality, and is untenable for their environment. If they stick with QSV and change the Output Mode from Simple to Advanced, then manually change the 'b-frames' value to 0 instead of the default (1 or 2 afaik), then the stream works.

All in all, I'm just trying to figure out why the default QSV encoder settings don't work, and if I need to alter my streamer documentation for those that use this encoder. Is it a bug, or is this just how it works with QSV?

Describe how to replicate the issue

1. start the server
2. publish a stream with OBS from an external machine ('alex' in this case), using the settings automatically configured after using the 'auto-configuration wizard' (QSV is the encoder).
3. read with a centralised OBS server (or any other software able to read the RTMP stream on any other machine)
4. stream appears to play for a split second before dying
5. check logs and see the below - closed (DTS is greater than PTS)

Did you attach the server logs?

yes (below)

Jul 18 11:04:31 [hostname] systemd[1]: Started rtsp-simple-server.service.
Jul 18 11:04:31 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:31 INF rtsp-simple-server v0.19.2
Jul 18 11:04:31 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:31 DEB path manager created
Jul 18 11:04:31 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:31 INF [RTMP] listener opened on :1935
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 INF [RTMP] [conn 192.168.178.3:58249] opened
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 DEB [path alex] created
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 INF [RTMP] [conn 192.168.178.3:58249] is publishing to path 'alex', 2 tracks
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 INF [path alex] runOnReady command started
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 INF [RTMP] [conn 127.0.0.1:59812] opened
Jul 18 11:04:37 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:37 INF [RTMP] [conn 127.0.0.1:59812] is reading from path 'alex'
Jul 18 11:04:40 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:40 INF [RTMP] [conn 127.0.0.1:59812] closed (DTS is greater than PTS)
Jul 18 11:04:40 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:04:40 INF [path alex] runOnReady command exited with code 0
Jul 18 11:05:41 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:05:41 INF [path alex] runOnReady command stopped
Jul 18 11:05:41 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:05:41 DEB [path alex] destroyed (not in use)
Jul 18 11:05:41 [hostname] rtsp-simple-server[181260]: 2022/07/18 11:05:41 INF [RTMP] [conn 192.168.178.3:58249] closed (EOF)

Did you attach a network dump?

no (not sure if the network matters here, considering all other streamers don't have this problem)

[aler9]

Hello, H264 streams generated with the QSV encoder declare into their SDP that there are 2 reordered frames at maximum:

max_num_reorder_frames = 2

But there seems to be at least 3 frames, i.e. frames are received in this order (the first number is PTS, the number in parenthesis is DTS):

2 (-1 = 1 - max_num_reorder_frames = 1 - 2)
3 (0
4 (1)
1 (2)

Consequently DTS > PTS since the server can't compute the initial delay to apply to the stream before starting decoding (that is equal to max_num_reorder_frames). Since increasing max_num_reorder_frames increases latency, at the moment i can't touch it and i don't have a solution for this issue.

[kingprawn22]

Hi @aler9,

Thanks for the information. No problem if there's no solution - I'll just create a section of documentation that adds the correct configuration for those that use QSV. Thanks for your help.

[aler9]

Maybe a solution will be found, at the moment my knowledge is limited to the algorithm i explained above :)