As part of a recent project we have been involved in producing a series of short videos for increasing the awareness of doctors of how to use a physiotherapy referal service. A technical am of this project has been to deliver these videos to both PCs and mobile devices, but without using a video delivery service such as YouTube or Vimeo. So we wanted to encode one version of the video file into a format that would play in a flash video player embedded in a web page and also be playable on the iPhone/iPad which obviously doesn’t currently have a flash player.
Unfortunately it then turned out we had another more significant issue to overcome. Once we had uploaded our video files and began testing them on-line we encountered serious audio synchronisation issues in the videos when viewing on a PC. This problem did not affect viewing on an iPhone and seemed to disappear if the video was paused and restarted. Initially we thought this must be an intermittant file caching issue. However the same problem was reported by various viewers and we slowly realised this was more serious.
A web search eventually found this forum post by Andrew Wallace which appeared to shed light on this problem:
The H.264 is not a completely “contained” compression method — by this I mean that Audio and Video tracks are still treated as separate entities that only QuickTime can recognize integrated timing information to match each track with one another. Flash, however, can not detect this information and so when it sees a gap of no audio, it shifts the remaining audio to fill in the gap, thus causing a sync issue. Why? Not entirely sure — it’s a Flash issue that has never been addressed by Macromedia/Adobe.
The same post suggests a solution to this problem:
Create a white noise track (generated in a sound program like Soundtrack) that is the complete duration of your video tracks and insert it underneath your currently existing audio track. Set the level to around -70dB thus making it inaudible. This track acts as a binding track to keep things in sync. Export as a self-contained file and compress as you normally would. You can still use H.264 as your compression method.
A subsequent post in the same thread suggests that this solution isn’t necessarily always successful…
So what to do… for this particular project we have now chosen to encode into FLV format for PC delivery and offer a separate H.264 version for iPhone/iPad viewers and provide jQuery tabs to allow selection between the video options available. This is not to suggest that a single video format can’t be used, but we have discovered this is not as simple as it appears and so we opted to use a tried and tested approach that we can have confidence in.