AVChat Software Product Blog

The latest build of AVChat 3, made available for download today, packs some awesome new features:

• Tool tips on most buttons in the UI.
• Better UI (you can now re size your cam and the users list, other cams are now floating on top of the text chat area,cam borders are drawn correctly, slightly skinnier interface with default padding set to 6px).
• YouTube videos now play (again) in the actual YouTube player.
• Added option in the UI to show join/leave messages in the text chat.
• Lots of small updates for the text chat (proper html encoding for html characters, better detection/highlight mechanism for links, in some cases text chat would go over YouTube videos/pictures previews).
• Some small changes to the upload mechanism in php to go around some wierd web server security settings we’ve met : “http” not allowed in GET variables, not even HTML encoded !!!
• Added a new video/audio quality profile for 768kbits/s streams .
• Ghost users should now be detected and disconnected in max 17 seconds on all 3 media servers.
• Changed the way the fps, free time, nr of viewers shows up in the cam areas.
• Clicking the [Add IT] buttn in the YT submit button now adds the video directly.
• Spaces in usernames are not replaced by _ anymore.
• New option in avc_settings.xxx to disable YouTube previews.
• Added memory usage display (off by default, you can turn it on from avc_settings.xxx)

and bug fixes:

• The info  about who is someone watching visible in admin.swf was not exact all the time.
• When cliking ACCEPT/DENY for someone’s request to your private stream some wierd text would fill up the text chat input box (bug introduced in build 609).
• Window padding value in style.css now actually works.
• Sorted out some sorting issues for the users list.
• When a  YT movie preview was shown in the chat the whole movie was downloaded even tough you weren’t watching it.
• private streams were not working on Wowza 2 (they were on Wowza 1.7)!

and some updates to security too:

• Added the possibility to add an ip range for the ips from where admin.swf is allowed to connect.
• Admins now see the ip of each user in the text chat, you can double click the ip to select it.
• The allow localhost connections option is now available for all 3 media servers: Wowza, FMIS, Red5.
• The Rooms List in admin.swf  now shows the ip of the creator of the room.
• Admin can now enter closed rooms.

How to get the new AVChat 3 release

You can obtain the latest AVChat 3 build by downloading the software again ( using the download link from the delivery/trial email) and:

• doing a clean install
  or
  
• overwrite all the old files including the FMIS/Red5 server side files and the translation files

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 is part 2 of our 3 part series on recording high quality Flash video over slow connections.

As explained in the first part, a big buffer should be used in the recorder flash app so that the video and audio data has where to wait before its turn comes to travel to the media server.

When the user stops the recording (by pressing a STOP button for example) most probably there still is some audio & video data in the buffer, data that has not been sent yet to the media server.

Part 2: wait for the audio and video data to reach the media server before we display any SUCCESS message to the user

Otherwise you will most probably end up with videos with missing endings and frustrated users.

Heres how stopping a recording unfolds in our flash video recorder:

1. STOP button is pressed (or recording time limit is reached)
2. we stop capturing data from the cam and mic
3. we display a SAVING VIDEO message until the buffer is empty (all the data in the buffer is sent to the server)
4. when the buffer reaches 0 we finally display the recording saved properly success message.

In code (as2) Step 2 translates in ns.attachAudio(null) followed by ns.attachVideo(null).

Step 3 and 4 (detecting when all the data has reached the media server ) can be done in several ways but we listen for a NetStream.Buffer.Empty or NetStream.Record.Stop net status event fired while ns.bufferLength == 0 .

In as3 the procedure should be similar.

In part 1 we’ve talked about using a big buffer on the client side.

In part 3 we will talk about getting the media server to properly save the video and audio data to the HDD.