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

[maomj200811]

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:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. 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.

[scottlamb]

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]

[maomj200811]

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]

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]

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

[maomj200811]

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]

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.