-
Notifications
You must be signed in to change notification settings - Fork 1
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
LU-3407 first frame #59
Conversation
✅ Linked to Bug LU-3407 · Avatar isn't visible the first frame |
// If we're looking for a frame at 2500, we want to return the frame at 2000 | ||
const closestFrame = filteredFrames.reverse().find(f => f.pts <= targetPTS); | ||
const closestFrame = (this.#packetReadCount === 1 && filteredFrames[0].pts > targetPTS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this work with looping too? like if we seek back to an earlier timestamp. I'm not sure how framefusion handles that but could be a case to consider? So if we play and then loop back to the start (maybe not a use case for AI avatar specifically now but is a use case more generally)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll add a test for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we have a few tests for looping: can get frames at random times (forward and backward)
and can get frames when looping
. Both of them passed with my changes so I think we're good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but I'm guessing those tests don't use the new code path? Like the case for when PTS is greater than what we're looking for
When seeking to time 0 for our avatar
webm
videos, we wouldn't be able a frame. That's because we would skip a packet if its PTS was larger than the target PTS. So if we're looking for a PTS of 0 and the first packet would have a PTS of 100 then we would return (and thus end up with nothing). I've fixed this here so if the first packet has a higher PTS then the requested PTS, then we use that one which solves our no frame at 0 issue.