Skip to content
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.

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

Add taic, itai timestamp boxes #1003

Open
farindk opened this issue Oct 19, 2023 · 3 comments
Open

Add taic, itai timestamp boxes #1003

farindk opened this issue Oct 19, 2023 · 3 comments

Comments

@farindk
Copy link
Contributor

farindk commented Oct 19, 2023

This is work in progress, but ultimatively add ‘taic’ & ‘itai’ boxes which provide support for nano-precision timestamps.

@farindk
Copy link
Contributor Author

farindk commented Nov 12, 2023

taic uses a float32 value. Where is it defined how that value is stored in the file (little-endian / big-endian)?
Have you considered using an integer value for this in the standard?

@farindk
Copy link
Contributor Author

farindk commented Nov 13, 2023

Another point: I'd like to remove status_bits from heif_property_set_tai_timestamp(). If I read the spec correctly, timestamp_validity can be derived from TAI_timestamp (see my comments to the specs).
synchronization_status should be an extra parameter. It is the responsibility of the library to put this into the correct bits. That's exactly what should be transparent to the user.

Am I correct with the first assumption? Can we derive timestamp_validity from TAI_timestamp==0xFFFF....FFFF ?

@bradh
Copy link
Contributor

bradh commented Nov 13, 2023

taic uses a float32 value. Where is it defined how that value is stored in the file (little-endian / big-endian)?

It should (currently) be double(32) which is a big-endian value (see ISO 14496-1:2010 Section 8.2.2 - "most significant byte first").

Apparently there is a new part (-34) that will clarify the syntax, by codifying all the inconsistencies as normative. That will make double an obsolete alias and introduce float(32). See https://www.mpeg.org/structure/systems/ (https://www.mpeg.org/wp-content/uploads/mpeg_meetings/143_Geneva/w22951.zip for the draft)

Have you considered using an integer value for this in the standard?

Seems reasonable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants