Skip to main content

Debug Logs – RTSP, ONVIF & Playback

This document explains real debug log entries captured from ITVDesk v8.9.1 (Build 7.7.11.2) and helps distinguish normal behavior from actual errors.


1. Application & Environment Header

Example:

ITVDesk App Version: v8.9.1 Build 7.7.11.2 - Win 64bit
Debug Info: CPU: <hash>; RAM: <hash>; BIOS: <hash>; Motherboard: <hash>
ID: 1477b7e8c164f9661df07f0c4995278267393651

Meaning

  • Hardware values are hashed identifiers used for licensing and diagnostics.
  • No raw hardware serial numbers are stored or exposed.
  • ID is the internal runtime instance identifier.

2. RTSP Session Lifecycle (Normal Flow)

Typical RTSP client connection sequence:

OPTIONS
DESCRIBE
SETUP (video)
SETUP (metadata)
PLAY

Example log:

[INFO] new user over tcp from [192.168.68.71:53439]
[DEBUG] OPTIONS rtsp://192.168.68.71:5554/ipc1-stream1/screenlive
[DEBUG] DESCRIBE ...
[DEBUG] SETUP ... realvideo
[DEBUG] SETUP ... metadata
[DEBUG] PLAY ...

Explanation

  • This is a fully valid RTSP handshake.
  • The metadata track is ONVIF metadata (events, analytics, POS overlays).
  • Works with ONVIF-compliant clients, VMS systems, and FFmpeg-based tools.

3. SDP Content (DESCRIBE Response)

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:realvideo

m=application 0 RTP/AVP 98
a=rtpmap:98 vnd.onvif.metadata/90000
a=control:metadata

Explanation

  • Video is standard H.264 RTP.
  • Metadata stream follows ONVIF Profile M / G conventions.
  • Clients not supporting metadata may ignore the second stream.

4. CaptureMode & Encoder Logs

[DEBUG] CaptureMode::HTS - ScreenCapture!
[DEBUG] NativeStream::set FALSE, encoder; screenlive

Meaning

  • Source is desktop/screen capture.
  • Stream is encoded internally (not passthrough).
  • Fully normal for desktop, window, or combined media sources.

5. RTP-Info Header (Playback Accuracy)

RTP-Info:
seq=6335;rtptime=1611159406

Meaning

  • Indicates RTP sequence and timestamp alignment.
  • Important for:
    • Sync accuracy
    • ONVIF replay
    • Timeline-based playback

6. WARNING: rtsp_tcp_rx (NOT an error)

[WARN] rtsp_tcp_rx, ret=0, rcv_dlen=0, err=WSAE-0

Explanation

This is NOT a failure.

It means:

  • Client closed RTSP socket normally
  • VLC / ffplay / VMS ended playback
  • TCP FIN received without error

Action Required?

tip

No. This is expected behavior.


7. RTSP Cleanup & Resource Reuse

rtsp_close_rua
rtsp_media_send_thread, exit
rsua_set_idle_rua

Explanation

  • RTSP session closed cleanly
  • Threads exited correctly
  • Connection slot returned to pool

This confirms no leaks and no crashes.


8. FFplay Integration Logs

FFplayThread::run() -> starting process
ffplay.exe rtsp://admin:admin@192.168.68.71:5554/ipc1-stream1/screenlive

Meaning

  • ITVDesk internally launches ffplay for preview
  • Credentials embedded for quick local testing
  • Process exits normally after playback
Process finished normally, exit code: 0
tip

Expected behavior.


9. ONVIF Discovery (WS-Discovery)

onvif_probe_parse, discovery NetworkVideoTransmitter
onvif_probe_rly

Explanation

  • Device correctly responds to ONVIF Probe
  • Appears in ONVIF Device Manager, VMS, NVRs
  • Multiple replies = multiple virtual cameras

10. ONVIF SOAP Requests – Date & Time

GetSystemDateAndTime (OK)

tds:GetSystemDateAndTime
HTTP/1.1 200 OK
DateTimeType: NTP

✔ Device clock is accessible
✔ Required for ONVIF replay & search


11. ONVIF SOAP – Authorization Errors (Expected)

soap_err_rly, reason : Sender not Authorized
HTTP/1.1 401 Not Authorized

Why this happens

  • Client tries unauthenticated or weak auth request
  • Digest authentication required
  • Very common during ONVIF capability probing

Is this a problem?

tip

No. This is normal ONVIF client behavior.


12. ONVIF Capabilities (Replay Confirmed)

<trp:Replay>
XAddr: http://192.168.68.71:7000/onvif/replay_service
</trp:Replay>

Meaning

  • ONVIF Replay service is enabled
  • Device supports:
    • Recorded playback
    • Time-based RTSP Range requests
    • POS & event-linked playback

13. Media2 vs Media1 Profile Requests

/onvif/media2_service -> Not Authorized
/onvif/media_service -> Not Authorized

Explanation

  • Client probes both Media1 and Media2
  • Auth negotiation in progress
  • Final authenticated request usually succeeds

✔ Normal discovery behavior


14. Summary – What is Normal vs Error

Log TypeStatus
rtsp_tcp_rx WARNNormal
Sender not AuthorizedNormal
ONVIF Probe spamNormal
FFplay exit code 0Normal
RTP-Info presentGood
Threads exit cleanGood

15. When to Report an Issue

Only report a bug if you see:

  • RTSP session stuck (no PLAY response)
  • Repeated crashes
  • Memory growth without cleanup
  • SOAP faults after valid authentication
  • RTP timestamps jumping backward (without replay)

Last updated: 2026-02-04