bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
10.71k stars 1.4k forks source link

WAR [path (camera name)] Type 65 is not supported when saving rtsp stream from IP cam #3162

Open compilebunny opened 3 months ago

compilebunny commented 3 months ago

Which version are you using?

v0.0.0 - compiled from github source March 23, 2024

Which operating system are you using?

Describe the issue

I have a low-quality ONVIF compatible IP camera that I want to capture and save an RTSP stream from. The config file includes:

  # Record streams to disk.
  record: yes
  # Enable serving recordings with the playback server.
  playback: no
  # Path of recording segments.
  # Extension is added automatically.
  # Available variables are %path (path name), %Y %m %d %H %M %S %f %s (time in strftime format)
  recordPath: /save-directory/%path/%Y-%m-%d_%H-%M-%S-%f
  # Format of recorded segments.
  # Available formats are "fmp4" (fragmented MP4) and "mpegts" (MPEG-TS).
  recordFormat: fmp4

Unfortunately, mediamtx produces the following error at runtime: WAR [path (camera name)] Type 65 is not supported

In contrast, I can use ffmpeg to save the stream without processing it ffmpeg -i "rtsp://login:password@camera-ip-address/stream" -acodec copy -vcodec copy ~/rawcopy.mp4

I can then play the saved file using mplayer. In addition to video, mplayer generates the following messages:

libavformat version 58.76.100 (external)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f8d97c6f8e0]Protocol name not provided, cannot determine if input is local or a network protocol, buffers and access patterns cannot be configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
VIDEO:  [H264]  1920x1080  24bpp  15.000 fps  5465.4 kbps (667.2 kbyte/s)
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
[vdpau] Error when calling vdp_device_create_x11: 1
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.134.100 (external)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
 major_brand: isom
 minor_version: 512
 compatible_brands: isomiso2avc1mp41
 title: RTSP Session/2.0
 encoder: Lavf60.3.100

I also tried using

  # Available formats are "fmp4" (fragmented MP4) and "mpegts" (MPEG-TS).
  recordFormat: mpegts

in mediamtx.yml, but this leads to zero tracks being recorded.

Mar 23 22:13:08 cammy mediamtx[PID]: 2024/03/23 22:13:08 INF [path camera-name] [record] recording 0 tracks ()
Mar 23 22:13:08 cammy mediamtx[PID]: 2024/03/23 22:13:08 INF [path camera-name] [RTSP source] ready: 1 track (M-JPEG)
Mar 23 22:13:08 cammy mediamtx[PID]: 2024/03/23 22:13:08 INF [path camera-name] [record] recording 0 tracks ()
Mar 23 22:13:08 cammy mediamtx[PID]: 2024/03/23 22:13:08 INF [path camera-name] [RTSP source] ready: 1 track (M-JPEG)

This issue may be related to a question that another user posted:

Describe how to replicate the issue

You would probably need the same camera to replicate the issue directly.

Did you attach the server logs?

no

Did you attach a network dump?

no

aler9 commented 1 month ago

Hello, this can be probably fixed but you need to provide a network dump of traffic exchanged between the camera and the server, from the moment the server starts to the moment in which the error appears. Otherwise nothing can be done about it. From instructions:

If the bug arises when using MediaMTX with an external hardware or software, the most helpful content you can provide is a dump of the data exchanged between the server and the target (network dump), that can be generated in this way: 1) Download wireshark (https://www.wireshark.org/) 2) Start capturing on the interface used for exchanging packets (if the server and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card) 3) Start the server and replicate the issue 4) Stop capturing, save the result in .pcap format 5) Attach