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.

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.

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.

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.

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 1Mbit/s (which seems to be the upload/streaming limit in Flash Player)

Flash Player will buffer the audio and video data until it can be properly sent to the video server.

But what really happens is this: 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 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 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