Cache H264/H265 GOPs in order to allow readers to decode frames immediately

[jean343]

GOP Cache

This PR introduces Group of Pictures (GOP) caching to MediaMTX, enhancing its performance and reducing latency in streaming scenarios. By caching the last GOP for each stream, new subscribers can immediately receive the latest video data without waiting for the next keyframe, improving the user experience, especially for streams with long keyframe intervals.

This works for both H264 and H265, as well as for RTSP and WebRTC.

Configurable Cache Settings:

Introduced a new configuration parameter gopCache in mediamtx.yml for enabling/disabling GOP caching.

Fix: #1209

[aler9]

This is a great work. The important thing is that you can confirm that the feature works and in which scenarios (protocols, codecs, with/without B-frames).
We can then adjust details, the ones that come into my mind are:

• check on the GOP size to prevent RAM exhaustion
• additional codecs, at least AV1

[jean343]

Thanks @aler9 for your kind comment!

The feature does work in the following scenarios:

Protocol:

• WebRTC
• RTSP

Codecs:

• H.264
• H.265

I have only tried videos without b-frames as WebRTC does not support b-frames. There might be adjustments to make when dealing with b-frames over RTSP.

In order to reduce RAM exhaustion, we do not cache anything until we get a key frame, this will prevent unsupported codecs from storing anything, and will save a little bit for supported codecs.
In case the GOP is really long, we trim at 512 packets, conserving memory. In this case, clients will need to wait until the next key frame before video playback.

As per additional codecs, I could not find a reliable way to detect their keyframes.

In the WebRTC playback scenario, the PTS and Timestamp needs to be modified to prevent gaps. WebRTC will pause and stop playback if set incorrectly.

For example, incorrect Timestamp will look like:

Untitled.mov

Correct timestamp will look like:

Screen.Recording.2025-01-23.at.1.40.16.PM.mov