We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
@jwcullen In iamf-tools, I checked most timetamp is defined by int32_t, is it necessary to use int64_t ?
int32_t
int64_t
The text was updated successfully, but these errors were encountered:
It is just an internal timestamp. It increases based on the sample rate. It was sort of a leftover from when there was a Sync OBU.
I do see it is small enough to limit encoding to ~12 hrs of 48000 Hz:
(2^31 - 1) / 48000 Hz ~= limited to 44739 seconds ~= 12 hrs
So I'm tagging this as a bug because that limit is plausible to reach. int64_t does seem better.
Sorry, something went wrong.
No branches or pull requests
@jwcullen
In iamf-tools, I checked most timetamp is defined by
int32_t
,is it necessary to use
int64_t
?The text was updated successfully, but these errors were encountered: