AVChat Software Product Blog

Today we’re releasing a new version of HDFVR which was made primarily to fix the black boxes issue. however, during development, it quickly grew into something bigger.

Here are all the changes explained in great detail:

1. We’ve implemented the H264+AAC recording to MP4 using the Wowza Transcoder AddOn in the main build (until now we had a separate build – build 508- that had to be used for that).

This means:

• we’ve added the Wowza+Transcoder AddOn option (h264_w_t) to all the video quality .xml profiles

• we’ve tested it with Wowza 3.0.3+patch,3.0.4, 3.1.0, 3.1.1, 3.5 and 3.6

• the Wowza server-side files now contain the hdfvr_play app (used only with h264_w_t) and the hdfvr.xml transcoder template

• we’ve updated the Recording MP4 files (with H.264 video and AAC audio) article to:

  • contain instructions for build 508 and 567

  • contain instructions for Application.xml from 508 and 567

  • add the results from our Transcoder tests with different Wowza versions (from 3.0.3 to 3.6)

2. We’ve added a way to flip the video preview horizontally during recording (flipImageHorizontally in avc_settings.xxx). The final video will not be flipped.

3. The kfps setting from the video quality profile files is now used by HDFVR. All kfps values default to 15 which means one full frame (key frame) every 15 frames.

4. The streamPrefix option in avc_settings.xxx now has the default value  of “videoStream_” assigned from avc_settings.xxx, not from inside HDFVR.

5. Renamed duplicate trans-unit id=”037″ in the en.xml file to 037b (caused no issue).

6. The files for .NET servers (avc_settings.aspx and avc_settings.aspx.cs) have been included in this build.

7. We’ve also updated the documentation throughout avc_settings.php and the video quality .xml  profile files.

8. We’ve removed the documentation from avc_settings.asp, avc_settings.php is now the only reference for the options available in the avc_settings.xxx files.

9. We’ve added an automatic outgoing buffer increase mechanism on the client side which will prevent the outgoing buffer from becoming full and causing Flash Player to drop the entire buffer content causing big gaps in the video. You can still set the initial buffer size trough outgoingBuffer in avc_settings.xxx but if it ever becomes more than 90% full, HDFVR will now double it automatically. This feature will help a lot those trying to record high quality videos over slow connections.

10. We’ve also found out that Flash Player 11.3.300.257 released on the 8th of June 2012 removed the dreaded internal streaming limit (when publishing/broadcasting audio/video) found in previous versions of Flash Player, so the only limit now is your actual upload bandwidth with the media server. So we’ve:

• updated forum threads where the streaming limit in FP was mentioned

• updated our recording blog post: http://avchathq.com/blog/recording-high-quality-flash-video-over-slow-internet-connections-part-3/

• updated the Red5 1.0 RC1 article http://hdfvr.com/documentation#part11

11. And here are the fixed issues:

• We’ve managed to prevent the black boxes at the end of the recording process. This started to happen with a certain Flash Player version. We’ve managed to properly fix the issue by keeping the last frame on-screen when pressing STOP.

• Pause not working during playback, in build 508, when using Wowza + Transcoder (h264_w_t).

• When recording a second video (pressing record a second time), the video started with a few seconds of black video

Download and upgrade

You can download the new HDFVR build from your private client area.

If you’re upgrading from a previous version:

• most of the client side files have changed, so make a backup and replace them with the new ones (make sure your connection string is still set)
• the Wowza server-side have changed so, if you’re using Wowza, you will want to replace the old files with the new ones and restart Wowza

Trial users do not yet have access to this build.

Hello everyone,

As I promised , I updated the phpFox integration kit for AVChat to support the latest changes (ex. mobile version) that were made to our video chat (find out more). Here is a list of what was updated in the phpFox module:

• Never miss a new message from now. New browser tab notification lets you see how many new messages you received if you are in another browser tab.
• Detect if the browser is mobile or desktop and provide the appropriate content.
• Detect if you installed the AVChat files into the component directory.
• Facebook Application ID field integration in backend.

Remember that you need the latest build of AVChat (build 2170) to have access to these great features and also Red5 or FMS media server. This update is currently available only for phpFox 3, but if users demand, we will support other version of phpFox also.

You can download the latest version(build 2202) from you private client area.

Have a great day!

We are proud to bring you this year’s first build of AVChat that has a lot of major changes and a heap of improvements for both the Flash client and the HTML5 client

Here are the new features:

1. Red5 support for the mobile AVChat 3 client is here.

Setting it up: The mobile client requires a Web Server: A  web server with at least PHP 5.3.10  hosting the chat. 

Socket support must be enabled. You can use phpinfo(); to check if sockets are enabled.

After a normal installation, open avchat3.properties and change the webServerIp setting (new setting) to reflect the IP  of your web server.

Also you might want to disable some of the red5 logs, because when someone connects from the mobile client, Red5 will generate a lot of logs. To do this go in the installation directory of your Red5 server -> conf – > logback.xml, and here edit the following 2 settings:

<logger name="org.red5.io">
<level value="DEBUG" />
</logger>.

Change the level value from “DEBUG” to “INFO” in the code above..

<logger name="org.red5.server.adapter.MultiThreadedApplicationAdapter" >
<level value="OFF"/>
</logger>

Change the level value from “DEBUG” to “OFF” in the code above.

2. Updated .aspx files

upload.aspx, avc_settings.aspx and style.aspx have been brought up to date to their .php counterparts so now they pull all the configuration data from  avc_settings.xml, file_types.xml and style.xml .

3. New mechanism for removing empty rooms automatically

A new delete rooms mechanism has been implemented.  Previously the rooms were  automatically deleted  as soon as the last person left the room as described in the documentation

The media server now constantly checks for empty rooms and if:

• deleteRoomsWhenTheyBecomeEmpty = true ,
• the room is not protected (not included in the doNotDeleteTheseRoomsWhenTheyBecomeEmpty array) and
• is inactive for more than the number of hours expressed by a new setting ( deleteEmptyInactiveRoomsOlderThan ), then the room is deleted.

4. Better UI for when used in narrow spaces

AVChat now fits correctly in narrow spaces, this was a problem well known with some integrations. Here’s a quick view of it

5. New feature: CHAT HISTORY (for copying the entire chat history)

Added new button (Chat history) that opens up a new window with the whole chat history of the rooms it is opened in. This feature also take into account the setting autoAddIpToUsername. Here’s how it looks:

6. New ability to block all requests for access to a private stream

We added a new button that can be used to block all the view private stream requests.

7. Lots of improvements for the AVChat 3 Mobile Client:

1. The mobile client now supports emote icons. The path to the icons is stored in the same setting as for the flash client (emoticonsurl).

2. The mobile client now displays distinct icons for users that come from other mobile clients or from the desktop flash client.

   The camera/microphone icons now have 3 states: active ( icons are shown normal), inactive (icons are shown faded), and hidden(user has no cam/mic).

   

3. The connect button on the mobile client is now disabled unless a username with a least 3 characters is typed in.

4. Welcome message has been added to the chat room upon entry.

5. Pinch-zoom has been disabled for the mobile client to avoid unwanted scaling of the elements.

6. Fixed an issue with the mobile client that caused the Login button from the rooms list to not work after it was clicked if the rooms list was reloaded

8. The following issues have been fixed on the Flash client:

1. We implemented a cleanup for  the rooms list on connect for all media servers, to check if all the rooms contained in the rooms list are still physically on the disk, if not we delete them. This was discovered to cause the empty text chats and empty users list problem.
2. The background of the uploaded images when shown in the top right corner of the text chat area now scale according to the image size.

   

3. The user’s own camera no longer launches in another separate window if autoStartMyCamera and autoStartCameras are set to true.
4. Fixed issue with error messages that could not be seen entirely when the chat window was too narrow, here’s how it looks now:

   

5. Fixed small issue with owner name of a room being filled with the room name instead, in the users__.xml file on FMS.
6. Fixed issue with rotating text chat messages when leaving all rooms.
7. Fixed issue with the aligning of elements on the Y axis after an image that wasn’t square shaped was uploaded ( the issue was all other elements left a gap between the image and the next element )
8. Fixed padding for welcome messages and rotating messages.

   

9. Fixed issue with emoticons being  replaced when formed with the “event:” string used by FP and a username like this “event:paula” where “:p” would be seen as an emoticon and replaced with spaces, redirecting to an empty html link instead of triggering an event.
10. Fixed issue with search in users list working only in the first room that was joined.
11. Fixed small issue with shadow direction on the tab bar when flipTabMenu was set to true.

How to download and upgrade?

You can download this new build of AVChat from your client area. As a trial user you do not yet have access to this build.

Steps to upgrade an old installation:

1. overwrite all old client side files (You can keep your old language files. The missing phrases will default to English until you add them to your existing language XML file.)
2. overwrite the media server files and restart the media server

If you have issues with it after upgrading make sure you clear your browser’s cache. If you still have issues after doing that send us an email at support@avchathq.com.

If you want us to upgrade your AVChat installation for you you can purchase our additional AVChat Installation Service from here: http://avchat.net/buy-now#services .  Once you make the purchase just email us at contact@avchathq.com .

“I’d like to know if I can run other Red5 instances on my server, besides the one that AVChat requires.”

This is an issue that came recently for some of our existing customers and I thought that we can share this info to everybody.

It happens that you have been using a software that requires Red5 to transmit data and you have installed, for example, Red5 0.9. Good..

Now, after you got an AVChat license, you heard that the only compatible versions of Red5 with the chat software are 0.8 and 1.0 RC1. This made you wonder if you can still use your previous software running on the same Red5 0.9 as before and make a different installation of Red5, for AVChat to run.

You have to know that all versions of Red5 are using the same port configuration and if 2 copies of Red5 are started, there will be a port conflict there.

The default ports used by Redt5 are:

• 5080 for HTTP
• 1935 for RTMP

1. Open the /conf folder and search for a file called red5.properties.
2. Open it with a text editor
3. Change the value of all the ports, but make sure that the new ones are available, no other application on the server is using them.

After editing this file, Red5 must be restarted in order for the changes to apply.

Good..now we can start both Red5 instances with 2 different software using them.

I hope this helped and..happy chatting !

Hello, my name is Remus and i am a new employee at AVChat Software. I will be from now on , the main developer for AVChat 3.0 and build 1772 is my first build, and the one that helped me understand the inner workings of how it was developed so far. I hope i managed to implement a useful set of new features along with the other developers, and that we will continue to do so in the future.

Here are the major changes we did for you in this build:

1. We added a new feature that allows users to filter NSFW (not safe for work) content through the setting userCanSeeNSFWContent in avc_settings.xxx. This feature has 3 types of filtering: full filter which doesn’t allow any kind of NSFW content, a more permissive filter that allows the content to be available to other users but it is hidden unless the user chooses to see it, and fully permissive filter. The feature can also  be disabled altogether from avc_settings.xxx through the enableNSFWFeature setting. This will also completely remove the UI elements from the chat interface ( the checkboxes).
2. We added a new feature that allows users to choose the position of the tab menu (up or down) relative to the text chat area through the setting flipTabMenu in avc_settings.xxx
3. We added a new search feature to the users list which allows you to search users by username (case insensitive)
   
4. We improved the media server logs, they now contain logs on users joining/leaving rooms, users getting kicked from rooms, users getting kicked from chat and users getting banned. This will allow site owners to better supervise the activity of their moderators.
5. AVChat can now be setup to prevent duplicate usernames. A nickname can be used only once. This feature is disabled by default because we’re still getting reports of ghost users (and this will affect integrated versions) but it can be enabled from the media server settings file (settings.asc on FMS, avchat3.properties on Red5 and Wowza), just look for the uniqueUserNames setting.
6. The size of the side menus for the users list, user items and webcam area, now scale accordingly to the text length.
7. The names of the uploaded files on your web server through AVChat now contain the username of the uploader in them.
8. We added more YouTube link support so short youtube links will also be previewed.
9. Pressing enter on the login screen now has same effect as pressing the connect button. Yaay.

Other improvements:

• Ability to choose the default state of the button that enables the sounds in chat, through the setting defaultStateTextChatSoundButton in avc_settings.xxx
• Ability to choose the default user color used in the color picker through defaultUserColor setting in avc_settings.xxx if the toggleRandomColors feature is disabled
• Added all the new phrases in en.xml for all the new features, together with fallback ones
• Updates to style.css

Here’s what’s fixed

• Fixed issue with automatically created  rooms with password not working on Wowza
• Fixed issue with infinite rooms being created when auto create rooms was enabled on FMS
• Fixed issue with NSFW feature not working properly on Wowza and on private message tabs
• Fixed issue with close room button not being displayed correctly

How to download and upgrade?

You can download this new build of AVChat from your client area. As a trial user you do not yet have access to this build.

Steps to upgrade an old installation:

1. overwrite all old client side files (You can keep your old language files. The missing phrases will default to English until you add them to your existing language xml file.)
2. overwrite the media server files and restart the media server

If you have issues with it after upgrading make sure you clear your browser’s cache. If you still have issues after doing that send us an email at support@avchathq.com.

If you want us to upgrade your AVChat installation for you you can purchase our additional AVChat Installation Service from here: http://avchat.net/buy-now#services .  Once you make the purchase just email us at support@avchathq.com .

What’s next?

With more hands on the deck we’re preparing at least  2 major builds before Christmas.

Introduction

With the launch of Flash Player 11 (4th Ocotober 2011) Adobe introduced the H.264 video codec in Flash Player for video encoding. For those of you who don’t know yet what H.264 is, it is a standard for video compression, and it is currently one of the most commonly used formats for the recording, compression, and distribution of high definition video. The final drafting work on the first version of the standard was completed in May 2003.

The  Problems:

There are 3 major media servers on the market: FMIS, Red5 and Wowza. All three are supported by HDFVR, our video recording product.

From these three only FMIS and Wowza can produce MP4 files. Red5 can’t save the audio and video data in MP4 files.

None of them can produce MP4 files with AAC audio because the only audio encoding codecs available in Flash Player  are NellyMoser’s ASAO and Speex. Neither of these two audio codecs are recommended with MP4 containers.

In addition FMIS produces MP4 files using an industry-standard recording technology known as “fragments” or “moof atoms.” Some MPEG-4 compatible tools and players do not support moof atoms and therefore cannot recognize files recorded by Adobe Media Server unless they are post-processed with a tool called F4V Post Processor . This tool can be downloaded from here.

The solution:

After digging deeper into the problem we’ve came across the Transcoder AddOn for Wowza. The Transcoder AddOn takes a live stream, decodes the video and audio and then re-encodes the data to suit your needs (delivery to iOS devices, etc.).  It seems it works just as good for recording streams.

To produce MP4 files with H.264 video and AAC audio we need the Transcoder AddOn to

1. take in the audio and video data coming from HDFVR,
2. decode the audio and re-encode it with AAC
3. put the initial video data and the new AAC audio data in an .MP4 file

With a few configurations tweaks for HDFVR we’ve managed to do that. Let’s see how we’ve done it.

Requirements

Here’s everything we need (download and install step by step):

• STEP 1: HDFVR build number 508 (beta version)  or later (installation details here)
• STEP 2: Wowza 3 (trial, installation guide) or later
• STEP 3: For Wowza 3.0.3 you need this Wowza patch (more details below)
• STEP 4: Transcoder AddOn for Wowza 3,  this comes along with the trial version of Wowza 3 and is included with Wowza 3.5 (download, installation guide)
• STEP 5: 64 bit OS (Linux or Windows) and 64 bit Java runtime (download)

When running Wowza on Windows you will also need:

• .NET Framework 3.5.1 Feature (download)
• Desktop Experience  if you run Windows Server (details)

After installing everything, including the Transcoder AddOn you have to start Wowza in standalone mode. To do so you have to run startup.bat (on Windows) or startup.sh (on Linux). These startup files are inside the Wowza/bin folder.

Once Wowza is started, at the beginning of the log in the command line window, you should see a line telling you that the Transcoder AddOn is available. The message should look something like this: INFO server comment – Transcoder Streams Available.

In case your Transcoder AddOn appears as unavailable you should  check the log messages in the console window that show the  Java version. The correct line should look like this: INFO server comment – Java Architecture: 64. If this is not correct you should try installing the Java runtime again and set your Java path, details here.

Important note about Wowza versions:

===
Wowza 3.0.3

After testing with the latest Wowza – at the time of writing this article it was 3.0.3 - and the Transcoder AddOn we’ve found that the recorded mp4 files could not be played  with any external player. After researching a little bit we’ve came across a patch (Patch 3 for Wowza 3.0.3) that fixed this problem. The patch can be found here : http://www.wowza.com/downloads/WowzaMediaServer-3-0-3/WowzaMediaServer3.0.3-patch3.zip .
You will need to replace the files inside of your Wowza  3.0.3 installation folder with the ones inside the patch (only the files contained inside the patch).

===
Wowza 3.0.4 and later 3.0.x versions

Work as expected and do not need to be patched.

===

Wowza 3.1.0

We could not get it to transcode properlly and produced unusable .MP4 files.

===

Wowza 3.1.1, 3.1.2 and later (including 3.5 and 3.6)

Work as expected however the final MP4 file will not be created when the user presses STOP in HDFVR (build 508). It will only be created when:

• the client records another video (re-records)
  OR
• the client disconnects

Until one of the 2 events happen Wowza will not create the final .mp4 file and the existing .mp4 file will be unplayable. You will know Wowza has not closed the .mp4 dile and is waiting for one of the 2 events to happen when you see a .tmp file in the content folder:

.temp video file in Wowza 3.0.4file

After getting everything above installed and running follow these steps to configure HDFVR and Wowza/Transcoder addon for recording MP4 files with AAC audio and H.264 video.

Step 1 : Setting up HDFVR

1.1 Set the proper Audio Video Quality Profile in HDFRV

First we need to tell HDFVR we’re using Wowza + the Transcoder AddOn.

Inside the video quality profile of your choice set:

• <vcodec> tag to h264_w_t and
• <snd> tag to speex10

By default HDFVR uses the following video quality profile files depending on the HTML page that embeds HDFVR:

• VideoRecorder.html -> audio_video_quality_profiles/320x240x30x90.xml
• VideoRecorder-api.html -> audio_video_quality_profiles/320x240x30x90.xml
• VideoRecorder-sd-16by9.html -> audio_video_quality_profiles/wide/640x360x30x90.xml
• VideoRecorder-hd.html -> audio_video_quality_profiles/wide/1280x720x30x90.xml

Here’s the <vcodec> and <snd> tags properly set to h264_w_t in the 320x240x30x90.xml video quality profile file.

This will produce a stream with video encoded with H.264 and audio encoded with Speex or NellyMoser (the Transcoder can decode both so the sound codec choice does not matter) but upon reaching the media server Wowza will know that it has to transcode the audio to AAC.

speex10 will produce an audio stream containing 16khz audio at 42.2kbits/s.

According to the transcoder guide, Wowza does not know to decode NellyMoser’s ASAU audio codec so don’t use it, use Speex.

1.2 Configure  Application.xml

The next step is configure the Application.xml file for HDFVR. The Application.xml file for HDFVR is found inside Wowza/conf/hdfvr directory. Here’s what you need to change from the default Application.xml with which HDFVR is delivered:

• set the <StreamType> tag  to  live-record.
• uncomment the <LiveStreamPacketizers> and make sure it’s set to cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer
• uncomment the <Transcoder> and <HTTPStreamers> tags and make sure:
  • the <LiveStreamTranscoder> tag is set to transcoder (this will enable the Transcoder addon)
  • the <Templates> tag is set to hdfvr.xml
  • the <HTTPStreamers> tag is set to cupertinostreaming,smoothstreaming,sanjosestreaming

If  these options are not present in your Application.xml please add them. Make sure that they are  not commented.

In the end your Application.xml should look like this:

<Root>
	<Application>
		<!-- Uncomment to set application level timeout values
		<ApplicationTimeout>60000</ApplicationTimeout>
		<PingTimeout>12000</PingTimeout>
		<ValidationFrequency>8000</ValidationFrequency>
		<MaximumPendingWriteBytes>0</MaximumPendingWriteBytes>
		<MaximumSetBufferTime>60000</MaximumSetBufferTime>
		<MaximumStorageDirDepth>25</MaximumStorageDirDepth>
		-->
		<Connections>
			<AutoAccept>true</AutoAccept>
			<AllowDomains></AllowDomains>
		</Connections>
		<!--
			StorageDir path variables

			${com.wowza.wms.AppHome} - Application home directory
			${com.wowza.wms.ConfigHome} - Configuration home directory
			${com.wowza.wms.context.VHost} - Virtual host name
			${com.wowza.wms.context.VHostConfigHome} - Virtual host config directory
			${com.wowza.wms.context.Application} - Application name
			${com.wowza.wms.context.ApplicationInstance} - Application instance name

		-->

		<Streams>
			<StreamType>live-record</StreamType>
			<StorageDir>${com.wowza.wms.context.VHostConfigHome}/content</StorageDir>
			<KeyDir>${com.wowza.wms.context.VHostConfigHome}/keys</KeyDir>
			 <LiveStreamPacketizers>cupertinostreamingpacketizer, smoothstreamingpacketizer, sanjosestreamingpacketizer</LiveStreamPacketizers>
			<Properties>
			</Properties>
		</Streams>

		<Transcoder>
			<!-- To turn on transcoder set to: transcoder -->
			<LiveStreamTranscoder>transcoder</LiveStreamTranscoder>
			<!-- [templatename].xml or ${SourceStreamName}.xml -->
			<Templates>hdfvr.xml</Templates>
			<ProfileDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/profiles</ProfileDir>
			<TemplateDir>${com.wowza.wms.context.VHostConfigHome}/transcoder/templates</TemplateDir>
			<Properties>
			</Properties>
		</Transcoder>

		<HTTPStreamers>cupertinostreaming,smoothstreaming,sanjosestreaming</HTTPStreamers>

		<SharedObjects>
			<StorageDir></StorageDir>
		</SharedObjects>
		<Client>
			<IdleFrequency>-1</IdleFrequency>
			<Access>
				<StreamReadAccess>*</StreamReadAccess>
				<StreamWriteAccess>*</StreamWriteAccess>
				<StreamAudioSampleAccess></StreamAudioSampleAccess>
				<StreamVideoSampleAccess></StreamVideoSampleAccess>
				<SharedObjectReadAccess>*</SharedObjectReadAccess>
				<SharedObjectWriteAccess>*</SharedObjectWriteAccess>
			</Access>
		</Client>
		<RTP>
			<!-- RTP/Authentication/[type]Methods defined in Authentication.xml. Default setup includes; none, basic, digest -->
			<Authentication>
				<PublishMethod>digest</PublishMethod>
				<PlayMethod>digest</PlayMethod>
			</Authentication>
			<!-- RTP/AVSyncMethod. Valid values are: senderreport, systemclock, rtptimecode -->
			<AVSyncMethod>senderreport</AVSyncMethod>
			<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>
			<IdleFrequency>75</IdleFrequency>
			<RTSPSessionTimeout>90000</RTSPSessionTimeout>
			<RTSPMaximumPendingWriteBytes>0</RTSPMaximumPendingWriteBytes>
			<RTSPBindIpAddress></RTSPBindIpAddress>
			<RTSPConnectionIpAddress>0.0.0.0</RTSPConnectionIpAddress>
			<RTSPOriginIpAddress>127.0.0.1</RTSPOriginIpAddress>
			<IncomingDatagramPortRanges>*</IncomingDatagramPortRanges>
			<!-- Properties defined here will override any properties defined in conf/RTP.xml for any depacketizers loaded by this application -->
			<Properties>
			</Properties>
		</RTP>

		<Modules>
			<Module>
				<Name>base</Name>
				<Description>Base</Description>
				<Class>com.wowza.wms.module.ModuleCore</Class>
			</Module>
			<Module>
				<Name>properties</Name>
				<Description>Properties</Description>
				<Class>com.wowza.wms.module.ModuleProperties</Class>
			</Module>
			<Module>
				<Name>logging</Name>
				<Description>Client Logging</Description>
				<Class>com.wowza.wms.module.ModuleClientLogging</Class>
			</Module>

			<Module>
				<Name>flvplayback</Name>
				<Description>FLVPlayback</Description>
				<Class>com.wowza.wms.module.ModuleFLVPlayback</Class>
			</Module> 

			<Module>
				<Name>customServerHDFVR</Name>
				<Description>Server HDFVR</Description>
				<Class>com.naicuandnaicu.server.MyModule</Class>
			</Module>
		</Modules>
		<!-- Properties defined here will be added to the IApplication.getProperties() and IApplicationInstance.getProperties() collections -->
		<Properties>
		</Properties>
	</Application>
</Root>

You can download the above Application.xml code/file from here: http://codeviewer.org/view/code:26eb.

1.3 Setting up a Wowza application for playback:

Now we are ready to record mp4 files on Wowza but how about playing them inside of HDFVR.

Because the <StreamType> tag is set to live-record inside Application.xml after you finish recording you will not be able to play back the file. The stream can only be played only while it’s being recorded because Wowza treats it as a live stream.

Not to worry though because we have a solution. Wowza is storing the recorded files inside a folder (Wowza/content) that is shared by all the applications so all we need to do now is set up another app with a different <StreamType> tag that will recognize the files as recorded streams and play them back properly.

On your Wowza media server you will have to copy the hdfr_play files (they’re in the HDFVR build 508 (beta version) archive) as a normal application and the rest is done automatically by HDFVR.

The Application.xml for the hdfr_play app (Wowza/conf/hdfvr_play) should have the <StreamType> tag set to record.

For those of you who do not use HDFVR and want a better understanding of how it works the principle is pretty straight forward: HDFVR connects to one application (hdfvr) with its set of settings and uses the Transcoder AddOn to record mp4 files. To play the files HDFVR connects to another application (hdfvr_play) with a different set of settings.

Step 2: Setting up the Transcoder

Inside Application.xml for the hdfvr app (Wowza/conf/hdfvr) mentioned the following things are specified:

• the <Transcoder> tag contains the information  about where the configuration file for the addon can be found,
• the <TemplateDir> tag contains the path to the templates folder,
• the <Templates> tag contains the name of the template file to use and it has the following value hdfvr.xml .

Here’s the contents of hdfvr.xml, copy and paste it in a hdfvr.xml file inside your Wowza/transcoder/templates folder.

<Root>
	<Transcode>
		<Encodes>
			<!-- Example Encode block for source, not required unless Member of StreamNameGroup. -->
			<Encode>
				<Enable>true</Enable>
				<Name>aac</Name>
				<StreamName>mp4:${SourceStreamName}</StreamName>
				<Video>
					<!-- H.264, PassThru, Disable -->
					<Codec>PassThru</Codec>
					<Bitrate>${SourceVideoBitrate}</Bitrate>
					<Parameters>
					</Parameters>
				</Video>
				<Audio>
					<!-- AAC, PassThru, Disable -->
					<Codec>AAC</Codec>
					<Bitrate>48000</Bitrate>
				</Audio>
				<Properties>
				</Properties>
			</Encode>
		</Encodes>
		<Decode>
		</Decode>
		<StreamNameGroups>
		</StreamNameGroups>
		<Properties>
		</Properties>
	</Transcode>
</Root>

Here’s the above doe explained:

• The <StreamName> tag will tell the Transcoder to produce an mp4 file.
• The <Video> tag will leave the video untouched  as the <Codec> tag is set to  PassThru and the <Bitrate> tag is set to the maintain the source’s one.
• The <Audio> tag will encode audio as AAC set through the <Codec> tag and a bitrate of 48000 set through the <Bitrate> tag.

Results

After all this set up is time to run HDFVR in the browser. Press the record button and have fun. After you finished recording press play. If the recorded file does not play go back and see the section about the hdfvr_play app. To see the recorded mp4 files go to Wowza/content folder.

Conclusion

I m sure most of you know  why MP4  files are useful but for those of you who can’t quite get why this is a major feature here it goes: Flash Player is not supported by iOS and Android Internet Browsers thus .flv files can not be played on these devices. With this feature you will now be able to play you recordings straight away on any type of  OS.

There are many possibilities offered by the Transcoder AddOn not just recording mp4 files but saving different copies of your file with different quality settings , making playlists and so forth (the documentation is available here) , all you have to do is to configure the Transcoder configuration file hdfvr.xml to suit your needs.

I am going to explain in this blog post how video quality functions in flash video chat apps.

Understanding the steps the video quality goes trough in its travel from the broadcaster to the viewer is vital when trying to raise the general video quality experienced by your users.

This tutorial applies to AVChat, AVConference, SimplChat but also in some extent to HDFVR and AVChat IM.

So, here we go.

The  journey of the video from the broadcaster to the viewer can be imagined as a funnel with 8 steps. At each step the video quality can suffer. To increase the video quality at the end (on the viewer’s side) you can take measures at every step.

Step 1:  the lighting.

The amount of light in the space where the video is being captured is very important for the frame rate and detail a webcam can capture. The more light the better. Lots of natural light works best. Most of the lower end webcams can not capture more than 5fps when just a light bulb is lighting a room.

Step 2: the webcam itself.

Good “HD” webcams can capture video at high resolutions, high fps and high detail.

Step 3: the video settings used to capture video.

Once you have good light (Step 1) and a good webcam (Step 2) you must make sure nothing is lost in the encoding process.

Al0 our products ship with at least 90% picture quality setting and 15fps so if you’re getting low picture quality or low frame rate, something is happening in one of the other 8 steps.

Step 4: the CPU on the broadcaster’s computer.

Let’s say we have good light a good webcam and we’ve setup AVChat to record 400×300 at 30fps with 90% picture quality. Cool!

The limit will now be the CPU on the computer doing the encoding. A slow CPU will limit the amount of frames it can encode/second.

Microsoft recommends an Intel Dual-Core 3.0 GHz or higher CPU for 720p (HD) video calling with the Microsoft LifeCam Studio.

Step 5: the Internet connection of the broadcaster with the media server.

Once the video is properly captured and encoded, it needs to be sent to the media server.

For a live stream the connection bandwidth is vital. If there’s not enough “upload” bandwidth Flash Player will stop sending the video data to the media server and only send the audio data. On the viewer’s end this will be experienced as blocked/choppy video.

Low “upload” bandwidth can be caused by:

• the “upload” limit of the broadcaster’s Internet connection
• busy/high traffic network/internet connection
• the peak bandwidth limit of the media server hosting account (both influxis.com and uvault.com have peak bandwidth limits for their shared media server hosting accounts)

For when doing 2 way video chat the latency is also vital. If the video arrives with delay the 2 way video chat will not be very fluid.

Latency can be caused by any of these factors:

• broadcaster being connected via wifi
• media server being far away from the broadcaster (in another country/continent)
• broadcaster is behind a proxy

We recommend getting a media server as close as possible to your users and without any limit on peak bandwidth if you’re shooting for HD video broadcasting.

Step 6: the media server software

The media server just passes the video stream from one user to another but there are slight differences between the 3 big media servers: Red5, FMIS and Wowza.

There are also differences in what regards the load a media server software puts on the hardware with Wowza and FMIS being more efficient than Red5.

Step 7: the connection of the viewer with the media server

Again we’re hitting the internet connection limit but this time it’s the “download” connection from the media server to the viewer.

If the viewer has a “download” connection slower than the bandwidth/s used by the stream it will get choppy video.

Step 8: the CPU on the viewer’s computer

If you’re broadcasting high quality HD video and it manages to get trough all previous 7 steps without losing any quality, then a slow CPU will transform that beautifully smooth crisp video in’to choppy playback.

Just a few days ago I was alarmed on the forum that many users of AVChat started getting the error in the title out of the blue without the chat webmasters doing anything.

After a quick investigation we had found the culprit.

It seems Adobe has modified something in their latest Flash Player Update (11.1.102.62).

August 2012 update: it seems the issue also shows up in FP 10.3.183.20 released on 06 August 2012. teh patches at the bottom do not fx the issue for FP 10.3.183.20 .

They modified the contents of the pageUrl variable sent by Flash Player when it connects to a media server like FMS, Red5 or Wowza.

In FP 11.1.102.55 (released on November 7th, 2011) pageUrl looked like this: http://avchat.net/demos/avchat30/
In FP 11.1.102.62 (released on February 15th, 2012, the one thats causing the issue) pageUrl is truncated and looks like this: http://avchat.net

Strangely enough this modification/problem exists only in Firefox ( on both PC and MAC).

This shorter pageUrl flips our domain checking mechanism resulting in end users getting the error in the title when trying to connect.

To fix the issue we have compiled some new media server files (Red5, FMIS, Wowza) for the latest build of AVChat, 1418 and attached them to this blog post together with patching instructions.

We will compile such patches for both older versions of AVChat and other software like our HDFVR video recorder .

FLVAR for Red5 and FMIS, SimplChat and AVConference do not need patching.

============== AVChat 3 build 1418 patches below============

To fix the error when using AVChat 1418 and FMIS media server:

1. Download this archive: zip archive containing new main.ase file for FMIS
2. Extract the contents of the attached archive, it contains a new main.ase file
3. Replace your old main.ase file in FMS/applications/avchat30/ with the new one in the attached archive
4. Restart the media server OR reload the avchat30 application using the FMS management console/FCS application inspector
5. Done

To fix the error when using AVChat 1418 and Red5 media server:

1. Download this archive: zip archive containing new Application.class file for Red5
2. Unpack the attached archive, it contains a new Application.class file
3. Replace your old Application.class file in Red5\webapps\avchat30\WEB-INF\classes\avchat3 with the new one
4. Restart Red5
5. Done

To fix the error when using AVChat 1418 and Wowza media server:

1. Download this archive: zip archive containing new avchat3.jar file for Wowza
2. Unpack the attached archive, it contains a new avchat3.jar file
3. Replace your old avchat3.jar file in Wowza\lib with the new one in the attached archive
4. Restart Wowza
5. Done

============== AVChat 3 build 1252 patches below============

To fix the error when using AVChat 1252 and Red5 media server:

1. Download this archive: zip archive containing new Application.class file for Red5
2. Unpack the attached archive, it contains a new Application.class file
3. Replace your old Application.class file in Red5\webapps\avchat30\WEB-INF\classes\avchat3 with the new one
4. Restart Red5
5. Done

============== AVChat 3 build  1198 patches below============

To fix the error when using AVChat 1198 and FMIS media server:

1. Download this archive: zip archive containing new main.ase file for FMIS
2. Extract the contents of the attached archive, it contains a new main.ase file
3. Replace your old main.ase file in FMS/applications/avchat30/ with the new one in the attached archive
4. Restart the media server OR reload the avchat30 application using the FMS management console/FCS application inspector
5. Done

To fix the error when using AVChat 1198 and Red5 media server:

1. Download this archive: zip archive containing new Application.class file for Red5
2. Unpack the attached archive, it contains a new Application.class file
3. Replace your old Application.class file in Red5\webapps\avchat30\WEB-INF\classes\avchat3 with the new one
4. Restart Red5
5. Done

============== AVChat 3 build  960 patches below============

To fix the error when using AVChat 960 and Red5 media server:

1. Download this archive: zip archive containing new Application.class file for Red5
2. Unpack the attached archive, it contains a new Application.class file
3. Replace your old Application.class file in Red5\webapps\avchat30\WEB-INF\classes\avchat3 with the new one
4. Restart Red5
5. Done

============== HDFVR patches below============

To fix the error when using HDFVR (any build) and FMIS media server:

1. Download this archive: zip archive containing new main.ase file for FMIS
2. Extract the contents of the attached archive, it contains a new main.ase file
3. Replace your old main.ase file in FMS/applications/hdfvr/ with the new one in the attached archive
4. Restart the media server OR reload the hdfvr application using the FMS management console/FCS application inspector
5. Done

To fix the error when using HDFVR (any build) and Red5 media server:

1. Download this archive: zip archive containing new Application.class file for Red5
2. Unpack the attached archive, it contains a new Application.class file
3. Replace your old Application.class file in Red5\webapps\hdfvr\WEB-INF\classes\VideoRecorder with the new one
4. Restart Red5
5. Done

To fix the error when using HDFVR (any build) and Wowza media server:

1. Download this archive: zip archive containing new hdfvr.jar file for Wowza
2. Unpack the attached archive, it contains a new hdfvr.jar file
3. Replace your old hdfvr.jar file in Wowza\lib with the new one in the attached archive
4. Restart Wowza
5. Done

============== FLVAR patches below============

To fix the error when using FLVAR (any build) and Wowza media server:

1. Download this archive: zip archive containing new audiorecorder.jar file for Wowza
2. Unpack the attached archive, it contains a new audiorecorder.jar file
3. Replace your old audiorecorder.jar file in Wowza\lib with the new one in the attached archive
4. Restart Wowza
5. Done

Update 9th of March 2012:

Adobe just released Flash Player 11.1.102.63 for PC and 11.1.102.64 for Mac on March 4.

This update does not fix the initial issue that caused the “Connection rejected error” introduced in Flash Player 11.1.102.62.

We’re doing a small new build today of AVChat in an attempt to fix some of the issues that have popped up since our last build, here they are in no certain order:

• fixed issue with showWhoisInfoIntextChatArea in avc_settings.xxx not working
• silent ban was not working on Wowza
• profileCountryFlag in avc_settings.xxx was not working on Wowza
• added protections against several errors reported on Wowza
• fixed issue with the number of unread messages not showing up in tabs inside AVChat
• fixed issue with bans not showing up in admin.swf when used with Red5 (admin.swf increased to 600kbytes )
• empty connection string in avc_settings.asp

We’ve also added a few new features here and there:

• duration GET variable in seconds is now added automatically at the end of the banURL opened by AVChat when you get banned (this will allow you to save the ban in a separate database as well, banURL can be specified in avc_settings.xxx)
• weather or not web cam areas should show FPS info can be controlled trough the showVideoFpsInfo variable in avc_settings.xxx
• you can now control the columns that show in the rooms panel trough the columnsInRoomsPanel variable in avc_settings.xxx
• beta auto create rooms feature now available on FMS (check the end of settings.asc)

As usual the new build is available for download from your client/trial area.

All files have changed, so if you upgrade make sure you replace both the client side files on the websrver and the avchat30 application folder on the media server (lib/avchat3.jar if you’re using Wowza).

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.