AVChat Software Product Blog

AVChat 3 uses a media server (like Red5 and FMIS) to stream audio and video between users. The audio and video data travels from the broadcaster user to the media server and from there to the receiver user. While it goes trough the server the audio and video data can be captured and stored in .flv files.

Codecs being used…

The audio track will be encoded with the NellyMoser codec and the video track will be encoded with the Sorenson Spark h.263 video codec. The audio and video encoding is done  by Flash Player (before it sends the data to the media server), and Flash Player can only encode with those codecs.

So when the audio and video data hits the media server it is already encoded, the media server just saves the data into .flv files!

Enabling audio/video streams recording

The feature is disabled by default because it tends to use large amounts of space over the time.

If you use Red5:

1. edit avchat30/avchat3.properties
2. set recordAudioVideoStreams=true
3. restart Red5

You will find the resulting .flv files in Red5/webapps/avchat30/streams/_definst_

If you use FMIS:

1. edit avchat30/settings.asc
2. set recordAudioVideoStreams=true
3. reload the avchat30 FMIS application using the FMIS Management Console (or restart FMIS)

You will find the resulting .flv files in FMS/applications/avchat30/streams/_definst_.

Audio Video Quality

On the media server it is recorded whatever gets sent from the client .swf file, so to increase the audio/video quality of the recordings you need to increase the audio/video quality used inside the video chat software.

Important: Because you are recording audio/video streams that are destined for live viewing, the quality of the recordings  is not as high as the quality that you get with a dedicated Flash video recording software like our Flash Video Recorder. Live streams are maintained as “live” as possible by Flash Player and the media server by dropping video frames and even stopping the video data from being sent to the media server because audio data has higher priority than video data (this will only happen over slow connections tough where audio+video data just doesn’t t fit trough in a “live” way).

Playing back the recorded files

To play back the .flv files on your desktop you can use  this desktop flv player from Martijn de Visser.

To play back the .flv files on your website directly from the media server you can use any flash video player for websites that supports streaming. I recommend JW FLV Media Player or Flow Player. You can also move the .flv files from your media server to your web server and deliver them to your users via progressive download (YouTube in its first months)

.flv files with no meta data

Because of the way they are recorded, some .flv files will end up having no duration metadata, thus resulting in funny playback. To fix this run those flv files trough flvmdi or flvtool2.

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!

This post is the first part out of a 3 part series on how to record high quality flash video over the Internet. We’ve learned a lot while doing video recorders for our clients and while developing the AVRecorder bundle and we would like to share some of that knowledge with the community!

At the end of this 3 part series you will be able to record DVD like videos over the Internet using a simple audio video recorder made in Flash or Flex Builder (as2 or as3).

So, Part 1: In the client swf application use a big buffer on the outgoing stream.

All flash video recording applications are made out of 2 parts: the client side application, (a swf file embedded in a HTML page) and the media server application which can be Flash Media Server, Red5 or Wowza.

By the client application I mean the swf that gets embedded in the website, the actual recording application developed in Flash or Flex Builder that people will see and use.

The buffer is where the audio and video data are stored before they are sent to the media server, and it needs to be as big as possible to ensure that all the data captured from the web cam and mic are sent to the media server instead of being dumped (which is what happens over slow connections if you’ve got a small buffer)!

On a high-speed connection, the buffer size is not  a concern because data is sent almost as quickly as Flash Player can capture it.

When recording video over slow connections the buffer behaves just like a funnel! If a user is trying to record a 500Kbits/s video over a 300Kbits/s connection with the media server, the data that can not be sent as soon as it is captured and some of it (about 200kb every second in this case) is stored in the buffer until its time comes to travel to the media server. The bigger the buffer, the more data can be stored in it! As soon as the buffer fills, all the data in it will be dumped by the Flash Player, so you want to be sure you have a big buffer.

I typically use buffers about 60 or more seconds for recording applications, you can go even higher if the recording application might be used for recording long movies!

To set a big buffer on the publishing/outgoing stream in the client swf you use:

• in as2 this function : NetStream.setBufferTime(60)
• in as3 this property : NetStream.bufferTime = 60

This is it! The next part will cover waiting for all the audio and video data to be sent to the media server before you display any success/ok message to the user!

Update: Part 2 can be accessed here: http://www.avchat.net/blog/?p=33
Even later update: Part 3 is now available: http://www.avchat.net/blog/?p=27