ExportFileFormat 24.12 ONVIF™ www.onvif.org December, 2024 2013-2024 ONVIF™ All rights reserved. Recipients of this document may copy, distribute, publish, or display this document so long as this copyright notice, license and disclaimer are retained with all copies of the document. No license is granted to modify this document. THIS DOCUMENT IS PROVIDED "AS IS," AND THE CORPORATION AND ITS MEMBERS AND THEIR AFFILIATES, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL THE CORPORATION OR ITS MEMBERS OR THEIR AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT, WHETHER OR NOT (1) THE CORPORATION, MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR (2) SUCH DAMAGES WERE REASONABLY FORESEEABLE, AND ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT.  THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS AND THEIR RESPECTIVE AFFILIATES TO THE CORPORATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE CORPORATION. 1.0 March 2013 Gero Bäse First release 1.0.1 May-2014 Michio Hirai Change Request 1330 17.06 Jun-2017 Hans Busch Hiroyuki Sano Change Request 1843 Change Request 2065 18.06 Jun-2017 Stefan Andersson Hans Busch Add cstb box Add suep version 1 and Annex B 18.12 Dec-2018 Hiroyuki Sano Change Request 2299, 2356, 2358, 2359, 2383, 2405 21.06 Jun-2021 Hans Busch Move sigC definition to 5.4. Remove obsolete UUID notion. 21.12 Dec-2021 Hans Busch Add timed metadata. 22.06 Jun-2022 Hans Busch Add location information. 22.12 December-2022 Hans Busch Remove references to ISO 23000-10. Add support for cstb in meta to support cases without signing. 24.12 December-2024 Sriram Bhetanabottla Update ISO reference link. This document defines the ONVIF file format for exported media. The specification defines the mechanism necessary to support interoperable verification of the authenticity by the receiving party. ONVIFTM Core Specification <​> ONVIFTM Streaming Specification <​> ISO/IEC 14496-12 Information technology — Coding of audiovisual objects – Part 12: ISO base media file format <​> NIST FIPS 180-4 Secure Hash Standard <> ISO/IEC 14888-2 Information technology – Security techniques – Digital signatures with appendix – Part 2: Integer factorization based mechanisms <> ETSI TS 126 244 3GPP file format <> PKCS#1, v2.1 RSA Cryptographic Standard NIST FIPS 186 Digital Signature Standard (DSS) <> IETF RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 <> ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008, Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),Canonical Encoding Rules (CER)and Distinguished Encoding Rules (DER) <>

Certificate A certificate as used in this specification binds a public key to a subject entity. The certificate is digitally signed by the certificate issuer to allow for verifying its authenticity Signature A digital signature or digital signature scheme is a mathematical scheme for demonstrating the authenticity of a digital message or document.

SHA Secure Hashing Algorithm

This specification extends the ISO/IEC 14496-12 Base File Format in order to serve Video Surveillance requirements.

The ISO Base File Format has been mainly designed for storing movies and music clips. It defines a media timeline relative to the beginning which is defined as time zero. For Video Surveillance purposes it is important that the file includes the absolute start time of the captured frames. All other times can be derived using the relative time data defined in ISO/IEC 14496-12. Additional to this time information time corrections can be stored during the sealing process. In order to improve random access the ISOM baseline requires the movie fragment table at the end of the file. This redundant information does not require the protection seal.

Three mechanism for storing location information are defined for MP4 files by the mobile industry. This specification refers to the ETSI standard which has defined means for textual and spherical representation using the so called 'loci' box. Beside the ETSI standard two defacto standards exist for Android and iOS based mobile phones: Android phones use the '©xyz' box holding an alphanumeric string with lon and lat degrees. Mobile phones based on iOS store similar information in sub atoms of the meta box. Note that this meta box is incompatible with the ISO Base File Format specification. The location information is designated to provide a best effort for the video location in order to be able to geo-locate the video. For fixed cameras the location should approximate to the intersection of the camera axis with the ground location. For moving cameras such an appoach may not be feasible and a fallback to the camera location may be more suitable.

All data that a user wishes to carry away separately are put into a metaphorical bag. The bag is then sealed to enable tamper detection. Anyone wanting to use the data from the bag first examines the seal. The data in the bag are identical with the original data as long as the seal is intact. Here, the metaphorical bag is represented by a file and the seal is represented by a signature over all data in the file. The “bag of evidence” approach builds on procedures for media data and related metadata to be securely extracted from a trusted storage in a separate file. It defines which metadata has to be preserved in order to provide for accurate replay. Data are provided “as is” without any further assertions, whatsoever, to perpetuate evidence. Processing power usage can be reduced by performing hash functions before signature algorithms are applied. Multiple stages of signatures might be applied to collect additional information into a single sealed file. International state of the art standards are applied for the file structure, hash and signature algorithms. The surveillance application format and the RSA2048 signature defined by ISO/IEC as well as the SHA-256 hash algorithm approved by NIST come into operation for most widespread interoperability.

An operator exports a Video clip with associated Audio from a DVR of brand A onto two DVDs, because it didn’t fit on one. The selected recording period contains gaps because the recorder did only record when motion is detected. The DVD is then sent to a second site with Software where the content of the DVDs is copied to the local hard disk. The user then plays it back in the Video Management System of brand B. The operator at the playback station wants to see the gaps in the recording and to seek to a time where Video has been exported. On playback he expects the Video to playback smoothly with lip sync Audio.

A court receives video clips from a grocery store, a street surveillance system and a metro operator. All three videos are shown in the court’s approved video player. The judges want to see the suspect in all three video clips with exact time information. They also want to have information when the video clips have been exported and whether the video sequence is complete and authentic.

An authorized person receives video clips in the format defined in the present specification and wants to play back the media data on players conforming to the underlying standards definitions. Interpretation of the additional information added by the present specification is not required.

In order to maintain the integrity and authenticity of ONVIF streaming media signed in accordance with the ONVIF Media Signing specification when exporting to an MP4 container, the following prerequisite steps shall be adhered to during the export process to ensure signature verification remains intact and media evidence can be trusted as tamper-proof. Preserve NAL order and bytes ONVIF signed media bitstream captured from the device shall not be filtered, rewritten reencoded or normalized, as the raw format and order of NAL units is critical. Keep Media Signing SEI NAL units All SEI frames of type user data unregistered with UUID 005bc93f-2d71-5e95-ada4-796f90877a6f shall not be stripped. Add Certificate SEI NAL unit if present The exported file should contain a certificate SEI at the beginning of a stream. This SEI includes all necessary information to validate subsequent SEIs.

The SurveillanceExportBox is required. It is recommended that the SurveillanceExportBox be placed as early as possible in files, for maximum utility. In order to be able to associate the recording with a camera/microphone and the exporting system the following information shall be placed in the box: Source – Description of the video source Name – Name of the camera URL – Address under which the camera can be accessed MAC – Unique physical address of the camera (examples: 08-00-27-00-0C-15, 08:00:27:00:0C:15, 080027000C15) Line – Input line number token for multi channel devices Source – Description of the audio source Name – Name of the microphone URL – Address under which the microphone can be accessed MAC – Unique physical address of the microphone Export – Unit executing the export Name – Name of the exporting unit URL – Address under which the exporting unit can be accessed MAC – Unique physical address of the exporting unit Time – Date and time information as to when the export was executed (start time) Operator – Name or identification of the operator performing the export SurveillanceExportBox Box Type: ‘suep’ Container: Meta Box (‘meta’), file level Mandatory: Yes Quantity: Exactly one This box shall contain information for all available tracks. Syntax Semantics String items are null-terminated strings in UTF-8 characters. If not applicable, the string shall contain the null-termination only. ExportOperator is a string that gives the name or identification of the operator performing the export. This string may be empty. ExportUnitTime is an integer that provides date and time designation as defined in ISO/IEC 14496-12 of when the export operation has been started. entry_count is an integer that provides the number of tracks.

The box defined in the section shall be used to provide the start date and time of the capture. Subsequent signing instances may define corrected start times. StartTimeBox Box Types: 'cstb' Container: Protection Scheme Information Box (‘sinf’) or Metadata box ('meta') Mandatory: No Quantity: Zero or one Syntax Semantics track_ID An integer that provides a reference to a track in the presentation. track_IDs are never re-used and cannot be equal to zero. startTime The UTC based time represented by the number of 100-nanosecond intervals since January 1, 1601 of the origin of the media timeline. Note, typically it is sufficient to provide the start time for the first track only. Multiple entries e.g. allow to correct audio and video synchronization. Each track fragment shall contain the Track Fragment Decode Time box ‘tfdt’ as defined in ISO/IEC 14496-12 to ease seeking during playback.

When available, the location of the camera view shall be provided as 'loci' box according to ETSI TS 126 244. See below informal repetition of the definition. Location Box Box Types: 'loci' Container: User Data Box (‘udta’) Mandatory: No Quantity: Zero or one Syntax All characters of string based fields shall be encoded as UTF-8. The following semantics apply: Role Shall be '1' - real location Name Human readable street address of the location, optionally including building internal addressing. Longitude and Latitude 16.16 bit fixed point angle in degree. Altitude Height of the location in meter.

ONVIF metadata supports transport of frame related scene description, events and PTZ information. This section defines how such information can be stored in export files. ISO/IEC 14496-12 Base File Format defines the box requirements for timed XML metadata. This specification defines how to interpret the metx box. content_encoding Defaults to 'xml'. Options defined by ONVIF are 'gzip' and 'exi'. namespace For ONVIF compliant metadata this parameter shall be set to "http://www.onvif.org/ver10/schema". schema_location Not used. BitRateBox Not used. An ONVIF compliant device shall describe a timed metadata track containing ONVIF metadata as defined by the ONVIF Streaming Specification using a XMLMetaDataSampleEntry box. Content compression shall be signaled via the content_encoding field. See the ONVIF Streaming Specification for compression data format. Note, XML documents should not be preceeded by an XML declaration since both version and encoding are well defined.

Inputs to the signature algorithm are all boxes of the file. These include boxes for signature creation, whose corresponding type is a string, set to a null value. The input contains signatures that are already present for repeated signing operations.

Implementations of this specification shall support RSASSA-PSS signatures as specified in ISO/IEC 14888-2 and PKCS#1 v2.1 with: SHA-256 as specified in FIPS 180-4 as cryptographic hash function an RSA modulus length of at least 2048 bits MGF1 as specified in PKCS#1 v2.1 as mask generation algorithm with SHA-256 as cryptographic hash function Salt length 20 Trailer field number as specified by the trailerFieldBC constant Implementations may support other digital signature algorithms, if appropriate. The generated signature string has to be included in the SignatureBox as defined in . Generating and maintaining parameters of the signature algorithm, particularly signature and verification keys, is outside the scope of this document. Recommendations given, e.g., in FIPS 186 should be followed where appropriate.

There are no changes to the file itself or the content after the signing operation has been performed. The sole exception is the input of the signature at the appropriate place. The following box definitions provide for signature identification and inclusion. Encryption is not required; therefore an OriginalFormatBox is not necessary.

Box Type: 'ipro' Box definitions can be found in ISO/IEC 14496-12 Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format. Container: Meta box (‘meta’) Mandatory: Yes Quantity: Exactly one The protection_count shall be 1.

Box Type: 'sinf'2 Container: Item Protection Box (‘ipro’) Mandatory: Yes Quantity: One per signing instance Contains exactly one SchemeTypeBox and exactly one SchemeInformationBox.

Box Type: 'schm'2 Container: Protection Scheme Information Box (‘sinf’) Mandatory: Yes Quantity: One per signing instance The scheme_type shall be 0x6F656666 („Onvif Export File Format‟). The scheme_version shall be 0x00010000 (version 1).

Box Type: 'schi'2 Container: Protection Scheme Information Box (‘sinf’) Mandatory: Yes Quantity: One per signing instance Contains exactly one SignatureBoxand exactly one CertificateBox. May also contain exactly one AdditionalUserInformationBox, exactly one SignatureConfigurationBox, and one CorrectStartTimeBoxCorrectStartTimeBox was added in version 1.1 of the ONVIF Export File Format.

Box Type: 'sibo' Container: Scheme Information Box (‘schi’) Mandatory: Yes Quantity: One per signing instance Syntax Semantics signature binary byte array. Length depends on used RSA key length.

Box Type: 'cert' Container: Scheme Information Box (‘schi’) Mandatory: Yes Quantity: One per signing instance Syntax Semantics data is the DER encoded binary byte array representation of the certificate for the key that should be used to verify the signature in the SignatureBox

Box Type: 'sigC' Container: Scheme Information Box (‘schi’) Mandatory: No Quantity: Zero or one per signing instance Syntax Semantics The ‘sigC’ box shall be present when the signature algorithm deviates from the default defined in . Its AlgorithmIdentifier is the signature algorithm identifier with optional parameters as defined by RFC 3280 and RFC 4055. It is encoded using the ASN.1 distinguished encoding rules (DER) and has the structure: :AlgorithmIdentifier ::= SEQUENCE {

To add an item, for example, electronic receiving stamps, repeated signing of the file may be required. Repeat steps defined in and and append another ProtectionSchemeInfoBox at the foot of the list of already existing boxes of that type as defined in while not changing protection_count in the ItemProtectionBox. Parsers are required to check for the existence of multiple ProtectionSchemeInfoBox despite protection_count is fixed to 1, because any change of content which has already been signed would render the appropriate signature invalid. An optional AdditionalUserInformationBox might be used in order to add information. In order to include optional user information, data related to an additional signature ‘auib’ box is provided.

Box Type: 'auib' Container: Scheme Information Box (‘schi’) Mandatory: No Quantity: Zero or one per signing instance Syntax Semantics UserInformation is a null terminated string in UTF-8 characters

characterizes the box arrangement defined in the present specification for data export.

characterizes the box arrangement after repeated signing.

The red color represents the signature introduced at the export stage. The green color represents another signing operation happening after the export stage. The CertificateBox provides the public key for signature verification. Within the SignatureConfigurationBox information is contained describing a nondefault signature algorithm and its parameters. Additional information has been added in the AdditionalUserInformationBox. In order to check validity of a signature the signature itself has to be taken from the SignatureBox and the bit values for the signature string be set to zero. The hashing operation is performed followed by the signature operation on the hash value. Now the two signatures can be compared. Example: Steps to check validity of the first (red) signature from above Remove the (green) boxes created for the second signing Re-adjust box sizes of ‘ipro’ and ‘meta’ according to the size of removed ‘sinf’ box Read the public key from the red CertificateBox (do not change the box content) Take out the signature from the red SignatureBox Set the bit values of the red SignatureBox to zero Perform hash operation on the remaining file data Perform signature operation on the obtained hash value Compare the just generated signature with the signature taken out before The diagram below provides an overview on required boxes and their referencing for a video stream with audio and timed metadata. In order to simplify the example, it shows the content of a single fragment while a real file would contain numerous fragments. ftyp1 File brand ‘isom’. moov1 File wide definitions mvhd1 Movie header with creation time, timescale, duration and others trak1 First track is expected to contain Video tkhd1 Track header with creation time, timescale, duration, track ID mdia1 mdhd1 Media header with creation time, timescale, duration and others hdlr1 Signals that this is a Video track (type is 'vide') minf1 Contains creation time, timescale, duration and others vmhd1 Video color information dinf1 Data location information. dref1 url1 Data location flag in file must be set stbl1 Container with sample descriptions. stsd1 Codec information avc11 H.264 codec information stts1 Sample index by time stsc1 Sample to chunk mapping stco1 List of Chunk offsets inside 'mdat' relative to file begin trak1 Second track with Audio tkhd1 Track header with creation time, timescale, duration, track ID mdia1 mdhd1 Media header with creation time, timescale, duration and others hdlr1 Signals that this is a Audio track (type is 'soun') minf1 Contains creation time, timescale, duration and others mhd1 Audio stereo balance information dinf1 Data location information. dref1 url1 Data location flag in file must be set stbl1 Container with sample descriptions. stsd1 Codec information mp4a1 Audio format information stts1 Sample index by time stsc1 Sample to chunk mapping stco1 List of Chunk offsets inside 'mdat' relative to file begin udta1 User data loci3 Geo location information trak1 Third track with timed metadata tkhd1 Track header with creation time, timescale, duration, track ID mdia1 mdhd1 Media header with creation time, timescale, duration and others hdlr1 Signals that this is a metadata track (type is 'meta') minf1 Contains creation time, timescale, duration and others nmhd1 Null media handler box dinf1 Data location information. dref1 url1 Data location flag in file must be set stbl1 Container with sample descriptions. stsd1 Codec information metx1 Metadata format information stts1 Sample index by time stsc1 Sample to chunk mapping stco1 List of Chunk offsets inside 'mdat' relative to file begin mdat1 Raw Video and Audio of first fragment (moov) moof1 Fragment mfhd1 Contains creation time, timescale, duration and others traf1 First track with Video tfhd1 Sample information tfdt1 Track fragment decode time trun1 Access to raw data in mdat box traf1 Second track with Audio tfhd1 Sample information tfdt1 Track fragment decode time trun1 Access to raw data in mdat box traf1 Third track with timed metadata tfhd1 Sample information tfdt1 Track fragment decode time trun1 Access to raw data in mdat box mdat1 Raw Video and Audio of this meta1 File level meta information hdlr1 suep2 Export supplementary information ipro1 File protection sinf1 File protection information cstb2 Start time schm1 Protection scheme OEFF defined by this specification schi1 sibo2 Signature of the export cert2 Certificate of the exporter mfra1 Optional movie fragment random access (must be last in file) tfra1 Track fragment random access mfro1 Movie fragment random access offset The superscripts denotes the specification that defines the box: 1 ISO/IEC 14496-12 2 This specification 3 ETSI TS 126 244 No re-encoding ONVIF signed media stream captured from the device shall not be transcoded or recompressed. Instead Use pure remuxing (-c copy in ffmpeg) to change containers. Treat the video elementary stream as immutable Keep all SPS/PPS/VPS, access unit delimiter (AUD), prefix/suffix SEI and slice NALs in their original order. Do not change frame rate, timescale, timebase or GOP structure. Avoid frame duplication, dropping, de‑interlacing or timestamp “cleanup”. For SEI preservation: In H.264 the SEI NAL type is 6; in HEVC, SEI prefix/suffix types are 39/40. These must stay attached to the same access units they originally accompanied. Do not convert or regroup SEIs (e.g., never swap HEVC prefix and suffix). Avoid bitstream filters. Only use a filter when absolutely certain it will not modify or remove SEIs. Never run “cleaning” filters that remove private SEIs. Validate before and after File Export. Run Media Signing validation on the original source and again on the exported MP4 to confirm integrity. A simpler test is to only verify that the MP4 file has SEIs present after export. Below is an ffmpeg command for that. &1 | grep -i sei]]> Cut at signature‑safe boundaries Trim at SEIs. There will always be a "dangling end" of the exported file, that is, frames that cannot be validated since the associated SEI is not present in the exported recording. To minimize the "dangling end", trim at frames with a signed SEI (inclusive), that is, a SEI with a signature.