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

AVPlayer timescale warnings #52

Open
vorg opened this issue Mar 4, 2016 · 2 comments
Open

AVPlayer timescale warnings #52

vorg opened this issue Mar 4, 2016 · 2 comments

Comments

@vorg
Copy link
Contributor

vorg commented Mar 4, 2016

I'm getting following error when using player.seekToTime(1.1)

2016-03-04 09:25:43.907 Plask[26985:5357889] CMTimeMakeWithSeconds(1.100 seconds, timescale 1): warning: error of -0.100 introduced due to very low timescale

I can see that you have marked plask_bindings.mm#L7491 as FIXME, why?

CMTime time = (curtime.flags & kCMTimeFlags_Valid) ?
        CMTimeMakeWithSeconds(args[0]->NumberValue(), curtime.timescale) :
        CMTimeMakeWithSeconds(args[0]->NumberValue(), 50000);  // FIXME
@deanm
Copy link
Owner

deanm commented Mar 4, 2016

Basically CMTime is a struct { int64 value; int32 timescale; }, it is a numerator / denominator representation, so the time is value / timescale. But notice that the value is an int64. So what the above is saying is you wanted to represent 1.1 as a CMTime, with a timescale of 1, which means 1.1 will be truncated to 1, so that's why the -0.1 error is introduced. I am not sure where the timescale of 1 came from, but I guess it's from curtime.timescale... I don't know why [player currentTime] would return a timescale of 1. I had sort of thought it would always use the same timescale, but perhaps not. I would have thought timescale was related to the frames per second of the video and would just always be constant, so the value portion would sort of be the frame number. I've seen some code that gets timescale from the duration instead of from currentTime, but not sure if that would make a difference.

Perhaps it's just that currentTime is zero and zero always has a timescale of 1?

Anyway, I think the options would be:

  • Get timescale from duration instead of currentTime, see if that has a better timescale.
  • Always use some hardcoded timescale (like 50000). In theory this isn't perfect because it should depend on the FPS/encoding of the video, but it probably doesn't matter so much in practice.
  • Do some combination, checking the timescale, and if it's not good fall back to hardcoded. That's basically what it is now but perhaps we add some more to the check.

@ixeau
Copy link

ixeau commented Jan 19, 2017

You explanation was really helpful for me @deanm, thank you!

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

3 participants