Skip to content

Structural limitation for multi-streaming, metadata race condition, and ffmpeg option incompatibility #93

@hyuyeon

Description

@hyuyeon

While using node-rtsp-stream, I discovered three issues related to multi-streaming, metadata timing, and ffmpeg option compatibility. I am sharing the findings along with possible improvement directions.

1) Issue 1 — Structural limitation: one WebSocket server per RTSP stream

Problem
To relay multiple RTSP streams, users must create as many VideoStream instances as the number of streams.
Each instance launches its own WebSocket server on a unique port.
→ This leads to a 1:1 mapping between RTSP stream and WebSocket port, meaning N RTSP sources require N running WebSocket servers.
Cause
The current VideoStream architecture couples RTSP processing and WebSocket output into one unit.
Suggested Improvement
Introduce an upper-level HTTP server + WebSocket server
WebSocket path (/cam01, /cam02) becomes a unique stream identifier
If a stream already exists, simply attach the new ws client
If no clients remain, gracefully kill FFmpeg and remove the stream
Make RTSP URL resolution configurable via callbackGetRtspUrl, allowing DB lookup, static mapping, etc.
In the current design, the VideoStream class is responsible for both: Handling the RTSP input and decoding (FFmpeg → MPEG1), and Managing the WebSocket server and client broadcasting.
Separate responsibilities of VideoStream into two classes:
RtspMpegSource (RTSP → MPEG1 decoder)
MultiStreamServer (network & WebSocket multiplexing layer)

2) Issue 2 — Metadata (width/height) may not arrive before WebSocket header is sent

Problem
If FFmpeg outputs metadata late, the WebSocket header may be sent while width/height are still null.
Cause
Header sending is triggered immediately on socket connection with no metadata readiness check.
Suggested Improvement
Send the header only after metaDataReady
Queue wsClients until metadata becomes available
Once metadata is ready, push initial header to all pending clients

3) Issue 3 — jsmpeg shows corrupted / colorful artifacts

Problem
When using the jsmpeg player on the client side, the video appears corrupted.
Cause
Mpeg1Muxer enforces fixed ffmpeg defaults:
-f mpegts
-codec:v mpeg1video
jsmpeg cannot decode this combination correctly.
Suggested Improvement
Allow ffmpeg options (-f, -codec:v) to be overridden by user
Provide compatibility guidance:
JSMpeg requires: -f mpegts -codec:v mpeg1video
jsmpeg requires removing these options

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions