7th of May 2014 update:  We’ve created a patch for Red5 1.0.2 that fixes the recording issues and compiled a new Red5 build that includes the patch, more details in this blog post.

5th of June 2013 update: Flash Player 11.3.300.257 (the 1st FP 11.3 release) released on the 8th of June 2012 removes the internal upload limit of FP.

28 April 2011 update: updated with latest available information on the issue and link to Red5 1.0 RC1 fix.

This 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 11.3.300.257 (the 1st FP 11.3 release) released on the 8th of June 2012 removes the internal upload limit of FP.

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 prioritises the audio data. Audio data is sent to the media server while the video data is buffered.

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 client buffer that was holding the video data because it became too big

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.
  • Red5 1.0 attempts to fix this issue to by exposing a save data to flv treshold variable, more info on that here.
  • We’ve created a patch for Red5 1.0.2 that fixes the recording issues and created a new Red5 build that includes the patch. More details in this blog post.

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.