FLV performance and garbage collection

Question

I'm building a large flash site (AS3) that uses huge FLVs as transition videos from section to section. The FLVs are 1280x800 and are being scaled to 1680x1050 (much of which is not displayed to users with smaller screens), and are around 5-8 seconds apiece. I'm encoding the videos using On2's hi-def codec, VP6-S, and playback is pretty good with native FLV players, Perian-equipped Quicktime, and simple proof-of-concept FLV playback apps built in AS3.

The problem I'm having is that in the context of the actual site, playback isn't as smooth; the framerate isn't quite as good as it should be, and more problematically, there's occasional jerkiness and dropped frames (sometimes pausing the video for as long as a quarter of a second or so). My guess is that this is being caused by garbage collection in the Flash player, which happens nondeterministically and is therefore hard to test and control for.

I'm using a single instance of FLVPlayback to play the videos; I originally was using NetStream objects and so forth directly but switched to FLVPlayback for this reason. Has anyone experienced this sort of jerkiness with FLVPlayback (or more generally, with hi-def Flash video)? Am I right about GC being the culprit here, and if so, is there any way to prevent it during playback of these system-intensive transitions?

Answer 1

Have you tried encoding the videos in H.264 instead? Flash player supports them for some time now, it may end up working better. That's what most people doing HD video in Flash use (eg Youtube, Vimeo, etc).

Just as a test, try plaing a 1080p HD video on youtube and see if that pauses at all for you.

Answer 2

Check out http://zehfernando.com/2010/benchmarking-video-playback-performance-in-flash/

Answer 3

Jerkiness in FLV/F4V playback is hardly the result of garbage collection - the video is actually kept in memory until it is fully unloaded, so there's no garbage collection taking place at all (unless you've done something unorthodox like placing the video on a container with cacheAsBitmap set to true).

Switching to F4Vs if you don't need specific FLV features (like the link posted by daidai suggests - disclaimer, it's my blog) would help, but overall, you also have to be aware of anything that's impacting compositing of the video on screen. Because a big size video forces everything that's overlapping it to be re-rendered, any small object can have a big impact on performance.

Do you have things on top of the video? Try getting rid of them, if possible, or setting cacheAsBitmap to true (if they're not animated). This is specially good for complex vector drawings or text (bitmaps/images are much faster to draw). If they have different blending modes, you're sort of screwed - can you use the normal blending mode instead?

Do you have anything below the video? If so, get rid of them while the video is playing (just set visibility to false).

To check on unnecessary renderings, somehow pause the video, right-click, turn on 'show redrawn regions' (debug player). Do you see the red square drawing continuously? Then there's something happening there on the background, better to get rid of it.

Do you have anything happening on the background via onEnterFrame or timers/intervals? Try pausing it.

Is your video 30fps, and a CG rendering (eg, can use motion blur)? If yes, try rendering at 24fps instead, or something between - still good quality, but much less data to decode and draw.

Can you use smaller videos? Even if you're still rendering them at the same bigger size, less pixel data to decode and render helps immensely, and the impact in quality can be pretty small.

That pretty much sums it all. Getting rid of everything else on screen is usually your #1 priority though.