Questions about Video API of Nx Witness
Answered
Q1. When using direct download API, there is a gap between
the time designated by the "pos" parameter
and the actual start time of the downloaded video stream.
It seems that the actual start time can only be the time at which a key frame exists.
Is it possible, with direct download API,
to download a video stream whose actual start time is
"exactly" (not almost) equal to the time designated by the "pos" parameter?
Q2. If the answer to Q1 is no,
is it possible to know the epoc time (or some other kind of an absolute time stamp)
of the first frame of the downloaded video stream?
Q3. When using RTSP Streaming,
is it possible to get the frame rate of the result video stream?
Q4. When using RTSP Streaming,
is it possible to designate the end time of the result video stream?
(To put it another way, does RTSP Streaming have an equivalent of
the "endPos" parameter of HTTP Streaming?)
Q5. If the answer to Q4 is no,
is it possible to get the average frame rate of the result video stream
with an API offered by Nx Witness?
Q6. When using HTTP Streaming,
how is it possible to know the format and the "resolution" parameter value
that produce the least amount of transcoding?
Q7. Unlike RTSP Streaming, HTTP Streaming does not have a "speed" parameter.
When using HTTP Streaming without designating the "sfd" parameter,
what is the maximum value of the playback speed of the result video stream?
-
Official comment
Hello Yuta.
Q1. No. You are right that VMS server starts export from the closest key frame. You can not start export from arbitrary moment because the exported stream has to start from a key frame. You can transcode received stream to have a key frame at a convenient date/time.
I am going to slightly disclose logic behind how VMS server chooses initial key frame to begin export from.
- If there is no footage in archive at requested Pos, server searches forward on the timeline and starts export from the first key frame found.
- If the requested footage is available, server searches for first available key frame backward on the timeline, or, if requested position points exactly to key frame, that key frame is used.
Q2. No. But it can be quite easily implemented by feature request.
Q3. No. VMS does not store frame rate in metadata, so the only way to know frame rate is to decode the stream.
Q4. No, you Can not do it with URL parameters. But you can use Range RTSP header (As in RFC 2326 paragraph 12.29, but utc-range has slightly another semantics. Unlike in 3.7, utc-time is expressed in milliseconds since Unix Epoch).
Q5. No, you can only obtain frame rate when you start decoding of video stream.
Q6. Generally speaking, the less bitrate you cope with, the less CPU load is generated, so small picture is preferable here. Optimal format is MPEG-TS since it does not imply transcoding. For VMS 4.0 and later MP4 is more preferable.
Q7. SFD parameter is implemented for clients to avoid usage of memory for storing cached content. It limits server's outbound streaming bitrate.
Playback speed (with SFD=false) is not limited anyhow intentionally and has only environmental limits, such as CPU transcoding framerate, storage and network throughput.
-
Dear Artem,
Thank you very much for your kind reply, which helped me a lot.
Now, I'd like to make a further inquiry about Q2.
If I send you a feature request, when is it possible for you, at the earliest, to release the newest version that implements the required function?
I'll be waiting for your reply.
0 -
Hello Yuta,
At the moment, the earliest possible version any feature to be considered for is 4.2.
There is no yet estimated release date for version 4.2
0
Please sign in to leave a comment.
Comments
3 comments