No content in direct download response when exporting video

Completed

Comments

13 comments

  • Avatar
    Anton Babinov

    Hello Peter,

    http://<ipaddress>:<port>/hls/1.mkv?&pos="1612256206049"&duration=10

    You don't need quotes around pos parameter value - try it like this:

    http://<ipaddress>:<port>/hls/1.mkv?&pos=1612256206049&duration=10

    If that won't fix your issue, please tell me your VMS build number(4.1.xxxxx) from System administration-> updates tab.

     

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman

    Hello Anton,

    I have removed the quotes, still no content.

    VMS build number is 4.1.0.31400

    0
    Comment actions Permalink
  • Avatar
    Anton Babinov

    Hi Peter,

    I found a similar issue reported earlier for the release version of 4.1. Could you please check if you can get a video with /media API? Something like this:

    /media/<cameraId>.<format>?pos=<starttime>

    We have 4.2 release coming soon. With this release, we're adding stream and duration parameters so that /media/ API will be used for direct download instead of /hls. 4.2 beta is already out, so you can test it on your test environment or wait few weeks for the official 4.2 release.

     

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman

    Hi Anton, 

    thank you for the information.

    I was just about to update this thread by telling you I am now getting video content back.

    The error was due to a combination of my url not being constructed properly and attempting to download unrecorded content.

    However, occasionally the download fails with a valid url and a valid recorded time period which is what was confusing me before but I am looking into this.

    I have tried using a url with media like the one you posted in my current 4.1 version and I get a 404 Not found.

    Is the media method available in 4.1 or only in 4.2 beta at the moment?

    Do you have a date for when the 4.2 official version will be released?

    And finally, is there any way of knowing the size of the download either using hls or media? As the ContentLength for the hls response is always -1.

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman

    Hi Anton,

    The download function is working and I think the new version will be released too late for us to implement this and get our application on site in time. However, after discussing some issues with my colleagues. We have the following questions.

    We are implementing a recorded stream in an application, we have a few questions about features and a few issues:
     
    * Can a recorded stream from Wisenet be paused? If so how?
    * Can a recorded stream be played in reverse, and at multiple speeds?
    * When we play a recorded stream at a faster speed, the NTP timestamps in the RTP header extension do not seem to correspond with the stream - instead they are increasing at 1 sec per second and are of a much older date. Is this a known issue, is there anything we can do to fix it?
     
    Thanks.

     

    0
    Comment actions Permalink
  • Avatar
    Anton Babinov

    Hi Peter,

    Is the media method available in 4.1 or only in 4.2 beta at the moment?

    Do you have a date for when the 4.2 official version will be released?

    Official release of version 4.2 is scheduled in a few weeks. It seems that the latest 4.1 patch from January already includes improvements for /media method.You can execute it like this:

    /media/<cameraId>.<format>?pos=<starttimeMS>&stream=<0 for primary,1 for secondary>&duration=<chunk duration in seconds>

    I have tried using a url with media like the one you posted in my current 4.1 version and I get a 404 Not found.

    Release of 4.1 already included /media API. However, it could be used only for live HTTP streaming as it didn't support duration parameter. Could you please show me example of your request?

    * Can a recorded stream from Wisenet be paused? If so how?

    You can Pause/Play live or recorded stream from camera in Wisenet client at anytime. If you want to see the stream in some third-party software - you can access archive as live HTTP/RTSP stream from older start position. Check our Video API reference at https://<VMS server IP>:7001/static/api.xml#group_Video_API for more details. When accessing recording over API, pause feature doesn't depend on the server, it can be implemented in your client.

    * Can a recorded stream be played in reverse, and at multiple speeds?

    Reverse playback and multiple speeds are supported for rtsp streams. You can use scale parameter of RTSP protocol, it allows you to set playback speed.

    * When we play a recorded stream at a faster speed, the NTP timestamps in the RTP header extension do not seem to correspond with the stream - instead they are increasing at 1 sec per second and are of a much older date. Is this a known issue, is there anything we can do to fix it?

    How do you open stream and which video player do you use? Do you use RTSP streams or HTTP?

     

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman
    Hi Anton,
     
    We're playing the stream via FFMPEG, and we are use RTSP to start the stream. The rtsp uri we're using is something like rtsp://<user>:<password>@<ipaddress>:<port>/2?pos=1612958057000&resolution=240. We haven't been able to add the pos as a Range value in the header. The example url in our app successfully plays, via FFMPEG, recorded video from Wisenet. However, if we set the Scale in the header, nothing happens.
     
    Order of events currently when trying to play at 8.0 speed is:
     
    Send OPTIONS
    await response with options / confirmation of auth.
    Send DESCRIBE
    await response
    Send SETUP
    await response
    Send PLAY
    await response
     
    The full rtsp command for the PLAY is:
    (I've redacted some of the fields)
     
    PLAY rtsp://<ipaddress>:<port>/2 RTSP/1.0
    Scale: 8.0
    Require: onvif-replay
    CSeq: 5
    User-Agent: Lavf57 82 100
    Session: 21315238229441815024209
    Authorization: Digest username="REDACTED", realm="VMS", nonce="REDACTED", uri="rtsp://<ipaddress>:<port>/2", response="REDACTED", algorithm="MD5"
     
    This doesn't appear to play a stream at an increased speed, though onvif-replay has worked just fine - we're getting NTP timestamps just fine. We've also tried putting the speed in the uri as suggested by your documentation (for example, rtsp://<ipaddress>:<port>/2?pos=1612958057000&resolution=240&speed=8000), but this results in packets being sent to us with incorrect NTP timestamps as described above.
     
    Finally, there's nothing about pausing video in the API documentation. Is our API documentation out of date? It only has one entry for rtsp playback. The NVR version is 4.1.0.31400
    0
    Comment actions Permalink
  • Avatar
    Anton Babinov

    Hi Peter,

    We're playing the stream via FFMPEG, and we are use RTSP to start the stream. The rtsp uri we're using is something like rtsp://<user>:<password>@<ipaddress>:<port>/2?pos=1612958057000&resolution=240. We haven't been able to add the pos as a Range value in the header. The example url in our app successfully plays, via FFMPEG, recorded video from Wisenet. However, if we set the Scale in the header, nothing happens.

    Sorry, it seems I misled you. I've checked with our developers and here are more details. For increased speed forward playback you should use URI parameter speed in range 1..32 as described in our manual. 

    Reversed playback should be implemented in your client, but we implemented Nx protocol extensions for RTP which would allow you to download chunks in reverse order without re-establishing RTSP session for each chunk. This document provides request examples. Nx extension allows to initiate RTSP session once and get the GOPs in the reverse order within the same session. The actual value of the scale parameter isn't relevant at the moment, server just checks if it's negative or not. If market `X-FFMPEG-RTP` is set and scale value is negative, server will send GOPs in reverse order as fast as you can process them.

     
    Finally, there's nothing about pausing video in the API documentation. Is our API documentation out of date? It only has one entry for rtsp playback. The NVR version is 4.1.0.31400

    Server supports RTSP PAUSE/PLAY commands. Server documentation doesn't cover specifics of RTSP protocol implementation, we'll consider improving it in future releases.

     

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman

    Hi Anton,

     

    Thanks for the info. We'll take a look at the document you've provided and see what we can do with reverse playback.
     
    Regarding the speed parameter; this is what we initially tried, but as we explained in the original post, whilst the stream itself was showing video at a faster speed, the NTP timestamps that were coming with the packets were incorrect. The NTP timestamps for each packet showed a much older time, and were progressing as if for 1x speed packets instead of 4x speed. Is this a known issue and one we can fix, or are NTP timestamps not supported with faster than 1x speed?
     
    Likewise, the PAUSE rtsp command doesn't appear to be doing anything with Wisenet; we send the command, receive an OK, but UDP packets are still arriving. I assume this is not expected behaviour?
     
    I have wireshark logs if these would be helpful.
    0
    Comment actions Permalink
  • Avatar
    Andrey Terentyev

    Hello Peter,

    Sorry for long silence.
    We are working on the solution.Please, allow us some time. We'll update soon.

    0
    Comment actions Permalink
  • Avatar
    Anton Babinov

    Hello Peter,

    sorry for the delay. I did some tests and was able to confirm described behavior, so Wireshark logs won't be required.

    Regarding the speed parameter; this is what we initially tried, but as we explained in the original post, whilst the stream itself was showing video at a faster speed, the NTP timestamps that were coming with the packets were incorrect. The NTP timestamps for each packet showed a much older time, and were progressing as if for 1x speed packets instead of 4x speed. Is this a known issue and one we can fix, or are NTP timestamps not supported with faster than 1x speed?

    At the moment RTSP server implementation doesn't support it. Server can send data faster, but it's up to the client to process it.

    Likewise, the PAUSE rtsp command doesn't appear to be doing anything with Wisenet; we send the command, receive an OK, but UDP packets are still arriving. I assume this is not expected behaviour?

    Pause command also isn't supported by the server. I've checked few video players, like VLC, and none of them uses it.

    We'll consider improving our rtsp server implementation in future releases, but for now, the only way would be to implement the support for required features in the client without depending on the server.

    0
    Comment actions Permalink
  • Avatar
    Peter Chapman

    Hi Anton,

    Is there support for controlling Wash\Wipe\Aux for a camera?

     

    0
    Comment actions Permalink
  • Avatar
    Anton Babinov

    Hi Peter,

    if you have some additional question which doesn't relate to the original problem in the thread, please consider creating new forum thread. This way will be easier to manage posts and it would help other to find answers to similar questions.

    Is there support for controlling Wash\Wipe\Aux for a camera?

    You can make an event rule which would send command to camera API to trigger these function. Please check this thread - https://support.networkoptix.com/hc/en-us/community/posts/1500000163602-Send-Aux-Command-to-Camera

     

     

    0
    Comment actions Permalink

Please sign in to leave a comment.