AVChat Software Product Blog

Both the HD Flash Video Recorder and the FLV Audio Recorder grab the audio/video data from the webcam/mic, encode it and send it to the media server where it is saved in a .flv file.

The folder where the .flv files are crated can be changed on FMIS. To do this you need to :

1. Copy conf\_defaultRoot_\_defaultVHost_\Application.xml to applications/hdfvr or to applications/audiorecorder.
2. Edit the newly copied Application.xml with a text editor.
3. Change the value of the <StorageDir></StorageDir> tag (line 191) to the folder where you want the .flv files to be created.
4. Save Application.xml and restart FMIS or reload the application using the FMIS Management Console.

Why a connection attempt to a working media server might fail:

Red5, FMIS and Wowza by default only accept  rtmp connections over port 1935. This will work fine for most home Internet connections however when your user is behind a corporate firewall/network he might hit 2 major restrictions:

1. NO traffic/connections to non standard ports like 1935 (default port for rtmp). Traffic is only allowed to standard ports like 80 (http) and 443 (https) . The solution for this is to configure the media server to accept  rtmp connections over ports 443 and 80 .
2. NO non-http traffic allowed (or a proxy server is used). The solution for this is to configure the media server to accept  rtmpt connections. Rtmpt is rtmp wrapped as http and its slower. It also adds some overhead/consumes more bandwidth because each rtmp packet needs to be wrapped as http. According to a 2004 Adobe article, only 4% of Internet users are behind such a network.

The automatic connection sequence in Flash Player:

By default, when a Flash Player app (AVChat 3 for example) tries to connect to a media server (Red5, FMIS or Wowza), it automatically tries to establish a connection by using the following sequence of ports and protocols:

1. rtmp://myserver:1935/avchat30/_definst_
2. rtmp://myserver:443/avchat30/_definst_
3. rtmp://myserver:80/avchat30/_definst_
4. rtmpt://myserver:80/avchat30/_definst_

This connection sequence can enable connections to succeed that otherwise would not. This automatic retry sequence occurs only if the initial connection specifies the RTMP protocol and does not specify a port – for example rtmp://myserver/avchat30/_definst_ . During this connection sequence, users may wait several seconds for multiple connection attempts to time out.

However for the above connection sequence to actually produce more sucessfull connection attempts, the media server must also be properly configured to listen for rtmp connections over ports 1935, 443 and 80 and for rtmpt connections over port 80.

Configuring your media server for best connection success rate:

[Before making the below changes make sure there is no other program listening on port 80 or 443 on your media server. These ports are surely already used by Apache. Use the netstat -ant command on linux to see which ports are already used.  FMIS, Red5 and Wowza use port 1935 by default for a reason]

If you’re using FMIS:

• solution for restriction 1: configure it to listen for rtmp connections over ports 1935, 443 and 80. You need to edit conf/fms.ini, set ADAPTOR.HOSTPORT = :1935,443,80 and restart FMIS. Make sure you don’t have other apps (like the Apache web server) started and listening on 80 or 443.
• solution for restriction 2:  same as above, FMIS can listen for both rtmp and rtmpt connections over the same ports at the same time

Most FMIS hosting services (like influxis.com) are already configured like this  out of the box.

If you’re using  Wowza:

• solution for restriction 1: make it listen for rtmp connections over ports 1935, 443 and 80. You need to edit conf/VHost.xml , set <Port>1935,443,80</Port> and restart Wowza. Make sure you don’t have other apps (like the Apache web server) started and listening on 80 or 443.
• solution for restriction 2: same as above, Wowza can listen for both rtmp and rtmpt connections over the same ports at the same time

If you’re using Red5:

• solution for restriction 1: bind rtmp connections to port 443 instead of 1935 (Red5 0.9 can not listen for rtmp connections over several simultaneous ports like Wowza and FMIS can). You need to edit conf/red5.properties, set rtmp.port=443 and restart Red5. Make sure you don’t have other apps (like the Apache web server) started and listening on 443 . You can also use port 80 but we will use that for listening for rtmpt connections as explained below.
• solution for restriction 2: bind rtmpt connections to port 80. You need to edit conf/red5.properties, set rtmpt.port=80 and restart Red5. Make sure you don’t have other apps (like the Apache web server) started and listening on 80.

How can you check your connection

Here you will find 2 port testers which will attempt to establish rtmp and rtmpt connections (using all ports) to a properly configured media server. Red5 ships with a similar tool and you can download another one from here.

More info

There is a great article (from 2005 I think) on the Adobe website that goes more in depth about these issues. I recommend you read it if you want to understand a little bit more about how the Internet works and why these steps are necessary and why such configurations are not the default: http://www.adobe.com/devnet/flashcom/articles/firewalls_proxy.html .

About bandwidth usage

The bandwidth usage/month depends on many factors and can never be guessed without several days of actual running the video chat software on your website:

• number of people online watching cams and how much time they spend watching
• number of people online broadcasting cams and how much time they spend broadcasting
• how many cams a user can see at once
• audio/video quality (128,256,512kbits/s etc…)

For example a user broadcasting its webcam for 30 minutes at 256kbits/s will use  57Mbytes of bandwdith (256kbits/s * 60 seconds * 30 minutes=57Mbytes).

Another user viewing the first one for 30 minutes will use the same amount: 57Mbytes. Total: 114Mbytes for a 30 minute 1 to 1 video chat session.

Reducing bandwidth usage

AVChat 3 offers several ways to reduce the monthly bandwidth used on the media server:

• the automatic bandwidth reduction feature which is on by default
• you can lower the audio/video quality for the streams so that they use less bandwidth
• you can limit the amount of time/day users can view web cams
• you can limit the amount of web cams users can view at once (4 by default)

Error 1: If, when trying to connect using AVChat 3, you are getting this error message: Connection failed, media server might be down or firewall might be blocking the connection! like this:

You need to check:

• your rtmp connection string inserted in avc_settings.xxx
• the media server might not be running (you can check if Red5 is running by going to http://yourred5server.com:5080/)
• the media server might have not started properly (thus is not running, you can check the logs in Red5/log for any ERROR messages during startup)
• there is a firewall on the media server blocking TCP traffic over port 1935 (and 5080)
• the user trying to connect is behind a firewall that blocks the connection (either a personal one installed on his computer or a corporate one installed on his network, to test his connection capabilities he should run these connection tests: http://www.flashcomguru.com/apps/port_test/index.cfm )

Error 2: If, when trying to connect using AVChat 3, you are getting this error message:  Connection Rejected:No scope ”avchat30/_definst_” on this server OR The connection with the video chat server could not be made like this:

It means you are using Red5 and your Red5  is running but:

• make sure you use Red5 0.8 final (AVChat 3 is not compatible with any other versions)
• make sure you installed the AVChat 3 Red5 server files properly (Red5/webapps/avchat30)
• make sure you restart Red5 after you installed the Red5 server side files (Red5/webapps/avchat30)

Error 3: When trying to connect using AVChat 3, you are getting this error message: Application (avchat30) is not defined , like this:

There are 2 causes/solutions for this error:

• you are using FMIS and you have not created the FMIS server side avchat30 app (FMIS/applications/avchat30), follow the installation instructions and try again.
• If the avchat30 app folder is installed properly restart the FMIS server (or just the vHost trough the FMS Management Console)

Error 4: When trying to connect using AVChat 3, you are getting this error message: Connection success, waiting for server… .

There is 1 possibe cause/solution for this issue:

• the avchat30 application folder was not installed properly on the media server (it does not contain the proper files). make sure you follow the installation instructions for the avchat30 app folder exactly.

Changing the license key:

Why would I change the license key?

• Insert a new trial key
• Switch from trial to non-trial key
• Switch the domain on which the software will be used
• Upgrade from Lite to 40 users (for example)

What do I have to do?

1. Log in the video chat using the admin interface (admin.swf)
2. Click the Settings button at the top
3. In the window that shows up, delete the old key from the text field and insert the new key
4. Press the [Change Key] button
5. If successful, you should now see the new  limits/expiration date/domain above the license key text field!

Resetting the license key:

If something goes awfully wrong and you find yourself locked out of the video chat (you’ve inserted a key for a domain to which you do not have yet access or has not yet been registered ) you can reset the license key.

What do I have to do?

1. Delete this file
   • on Red5:   red5/webapps/avchat30/persistence/SharedObject/_definst_/licensekey.red5
   • on FMIS:   fms/applications/avchat30/sharedobjects/_definst_/licensekey.fso
   • on Wowza: wowza/applications/avchat30/sharedobjects/_definst_/licensekey.rso
     
2. Restart Red5, FMIS or Wowza
3. Enter the video chat and you will be asked for the key again!

To see what AVChat 3 build you have installed you need to right click on the video chat software. The first item in the menu that shows up is the build number:

The AVChat 3 build number showing up on right click!

Why is the build number important?

The build number allows you to check if you have the latest version of our software.  If your build number is 284 and on the blog we announce a  new release with the build number 340, then it means you should consider upgrading your installation!

Each increment in the build number might represent any of the following things:

• code cleaning
• bug fix
• new feature
• new file
• new entry in the translation file
• new setting in the config files
• etc…

but you should check the release notes for the exact new features and bug fixes in each build.

Build numbers on our demo of AVChat 3

Our online demo of AVChat 3 is frequently updated, so even tough the latest build available for download might be 284, the demo might be 310 for example. We update the demo more frequently to test new features and UI changes before we release these changes to the customers.

In the side menu for other people’s web cams, AVChat 3 now shows an estimation of how much it takes for the video and audio data to travel from the broadcaster to the viewer (trough the media server) . We call this value trip time but its also known as latency.

Video Stream Trip Time

The value is not always 100% exact but it is a really good estimation!

For one to many broadcasts the trip time value  is not important, live TV broadcasts generally  have a 5-15 seconds delay to give broadcasters time to censor any audio needing censorship

A low trip time is really important when the audio/video communication goes both ways, for example when 2 people are in a video conference. Imagine what would happen if when talking with someone over the phone it would take 5 seconds for your voice to travel from you to the other person.

The trip time in AVChat 3 is influenced by

• how close the broadcaster and the viewer are to the media server
• sound quality (paradoxically the higher the better)
• the Internet connection of the broadcaster and the viewer

Trip time values you are likely to get when your video chat users are close to the media server and have good, low latency, Internet connections:

• 200 ms on audio+video streams
• 50ms on video only streams

AVChat 3 uses a media server (like Red5 and FMIS and Wowza) 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/viewer . While it goes trough the server the audio and video data can be captured and stored in .flv files.

Codecs being used…

The audio data will be encoded with wither the NellyMoser or Speex codec (depnding on your audio settings) and the video data 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 new .flv files in Red5/webapps/avchat30/streams/_definst_

The flv files are named like this: username+ “_”+ unique user id assigned by FMS + “_”+ timestamp (from when the userstarted publishing ).

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 new .flv files in FMS/applications/avchat30/streams/_definst_.

The flv files are named like this: username+ “_”+ unique user id assigned by FMS + “_”+ timestamp (from when the user connected to FMIS).

If you use Wowza:

1. edit Wowza/conf/avchat30/Application.xml
2. On line 25 change live-lowlatency with live-record and save
3. Restart Wowza

You will find the new .flv files in this folder: Wowza/content/ .

As oppsed to FMS and Red5, by default, the .flv files are not grouped in folders by application and application-instance like this:

• Wowza/content/avchat30/_definst_
• Wowza/content/avchat30/_siteB

To group them like that you need to:

1. edit Wowza/conf/avchat30/Application.xml
2. On line 26 change the default folder path
   ${com.wowza.wms.AppHome}/content
   WITH
   ${com.wowza.wms.AppHome}/content/${com.wowza.wms.context.Application}/${com.wowza.wms.context.ApplicationInstance}
   and save
3. Restart Wowza

The .flv files are named like this: username+ “_”+ unique user id assigned by Wowza .

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).

Important 2: When you have auto bandwidth reduction turned on (it’s on by default) streams are passed trough the media server only when there is someone watching the respective stream. So even tough user X is broadcasting, his stream will only be recorded if he has one or more viewers. teh steram recording process will also stop when user X has no more viewers. You can turn off auto bandwidth reduction.

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.

AVChat 3 , as all the other flash video chats out there, 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.

Even tough there is no receiver (if there is no one watching) the stream still travels from the broadcaster to the media server, thus consuming bandwidth on the media server and on the broadcaster’s Internet connection.

This is where AVChat 3′s “Dynamic Bandwidth Usage Reduction” kicks in. When this feature is activated (it is by default) the broadcaster streams audio and video to the media server ONLY WHEN IT HAS VIEWERS.

Here is bandwidth usage graph explaining how this feature works:

Dynamic bandwidth usage reduction in action

This feature will save a lot of bandwidth over time both on your media server ( or media server hosting account) and on your users Internet connections.

To disable it (now why would you want to do that? ) edit avc_setting.xxx and search for the automaticallyReduceBandwidthUsage variable. Set it to 0 to disable it.

1) Increase the video and audio quality settings (obviously ):

As a webmaster you most probably have control over the audio and video encoding settings used by your video chat software. These encoding settings directly affect the audio and video quality.

In what regards sound, you should be able to change the sound rate (the higher the better). 44 is the maximum audio quality setting supported by Flash Player when capturing audio from mics but it also consumes the most bandwidth with 88kbits/s! Other values for the sound rate are 22 (44kbits/s) 11 (22kbits/s) and 8 (16kbits/s).

In what regards the video quality you should have more control! You should be able to change at least the resolution, the fps, the picture quality and the maximum bandwidth to use!

Also remember that video quality is mostly influenced by the quality of the camera! You will never get from a consumer webcam the quality you get from a DV camcorder! Also good lightning (like natural light) helps  A LOT! With consumer webcams in low light you will not get too many frames per second!

2) Use a dedicated FMS/Red5 server/FMS hosting close to where your users are located:

A media server closer to your users will mean lower latency (audio/video data travels faster between the users computer and the media server) and higher peak bandwidth between your users computer and the media server (more audio and video streams can be exchanged between a user and the media server without affecting delivery quality) .

3) Configure the media server properly (FMS only)

Flash Media Server by default aggregates audio and video data into larger chunks that it sends out to users. This means that audio/video data is not sent to the users as soon as it arrives to the media server , which translates into higher latency for audio/video streams. In one to many scenarios this is not as important but when you have a 2 way audio/video discussion latency is VERY important.

You can dsiable packet aggregating by editing the Application.xml file found in FMS3.5\conf\_defaultRoot_\_defaultVHost_ and set <Queue enabled=”false”>.

This will however affect performance of the media server so if your website is driving large traffic you might want to test first or try some of the other settings in the file related to queuing and packet aggregating.

The lowest sustained latency we have achieved with a remote FMS server is 30ms for video streams and 150ms for audio+video streams.

Whatever you do, don’t forget about the bandwidth usage:

If a user broadcasts his webcam/mic to the media server and he uses high quality sound (44Khz which uses about 88Kbits/s of bandwidth) and low quality video (160×120@15fps at about 168kbits/s) he will consume 88+168=256kbits/s . If he watches another similar audio/video stream he will be using another 256kbits/s for a total of 512kbits/s.

If you increase the bandwidth usage for one audio+video stream to 512kbits/s, your user will now need a full 1Mbit/s of bandwidth between their computer and the media server to send and view a stream at the same time without interruptions!

If the bandwidth used by the stream(s) consumed by a user is just a little higher than the available bandwidth between the users computer and the media server, the user will start to experience breaks in frame rate, delays in delivery, frozen frames, breaks in sound, etc… .