Skip to content

Conversation

@jflevesque-genetec
Copy link
Contributor

Add new APIs in the Search and Recording specification to be able to list and export recorded segments towards a cloud storage.

@jflevesque-genetec

This comment was marked as outdated.

@jflevesque-genetec jflevesque-genetec marked this pull request as ready for review July 16, 2024 19:07
HansBusch

This comment was marked as resolved.

@74qb
Copy link

74qb commented Aug 11, 2025

@jflevesque-genetec @HansBusch
During prototyping I realized that specification is not saying anything about the span length.
We can assume that span size is defined by number of export jobs for specified time range or use span duration from recording configuration. Whatever will be decided it should be mentioned in the specification to avoid confusion.

@jmelancongen
Copy link
Contributor

If we're talking about span duration, and not segment duration, the only visible effect would be the _end file and the segment counter. For those, we left it a bit vague on purpose, to allow a device to use directly its recorded data if it already records locally with the right format, and already allocated span counter in file names. But to also allow a device that converts on the fly from it underlying storage, to reset the span counter as it wishes.

We're willing to add a clarification if needed, but I'm just not sure what it should be in this case.

Copy link
Contributor

@kieran242 kieran242 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jflevesque-genetec it was some time since I reviewed this PR and I have read all the contributions again and the full text and WSDL updates and I am happy to approve. I am aware this is in the Prototyping stage and this could change with Minor update.

Approving for now.

@kieran242

This comment was marked as resolved.

The figure <xref linkend="_refSegmentExportStabilityExample" /> illustrates how a global real time clock timestamp (that doesn't reset on device reboot
or resync on NTP) could be segmented in time ranges for the target segment duration with a modulus operation. Then each boundary of these ranges are
adjusted to match the time of the next keyframe. The result is the list of segment boundaries that overlap with the original time range of the query.
Care should be taken not to return the most recent segment if it is incomplete (when more frames may be appended to it later, i.e.: it overlaps with the current time).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jflevesque-genetec ,
Would be nice to clarify, the first segment case also. Even for the first segment, is it expected to find the next following Key Frame ? In this case there is a chance that some short initial duration might be missing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added The results shall include segments that cover the requested time range entirely, even if they start before or end after the requested time range.

@ocampana-videotec
Copy link
Collaborator

Rescheduling for 26.06 , since @jmelancongen confirmed that prototyping cannot be done in time for 25.12

@ocampana-videotec ocampana-videotec added this to the 26.06 milestone Dec 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants