Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Holo_Back

Play Video Reverse with GSAP

Recommended Posts

Hi everyone,

 

I'm trying to play a short video clip on mouseover and play it reverse on mouseout:

 

mouseover: video.play()

mouseout: video.playReverse()

 

As there is currently no native function for playing a video reverse, I tried it with setInterval by manipulating currentTime, but this solution is not smooth enough.

Is there a smooth solution with GSAP to play a video backwards?

Link to post
Share on other sites

Hey Holo_Back. Video formats are not designed to be played in reverse. The following is probably about as good as you're going to get and it's pretty choppy to me in reverse:

See the Pen OJNzNRb by GreenSock (@GreenSock) on CodePen

 

Note that this is not a limitation in GSAP - GSAP is doing it's job. It's a limitation of the video formatting and how browsers render video.

  • Like 1
Link to post
Share on other sites

Hi Zach,

 

thanks a lot for your fast response!

Unfortunately it's as choppy as my solution - let me show you what we want to achieve:

 

Basically we have developed a car configurator for a sports car tuning company and now we want to extend the manufacturer grid with short 3D car renderings (.mp4) instead of simple images, which are animated on mouseenter and mouseleave - is there a better solution without videos?

Link to post
Share on other sites

Yeah, like Zach said this has nothing to do with GSAP. I think it's related to how your video is encoded (and how video playback of encoded video works at its core). There are keyframes in compressed video, typically every X frames (you decide when you encode) and then it only saves the CHANGES on subsequent frames, until it reaches the next keyframe. So when you play forward, it is flawless and smooth. When you go backwards, it's much more difficult on the computer because it either just burps and renders the previous keyframe (which may be 15, 30, 60, or even 90 frames earlier) or it must find the previous keyframe and iterate through all the changed frames after that until it reaches the desired time. 

 

So you could encode your video with keyframes MUCH more frequent (literally making every frame a keyframe would deliver amazing quality and smoothness), but the file size will probably go up drastically (because it's forced to save a lot more data). 

 

Again, this is totally unrelated to GSAP. It's about video encoding/decoding. 

 

Instead of video you could use a series of images or a spritesheet, but I'm guessing that'd end up being more kb overall. 

  • Like 1
Link to post
Share on other sites

Hi GreenSock,

 

thanks a lot for your feedback!

 

We thought about image series and spritesheets to, but as you've mentioned, the file size is a problem. I'll talk to our video guy to experiment with different encoding techniques.

 

Thanks and have a nice day!

  • Like 1
Link to post
Share on other sites

A frame by frame animation with images is almost always the way to go with something like this performance wise. Syncing audio becomes more difficult if you need that but the actual switching out images is much more performant. Using modern image compression and file types the file size usually isn't terrible in the end unless you have a really long video/animation.

Link to post
Share on other sites

Hi Zach, okay we'll try that too - can you provide a best practise example with GSAP?

Link to post
Share on other sites

It depends on whether you're using a single sprite or a bunch of images. I'd guess you'll find it's better with a bunch of images in which case this example provides a framework for what you need:

See the Pen VweybzG by GreenSock (@GreenSock) on CodePen

  • Like 1
Link to post
Share on other sites

Great, I think that's exactly what we are looking for :) Thanks!

Link to post
Share on other sites

Hi Zach,

 

we tried your solution and it works great, but the thing is, we have 19 manufacturers with 119 frames/jpegs per manufacturer and therefore the loading times are very long, even though we are using latest compression techniques and async loading (IntersectionObserver). Is there a solution for this problem?

Link to post
Share on other sites

I highly recommend using a modern image file format. Doing so can bring your total file size down a good bit. Compressing frames that aren't seen much (like ones that are only used for transitions) can also help. But ultimately if you have a lot of images then there's not much more you can do besides cut down the manufacturers or frames per manufacturer.

Link to post
Share on other sites

It doesn't change anything if we use .webp instead of .jpg or .png, because - as you have mentioned - the amount of requests is too high with 19 manufacturers and 119 frames per manufacturer. We'll try cutting down the frames per manufacturer, otherwise we probably need to throw away this idea for now...

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×