Recording High Quality Flash Video Over Slow Internet Connections Part 3 (Behaviour of client side buffer)
Thursday, April 2nd, 2009This post is part 3 of our 3 part series on recording high quality Flash video over slow connections.
In theory whenever someone is trying to use a flash video recorder to:
- record audio/video at a data rate higher than the upload connection to the media server (Red5, FMS, Wowza, etc..) allows,
- record audio/video at a data rate higher than about 1Mbit/s (which seems to be the upload/streaming limit in Flash Player)
Flash Player should buffer both the audio and video data until it can be properly sent to the video server, but what really happens is it starts buffering just the video data and keeps sending the audio data to the media server.
It does that because Flash Player thinks all streams are live (even those specifically destined for being recorded) so it tries to at least keep the audio “live” if its not possible to keep both audio+video “live”.
What happens now is that the video frames will arrive at the media server:
- later than the corresponding audio frame
- arrive after the media server has already written the corresponding audio frames to the .flv file
- never arrive, because Flash Player has flushed the client buffer that was holding the video data
This can cause several issues in the final .flv file:
- missing or little video data across some sections
- sudden increases in video frame rates (the video plays in a “fast forward” way because several video frames finally reach the server as a bundle)
- flv files with static video, normal audio playback and the rest of the video data grouped at the end
- flv files with large areas where you can not seek (because there is only audio data in those areas)
- out of sync audio and video
To solve this issue, some media servers are now waiting longer for the video data to come from the client (flash video recording software) before writing the existing audio data to the .flv file:
- Wowza Media Server and Flash Media Interactive Server 3.5 both solve this issue out of the box.
- Flash Media Interactive Server 3.0 can also solve this issue by adding some custom/hidden XML tags to Server.xml.
- Red5 up to 0.9.1 has this issue and a bug has been submitted which you can follow here here.
- Red5 1.0 attempts to fix this issue to by exposing a save data to flv treshold variable, more info on that here.
This concludes our 3 parts (part 1, part 2) series on recording high quality audio and video files over slow connections.
Next I think we will talk about increasing the audio and video quality for the average user!
28 April update: updated with latest available information on the issue and link to Red5 1.0 RC1 fix.