Hello Milestone team,
Currently, I’m doing video clips for certain period, for example, when an event happen, I need to generate the a 1 min video clip from 30 sec before the event happen to the 30 sec after the event happen.
From the ONVIF document, I understood I can only get the whole recording RTSP?
Is there any service/API to get a rtsp url for specific time range?
thanks
Hi Cheng,
In short no - not in the URL.
But RTSP protocol as well as Milestone RTSP service support specifying start and end time as parameters of the Range header.
Range header could/should be provided in PLAY command and Milestone RTSP server supports NPT play times (seconds since start of the DB recordings) as well as absolute UTC times.
Hi Petar,
Thank you for your reply. Can you let us know, what is Milestone RTSP server we should connect to ? what Ip and port? i used default settings. thanks.
Sorry Cheng,
Probably I wasn’t completely clear.
Milestone ONVIF Bridge server is built on top of two services - ONVIF service and RTSP service.
They are both installed together.
First one is usually running on port 580. The second one on 554.
If you want to access live camera streams you should access them at:
rtsp://<ONVIF_Bridge_Address>:554/live/<camera_id_in_vms>.
Accessing video recordings happens on
rtsp://<ONVIF_Bridge_Address>:554/vod/<camera_id_in_vms>.
You should read the manual first in order to configure the allowed users from the Management Client.
Hi Petar,
Thanks for your guide. Now I already can get response from rtsp DESCRIBE command(Need digest auth). And the request and response are as follows:
Request:
DESCRIBE rtsp://20.20.0.154:554/vod/8DF206C2-5E0F-4EB3-A063-F2862A4A4526 RTSP/1.0
Cseq: 3
Authorization: Digest username=“milestone”, realm=“RtspServerLibrary”, nonce=“yFyfSAOWgBmaGil0PwPCGeBHWNhbpGaF”, uri=“rtsp://20.20.0.154:554/vod/8DF206C2-5E0F-4EB3-A063-F2862A4A4526”, response=“e129a81f6712f74c48ccf60f66d8d5c1”
Response:
RTSP/1.0 200 OK
CSeq:
Date: Wed, Oct 21 2020 01:48:51 GMT
Supported: play.basic, play.scale, setup.rtp.rtcp.mux
Content-base: rtsp://20.20.0.154:554/vod/8DF206C2-5E0F-4EB3-A063-F2862A4A4526
Content-type: application/sdp
Content-Length: 264
v=0
o=- 1603244952629091 1 IN IP4 127.0.0.1
s=libRtspServer
c=IN IP4 0.0.0.0
t=0 0
a=tool:libRtspServer 1.0.0
a=range:npt=0.0-89977.9
m=video 0 RTP/AVP 96
a=framerate:1.000000
a=rtpmap:96 H264/90000
a=control:streamid=0
a=fmtp:96 packetization-mode=1;
However, when I issued the next command SETUP, it seems I had to re-do digest auth, and still I always got 401 unauthorized response even though I re-did digest:
Request:
SETUP rtsp://20.20.0.154:554/vod/8DF206C2-5E0F-4EB3-A063-F2862A4A4526/streamid=0 RTSP/1.0
Cseq: 4
Transport: RTP/AVP;UNICAST;client_port=16264-16265;mode=play
Authorization: Digest username=“milestone”, realm=“RtspServerLibrary”, nonce=“yFyfSAOWgBmaGil0PwPCGeBHWNhbpGaF”, uri=“rtsp://20.20.0.154:554/vod/8DF206C2-5E0F-4EB3-A063-F2862A4A4526”, response=“5c2f33ac15a9b2dac41ee2aaa8b728ab”
Response:
RTSP/1.0 401 Unauthorized
CSeq:
Date: Wed, Oct 21 2020 01:48:53 GMT
WWW-Authenticate: Digest realm=“RtspServerLibrary”, nonce=“VybRuZighlmoc1Rsdq7fy9GYyvqMfUwq”
My DESCRIBE and SETUP digest generators are as follows:
private String genResponseValue(String url, String username, String password, String realm,
String nonce) {
String firstPreMd5Value = DigestUtils.md5Hex((username+":"+realm+":"+password));
String firstPostMd5Value = DigestUtils.md5Hex("DESCRIBE:" + url);
return DigestUtils.md5Hex(firstPreMd5Value+":"+nonce+":"+firstPostMd5Value);
}
private String genResponseValue2(String url, String username, String password, String realm, String nonce) {
String firstPreMd5Value = DigestUtils.md5Hex((username+":"+realm+":"+password));
String firstPostMd5Value = DigestUtils.md5Hex("SETUP:" + url);
return DigestUtils.md5Hex(firstPreMd5Value+":"+nonce+":"+firstPostMd5Value);
}
Please help check is the SETUP digest generator correct? If not, please kindly give some advice.
Thank you
Hi Cheng,
Once you receive unauthorize response from the server, you should start using it for all the calls/methods (except OPTIONS of course).
The construction of the digest response is identical in the cases of DESCRIBE and SETUP. The difference is only in the method used.
If I were you I would probably use one and the same function, passing method to it, thus ensuring code that generates the response is the same.
Nevertheless what you have made should work (of course if there is no some difference in one symbol somewhere, for example another copy of “:” written in different language or something).
However, If you receive 401 (Unauthorized) on the first SETUP command request, server will generate new “nonce”, and from now on, it has to be used for all other commands.
So you can check these two things as a starting point:
Hi Petar,
Thank you for your help. Finally, I could SETUP and PLAY, it was the nonce problem, it must be the same nonce.
Now, I can get the response from PLAY:
_________________________________________
RTSP/1.0 200 OK
Scale: 1
Range: clock=20201022T140000.365Z-20201022T151400.365Z
CSeq:
Date: Thu, Oct 22 2020 09:55:12 GMT
Session: 4A3E081F
RTP-Info: url=rtsp://20.20.0.154:554/vod/171980bc-4880-40b3-91ef-31251635b9bb;seq=12309;rtptime=14638
Can you give me a bit clue about how to handle this response in case to generate a mp4 video clip? I played the above rtsp url using VLC, it seems doesn’t work ..
Hi Cheng,
I’m not sure I completely understand you.
Especially in the part "I played the above rtsp url using VLC, it seems doesn’t work ".
VLC is one of the tools we use extensively when we test the RTSP server. So it should play. You have to ensure the camera is set to H.264 in the VMS and check if the VLC is configured to use TCP or UDP from the client. If it is an UDP, check if your network doesn’t filter it.
As far as your code - now you have created streaming and you have to start to consume it. In other words you have to start receiving RTP frames. From there you can reconstruct the original video frames. Those video frames should be multiplexed then to CMAF container (MP4 file format).
If you however doesn’t have any knowledge on how to consume RTP frames and/or how to build MP4 files, I’m afraid it will be very complex and time consuming task for you.
I’ve heard something similar should be possible with third party tools as ffmpeg for example, but I personally don’t have any experience with them.
Good Luck !
Hi Petar,
Response:
______________________________________________________________________
RTSP/1.0 200 OK
Scale: 1
Range: clock=20201022T140000.365Z-20201022T151400.365Z
CSeq:
Date: Thu, Oct 22 2020 09:55:12 GMT
Session: 4A3E081F
RTP-Info: url=rtsp://20.20.0.154:554/vod/171980bc-4880-40b3-91ef-31251635b9bb;seq=12309;rtptime=14638
From my previous experience, I converted valid rtsp url to mp4 using gstream. Now the rtsp url from PLAY command cannot play using VLC. (rtsp://20.20.0.154:554/vod/171980bc-4880-40b3-91ef-31251635b9bb;seq=12309;rtptime=14638), so I doubt whether I can convert this rtsp url to mp4 as i did before or not. Is my understanding correct?
I’m seeing you have specified in your set-up request underlying transport to be UDP:
Transport: RTP/AVP;UNICAST;client_port=16264-16265;mode=play
What is the response of the server btw ?
I’m however curious how you will provide afterwards this information to the VLC or to whatever rtp/udp/network source you are using in the GStreamer pipeline.
It definitely shouldn’t be rtsp://.
I would assume it should be something like
rtp://20.20.0.154:16264?seq=12309&rtptime=14638
or
udp://20.20.0.154:16264?seq=12309&rtptime=14638
But definitely not something containing the whole RTSP address of the already established connection.
Btw if you meanwhile close the underlying TCP connection of the RTSP channel, Milestone RTSP server will close the whole channel, including and video that is passing over the UDP.
Passing the whole RTSP link to the VLC just doesn’t make sense, because it will try to establish a new connection to the RTSP server.
SETUP rtsp://20.20.0.134:554/vod/171980bc-4880-40b3-91ef-31251635b9bb/streamid=0 RTSP/1.0
Cseq: 4
Authorization: Digest username=“milestone”, realm=“RtspServerLibrary”, nonce=“TGtEUQqaE4wBShyi3sEoaGtpWWz3uTRz”, uri=“rtsp://20.20.0.154:554/vod/171980bc-4880-40b3-91ef-31251635b9bb”, response=“a5780dc976a845610fd56316bb2f686a”
Transport: RTP/AVP;UNICAST;client_port=16264-16265;mode=play
Response:
RTSP/1.0 200 OK
CSeq:
Date: Mon, Oct 26 2020 01:32:39 GMT
Session: 908711B3
Transport: RTP/AVP;unicast;client_port=16264-16265;server_port=4000-4001
Media-Properties: Random-Access=2.5, Unlimited, Immutable, Scales=“-16:16”
PLAY rtsp://20.20.0.134:554/vod/171980bc-4880-40b3-91ef-31251635b9bb RTSP/1.0
Session: 908711B3
Cseq: 5
Range: clock=20201022T140000.365Z-20201022T151400.365Z
Authorization: Digest username=“milestone”, realm=“RtspServerLibrary”, nonce=“TGtEUQqaE4wBShyi3sEoaGtpWWz3uTRz”, uri=“rtsp://20.20.0.154:554/vod/171980bc-4880-40b3-91ef-31251635b9bb”, response=“db44c8ff6ea9edb8a1905a5d486d5123”
Response:
RTSP/1.0 200 OK
Scale: 1
Range: clock=20201022T140000.365Z-20201022T151400.365Z
CSeq:
Date: Mon, Oct 26 2020 01:32:41 GMT
Session: 908711B3
RTP-Info: url=rtsp://20.20.0.134:554/vod/171980bc-4880-40b3-91ef-31251635b9bb;seq=43008;rtptime=26197
Hi Petar,
Please see the above for SETUP and PLAY responses, I thought I should process with the PLAY response(RTP-Info: url=rtsp://20.20.0.134:554/vod/171980bc-4880-40b3-91ef-31251635b9bb;seq=43008;rtptime=26197). If not, can you advise how to handle with the above responses, I’m not sure where "rtp://20.20.0.154:16264?seq=12309&rtptime=14638" and “udp://20.20.0.154:16264?seq=12309&rtptime=14638” come from. sorry.. I quite lack of experience in video processing.
thank you
Hi Cheng,
According to the RFC 2326 - p55
"url: Indicates the stream URL for which the following RTP parameters correspond. "
Therefore I doubt it should be used as you tried.
In general response of the SETUP command and in particular this header:
Transport: RTP/AVP;unicast;client_port=16264-16265;server_port=4000-4001
means the underlying transport for the RTP video packets will be done on UDP, unicast, as client will use port 16264, and the server 4000.
16265 and 4001 will be used for the corresponding RTCP channel.
If you want to implement it you should start listening for such network packages, but on top of that you have to implement RTP de-multiplexor (extract RTP headers and combine their data to separate video frames).
However I’m not sure how this should happen using third party components.
In general every RTSP client library supports some sort of parameters that can be provided to the server in order to be performed some sort of “seeking” in the stream.
VLC supports such in NPT time for sure.
So if you are using third party RTSP client library you have to find out what kind of parameters it supports and provide them to it, instead of trying to implement some part of the RTSP protocol and to “force” the library to continue the RTSP connection from where you left it.
Live 555 have similar capabilities, but you have to hook on very low level in order to implement it.
Probably you should look for something on higher level. For example you could specify start and end stream time when you start VLC from the command line. For example:
vlc.exe --start-time=3600 “rtsp://:@<rtsp_server>:554/vod/<camera_id>”
This will instruct rtsp server to perform “seek” to 3600 seconds after beginning of the records in the RS DB (relatively to DB start).
In this way all the handling of the RTSP commands and video is left for the library. You just have to find out what parameters to pass to it.
You can refer to the official RTSP specs for details: