RTCP Sender Reports not received from upstream source with useAbsoluteTimestamp enabled

[hirsch-alter]

Which version are you using?

v1.15.6

Which operating system are you using?

Linux amd64 Docker

Describe the issue

When useAbsoluteTimestamp: true is configured in pathDefaults, MediaMTX never receives RTCP Sender Reports from the upstream RTSP camera, causing all RTP packets to be dropped with the warning: received RTP packet without absolute time, skipping it

This results in downstream consumers receiving no video frames at all.

Important: The camera DOES send RTCP Sender Reports. When connecting directly to the same camera using aiortsp (Python RTSP library), RTCP SRs are received correctly and timestamps are extracted. The issue only occurs when MediaMTX is in the middle as a proxy.

Describe how to replicate the issue

1. Configure MediaMTX with useAbsoluteTimestamp: yes in pathDefaults
2. Create a path that proxies to an RTSP camera via the API:

   curl -X POST "http://localhost:9997/v3/config/paths/add/test_camera" \
     -H "Content-Type: application/json" \
     -d '{"source": "rtsp://user:pass@camera-ip:554/stream", "sourceOnDemand": true, "rtspTransport": "tcp"}'

3. Connect a consumer to rtsp://localhost:8554/test_camera
4. Observe MediaMTX logs showing endless warnings:
   received RTP packet without absolute time, skipping it
5. No frames are ever delivered to the consumer

MediaMTX configuration

logLevel: info
logDestinations: [stdout]

# Timeouts for read/write operations
readTimeout: 30s
writeTimeout: 30s

###############################################
# Authentication - allow API access from internal network
###############################################

authMethod: internal
authInternalUsers:
  - user: any
    ips: []  # Empty allows all IPs
    permissions:
      - action: api
      - action: metrics
      - action: read
      - action: publish

###############################################
# RTSP server settings
###############################################

rtsp: yes
rtspAddress: :8554

###############################################
# API settings for dynamic path management
###############################################

api: yes
apiAddress: :9997

###############################################
# Metrics for Prometheus
###############################################

metrics: yes
metricsAddress: :9998

###############################################
# Path configuration
###############################################

# Default settings for all paths (including dynamically created ones)
pathDefaults:
  # Preserve camera's original RTCP SR timestamps instead of replacing with server time
  # This allows downstream consumers to get accurate camera timestamps for synchronization
  useAbsoluteTimestamp: yes

MediaMTX logs

With logLevel: info, the following warning repeats continuously once a consumer connects:

INF [RTSP] [conn ...] opened
INF [path test_camera] [RTSP source] started
WRN [path test_camera] received RTP packet without absolute time, skipping it
WRN [path test_camera] received RTP packet without absolute time, skipping it
WRN [path test_camera] received RTP packet without absolute time, skipping it

... (repeats indefinitely, no RTCP SR ever received)

The stream never becomes "ready" because no frames pass through. The path status via API shows:

{
  "ready": false,
  "readyTime": null,
  "tracks": []
}

Network dump

mediamtx_rtcp_bug.zip

[aler9]

Hello, thanks for providing the network dump. The RTCP packets that your camera is producing are not being decoded because they are malformed.

The camera is producing a sequence of RTCP sender reports and RTCP source descriptions:

RTCP source descriptions must end with a 0x00, but they do not, therefore this return is not triggered:

https://github.com/pion/rtcp/blob/460290bdc42c2b5fdb9dc2cc920f31e4932b9d75/source_description.go#L250

while this error is triggered:

https://github.com/pion/rtcp/blob/460290bdc42c2b5fdb9dc2cc920f31e4932b9d75/source_description.go#L262

If you provide the manufacturer and model of the camera we can evaluate whether we can improve the parser to support it.

[hirsch-alter]

Hi @aler9 ,

Thank you for addressing this. The manufacturer is Hanwha, and the model is QNV-8080R

I should also note that when I connect directly to the camera, I can understand the RTCP packet, even if the camera might not comply with the standard completely.

[aler9]

fixed by bluenviron/gortsplib#1099