-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to parse stream 0: bad clockrate in rtpmap #213
Comments
Since ~April 2021, I switched from ffmpeg to my own pure-Rust RTSP library, Retina. See #37. [Edit: oh, I missed your last paragraph. I see now you already knew that!] I'm happy I made the switch, but we're still going through some growing pains with Retina bugs and camera incompatibilities. In this case, your camera's |
Another small thing I'd like to change: the error message here: In hindsight, I don't like that it gives the If you don't mind, I might bug you later to run a (to-be-written) Retina command to grab the actual SDP bytes for that unit test. |
I'd be glad to help however I can |
$ git clone https://github.com/scottlamb/retina.git
$ cd retina
$ cargo run --example client -- info --print-sdp --url 'URL' --username 'USER' --password 'PASS' |
Cams 1, 2, and 3:
Cam 4:
Cam 5:
|
Just confirmed that my setup works without any issues on moonfire 0.6.3. |
If you pull the latest retina, does |
It does for cams 1, 2, 3, and 4. Cam 5 throws the following error:
|
Huh. I wonder if it's sending audio on the channel (even though it wasn't requested) or what. Does that error happen if it's been at least a couple minutes since anything has talked to the camera? Some live555-based cameras have a problem where they keep sending data for stale sessions on a particular file descriptor after it's been closed. If the fd reassigned to another connection, they just send the old session's data on the new connection. Their sessions time out after about 65 seconds. Do you mind sharing a couple packet captures—one with Retina failing, one with ffmpeg succeeding? ffmpeg should run with a command like this: $ ffmpeg -y -fflags nobuffer -rtsp_transport tcp -allowed_media_types video -t 5 -i 'rtsp://user:pass@...' -c copy ffmpeg.mp4 and I typically just grab packet captures with tcpdump in another terminal: $ sudo tcpdump -Uw blah.pcap -ni INTERFACE 'ip host 192.168.1.71'
...
^C when done If you don't want to share your MACs, camera credentials, etc. with the world, you can send it to me via email (attachment, download link, whatever) rather than on the public issue tracker. |
Sent it to your email |
Thank you. From looking at that, it looks like the stuff on RTSP interleaved channel 2 (e.g. packet 288 in So the question is: what should we do about it? I'm not sure, but I have a couple ideas:
|
This seems like the more robust approach. With the countless amount of RTSP implementations out there, I feel like this won't be the last time we'll see random packets on unassigned channels. Ignoring it seems like the safest bet to support as much hardware as possible in the future. |
It's still surprising to me how shoddy these RTSP implementations seem to be. In contrast, even in the cheapest devices, the HTTP implementations are basically fine. |
If you I'll likely make a Moonfire release with this change (and a few other things) next week. |
Seems like it worked. Thanks! Looking forward to the next release. |
For the most part it seems to be working, though after a few minutes (or even seconds, it's inconsistent) I get the following error. Seems like an issue parsing a keyframe since I only get it after a large byte video frame.
|
Thanks. I'll decode those |
I filed a fresh issue on that, #217. |
Describe the bug
No video is being written and no live view available. 0 bytes used as reported in
nvr-config
./media/nvr/sample
is also empty other than themeta
file. Logs shows hundreds of instances ofUnable to parse stream 0: bad clockrate in rtpmap
followed by a stacktraceThis is a regression since this setup with these cameras were previously working flawlessly 1 month ago. It was using an earlier release of moonfire (docker ~April 2021).
To Reproduce
Steps to reproduce the behavior:
nvr start
Expected behavior
At least some bytes should be written to indicate that moonfire is ingesting the stream.
Server (please complete the following information):
docker ps
docker images
Camera (please complete the following information):
Manufacturer, Model, Firmware (according to the camera lol):
They're just cheap onvif cams from aliexpress and thrift stores (dw, they're airgapped)
Desktop (please complete the following information):
Additional context
My hard drive recently failed and the root partition was located on the drive so I had to reinstall. If I were to guess, the regression is from dropping ffmpeg. I'll try the last release that used ffmpeg and report back here, though that'll probably have to wait till next week.
The text was updated successfully, but these errors were encountered: