my camera main stream and sub stream record video storage size is zero #300

maomj200811 · 2024-01-09T06:22:27Z

Describe the bug
A clear and concise description of the problem.

my flush_is_second is config 120 s.

my nvr config is following;

and my ui is show the folowing. the video length is 0 seconds.

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Server (please complete the following information):

moonfire-nvr --version
is newest version 0.7.12
Attach a log file. Run with the RUST_BACKTRACE=1 environment variable set if possible.

Camera (please complete the following information):

Camera manufacturer and model: [e.g. Reolink RLC-410]
Firmware version: [e.g. V2.0.0.1215_16091800]

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

The text was updated successfully, but these errors were encountered:

scottlamb · 2024-01-09T17:09:48Z

When you see an infinite fps and bitrate on the UI, that suggests an RTSP connection received only a single frame before failing. Moonfire calculates duration of frames from the differences in frames' timestamps. The final frame ends up with a duration of 0. So if the connection fails between the first and second frames, it stores a total duration of 0 => infinite fps and bitrate.

The reason this happened should be in the logs.

maomj200811 · 2024-01-10T01:14:53Z

maomj200811 · 2024-01-10T01:49:44Z

2024-01-10T01:48:23.776244 INFO s-mycamera-main streamer{stream="mycamera-main"}: moonfire_nvr::cmds::run: starting
2024-01-10T01:48:23.776376 INFO main moonfire_nvr::cmds::run: no LISTEN_FDs
2024-01-10T01:48:23.776443 INFO s-mycamera-main streamer{stream="mycamera-main"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.1.101/live/test
2024-01-10T01:48:23.776454 INFO s-mycamera-sub streamer{stream="mycamera-sub"}: moonfire_nvr::cmds::run: starting
2024-01-10T01:48:23.776677 INFO s-mycamera-sub streamer{stream="mycamera-sub"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.1.101/live/test
2024-01-10T01:48:23.786416 WARN tokio-runtime-worker streamer{stream="mycamera-main"}: retina::client::parse: DESCRIBE response at rtsp://192.168.1.101/live/test has no content type; trying sdp anyway
2024-01-10T01:48:23.787306 WARN tokio-runtime-worker streamer{stream="mycamera-sub"}: retina::client::parse: DESCRIBE response at rtsp://192.168.1.101/live/test has no content type; trying sdp anyway
2024-01-10T01:48:23.790138 WARN tokio-runtime-worker streamer{stream="mycamera-main"}: retina::client: Connecting via TCP to known-broken RTSP server "libavformat 58.25.100". See scottlamb/retina#17. Consider using UDP instead!
2024-01-10T01:48:23.791044 WARN tokio-runtime-worker streamer{stream="mycamera-sub"}: retina::client: Connecting via TCP to known-broken RTSP server "libavformat 58.25.100". See scottlamb/retina#17. Consider using UDP instead!
2024-01-10T01:48:23.797965 WARN tokio-runtime-worker streamer{stream="mycamera-main"}: retina::client: saw unexpected RTSP packet. This is presumed to be due to a bug in old
live555 servers' TCP handling, though tool attribute Some("libavformat 58.25.100") does not refer to a known-buggy version. Consider switching to UDP.

conn: ConnectionContext { local_addr: 192.168.1.105:47728, peer_addr: 192.168.1.101:554, established_wall: WallTime(Timespec { sec: 1704851303, nsec: 780058874 }) }
channel: 0
msg: RtspMessageContext { pos: 16187, received_wall: WallTime(Timespec { sec: 1704851303, nsec: 797935112 }), received: Instant { tv_sec: 2713, tv_nsec: 479066307 } }
2024-01-10T01:48:23.798177 INFO main moonfire_nvr::cmds::run: Ready to serve HTTP requests
2024-01-10T01:48:23.798686 WARN s-mycamera-main streamer{stream="mycamera-main"}: moonfire_nvr::streamer: sleeping for 1 s after error err=UNKNOWN
caused by: wrong ssrc after 11 RTP pkts + 0 RTCP pkts; expecting ssrc=Some(Ssrc { init: RtpPacket, ssrc: 0x3fc5372e }) seq=Some(Seq { init: RtpPacket, next: 3470 })

conn: 192.168.1.105:47728(me)->192.168.1.101:554@2024-01-10T01:48:23
stream: TCP, interleaved channel ids 0-1
ssrc: e94875e6
seq: 6
pkt: 16187@2024-01-10T01:48:23
2024-01-10T01:48:23.799596 WARN tokio-runtime-worker streamer{stream="mycamera-sub"}: retina::client: saw unexpected RTSP packet. This is presumed to be due to a bug in old
live555 servers' TCP handling, though tool attribute Some("libavformat 58.25.100") does not refer to a known-buggy version. Consider switching to UDP.

conn: ConnectionContext { local_addr: 192.168.1.105:47726, peer_addr: 192.168.1.101:554, established_wall: WallTime(Timespec { sec: 1704851303, nsec: 780096500 }) }
channel: 0
msg: RtspMessageContext { pos: 16187, received_wall: WallTime(Timespec { sec: 1704851303, nsec: 799562345 }), received: Instant { tv_sec: 2713, tv_nsec: 480693540 } }
2024-01-10T01:48:23.800191 WARN s-mycamera-sub streamer{stream="mycamera-sub"}: moonfire_nvr::streamer: sleeping for 1 s after error err=UNKNOWN
caused by: wrong ssrc after 11 RTP pkts + 0 RTCP pkts; expecting ssrc=Some(Ssrc { init: RtpPacket, ssrc: 0x3fc5372e }) seq=Some(Seq { init: RtpPacket, next: 3470 })

conn: 192.168.1.105:47726(me)->192.168.1.101:554@2024-01-10T01:48:23
stream: TCP, interleaved channel ids 0-1
ssrc: e94875e6
seq: 6

scottlamb · 2024-01-10T17:53:33Z

What server are you using? "libavformat 58.25.100?" seems to match up to ffmpeg git revisions d06aae732c16bd4c490c6dfa35cc2a35129c640f..268d1466498b0f404719b21f3b78802820b6881b, but those don't have a built-in rtsp server afaict. (ffserver was deleted a while before then.) In #298, you said "video source is published using ffmpeg"; can you be more specific?

I'm also a little confused that the screenshot and the later log comment describe different errors; did you change something between the two?

maomj200811 · 2024-01-11T04:36:11Z

I using ffmpeg + EasyDarwin , ffmpeg for push stream, and EasyDarwin for stream media service.

maomj200811 · 2024-01-13T02:36:53Z

I using vlc publish video streaming,but moonfire-nvr config test failed. I selected udp transport ,error message is
UNKNOWN: couldn't find H.264 parameters,
but ffmpeg tool pull stream is ok using udp method

scottlamb · 2024-04-18T13:22:27Z

I using vlc publish video streaming,but moonfire-nvr config test failed. I selected udp transport ,error message is UNKNOWN: couldn't find H.264 parameters, but ffmpeg tool pull stream is ok using udp method

I could likely fix this you'd be willing to send me a couple packet captures (e.g. via wireshark): one with Moonfire, one with some other client that's working successfully (e.g. the "ffmpeg tool pull stream"), and/or give me precise instructions to replace your vlc/ffmpeg(?) + EasyDarwin setup.

Tuhinpaul5 · 2024-07-03T12:36:51Z

When you see an infinite fps and bitrate on the UI, that suggests an RTSP connection received only a single frame before failing. Moonfire calculates duration of frames from the differences in frames' timestamps. The final frame ends up with a duration of 0. So if the connection fails between the first and second frames, it stores a total duration of 0 => infinite fps and bitrate.

The reason this happened should be in the logs.

I am having the same problem :

sleeping for 1 s after error err=INVALID_ARGUMENT: pts not monotonically increasing; got 0 then 0
2024-07-03T18:06:27.813014  INFO          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.0.166:554/stream1
2024-07-03T18:06:27.928474  WARN          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: sleeping for 1 s after error err=INVALID_ARGUMENT: pts not monotonically increasing; got 0 then 0
2024-07-03T18:06:28.928704  INFO          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.0.166:554/stream1
2024-07-03T18:06:29.088147  WARN          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: sleeping for 1 s after error err=INVALID_ARGUMENT: pts not monotonically increasing; got 0 then 0
2024-07-03T18:06:30.088365  INFO          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.0.166:554/stream1
2024-07-03T18:06:30.263218  WARN          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: sleeping for 1 s after error err=INVALID_ARGUMENT: pts not monotonically increasing; got 0 then 0
2024-07-03T18:06:31.263394  INFO          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: opening input url=rtsp://192.168.0.166:554/stream1
2024-07-03T18:06:31.433954  WARN          s-cam1-main streamer{stream="cam1-main"}: moonfire_nvr::streamer: sleeping for 1 s after error err=INVALID_ARGUMENT: pts not monotonically increasing; got 0 then 0

scottlamb · 2024-07-06T18:35:42Z

@Tuhinpaul5 I've never seen that one before, but it suggests your camera is sending multiple frames without advancing the timestamp at all. Could you open a new issue with details of your camera? If you're able to, it'd also really help to get a packet capture (e.g. with Wireshark) of the communication with your camera: with Moonfire, and/or with some other software that is successfully getting video.

scottlamb · 2024-07-06T18:36:19Z

Oh, I see you did open #322 . I'll reply there.

scottlamb mentioned this issue Jan 9, 2024

stream test failed #298

Closed

scottlamb added the need-input Need input, usually from the issue reporter, to proceed label Apr 18, 2024

scottlamb mentioned this issue Apr 18, 2024

why my saved video length 15s only, flush_if_second is config 120s or more time #301

Closed

scottlamb closed this as completed Jun 1, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

my camera main stream and sub stream record video storage size is zero #300

my camera main stream and sub stream record video storage size is zero #300

maomj200811 commented Jan 9, 2024

scottlamb commented Jan 9, 2024

maomj200811 commented Jan 10, 2024

maomj200811 commented Jan 10, 2024

scottlamb commented Jan 10, 2024

maomj200811 commented Jan 11, 2024

maomj200811 commented Jan 13, 2024

scottlamb commented Apr 18, 2024 •

edited

Loading

Tuhinpaul5 commented Jul 3, 2024

scottlamb commented Jul 6, 2024

scottlamb commented Jul 6, 2024

my camera main stream and sub stream record video storage size is zero #300

my camera main stream and sub stream record video storage size is zero #300

Comments

maomj200811 commented Jan 9, 2024

scottlamb commented Jan 9, 2024

maomj200811 commented Jan 10, 2024

maomj200811 commented Jan 10, 2024

scottlamb commented Jan 10, 2024

maomj200811 commented Jan 11, 2024

maomj200811 commented Jan 13, 2024

scottlamb commented Apr 18, 2024 • edited Loading

Tuhinpaul5 commented Jul 3, 2024

scottlamb commented Jul 6, 2024

scottlamb commented Jul 6, 2024

scottlamb commented Apr 18, 2024 •

edited

Loading