feat: improve RTMP control message compatibility with non-standard cameras

[hyesung913]

Problem

MediaMTX strictly enforces RTMP specification requiring control messages to use Chunk Stream ID 2, causing connection failures with many IP cameras and PTZ cameras that use non-standard implementations.

Solution

• Added flexible isControlChunkStreamID() validation function
• Support common non-standard Chunk Stream IDs (2, 3, 4, 5, 6) used by various camera manufacturers
• Maintain full backward compatibility with standard RTMP clients
• Centralized compatibility management for easy extension

Changes

• Core: Added isControlChunkStreamID() helper function in message.go
• Control Messages: Updated all control message validation logic
• Compatibility: Support Chunk Stream IDs 2, 3, 4, 5, 6
• Error Messages: Improved error reporting with specific Chunk Stream ID values

Benefits

• PTZ cameras (Chunk Stream ID 4) now work
• Various IP cameras (3, 5, 6) now supported
• nginx-rtmp level compatibility achieved
• Zero impact on existing functionality
• Easy to extend for future camera types

Background

This issue was discovered when PTZ cameras failed to connect with "unexpected chunk stream ID" errors. Investigation showed that while RTMP spec defines Chunk Stream ID 2 for control messages, many real-world camera implementations use different IDs (3, 4, 5, 6). nginx-rtmp handles this gracefully, and this PR brings MediaMTX to the same level of practical compatibility.

Fixes connection issues with cameras that send control messages on non-standard chunk stream IDs while maintaining strict RTMP compliance for standard clients.

[aler9]

Hello, can you write the manufacturer and model of the camera that require this change?

Furthermore, can you provide tests or alternatively a network dump of packets exchanged between camera and server so we can generate tests?

[hyesung913]

Hello, can you write the manufacturer and model of the camera that require this change?

Furthermore, can you provide tests or alternatively a network dump of packets exchanged between camera and server so we can generate tests?

The PTZ camera I used is:

Manufacturer: Ever Information

Model: 330UI

Link: Product page

At the moment, I don’t have access to this camera, so I cannot capture a new packet dump myself.
However, there is an existing issue(#4807 ) describing the same problem, and that report already includes a packet dump. The attached screenshot is taken from that dump.

In the dump, the Set Chunk Size command is sent as a control message. According to the RTMP specification, it should use Chunk Stream ID 2, but this camera sends it on ID 4 instead.

It seems that some PTZ cameras do not fully comply with the standard. Both ffmpeg and nginx-rtmp are tolerant of this behavior and handle it gracefully.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.29%. Comparing base (15e2713) to head (371c795).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4909      +/-   ##
==========================================
+ Coverage   55.20%   55.29%   +0.08%     
==========================================
  Files         216      216              
  Lines       22823    22790      -33     
==========================================
+ Hits        12600    12602       +2     
+ Misses       9276     9250      -26     
+ Partials      947      938       -9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aler9]

i removed the check entirely, added tests and merged, thanks!

[github-actions]

This issue is mentioned in release v1.15.0 🚀
Check out the entire changelog by clicking here