Video/object track aggregation event

[bsriramprasad]

Here is the summary of changes included in PR

18/06/2024

• Created a new section "Object Track Aggregation" event description in Analytics specification
• Created schema structures referred in the event description
• No additional changes in Metadata configuration, follows existing Event transport.
• Not defined as a property event
  • Primary use case to standardize only the 'final aggregation'
    • Initial/intermediate aggregations are made optional
  • use case NOT at all focused to get the state of every object in the scene at any time.
• If we are sending only one (final aggregation) event per object, it is an overkill to fit into the property event paradigm.

23/08/2024 Update

• Removed individual structures created for snapshot/bounding box
  • Reused the tt:Object with the capture time attribute
• Included Rule options for below
  • ReportTimeInterval
  • Data filter for including complement data like snapshot/bounding box
  • Add Rule options response sample

10/09/2024 Update
Addressed below changes based on the Bangkok F2F discussions

• Rename ObjectComplement as ObjectTrack
• Clarify Object track data as additional data generated by the device based on the ObjectTrackDataFilter configured by the client
• Fixed rule type as tt:ObjectTrack, incorrectly referring tt:ObjectClassification
• Remove AggregationEnd and use event time instead
• Fixed the extension structure as suggested by @HansBusch

11/03/2025
Addressed below changes based on IST F2F discussions

• Added additional description text for clarifying context and usage of the event
• Renamed FinalAggregation to Final
• Renamed ObjectTrackData to ObjectTrack
• Clarified that final aggregations should be sent even if class/threshold filters prevent sending one

18/03/2025
Addressed below changes based on IST F2F discussions

• Clarified description about sending final mandatory if initial/intermediates sent
• Paraphrasing few words for clarity

08/04/2025

• Clarified ambiguous interpretation with reuse of tt:Object for aggregation and object track.

• Fixed issue with schema as original proposal was violating core spec Section "9.4.1 Notification Message Format" in the ONVIF Core Specification states

  • Source, Data and Key are structured as item lists. Each can hold an arbitrary number of items of type SimpleItem
    or ElementItem. Each Item has a name and a value. In the case of an ElementItem, the value is expressed by
    one XML element within the ElementItem element. In the case of a SimpleItem, the value shall be specified by
    the value attribute. The name of all Items shall be unique within all Items contained in any group of this Message.

  • The interpretation being that it is not allowed by the core spec to have several ElementItem with the same on the level currently specified in a message.

[HansBusch]

There seems to be no way for the client to control the amount of produced track information.
Do we need a parameter to limit the number of snapshots?

[bsriramprasad]

There seems to be no way for the client to control the amount of produced track information. Do we need a parameter to limit the number of snapshots?

If we modify the Object track complement structure to change to include tt:Object to make it more generic, Are we not opening up for more data to be sent that could be hard to filter?

• That's the reason we have created a focused structure with just snapshot and bounding box.
  • Our previous F2F discussion focused a lot on trying to filter data - but it turned out to quite complex and hence opted for more focused proposal.

[HansBusch]

Editorial remark on extending types:

	<xs:complexType name="ObjectComplementData">
		<xs:complexContent>
			<xs:extension base="tt:Object">
				<xs:attribute name="CaptureTime" type="xs:dateTime"/>
				<xs:anyAttribute processContents="lax"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

[bsriramprasad]

Editorial remark on extending types:

	<xs:complexType name="ObjectComplementData">
		<xs:complexContent>
			<xs:extension base="tt:Object">
				<xs:attribute name="CaptureTime" type="xs:dateTime"/>
				<xs:anyAttribute processContents="lax"/>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>

Thanks for the suggestion, updated the schema as suggested.

[kieran242]

@bsriramprasad Approved after analytics document render.

[bsriramprasad]

2025-03-10

Assume client configured the rule with below parameters

Example 1

• Confidence threshold Level = 0.5
• Update event has {Human: 0.7} and is sent to the user.
• Final event has {Human: 0.4 } and is not sent to the user.
  Final confidence NOT meeting the threshold

Example 2

• Class filter = [Human]
• Update event has {Human: 0.7} and is sent to the user.
• Final event has {Vehicle: 0.4 } and is not sent to the user.

Though these examples may seem like an anomaly for aggregation, it would still be beneficial for the client to be notified of final aggregation at end of track.

Discussed in IST F2F and concluded that we need to add a requirement on devices to send Fina Aggregation irrespective of final not meeting the class/threshold rule parameters, PR update should reflect this change.