Skip to content

Update MediaSigning.xml with additional timestamp #561

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: development
Choose a base branch
from
+12 −9
Open

Update MediaSigning.xml with additional timestamp #561

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c941764
Update MediaSigning.xml with additional timestamp
bjornvolcker May 7, 2025
55de322
Removes spec version
bjornvolcker May 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 12 additions & 9 deletions doc/MediaSigning.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,12 +58,6 @@
signing feature, and also how an ONVIF client should validate the authenticity of a signed
stream. Audio is outside of scope.</para>
</chapter>
<chapter xml:id="chapter_spec_version">
<title>Specification version v1.0</title>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note that if we remove this and relay on the Specification revision (e.g., 25.12) only it can take 6 months before a change can be made in the source code.
Example: A change PR is made to this spec in July 2025. It is merged in August 2025 (to the development branch). The 25.12 does still not exist, hence strictly speaking the source code should not be updated to reflect the spec until January 2026. That is an awkwardly long time to wait. Or can we see the development branch as being the draft for next release? It is publicly available. If so, the source code should be fine to update right after merge.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another concern I have with using the specification revision is that if only a small grammar correction is made to the specification, the revision is updated. So even if the bitstream is intact a change from say 27.06 to 27.12 has no impact on what is used on the camera.

Or even worse, is the revision updated every release even if no change is made?

If the version is to be kept as in 24.12 I propose to change the name to "Bitstream version"

<para>This number should be updated when an update to the specification breaks the bitstream
format or when new features are added. Such features could be new ways of hashing or support
of more codecs.</para>
</chapter>
<chapter xml:id="chapter_a3s_njq_bwb">
<title>Normative references</title>
<para>ITU-T Recommendation, H.264: Advanced video coding for generic audiovisual services</para>
Expand Down Expand Up @@ -914,7 +908,7 @@
<itemizedlist>
<listitem>
<para>Tag version (1 byte)</para>
<para>Version = 1</para>
<para>Version = 2</para>
</listitem>
<listitem>
<para>Specification version (3 byte)</para>
Expand All @@ -933,9 +927,18 @@
</listitem>
<listitem>
<para>The UTC (8 bytes) based time represented by the number of 100-nanosecond intervals
since January 1, 1601 of the I-frame leading the GOP.</para>
<para>The timestamp value is a 64 bit parameter and the 8 bytes should be written with
since January 1, 1601 of the frame leading the (partial) GOP.</para>
<para>The start timestamp value is a 64 bit parameter and the 8 bytes should be written with
little endian.</para>
</listitem>
<listitem>
<para>Only present from tag version 2.</para>
<para>The UTC (8 bytes) based time represented by the number of 100-nanosecond intervals
since January 1, 1601 of the frame leading the upcoming (partial) GOP.</para>
<para>The end timestamp value is a 64 bit parameter and the 8 bytes should be written with
little endian.</para>
<para>The duration of the signed (partial) GOP can now be calculated as duration =
"end timestamp" - "start timestamp". Note that the end timestamp is exclusive.</para>
</listitem>
<listitem>
<para>GOP counter (4 bytes)</para>
Expand Down