Subscriber Discussion

RTSP Camera URL - Public And Free For Testing

KJ
Kenny Johnson
Aug 03, 2018

[UPDATE IPVM has made one of its test cameras publicly and freely available

URL:

rtsp://demo:demo@ipvmdemo.dyndns.org:5541/onvif-media/media.amp?profile=profile_1_h264&sessiontimeout=60&streamtype=unicast

Below is a screenshot sample of the FoV with license plates, chart, and live clock:

IPVM Image

Original Post:

anyone know of a public rtsp url from an ip camera i can use to test some software?

it needs to be something other than dahua or uniview.

i have searched but it is mostly dead links out there.

thanks

(1)
PS
Paul Shah
Aug 03, 2018
(1)
(2)
(1)
JP
John Poole
Jun 12, 2020

The problem with this is that it is a file, an mp4 format, that is being streamed. It may be that the decoding time stamp (DTS) and presentation time stamp (PTS) (see tutorial) do not reflect real-time disparities that might arise when streaming a file. vs. a camera's streaming feed of h264 encoded bytes. While helpful, I'd like to have a real-time camera to test against.

For example, when running ffmpeg against my Reolink camera, I occasionally get:

[h264 @ 0x556acd1b4c80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [null @ 0x556acd1922c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1770 >= 1770 [h264 @ 0x556acd260c80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd27d500] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [null @ 0x556acd1922c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1773 >= 1773 [h264 @ 0x556acd299cc0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd2b6480] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd2d2c40] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [null @ 0x556acd1922c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1776 >= 1776 [h264 @ 0x556acd1acf80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd1e4340] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd1be400] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [null @ 0x556acd1922c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1779 >= 1779 [h264 @ 0x556acd1b4c80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 frame= 1518 fps= 26 q=-0.0 size=N/A time=00:00:59.64 bitrate=N/A speed=1.04x [h264 @ 0x556acd260c80] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd27d500] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd299cc0] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [null @ 0x556acd1922c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1782 >= 1782 [h264 @ 0x556acd2b6480] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1 [h264 @ 0x556acd2d2c40] nal_unit_type: 1(Coded slice of a non-IDR picture), nal_ref_idc: 1

I tried running against the Bunny URL above and there were no such "monotonic" errors. Having a real live camera providing an RTSP stream will help isolate where the problem may be arising.

While one might jump to the conclusion that the problem is arising from Reolink's server (which I believe uses LIVE555 Streaming Media v2013.04.08), I have it on the authority of Scott Lamb, a Google engineer who has demonstrated expertise in streaming video that the problem actually lies in FFmpeg's code. See poor behavior when camera has audio enabled · Issue #36 · scottlamb/moonfire-nvr · GitHub

Avatar
Ethan Ace
Aug 03, 2018

Does it need to be looking at anything specific? We have some cameras on an open network for testing we could supply RTSP for, but it's just looking at a clock/wall (yes we know the date/time are wrong... power outages from storms the past couple days).

(1)
(2)
(2)
KJ
Kenny Johnson
Mar 04, 2021

Hello, I know it's been a while but... do you still have an rtsp url available for testing?

I need to test our software again.

All the cameras I have access to are Dahua and I need to test some different model camera.

Thanks!

JP
John Poole
Jun 12, 2020

I would very much like to have a public facing RTSP stream to test with that will available for an extended time period, e.g. months. I am preparing a bug report for the FFmpeg project in what we believe is a very low level timing bug on handling RTSP streams. Specifically, the error message:

 Application provided invalid, non monotonically increasing dts to muxer in stream 0: 311 >= 311

We think there is a bug in its demuxer.

I want to be able to run ffmpeg against a publicly available RTSP stream so that the developers in the FFmpeg project can duplicate the results from the same source and not suggest that the problem is with the streaming source.

Your video of a camera clock is a great idea... it would be nice if the time is relatively close, e.g. within minutes to actual time.

I hope your offer is still good.

Thank you.

Avatar
Ethan Ace
Jun 12, 2020

John, shoot me an email at ethan@ipvm.com with specifics. We have cameras online which might fit what you're looking for.

KJ
Kenny Johnson
Mar 04, 2021

I sent you an email just now.

TJ
Tay Joo Tang
Jun 12, 2020

Try these!

rtsp://freja.hiof.no:1935/rtplive/_definst_/hessdalen02.stream

rtsp://freja.hiof.no:1935/rtplive/_definst_/hessdalen03.stream

I found them while doing some short testing a while back.

:)

KJ
Kenny Johnson
Mar 04, 2021

The links you posted are gone now.

UE
Undisclosed End User #1
Mar 04, 2021

Go to Axis developer site and ask for a lease for a few days.

UM
Undisclosed Manufacturer #2
Mar 04, 2021
Avatar
John Scanlan
Jun 14, 2021
IPVM • IPVMU Certified

For those still looking for an RTSP camera URL that is public and free for testing you can you use this one:

rtsp://demo:demo@ipvmdemo.dyndns.org:5541/onvif-media/media.amp?profile=profile_1_h264&sessiontimeout=60&streamtype=unicast

Below is the FoV with license plates, chart, and live clock:

IPVM Image

(1)
(2)
KJ
Kenny Johnson
Jun 15, 2021

Thank you so much!

UM
Undisclosed Manufacturer #3
Feb 15, 2022

Was the password changed? demo/demo does not seem to work.

Thanks

(1)
UI
Undisclosed Integrator #4
Feb 15, 2022

It's an unpatched Hikvision camera. Make your own password. Looks like the current accounts on there are admin, OnlyMe, Operator1, and IPVM.

http://ipvmdemo.dyndns.org/Security/users?auth=YWRtaW46MTEK

See John Scanlon's response below

Avatar
John Scanlan
Feb 15, 2022
IPVM • IPVMU Certified

No, that's a different camera we use for class (port 80). That would be a bad choice to use as it gets defaulted frequently and the passwords are often reset by students.

The other Axis camera looks to be offline (port 5541). I just finished class and will check into shortly.

Thanks for letting us know.

(1)
Avatar
John Scanlan
Feb 15, 2022
IPVM • IPVMU Certified

U3 - thanks for the heads and my apology for the delay. It is now working:

IPVM Image

The camera had intermittent streaming and connectivity issues. After troubleshooting to no avail I defaulted the camera and then reconfigured it. I will keep an eye on it and replace it if we see the issues return.

UM
Undisclosed Manufacturer #3
Feb 15, 2022

Thanks!

rtsp://demo:demo@ipvmdemo.dyndns.org:5541/onvif-media/media.amp?profile=profile_1_h264&sessiontimeout=60&streamtype=unicast

is still the URL?

VLC gives a username/password error.

(1)
Avatar
John Scanlan
Feb 15, 2022
IPVM • IPVMU Certified

I added another camera here :

rtsp://demo:demo@ipvmdemo.dyndns.org:5542/onvif-media/media.amp?profile=profile_1_h264&sessiontimeout=60&streamtype=unicast

IPVM Image

Both cameras work as designed until the port forwarded IP address is assigned, then they begin to fail to connect. The public RTSP is gaining popularity with 20+ clients automatically connecting as soon as the original IP address is set. This is why each fails. Those connected to the first camera are fine, and those looking to connect can use this second camera. I will also look into the best way to provide this service with scale for a longer-term solution.

JS
John Smith
Nov 17, 2022

mistake

(1)
JS
John Smith
Nov 17, 2022

oops

(1)
New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions