I've got an email here with quite a few questions about FMS, so I'm going to cover the related ones bunched in a separate posts just to make it easier to read over later.
These are all great questions and come from a person who is not already working on Flash Media Server and Flash, which I like to hear from because it helps me get out of my box a bit. By a box, I mean that since I'm so used to FMS, I don't really think about some of the worries that others might have if they have never touched the software because I know that those aren't the difficult issues. Anyways, on with the show then:
The question: First, how difficult is it to administer FMS if our IT folks have little or no training in ActionScript?
AND
How easy is it to learn?
These are related questions I think, so lets see if I can cover them a bit here.
The answers:
To administer Flash Media Server, little or no Actionscript experience is needed I think. Now, I could be wrong in what "administering" means, but I have the impression that this covers install, settings changing and keeping an eye on applications and instances of those applications.
So to do that, all you really need is experience installing software and then stopping and starting services when you make changes to the settings. For the settings, it's all written out in XML and can be viewed with a common text file reader like notepad if you use Windows. THere are about 6 settings files in all and are full of comments on what each setting does, so it's not too easy to get lost there. Although I have found that some are a bit cryptic, those are the ones you don't really need to mess with. The Adobe techs have done a pretty good job there.
The only area that you need actionscript experience and knowledge is actually creating the applications. Both the client and server side coding is in actionscript. So I suppose in a way, if you had actionscript knowledge, it might help you administer the application if you could understand why a certain application is sucking up all the resources of the server or something because then you would be able to look at the files and see the problem. I'm not sure if that falls under administration tasks though.
The next part is whether FMS is easy to learn. Now that's a bit of an interesting question in itself, but I feel the answer should be yes. In reality, you don't need much knowledge at all to run applications on FMS and I think in the case of this person, they want to do lots of video streaming. Video streaming is simple really, I think there are free players out there that work with FMS, or even just the FLVcomponent in the Flash IDE works great. Place your videos on your server and you're just about done. So, in that respect, learning how to develop applications with FMS is not hard.
It will all depend on the application and how much functionality it has for whether or not the development learning curve and even administration difficulty will be.
So to sum that all up somehow, I feel that administering Flash Media Server really isn't that hard. Install it and for the most part just leave the default settings as they are. There are a couple of items to change, but the rest of the defaults work great for most apps. When it comes to actually using the technology for your own sites and apps, then the level of difficulty on learning to develop on it will be directly affected by the amount of functionality that your app has. If you already have a good knowledge of Actionscript, then developing shouldn't be too hard at all, you'll just need to understand how live apps work now and the things to think about when developing them.
Thanks to everybody who let me know. Comments are working now.
I think I've nailed it down to when we enter a new site in the blacklist we have, sometimes it has characters in it that mess with the regex that is used to block them. Deleting the offending regex entry fixes it. ho hum.. I wonder how long it's been like that..
Here's a good one that I've actually answered quite well in one of my presentations that are online.
The question: How do you use FMS2.0 to detect which version of Flash and then what FLV file to play depending on users connection
speed?
The answer:
To start off, there are 2 things that need to be done about this, first you need to figure out the bandwidth of the user. You can find out how to do that from this article on Adobe's site from Stefan Richter of Flashcomguru.
Next up is the key to getting the right FLV to a user with minimal setup and future maintenance. Use virtual keys. Rather than explain it in detail again in this post, here is a link to the presentation and you can follow the links to the presentation files that have an example on how to use virtual keys with FMS2.
I will quickly note though what you will be looking for in the preso and the files. You need to do the following:
1. Set the virtual stream directories and keys for each type of user you think you'll have. This is done in the XML setup files for FMS2.
2. Figure out the bandwidth of the client, once you know that you set the virtual key for the client
3. Then just play the FLV file and FMS2 will figure on which FLV file it should play based on the virtual key of the user.
Also now with FMS2, you can detect the users flash version and automatically set the users virtual key, but in this case we need to also check bandwidth. This means we have to manually set the key. But keep in mind it is possible to have FMS do everything for you if all you are trying to do is test the flash player version.
It's that easy thanks to the new functionality in FMS2. I hope that helps.
This one is a very good question and actually comes up quite often. I've seen it on forums and mailing lists. It gets answered but I guess people don't want to search. So it makes a good quick tutorial here on this site with all the rest of them :)
The question: Is it possible to insert or overwrite into the middle of an audio stream?
The answer:
Yes. You have to do this server side though.
The theory:
What you need to do is make a copy of the FLV up to the spot you want to insert your new piece in. Then you play the new piece and append it to the original. Then you take the remainder of the FLV and append it to the new FLV you are creating. This is really hokey and actually requires you take the complete time that both FLV files have. If you have a 5 minute FLV and you want to add in a short 20 second clip to the middle of it, this process will take 5 mins and 20 seconds.
So you take stream A, the original stream you want to add something into (all of this is server side)
oldStream = Stream.get("A");
Grab the piece you want to add in
smallClip = Stream.get("B");
Make a new stream to record into
newStream = Stream.get("newFile");
Make the new stream record the old file
newStream.play("oldFile");
newStream.record("record");
Then you need to monitor it with an interval of something short like every 100 milliseconds. When it reaches the time of whatever you want the new clip to go into then stop playing the old stream and put in the new one:
newStream.play(false);
newStream.play("smallClip");
** side note **
You can also at this point tell the server to stop recording too, and then use the append value in the record method to add onto the current FLV.
newStream.record(false)
newStream.play("smallClip");
newStream.record("append");
** end side note **
Watch the onStatus and see when it ends, you should get a "NetStream.Play.Stop" event, when you get that, then just play the other clip again, starting from the point where you finished off:
newStream.play("oldFile", 25); //25 is the seconds time you want the clip to start from.
When it finishes playing again then just stop recording and you should have a stream that has another stream in it. Delete the old one if you want I suppose.
So you can see it's a crappy tedious process, but yes, it can be done :)
A good question, unfortunately no good answer :(
The question: How can I playback more than one recorded streams in synchronization?
The answer:
This is definitely something that has been requested a billion times to the FMS team. Hopefully they are working hard on getting this going. To put it in a short sentence, "you can't". It sucks..
But what you can do is try to start playing them both at the same time with a low buffer. Like .5 of a second or something. Then when they are playing, up the buffer a bit to keep things in line. While the videos are playing, you also can keep a watch on the time that the videos are at and if the difference get's too high, just pause one and let the other catch up.
This requires quite a bit of coding and calculation because you have to figure out how much is buffered, how long it took to buffer, the difference in times of the videos, if the videos are staggered that will add even more trouble.
It's not that it can't be done, progressively it would be reasonably easy, just preload lots :) Streaming is a bit hard as you have to always buffer. On the flip side, using seek() to get to a point in the stream is good because you don't need to preload that part of the video to start playing it.
So, in conclusion, it can be done I guess, but it's your best calculations that are going to run it. This kind of feature is not built into FMS.
Another FMS guru question :) Getting quite a few of these, sorry I've been a bit slow to respond.
Anyways...
The question: What's with client.ping(), and how do I use it?
The answer:
Well, I guess to start off, the question is in reality a bit more advanced than what I've wrote above, but more or less it's "what the heck do I do with ping() and why doesn't work as I expect for what I want to do".
So, the first thing I will start off with is what ping() is all about. Ping in the normal network world is used to find a node on a network and how long it takes to get there and back. These packets are sent at high priority so there is less delay etc. I'm not going into too much detail on this of course, but what I can say is that FMS's client.ping() on the server side is just about the same.
What is happening behind the scenes when you call ping() on the client is the server is sending out some packets to the client at a high priority. Higher than all the other data that could be going back and forth. If it gets a response, true comes back. Not quite the same as the "normal" ping that we all know and love, but more or less you are knocking on the door and seeing if somebody answers. ping() doesn't really care how long that takes.
So, the next part of this question is "what would you use this for?". Well, a lot of people want to use it to see if a client is alive on the server. Why would you use ping for that? Well, supposedly it's the fastest way to tell. You're probably wondering "compared to what?".
Which leads us to the next question, "why would you want to know if somebody was connected up to the server if the client object still exists?"
Aha! now that is the key question here I think. In FCS1.0 and 1.5 (throughout all the updates too) there was the problem of "ghost clients". These clients would sit in the application objects that the server had yet to figure out they are gone. There are a few reasons for this of course, there could be a stay-alive going on here, where a router or something is just keeping the connection there. There is also the problem with IE in where even if you close the window, the connection to the server stays open. You can even still be sending your video and audio to the application if you didn't close it first and just closed the browser window!! Imagine that! I heard a story about how one guy's connection stayed up for over an hour with his vid and aud being broadcasted to a chat. I'm sure there are other instances of this.. It gets solved by closing ALL of the browser windows you have open of IE. Odd bug.. not sure who to blame, I guess Microsoft.
There was also the problem in where if you were doing nothing on the application, the app would disconnect you, although you'd still be there.. it's a really weird problem and it sucked, so you had to make your own "stay-alive" code to keep users connected when there was no data going back and forth in the application. Some people used ping() in this instance.
So, what does this mean to a developer of FMS apps? Well, you need to know if users are actually there and if they are going to stay there when nothing is going on. In FMS2, I've actually yet to see the problem of the user getting disconnected when nothing is going on in the app. This is a good thing :) Nice to see it fixed. There are less instances of ghost users, but they are there, especially in busier applications.
What do you do? Do you use ping() to see if they are there? My answer is to suggest "no". The reason is that ping() can return true even when the client is no longer connected. The router or something in the middle actually returns that the client is there (I don't actually know exactly what is happening here, I do know that ping() will return true even though the client isn't there).
So, this makes ping() a bit crappy. My suggestion to solve not only the worry to make sure clients stay alive in the app, and also to check if they are there is to call a function in the SWF file.
This is reasonably simple because all you need to do is create a function on the netConnection object.
myNC = new NetConnection();
myNC.checkForOnline = function(){
return "yes, I'm still here";
}
Then on the server side you just call that on all clients every 30 seconds or so (this will depend on your app of course). If the call returns an error, or nothing, or the wrong string then you know that either the client is not there or is a rogue user that has connected up to your application. The good side effect here is that you are adding a bit of security to your application. Security is always good :) Once you have discovered that the call failed or returned no string or the wrong string, you disconnect them and delete the client object.
That's about it. All about ping() and why it's not really that beneficial to use it :)
A couple of days late in adding this to our blog but, we've been working on this renewal for months now and it's finally a reality!
MediaCreator.jp renewal is a complete identity, design and development renewal of Japan's largest web designer/developer tutorial community site 3E4D. We've been looking to do this for quite some time just due to the amount of work that would go into making any sitewide changes due to the over 1500 pages worth of content. This can now be done by adjusting just a few pages!
The site now runs off of asp and coldfusion, with flash remoting splattered all over the place for getting results in the tutorial search pod, download page, main poll on the home page and the administration for adding downloads, tutorials, and changing the poll.
All of the administration has now been moved to a standalone desktop application which takes advantage of Flash remoting. This in itself has made it infinitely easier to update and add to the site, which is the most important part of a community site. When content starts to get stale, people get bored, and we don't want that.
We also improved the performance greatly by reducing the amount of pages and the amount of code on the page that the web server has to serve. The site itself loads faster and getting to the tutorials and paging through them, the main part of the site, is extremely quick.
Adding in some upgrades to the forum, rebuilding the download area for direct linking, adding RSS feeds that people can use in RSS readers for keeping up with additions, improving viewing of all pieces all-round has made this renewal a major milestone with this community site.
The one are that we really wanted to improve was the tutorials which I think we have by adding a print only page for easy printing and giving the users a place to put comments and questions on the forum for each and every tutorial. I got that tip from flashcomguru which I thought was a great idea for organization. They load quicker and just in general are easier to view I think.
I've gotta say that I'm really really looking forward to see how much the community grows from this point on.
With over a hundred tutorials to port over yet we've still got a bit of work ahead of us but it's looking great even with what's in there up to this point. If you can read Japanese, or like to use translators to view it then check it out here.
I stand half corrected on the CFMX6.1 issue, and believe me, nobody is happier about this than I am. We almost had to turn to the dark side there for a few days....
I believe a solution has been found to the problem of CFMX6.1 not understanding some XML UTF-8 feeds (as in not being able to read the encoding of the page to render out the right characters).
To give a little bit of background on this, I have been using the MXNA1.0/Fullasagoog aggregator code (which is in the DRK3) to put a blog aggregator up for the Japanese community on a site I manage/run. Up to this point I sort of let the problem of not being able to read in certain feeds go as for some reason others would get read in. It was odd, but by far not the first and most definitely not the last encoding issue of Japanese characters that we have dealt with. and.. other more important things came up.. (job etc..) and it got shoved to the back.
This month though, we are actually planning a major renewal for the site and I decided to take this chance to go over the CF code once again to get it working.
As I posted in my last post, there was nothing I could do to get the CF page (running on CFMX6.1 or CFMX7, although I did find a weird fix for CFMX7) to read in the "problem" UTF-8 feeds. Some people said there was no need to set anything to UTF-8 as CF supports that by default. Though I have read differently on MM's site. Oh well, that wasn't the problem anyways.
Thanks to Paul (in the comments), a solution has been found it seems (so far it works). Unlike some people who decided that I was wacked out, Paul was nice enough to point me to a blog entry that proved that it is CF that is a little out of wack but there was a solution to be found.
Check this blog entry over on Big Damn Hereos' site.
It turns out that CFMX6 (and 7 believe it or not) cannot support feeds as application/xml, which you will quickly note is not on CFHTTP's internal list of automatically stringified types.
Although it is noted in that blog entry that there could be a fix in the future for that.
So.. it wasn't an issue of not supporting UTF-8 it was an issue of not support application/xml in CFHTTP. This is an extremely interesting find I think. I wish that MM had made this a bit more open in a technote or something.
Well, the code that I have used up until now is now working perfectly (so far) which means we don't have to migrate to ASP.NET!!! Whew... not the direction I was looking forward to going, but when you gotta make something work, you gotta make something work.
I'm so glad that somebody else was willing to post how much trouble they went through to get the problem fixed which means happy times for people like me, stumped and dejected because no other "normal" way was working.
In conclusion, I have come to the understanding overall that I stand half corrected on this issue. Whereas CFMX does support utf-8 fully, it didn't support an important piece of the puzzle whereas so many others do. If only I had the tenacity to track down the problem as Roger Benningfield did.
I'm just glad there is a happy ending to this problem :) and to top it all off, no need to upgrade yet.
Sorry Coldfusion MX 6.1, but.... we've got to let you go. It's an unfortunate turn of events, but when you can't hold up to our expectations as an application server it's time to turn to different options.
Yes, we did try all kinds of things to get you to understand utf-8. From setting every page, component and function we could think of to use encoding utf-8 to even setting the cfprocessingdirective on EVERY SINGLE PAGE but you refused to understand the global language of utf-8. We also tried the far fetched idea of importing the data as binary and converting it over with the (newly added to 6.1) ToBase64 function to utf-8, but you spat out nothing but gibberish.
How sad we felt when we thought our savior was at hand after we tested Colfusion MX 7 with our new code and it worked! Praise the new version of Coldfusion! Even though setting everything under the sun to utf-8 didn't work, our far fetched idea of reading the data in as binary and converting it to utf-8 did! How surprised we were...
Unfortunately when we visited the Macromedia "Worldwide" store with our credit card in hand and eagerly tried to buy your newest sibling, Coldfusion MX 7, our "worldwide" Visa card was regected due to the application not understanding Japanese characters.
Feeling slightly dejected we decided to run off to the Japanese store, but to no avail as they are much too cool to offer the upgrade version of yourself and sent us off to a "partner" company who did not offer "real" online shopping as it said on their site. We would have been forced to make a bank deposit and only after that confirmation would we have received up to one week later our very much needed upgrade to make our application work as needed.
So alas, we gave up as our "experience" so far was quite disappointing and started to wonder if really it would be worth the cost of the upgrade. We have no clients that have asked for your services, which is most unfortunate but it is a fact, and to tell the truth most choose not to have their apps developed with you. Why? we can only guess...
So without further ado we set about to recreate your functionality with another application server... ASP.NET Thanks to our server being windows 2003, ASP.NET is in actuality, free. Just a bit of studying to be done on reading XML data and parsing it though. A small cost compared to over 600 dollars for upgrading we thought.
It's an unfortunate series of events that has lead to your demise here as we were actually so close to having you all sparkly in your newest duds. *sigh*
But have no fear as we still need you for one thing that upgrading to the newest version will have absolutely no effect, FLASH REMOTING. Yes, we still love your remoting ability, and that is what you shall do from now on. We use you profusely with our FCS apps, and our desktop flash CMS apps, which means you are still useful to us and that means you are needed.
Anyways, keep your chin up and turn that frown upside down because even though we've given up on you for normal application development, when it comes to ease of use of flash remoting you're tops in our books :)