Hey SO members,
I want to play back and forth a HTML5 video along with the scroll. The animation controls the video frame by frame regarding scroll amount.
I coded (it's lightweight and very simple) this using scrollMagic. The embedded video are lightweight as well (tried ugly/over downscaled videos with same results).
The issue i'm facing is that when you gently scroll, the animation looks barely smooth.
But when scrolling "fast", it's like many frames are dropped.
I would guess it could be normal, should the progress percentage drop from 50% to 75% for example. But it's not. The percentage displayed in the console shows that percentage value updates smoothly, some frames are not painted and result as a chopped animation. I'd like it to be smooth, no matter how fast the user scrolls. Any thoughts ?
https://jsfiddle.net/yumigo/h7g081n6/72/
I eventually figured out that the video is the key.
The MP4 needs to have a keyframe interval very low (2 in my case, instead of usually 10) to ensure smooth scrolling, especially when scrolling up.
Also, load the mp4 first as webm playback seems more CPU intensive.
Perfectly smooth now.
I updated my jsfiddle.
Related
I have html5 video tags of videos.
On chrome all is good, on firefox the orientation of landscape videos is wrong...
Even tried using video.js, no change.
I read that this is a problem because the videos originated in iOS.
so 2 questions:
1. How can I still overcome this issue. Really there is no solution?
2. (out of curiosity) - how does chrome manage to overcome this?
Example of a URL (scroll down a bit in the chapters to see a vertical video):
http://www.letsfeedme.com/moments/55802f142f2dad3c008b4575-Balsamic-Vinegar-%22Caviar%22
I read that this is a problem because the videos originated in iOS.
All videos recorded using mobile devices will contain rotation metadata including those from iOS and Android devices. It can take 4 values: 0 (tilted left), 90 (portrait), 180 and 270:
On chrome all is good, on firefox the orientation of landscape videos is wrong...
Firefox and IE 10 are the only major browsers not supporting the rotation metadata. Here's Firefox compared with Chrome:
The latest version, Firefox 42 as of today, still does not support it. IE11 and Edge 12,13 do support it.
List of mobile/desktop players that support the rotation info: https://blog.addpipe.com/mp4-rotation-metadata-in-mobile-video-files/
How can I still overcome this issue. Really there is no solution?
See this answer for the solution, basically you need to :
rotate videos using FFmpeg (so Firefox and other browsers that do not support the rotation metadata show the video properly)
remove the rotation metadata (so that other players don't rotate the video since it's already been rotated by FFmepg)
Images courtesy of: https://blog.addpipe.com/mp4-rotation-metadata-in-mobile-video-files/
Since the problem is with some iOS specific encoding options, which many NOT-Apple Players can't read, the easiest solution I can think of is to trancode and rotate the video.
Which was already discussed in oh so many posts on the web and here at SO... e.g.:
Video orientation using video.js
HTML5 mp4 video with firefox resizing video
Chrome HTML5 Video Flipping Portrait Sideways
http://help.videojs.com/discussions/problems/1508-video-orientation-for-iphone-wrong
I am guessing that Chrome is respecting the width="360" and height="640" attributes of your <video> tags, while Firefox is not. If I download one of your videos and play it back in Media Player Classic, again the orientation is incorrect. But just like in web browsers, there are inconsistencies: the same video opened in VLC player plays back with the correct orientation.
I would recommend that, if you can, you re-encode the videos using a (free) program called AVIdemux. I just tried it on one of your videos, and it worked well with minimal effort. As a bonus it shrunk your video down considerably, with only minimal quality loss.
Here are the steps:
Download AVIdemux from http://www.fosshub.com/Avidemux.html
Install and run AVIdemux
Go to File menu and choose Open. Pick the video to re-encode.
Go to Video menu and choose Filters
Choose Transform > Rotate (double-click) > Rotate by 270 degrees (OK)
Click the Preview button to check the output
Click the Close button
In the main window, under Video Output, choose MPEG4-AVC (x264)
Under Output Format, choose MP4 Muxer
Click the Save Video icon, and in the resulting window type a filename and click the Save button.
Then you will need to re-upload your video.
Probably not really a viable solution but adding a CSS rule such as
video {
-moz-transform: rotate(90deg);
}
would at least make the videos play back in the correct orientation in Firefox. Problems with this:
videos that play back in the correct orientation without the rule will play back in the wrong orientation with the rule
the video controls also get rotated
the posters will display in the wrong orientation
I see your site uses video.js. It might be worth looking at https://github.com/xbgmsharp/videojs-rotatezoom ?
I have a game I am developing for a client. Its not a particularly intensive game graphically but it does have quite a few different animations and a large number of textures. It seems that there is a threshold for the number of different spritesheet based animations that I have have in Chrome. When I go beyond that point (about 5 different animations) the FPS tanks to about 5FPS.
The weird thing is the game runs at a solid 60FPS all the time in Firefox with no problems.
It appears that it something to do with the way Chrome does hardware acceleration of the 2D canvas.
Note this video of the game, the game runs at a silky smooth 60FPS (see bottom right for FPS counter) when the game is smaller than about 220px high, but as soon as its even a little higher than that then it runs at 5-10FPS:
https://www.youtube.com/watch?v=3VWo6eQmy1g&feature=youtu.be
I think its got to be related to this issue:
https://code.google.com/p/chromium/issues/detail?id=170021
It says fixed but I dont think it is.
Does anyone have any more info on this?!
Cheers!
using:
Chrome 36.0.1985.125
Foundation Orbit 5.2.2 with animation: slide
I have a slide show, 5 slides, at the top of my page. They are set to transition via slide every 3000 ms.
I first noticed the repaint issue described below due to Fancybox being called near the bottom of the page. While the Fancybox iframe was "popped out" there would be a quick white flash / flicker affecting everything apart from the iframe, every 3 seconds.
Using Chrome's inspector's Timeline view as well as the Rendering option to "Show paint rectangles" proved my suspicions correct.
Even when the slide set (the top of the page) is off screen, still every 3 seconds there is a page-wide repaint. With the inspector's Timeline, I can see a "heartbeat" every 3 seconds in the flow, even when scrolled all the way to the bottom of the page, including a large purple and green spike, where purple represents rendering and green represents painting. With the Rendering option "Show paint rectangles" I see, again even when scrolled all the way to the bottom of the page, a quick flash of every element on the page framed and tinted in green (being painted) every 3 seconds.
I've looked around quite a bit for "foundation orbit flickering," "orbit slideshow repaint" "foundation orbit repaint offscreen," and similar terms and have so far not discovered anything of use.
One or two pages I read mentioned a font change or font flicker at regular intervals relating to the slides' transitions. The "fix" (or workaround) there was to change the animation parameter's value from slide to fade. Trying this, I found that the repaint issue went away completely. However, I would prefer to use the slide transition.
I haven't been able to reproduce this in Safari or Firefox, but I also don't know what developer tools to use in either of those browsers that would confirm or deny whether the repaint is occurring (i.e. the equivalent of Timeline or "Show paint rectangles" in Chrome's inspector). Failing that behind-the-scenes proof, it is the case that in Firefox and Safari, with the Fancybox iframe popped out near the bottom of the page, there is no white flash / flicker, as there is in Chrome due to the repaint.
Any help would be greatly appreciated.
And yes, I realise that the Foundation Orbit slideshow is no longer supported.
Many thanks.
I'm working on a site where the client requested a video fill a div as the background. I have it in and working for myself but they keep complaining that they can't scroll. I have no issues on multiple computers scrolling. Is there some sort of common issue other than a slow machine that would cause this? Could it be a CSS issue? The staging site is here if it helps: http://arkroyal.staging.wpengine.com/
UPDATE
I am using a video hosting service and it seems this is only happening when the flash fallback is in there... I have set it to flash be default now and I can not scroll when my mouse is over it. So now I guess this is a flash issue?
I agree with user3285910's answer, however, that's not to say there isn't anything you can do about it.
When I first went I didn't not attempt to scroll, I just let the entire page load. Afterwards I checked the load times for the media, the Winsta MP4 took 27.36 seconds to load. That's in Chrome on a T1 line. I used Chrome because the webkit browsers are known for their laggy video lading.
With that information I would look at changing the preload value for the <video>. Currently it's "none". There are a lot of different approaches to preloading data and you cannot account for everyone's PC speed, bandwidth, etc.
I would recommend letting the browser determine their capabilities for you and adjusting accordingly. Usually 5-7 seconds of preload is enough to get around the jumping behavior. Here is a link to an article that goes into more detail with analysis.
After looking at the staging site, it doesn't seem to be an issue with the site itself, but more the video you are using. The video is high quality and will cause systems to slow down drastically. If this is the video they want as the BG, I would see if you couldn't get the video resolution lowered drastically, as this will cause issues in the rendering on some systems. This will also make users unable to scroll down the page, because their video card is busy trying to render the images that are being produced by the BG video.
Over the past week I've been helping a friend experiment with SVG-based sprite sheets in the browser. We wanted to come up with an ideal workflow to prepare, publish, and run high-quality animated graphics in the browser. So ideally have a single source of animation data that would work for small smartphone screens, tablets, retina displays, and desktop browsers.
In theory, (vector-based) SVG should be ideal for that, but since SVG is not usually used that much - we decided to test it out. The idea was not to use SMIL SVG (so no SVG-based animation) but instead create an animation sprite-sheet (as you normally would with raster data PNG/JPG) but do this with pure vectors i.e. SVG. Its was a bit bigger but if it works this - it would work even with something thats even more optimized.
Plus frame-by-frame vector animation could do great things for our workflow - it would allow us to use the Flash editor to do the animations and then export them to SVG sprite sheets.
Anyway, the result works surprisingly well but also fails in some areas (please note for test purposes we only worked with Webkit-based browsers i.e. Safari, Chrome, mobile Safari on iOS, and Android ICS).
In CSS it's pretty easy to trigger hardware acceleration for a sprite sheet like this (at least in modern browsers with keyframes and steps) - you simply do this:
background-image: url(my.svg);
-webkit-animation: walk 1s steps(12, end) infinite;
to call keyframe-based animation shown here:
#-webkit-keyframes walk {
from { -webkit-transform: translate3d(0, 0, 0); }
to { -webkit-transform: translate3d(-100%, 0, 0); }
}
where the use of translate3d should let GPU kick in and the entire thing should be hardware accelerated in iOS mobile Safari and Android ICS browser.
Surprisingly enough considering that it's kind of a brute-force technique and a fairly large vector animation (600x600px for the test) - the whole thing flies. But its not perfect - it flickers in Safari before taking off. And in the ICS browser its flickering all the time so its not really usable.
So we tried the usual tricks to get rid of flickering such as:
-webkit-transform: translateZ(0);
-webkit-backface-visibility: hidden;
-webkit-perspective: 1000;
But that didn't work. So then we tried rasterizing SVG dynamically in memory and using it as a texture with -webkit-transform: scale3d(1, 1, 0) but that didn't help ether.
Finally we just replaced the SVG with a rendered out PNG/JPG sprite sheet of the same size thinking the complex vectors are just too much for the browser - but guess what? Its the same issue - so its not SVG rendering at all - its a browser drawing issue. A further proof of that is if we slow the animation down to 1FPS - flickering still persists.
Is the image just too big for GPU? Have we reached the performance limit of what you're able to comfortably draw/animate in the browser (mobile in particular)?
I would really appreciate ideas/hacks on how to potentially get rid of the flickering (especially since its performing sooo fast). Its just a promising technique - hight performance browser animation that adapts to different screen sizes - the HTML5 Holy Grail ;)
With a few optimizations such as
<svg preserveAspectRatio="xMinYMax slice" viewBox="0 0 600 50">
and some CSS magic we're able to have the SVG adapt to its container perfectly and change its size from a single CSS class. It really would work wonders - but alas the flickering.
Anyway - please read more about it here where you're also able to try it out.
Pretty cool idea.
How about changing the zindex of the frames so you are layering the images on top of each other? This might solve the flickering because during the redraw the last frame is still visible. So, you'd just keep increasing the zindex value of the latest frame. Of course, there is a limit to that and you'll need to reset the zindex again, but it might have a big impact on cutting down the flickering.
I don't have ICS here to check it out, but on iOS 6 on an iPhone 5 and Jelly Bean 4.1.1 on a Galaxy Nexus the animation looks pretty smooth, except when I zoom, at which point I get a few flickery frames and then it settles down again.
Which reminded me of a similar issue I was having rendering onto a large canvas and transforming it around the screen (with the majority of the canvas offscreen at any given time).
My black-box analysis at the time suggested it was some optimization where the browser wasn't bothering to render offscreen content, instead waiting until it became visible, which completely defeated the purpose of having the large image and hardware-accelerating it around.
My "solution" was to -webkit-transform: scale the entire image down small enough to guarantee it all fits onscreen (so the browser has no choice but to render the entire image), let it render, and then scale it up to the size I wanted.
(As an aside: to hide this hackery from the user, I initially experimented with setting opacity: 0 so the pre-render wouldn't be visible, but it seems this had the same effect as offscreen rendering - it got optimized out. In the end I set the opacity very low and covered it with an almost opaque "loading" message, meaning the background rendering wasn't visible to the naked eye, but the browser had no absolute visible/invisibles to optimize out. Not sure if this was overkill, but it seemed to work for my setup.)
I'd be very interested to know if a similar technique might work for you.