Subscriber Discussion

RTSP Camera URL - Public And Free For Testing

[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

Agree
Disagree
Informative: 1
Unhelpful
Funny

Agree: 1
Disagree
Informative: 2
Unhelpful
Funny: 1

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

Agree
Disagree
Informative
Unhelpful
Funny

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).

Agree: 1
Disagree
Informative: 2
Unhelpful
Funny: 2

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!

Agree
Disagree
Informative
Unhelpful
Funny

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.

Agree
Disagree
Informative
Unhelpful
Funny

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

Agree
Disagree
Informative
Unhelpful
Funny

I sent you an email just now.

Agree
Disagree
Informative
Unhelpful
Funny

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.

:)

Agree
Disagree
Informative
Unhelpful
Funny

The links you posted are gone now.

Agree
Disagree
Informative
Unhelpful
Funny

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

Agree
Disagree
Informative
Unhelpful
Funny
Agree
Disagree
Informative
Unhelpful
Funny

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

Agree: 1
Disagree
Informative: 2
Unhelpful
Funny

Thank you so much!

Agree
Disagree
Informative
Unhelpful
Funny

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

Thanks

Agree
Disagree
Informative: 1
Unhelpful
Funny

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

Agree
Disagree
Informative
Unhelpful
Funny

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.

Agree
Disagree
Informative: 1
Unhelpful
Funny

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.

Agree
Disagree
Informative
Unhelpful
Funny

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.

Agree
Disagree
Informative: 1
Unhelpful
Funny

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.

Agree
Disagree
Informative
Unhelpful
Funny