AVChat Software Product Blog

This post is part 3 of our 3 part series on recording high quality Flash video over slow connections.

Whenever someone is trying to use a flash video recorder to record audio/video at a higher data rate than the connection to the media server (Red5, FMS, Wowza, etc..) allows, Flash Player, in theory, will buffer the audio and video data until it can be properly sent to the video server.

But that is not a quite exact description about what really happens!

What really happens is this: whenever Flash Player detects a low quality connection to the video server, it starts buffering 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:

1. later than the corresponding audio frame
2. arrive after the media server has already written the corresponding audio frames to the .flv file
3. never arrive, because Flash Player has flushed the data in 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, 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 also solves this issue by modifying Server.xml.

Red5 still has this issue and a bug has been submitted which you can follow here 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!