On slower machines (like older iPhones, or old Windows machines running IE) ogv.js now makes better use of dual-core CPUs to overlap decoding one frame with drawing another, etc. It's also much more aggressive about keeping audio and video synchronized, making short delays instead of letting it get wildly out of sync followed by a weird catchup period.

With the seek & sync bugs mostly cleaned up, I'm also turning some of my A/V attention to iOS, making updates to my OGVKit Objective-C library which uses native builds of the Ogg and VPX libraries, able to handle higher resolutions on slower phones than ogv.js can. I'll track down the current iOS mobile app folks and see what the best way to work with them on this is. :)

Back to TimedMediaHandler -- Derk-Jan has been doing some more updates on the Video.JS-based new frontend code, which I'm reviewing through this week and hope to have merged and cleaned up for further testing. In addition to looking more modern and being more actively maintained, video.js is more mobile-friendly -- deploying the new frontend when it's ready will get us more consistent media playback on Android, and ogv.js-based playback on iPhone and iPads in the mobile view.

I've also got a number of back-end fixes to finish up such as a new maintenance script for re-running video transcodes. It currently needs just one more option, which is a 'throttle' so we can background-run it unattended without worrying it'll fill up the job queues.

Farther out in the future -- I did testing last month on transcoding, and some preliminary planning for how to do adaptive streaming (seamless resolution switching as necessary). I've got a pretty good handle on how it will work for native WebM playback, and a good theoretical model for how it should be possible with ogv.js and Ogg playback by creating an analogue of the native Media Source Extensions APIs, and encoding / dividing up the packetized files _just so_.

Note that creating adaptive-switchable Ogg transcodes will require customizing ffmpeg2theora and/or creating a separate similar tool specific to our needs. Shouldn't require any new daemons/services though.

-- brion