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

YouTube Seek/swap lag #109

Open
jbenet opened this issue May 2, 2013 · 0 comments
Open

YouTube Seek/swap lag #109

jbenet opened this issue May 2, 2013 · 0 comments

Comments

@jbenet
Copy link
Member

jbenet commented May 2, 2013

Thanks to Bryant for these comments:

short answer

  • don't use "display: none" on a youtube player. take the player and just position it off screen to hide it. i don't remember the exact problems this caused, but it was a headache.

other comments...

  • instead of creating a new player for each video, i just had two that I'd swap back and forth. Always creating a new one led to memory issues and random crashes. though in my case you might watch like 50 straight, i assume most acorn videos are just 4-5.
  • I created my two players up-front so they would be available for use immediately
  • i had the same issue with loadVideoById. need to call playVideo immediately after. and there's no callback to know when it will start playing. so you need to track yourself if you need to know.
  • right after calling loadVideoById() and playVideo() I had a whilePlaying method I called with setInterval. I could detect when it actually had started with "if @youtube and @youtube.getCurrentTime and @youtube.getDuration() > 0". duration is 0 until it's started loaded. and getCurrentTime updates when it starts playing. then x seconds from the end of a video, I'd start the next video. I'd also fade in/out volume here and handle logging plays.
  • the big difference was I didn't care when the next one started, as long as it was before the current one ended. Your situation is a little tricker, where you want an exact cutover (or do you?). A little 1-3 second cross-over (mine was 10 - load time, so usually about 5 seconds) made it really smooth. i'd suggest doing the same, with a volume fade as well.
  • another tricky part was handling z-indexes. I'd pull the new video down over the previous one, then once fully covered, move the old video off screen, then pull the z-index back in front to be ready for the next video.
  • I vaguely remember some weird seeking behavior. but I ended up removing seek and making the service more like a radio, so I'd have to really go digging to find anything there.
jbenet added a commit that referenced this issue May 5, 2013
Following suggestions in #109

This actually fixes the spliced video transition lag!
Except for the first playthrough...
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

1 participant