Skip to content

RTSP

Jump to bottom
skrtk98 edited this page Oct 24, 2026 · 1 revision

RTSP（554 番）

接続

  • URL は rtsp://ユーザ:パスワード@<カメラ>:554/streamN。認証は Digest で、カメラアカウントを使う。
  • サーバの名前は SDP の s=Session streamed by "TP-Link RTSP Server"。
  • stream1・stream2・stream8 が使える。stream3 は 404 Stream Not Found。
ストリーム ONVIF のプロファイル 映像 音声
stream1 profile_1 H.264 High 2560×1440、30fps G.711 A-law 8kHz モノラル
stream2 profile_2 H.264 High 640×360、30fps 同上
stream8 profile_3（jpegStream） MJPEG 640×360 同上

SDP

Require: www.onvif.org/ver20/backchannel を付けた DESCRIBE の応答（stream1）：

s=Session streamed by "TP-Link RTSP Server"
m=video 0 RTP/AVP 96
b=AS:4096
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=640032; sprop-parameter-sets=Z2QAMqzSgKAC1oQAAA+kAAOqcBA=,aO4wrIKw
m=audio 0 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=control:track2
  • profile-level-id=640032 は High プロファイルの Level 5.0。
  • backchannel を求めても、トラックは映像と音声（どちらも受信）の2本だけ。カメラへ音声を送るトラックは無い。
  • PLAY の応答の RTP-Info は、どちらのトラックも rtptime=0。
  • ONVIF は音声を 16kHz と答えるが、SDP も中身も 8kHz。

中身の実測

30 秒間受け取って数えた値。

stream1 stream2
ビットレート 2041kbps 219kbps
フレームレート 30.0fps（890 パケット / 30 秒） 30.0fps
キーフレームの間隔 1.99〜2.00 秒（30 秒で 15 枚） 2.00 秒
キーフレームの平均の大きさ 178,686 B 24,063 B
それ以外のフレームの平均 5,578 B 513 B
B フレーム 無い（dts と pts が違うフレームは 0） 無い
  • 音声は 1 パケットが 512 バイト（64ms ぶん）で、毎秒約 15.7 パケット（64kbps）。
  • ffprobe は r_frame_rate を stream1 で 60/1、stream2 で 60000/1001 と出すが、実際は 30fps。
  • 到着の間隔は、映像が中央値 33ms・p95 42〜43ms・p99 56ms・最大 67〜77ms、音声が中央値 64ms・最大 114〜146ms。

stream8（MJPEG）

  • JPEG は JFIF、yuvj422p、1 枚約 48KB。ffprobe の r_frame_rate は 269/12。
  • 5 秒間に届いた 307 枚のうち、別の画像は 5 枚だけだった。同じ画像を送り直してくるので、約 25Mbps（6 秒で 18.8MB）にもなる。
  • Chromium ではこの JPEG が灰色にしか描かれなかった。ライブラリでは使っていない。

同時接続

  • 同時に受けられるのは 3 接続まで。同じストリーム 3 本でも、別々のストリームでも同じ。
  • 4 本めは約 0.2 秒で拒まれる。ffmpeg は Operation not permitted、PyAV は PermissionError になる（RTSP のステータスコードは記録していない）。
  • 6 秒間 -c copy で受けたときの量は、1 本あたり stream1 が 1.53〜1.76MB、stream2 が 0.20〜0.23MB。

音声だけを受けられない

音声のトラックだけを SETUP すると（ffmpeg の -allowed_media_types audio）、何も届かず時間切れになる。 録音するときも、映像ごと受けて捨てる必要がある。

RTCP の時刻の乱れ

RTP のタイムスタンプは正しく進み、パケットも滑らかに届く（12 秒間で RTP の時刻が戻ったのは 0 回）。 問題は、約 0.5 秒ごとに届く RTCP の Sender Report（SR）である。SR が示す NTP 時刻と RTP 時刻の対応が、交互に大きくずれる。

SR ごとのずれ：+0 → −382 → −24 → +360 → −51 → +333 ms …

libav（ffmpeg）は SR に合わせて pts を直すので、pts が 327〜376ms 戻っては 390〜443ms 飛ぶことを毎秒くり返す。

影響：

  • ffmpeg で MP4 に録画すると、16 秒で 24 回、最大 420ms の乱れが映像に出る。音声（AAC）も最大 510ms 乱れる。WAV への録音は影響を受けない。
  • -vn で音声だけ取り出すと Non-monotonic DTS の警告が続く。
  • WebRTC では、ブラウザが映像を毎秒止め（20 秒で 20 回・計 7 秒）、音声の約 43% を補間で埋めた。

対策：

方法 結果
-fflags nobuffer+igndts 直らない
-use_wallclock_as_timestamps 1（届いた時刻を使う） 戻りは 0 回。MP4 の乱れは 12 秒で 1〜5 回、最大 73〜110ms に減った
自前で付け直す（映像は飛びを1つ前の進み幅に置き換え、音声は標本の数で数える） WebRTC で止まり 0 回、補間 0%、30fps（WebRTC でブラウザへ送る）

観察された障害（原因不明）

スピーカーへ送っている途中に、カメラが受信を止めたことが 1 回あった。

  • 約 42 秒ぶんを送ったところで TCP の確認が止まり、同じ時間帯の RTSP の新規接続は 10 秒で時間切れになった。
  • このとき RTSP の 3 枠は、残ってしまった録音用の ffmpeg 2 本と WebRTC で埋まっていた。
  • ping と 4 つのポートの応答は、あとで戻った。
  • 1 回試した再現では起きなかった。原因は分かっていない。

Clone this wiki locally