AVChat Software Product Blog

We’ve got a new build of our video recorder ready for you today. This build includes fixes for a few bugs we received trough the forum and small changes in the looks & usability departments.

• Videos for which the user had not pressed the SAVE button did not have any snapshot and the video file did not had the right permissions set in avc_settings.xxx [FIXED]
• Added 4 HTML files to the HDFVR archive, each one embeds HDFVR in a different way. The same HTML files are available online in our HDFVR demo area: http://hdfvr.com/demo/weblauncher.html
• The progress bar+buffer will now show during playback (independent of the scrubber when it is clicked and dragged )
• Only one press of the SAVE button is allowed per each recording
• Fixed this issue mentioned in the forum regarding the SAVE button
• When the SAVE button is turned off the scrubbar will occupy the remaining space
• Changed the SAVE icon and improoved the rest of the icons
• The menu can be in any colors (some colors caused issues in the past)
• The up/over/pressed states of the buttons have been revised (similar to YouTube)
• Padding between the scrub bar and it’s container
• Visible vertical lines between the buttons
• While dragging the scrub button the red playback line and white buffer line are still updated
• Better comments and explanations for some variables in avc_settings.xxx

You can go grab the new build from your client/trial area. To update just overwrite the old HDFVR files. You will loose your existing changes. Make a backup first just in case.

Just the client side files have been changed , the hdfvr app that goes on the media server has not suffered any change so there’s no need to update it or restart the media server.

Later edit: build 396 is now available and it solves a playback issue in 394

A week ago we’ve announced that Adobe will support h.264 video recording in the next version of Flash Player 11.

Since then we’ve made some tests .

Here’s our setup:

• Flash Player Incubator preview version
• a special build of our video recorder (HDFVR).
• Flash Media Server 4
• a Microsoft LifeCam Cinema HD web cam.
• Run of the mill laptop with Dual Core Intel P8400 @ 2,26GHz CPU

Here are our conclusions:

• Recording HD (1280×720) H.264 video (main profile) maxes the  CPU  at about 20 fps. It would go higher in fps if I would have a better CPU.
• The sound is encoded with Speex, there’s no AAC option.
• On the media server the video+audio data is saved in a F4V file.
• The recording file can be played back right away trough streaming (sound plays ok).
• For progressive download/desktop playback you need to pass the new F4V file trough Adobe’s F4V Post Processor but there’s no sound. We’ve reported this issue to Adobe and they’re aware of it.
• Users will need Flash Player 11 or later to record h.264 video.
• We’ve not tested yet Red5 and Wowza.
• Both the Baseline (non cpu intensive) and Main (medium cpu intensive) h.264 profiles are supported. High Profile is not supported.
• All h.264 levels are supported up to 5.1.

That’s a good overview of what we’ve discovered so far.

We’ll be buying an 8 core desktop computer and a better webcam (the Logitech C910 1080p webcam) soon to do more tests .

PS: The Microsoft LifeCam Cinema HD seems to be limited to 10fps when using the official Microsoft Lifecam drivers. We had to use the generic “USB Video Device” drivers from Windows to get it past 10fps.

A new build of  HDFVR is available now.This build contains a lot of bug fixes and an improved UI.

The new UI:

• The fps counter is aligned to the left bottom corner.
• The backround color property is now functional.
• The sound level display is tinier.
• Corect paddings for all the elements in the scene.  A  padding var was added to avc_settins.xxx so that you can control the padding between the elements.

Issues fixed:

We’ve fixed a lot of small bugs from UI and functionality and a few critical ones:

• Spellchecked and corected docs.We’ve added better comments in avc_settings.xxx.
• We’ve fixed the issue with streamName change that was not working properly.
• We’ve fixed the issue with the size of the snapshot.
• We’ve fixed the issue with taking a snapsot for each video when recording more than one video in a session.
• The kfps info inside the quality files is actualy doing something.
• We’ve corected some of the error messages (proper error when wrong domain name and proper error when coming from an unlicensed domain ).

Where can you get it?

You can download the new build from your client/trial area.

How to install the new version?

Just make a clean install or overwrite the old files (including the files on the media server) and restart the media server.

How do I get HDFVR?o

You can buy it from here: http://hdfvr.com/buy-now or get a 30 day trial from the HDFVR web site.

A few tiny updates this month:

• index.swf and admin.swf are down again to about 400+ Kbytes  in size.
• fixed issue in Wowza where the shared object holding the text chat history would grow a lot.
• AVChat now works with an empty welcome message in the language file (en.xml).
• there is a new ban option: 3 days.
• there’s a new option in avc_settings.xxx named showUserSideMenuOnTextArea which controls what clicking an underlined username in the text chat area does: it can either bring up the side menu shown below or put the username in the text chat input box.
• the fonts available for text chat can now be finally changed using fonts.xml.
• expired bans are not shown anymore in the banned ip’s list in the admin area of AVChat.

You can download the latest build from your client/trial area, to install just overwrite the old files (including the files on the media server: Red5/FMIS/Wowza).

Today we’re releasing a new build of HDFVR that contains a feature that has been requested for a long time by you guys: write JavaScript API. That and a few bug fixes.

New features:

• there is a new JavaScript write API. With this API you can make calls from JavaScript to HDFVR to perform different actions like start recording, stop recording etc. You can viw the documentation regarding it here: http://hdfvr.com/api#jswrite and you can view a demo with it in action here: http://hdfvr.com/demo/apilauncher.html .
• a new JavaScript function is availabe: onFlashReady() that tells you when HDFVR is ready to accept calls from JavaScript

Issues fixed:

• the allow/deny screen has been replaced with a new one t the settings that allows you to remember (save) your privacy settings
• there was a yellow rectangle appearing over the video,  we ve fixed that.
• when you chose to deny access to the camera  the recording button will be disabled (until now it  was remaining enabled even if there was no cam)
• recordAgain setting in avc_settings.xxx was ignored when recording was stopped due to  the maximum recording time being reached

Where can you get it?

You can download the new build from your client/trial area.

How to install the new version?

Just make a clean install or overwrite the old files (including the files on the media server) and restart the media server.

How do I get HDFVR?

You can buy it from here: http://hdfvr.com/buy-now or get a 30 day trial from the HDFVR web site.

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 should buffer both the audio and video data until it can be properly sent to the video server, but what really happens is it starts buffering just 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 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, 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 and a bug has been submitted which you can follow here here.
• Red5 1.0 attempts to fix this issue to by exposing a save data to flv treshold variable, more info on that 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!

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

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.

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