# \[EXPERT\]Variable framerate FLV playback **URL:** \ **Category:** flash\ **Created:** [July 31, 2012, 3:53pm UTC](https://forum.kirupa.com/t/expert-variable-framerate-flv-playback/329197 "2012-07-31T15:53:23Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![archont](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/archont/32/2076_2.png) [@archont](https://forum.kirupa.com/u/archont)\ **Post date:** [July 31, 2012, 3:53pm UTC](https://forum.kirupa.com/t/expert-variable-framerate-flv-playback/329197/1 "2012-07-31T15:53:23Z")
Hello, a question for the flash _hackers_ here: The project I’m doing requires dynamic variable FLV playback speed adjustment. The user is de facto running on a threadmill with a sensor. The faster the user runs the faster the video displayed on the monitor plays. A similar desktop-based tech was done here:[http://outsideinteractive.net/software.php](http://outsideinteractive.net/software.php) I realize this problem is generally regarded as impossible using traditional methods but I’m willing to go the extra mile and try experimental technologies. Here’s what I’ve come up so far: [SIZE=4][FONT=century gothic]1) Interpolation-based seeking[/FONT][/SIZE] seek to the nearest frame that corresponds to where the video should be and stop, repeat every frame. **CONS:** choppy as hell, buffer may/will go FUBAR **PROS:** simple and allows for fully dynamic variable playback [SIZE=4][FONT=century gothic]2) Software frame buffer[/FONT][/SIZE] Render video to bitmaps and store the bitmaps in a buffer, display and then discard them according to the frame rate. **PROS:** video display has potential to be smooth if the buffer can be rendered on time **CONS:** garbage collector will have a field day - a single frame of 720p is 3,5mB, 48 frames are 170mB. In addition the CPU load may set the machine on fire or something. [FONT=century gothic][SIZE=4]3) Multithreaded frame buffer using worker threads[/SIZE][/FONT] Basically option 2, just that the rendering isn’t done in the main thread but in separate workers. Reserves 1 to 3 cores to rendering the video to bitmap and pushing it to the software frame buffer. **PROS:** theoretically faster playback as up to 3 cores can be used to render the frames \*\*CONS: \*\*I have no idea how efficient sending data between threads is but the worst case scenario is 85mB/second. The runtime may curl up and die. [SIZE=4][FONT=century gothic] 4) Serverside time disortion and streaming[/FONT][/SIZE] The client just passively displays a live stream, the server does the actual work by adjusting the video stream realtime. A server like FMS or RED5 will be used. **PROS:** Will work on any machine, anywhere, easy to implement client-side **CONS:** Required dedicated server (and a VERY beefy one at that), doesn’t use client-side number crunching power (which is free) [SIZE=4][FONT=century gothic]5) Native browser plugin[/FONT][/SIZE] Simply enough develop my own plugin, much like the DivX video player, VLC plugin or PDF reader… or flash itself! **PROS:** native code performance, will run on any machine **CONS:** different browsers, different operating systems - too close to the silicon for comfort. And building a cross-platform UI in C is a ɥɔʇıq. In addition that seems to be too much complexity for the project - there has to be a simpler way. [SIZE=4][FONT=century gothic]6) Several speed-adjusted videos _(courtesy of bwhiting)_ [/FONT][/SIZE]Create a series of videos with different actual speeds - let’s say 1.4, 1.8, 2.2, 2.6, 3.0 - that’s 5 videos for speeds from 1 to 3. Then play the correct video depending on which speed is required **PROS:** the simplest solution, elegant, only one video playing, low resource usage **CONS:** requires a fiber-optic connection, streaming 5 HD videos at the same time will kill the memory and the bandwidth. Switching in-between may be choppy and there’s little granularity in speed. When the desired speed oscillates at the border levels the videos will constantly switch. [SIZE=4][FONT=century gothic]7) Dynamic RAW video re-encoding\* (courtesy of cleong)\* [/FONT][/SIZE]Decode the video, speed it up and encode it back into a RAW format, then stream that RAW bytearray to the player - do the computing in a separate thread and use alchemy for speed. **PROS:** potentially the fastest and best solution - the Video object is the best for displaying Videos and the only performance hit is during the re-encoding. **CONS:** I have absolutely no idea how to speed-up and reencode the video in a FAST way. Do you? What do you think about those approaches? Which is the best? What would _YOU_ do? Maybe you have a different approach? Any thoughts, ideas, tips, lolcat images, links, code samples or whatever input is appreciated and welcome.