Its totally absurd that after 24+ hours, my gmail account which I’ve had for at least 11 years is still locked. What’s even worse is that you must sit and wait until???  There are no “helpful” links on this page, nor any resolution options available; You’re simply at their whim.

After racking my brain last night about why this may have occurred, I figure it had to be the ebooks that I mailed to my KindleFire HD; there were several. Is usage of my account any reason to lock it for so many hours? I’m really freaking livid right now.. getting more pissed off by the hour.

Update: Regained access after 30+ hours of waiting and sending 2 reports from my phone. Lets work on that customer service Google; you could learn something from Apple in this area.

Interesting… So I guess Skype on Windows now utilizes Flash? Who knew…

This was on my screen when I got home tonight:

Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.
	at fl.video::VideoPlayer/setSize()
	at fl.video::FLVPlayback()
	at com.skype.video.videoPlayer.players::FLVPlayer()
	at com.skype.video.videoPlayer::VideoPlayer/initPlayer()
	at com.skype.video.videoPlayer::VideoPlayer/init()
	at com.skype.video::Main/onServiceReady()
	at flash.events::EventDispatcher/dispatchEventFunction()
	at flash.events::EventDispatcher/dispatchEvent()
	at com.skype.video::PlayerL10N/onReady()
	at MethodInfo-666()

After dismissing, I got this:

Error: Error #1502: A script has executed for longer than the default timeout period of 15 seconds.
	at com.skype.video::PlayerL10N/getPropertyFromXML()
	at com.skype.locale::L10N$/getFromHtml()
	at com.skype.locale::L10N$/localiseTextfield()
	at player_fla::TooltipRight_66/frame1()

Head over to the Infrared5 blog for details!

I’ve added some xml to hopefully support Maven and Ivy projects that use Red5 as a dependency just a little better. The group id is “org.red5″ and the artifact id is “red5-server” or “red5-client”. For Ivy, add this pattern to your ivysettings.xml:

<artifact pattern="http://red5.googlecode.com/svn/repository/[organisation]/[artifact]/[revision]/[artifact]-[revision].[ext]" />

For your ivy.xml here are the dependency entries:

<dependency org="org.red5" name="red5-server" rev="1.0-RC2" />
<dependency org="org.red5" name="red5-client" rev="1.0-RC2" />

For Maven use this repository:

<repository>
  <id>Red5</id>   <url>http://red5.googlecode.com/svn/repository</url>
</repository>

and these dependency entries:

<dependency>
  <groupId>org.red5</groupId>
  <artifactId>red5-server</artifactId>
  <version>1.0-RC2</version>
</dependency>

<dependency>
  <groupId>org.red5</groupId>
  <artifactId>red5-client</artifactId>
  <version>1.0-RC2</version>
</dependency>

I have created pro version of my broadcaster app for Android and Blackberry (playbook). The pro version allows for FMS or Red5 authentication as well as selection of all available cameras / microphones. The next two things I’ll be adding are i10n/i18n and h.264; the latter may not be possible in mobile air but I’ll give it a go.

Pro: https://market.android.com/details?id=air.org.gregoire.mobile.BroadcasterPro

Free: https://market.android.com/details?id=air.Broadcaster

The free version probably won’t be seeing any updates since I hate working on it in Flash CS5.

Lastly, If there’s enough interest I’ll do a version for iOS.

Update 1/18/12

I got h264 publish working in Android last night! woot! What a pain that was.. I need to verify that all is well with the stream data and my modifications to the application then I’ll put the update in the market.

Update #2 1/18/12

The latest pro build is up on the market 1.0.3, it allows you to stream h.263 or h.264 from your Android device. Enjoy!

I know this is supposed to be the “last” year, but I don’t believe it; bring on the supposed end of the world.. lol

Happy New Year my friends and readers! I know I’m planning positive changes for myself and I hope you all do as well. I am also looking forward to the new year’s entertainment, especially the summer movies; Avengers and Promethus!! For now I offer you a gif that makes me laugh and miss one of my favorite shows

The first step to becoming a grill master is having the right tools; actually that goes for anything you want to “master”. I’d say I’m pretty good at grilling almost anything over fire but I’ve always hated my “stock” grill grates, to me they seemed an after thought on the part of the grill maker. So when I got a groupon for a “man grate” I was intrigued and purchased a single grate with a brush. When the cast iron grate came in the mail I was impressed at the heft and construction; now this is what I was looking for! Cooking on cast iron is awesome and it takes me back to when my late Grandmother made eggs and bacon on her perfectly seasoned skillet (which is now mine).

But alas, not everything in wonderland was sunshine and rainbows. I had neglected to notice meaning of a single grate, this was my mistake. I contacted Justin over at mangrates and he explained everything in great detail as well as how to care for my new grates. To go even one step beyond with customer service is unusual in this day and age, but Justin came though and even offered me a deal I could not refuse to get a couple more grates!! Now here I am with three grates that will cover one side of my gas grill or my entire charcoal grill; ready to cook-up some meat!

If you want to grill like a pro, head on over to http://mangrate.com/ and get your “man” grates!

Lastly, Happy Thanksgiving to all of you!

New offer $10 off the regular price: https://www.mangrate.com/offers/GFOrder.aspx?affiliateid=15971&linksourceid=2

I just noticed a cool feature in Gmail, you can “nest” labels now!! Yay!

I also want to tell you all that I have post up on my company’s blog for clustered chat http://bit.ly/qFfkYp

I will dub this feature beta only because I’m not sure that my handling or signaling is “exactly” right yet. The latest revision is now 4245 and those of you with the skills may use this version to stream like the pros do with FMS and Wowza.. dynamically! Be aware that Q0S is not implemented yet so hold your bugs saying it doesn’t work for now.  The following transitions are currently supported:

• NetStreamPlayTransitions.RESET – Clears any previous play calls and plays the specified stream immediately.
• NetStreamPlayTransitions.APPEND – Adds the stream to a playlist and begins playback with the first stream.
• NetStreamPlayTransitions.APPEND_AND_WAIT – Builds a playlist without starting to play it from the first stream.
• NetStreamPlayTransitions.SWITCH – Switches from playing one stream to another stream, typically with streams of the same content.
• NetStreamPlayTransitions.SWAP – Replaces a content stream with a different content stream and maintains the rest of the playlist.
• NetStreamPlayTransitions.STOP – Stops playing the streams in a playlist.

With any new feature there will be bugs, so bare with us and we’ll get them fixed up as soon as possible. Post any issues (with test code if you have some) to the issue tracker.

Lastly, without the help of Dan Rossi and Abhinav Kapoor’s post (http://www.adobe.com/devnet/flashmediaserver/articles/dynstream_actionscript.html) this would have been a much longer endeavor. Mucho gracias to Infrared5 for allowing me to work on this and other Red5 features. All the testing so far was accomplished with Flowplayer v3.2.6.

In the last couple of days I’ve fixed several issues in Red5 to get it ready for 1.0. Luckily some of these fixes resulted directly from projects being worked on at Infrared5.

The first issue looked into was with shared object usage with RTMPT. This issue seemed to by caused by the way that we manipulate the classloader hierarchy. A word of warning: working with classloaders can be a very scary task and not one that any novice Java developer should want to take on. Briefly, each Red5 application has its own classloader which is separate from any other Red5 application; this is mainly for sandboxing and is the way in which all JEE application servers operate. The internal instances (if enabled) of RTMPT and RTMPS are started in the Tomcat loader thread after all of the applications have been initialized and thus they cannot access the Red5 applications individual classloaders; meaning they can’t share SO’s etc. For that reason I never recommend using the internal instances and instead suggest that implementers use the RTMPT servlet within their Red5 application; this is a simple addition to their web.xml. In the end, after working on this bug and an RTMPT binding issue at the same time I found that the classloader issue was fixed by making sure the internal instances were binding to an IP, instead of allowing Tomcat to handle it as it saw fit. It would appear that Tomcat has some sort of sharing in-place that allowing web application classloaders to talk with each other. The “fix” has been added to trunk around revision 4241 and will be in the 1.0 release configurations.

The last two things that I resolved today were found by using FMLE 3.2 as a test publisher. I must state that we as a team cannot support FMLE due to its EULA, but it is a very handy and capable application for streaming to your media server if you want something other than Sorenson and NellyMoser.  I didn’t find any specific issues for “onFI” or AAC live streaming on the tracker, but these are the two items I fixed using FMLE. The initial work for AAC was done early-on by Tiago and modified by Vladimir Hmelyoff, so a big thank you to them. Fixing live streaming with h.264 and AAC was as easy as making the ClientBroadcastStream check for audio codec information and setting it if it was absent; I love ez fixes!  To fix “onFI” I had to dig around on Google to find out what this call was, for those who don’t know it is used for active timecoding in a stream. The publisher will send the local system time and date as strings in a mixed-array, keyed as “st” and “sd” respectively. All that needed to be done by Red5 at this time was to handle the callback and pass it on to the subscribers.

One last note about FLME, when you stream live it will send parameters with your stream name and we used to simply ignore them. These parameters are now stored on your broadcast stream and may be accessed on the server side by calling getParameters().

Lastly, I don’t know when 1.0 will be available but you may all certainly use the current RC2 version in SVN.