How to stop, start or restart red5

Important commands for the red5:

Login to ssh and enter the following commands.

#cd /usr/local/red (takes you to the red5 folder)

to stop red5:
#service red5 stop
or
#./red5-shutdown.sh

the command to start red5:
#./red5.sh &

When you see this line:
2009-09-27 23:26:32,365 [main] INFO org.red5.server.Standalone – Startup done i
n: 5464 ms (it will be easy because the lines will stop running at this point)

Wait 15 seconds
Then you must log off from the terminal screen
Press ctrl+A+D (if you don’t log off, after a while red5 will go down again)

Every time you put some folder on /red5-server folder/webapps/ you will need to restart the red5.

Red5 Hosting

Red5 Tutorial and Red5 Hosting

Red 5 is a pretty amazing server software written in java. The Red 5 development team has put in tons of effort to make it a open source alternative to Adobe FMS Flash Media Server.
Red 5 is a perfectly suitable technology for Video On Demand applications, streaming, publishing, mealtime collaboration, multi player gaming and more….
Red 5 is on all shared hosting plans of Hosting Marketers. By default the red5 server comes with some sample applications pre installed into it, like oflaDemo, fitcDemo, SoSample etc.

When installing and using red5 you have to keep in mind some configurations and security concerns. Red 5 was created to emulate the RTMP Protocol (realtime messaging).
Even today where many don’t know the capabilities of Red5 or are scared of the complications offered by java coding, i must tell you… once you get to use it you will love it :).
There are many applications to be made with RTMP and many possibilities to be discussed. Here we will discuss a simple application that can stream from custom directory. This application will be server side and will help you set up your own basic application which does not require you to use the global oflaDemo.

Hosting Marketers offer you Red5 Hosting facility on their servers, which is needless to say … amazing.

You can host you own youtube or clipshare clones at a very nominal cost. However to avoid any problems, as you will be sharing resources on a shared server, its always better to create your own application, that accepts incoming outgoing requests.
This tutorial does not give you the scope to create the application from scratch, rather configure it to use a custom path on the server to stream from / record to . You can then safely use your own account path to handle streams. By default oflaDemo uses streams directory on the server to play/record streams.

Though this tutorial gives you a course on setting up the same, many have difficulties getting it done.
So here is the practical way of doing it.

I assume you already have basic Application class ready, which makes your application valid. We will simply use a custom filename generator to change the stream paths.

Setting up a custom Filename Generator: – CustomFilenameGenerator.java

package com.flashvisions;
import org.red5.server.api.IScope;
import org.red5.server.api.ScopeUtils;
import org.red5.server.api.stream.IStreamFilenameGenerator;
public class CustomFilenameGenerator implements IStreamFilenameGenerator {
/** Path that will store recorded videos. */
public static String recordPath;
/** Path that contains VOD streams. */
public static String playbackPath;
private String getStreamDirectory(IScope scope) {
final StringBuilder result = new StringBuilder();
final IScope app = ScopeUtils.findApplication(scope);
while (scope != null && scope != app) {
result.insert(0, “/” + scope.getName());
scope = scope.getParent();
}
return playbackPath + result.toString();
}
public String generateFilename(IScope scope, String name, GenerationType type) {
return generateFilename(scope, name, null, type);
}
public String generateFilename(IScope scope, String name, String extension, GenerationType type) {
String filename;
filename = getStreamDirectory(scope) + name;
if (extension != null)
// Add extension
filename += extension;
return filename;
}
public boolean resolvesToAbsolutePath() {
return true;
}
/* Setters for your path variables */
public void setPlaybackPath(String path) {
playbackPath = path;
}
public void setRecordPath(String path) {
recordPath = path;
}
}

Save this code in a file: CustomFilenameGenerator.java in the same package as your application class.
Now that we have setup the code , we need to make our application aware of the class so that it may
use the path values from this.
So we edit red5-web.xml. This one of the configuration files of red5. Generally the content or red5-
web.xml looks like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN”
“http://www.springframework.org/dtd/spring-beans.dtd”>
<beans>
<bean id=”placeholderConfig”
class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>
<property name=”location” value=”/WEB-INF/red5-web.properties” />
</bean>
<bean id=”web.context”
autowire=”byType” />
<bean id=”web.scope”
init-method=”register”>
<property name=”server” ref=”red5.server” />
<property name=”parent” ref=”global.scope” />
<property name=”context” ref=”web.context” />
<property name=”handler” ref=”web.handler” />
<property name=”contextPath” value=”${webapp.contextPath}” />
<property name=”virtualHosts” value=”${webapp.virtualHosts}” />
</bean>
<bean id=”web.handler”
class=”com.flashvisions.Application”
singleton=”true” />
</beans>

The last bean instructs Red5 about the main application class. So just before the </beans>
closing tag .. we will add the directive for our CustomFilenameGenerator class.
So our final red5-web.xml will look like this:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN”
“http://www.springframework.org/dtd/spring-beans.dtd”>
<beans>
<bean id=”placeholderConfig”
class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>
<property name=”location” value=”/WEB-INF/red5-web.properties” />
</bean>
<bean id=”web.context”
autowire=”byType” />
<bean id=”web.scope”
init-method=”register”>
<property name=”server” ref=”red5.server” />
<property name=”parent” ref=”global.scope” />
<property name=”context” ref=”web.context” />
<property name=”handler” ref=”web.handler” />
<property name=”contextPath” value=”${webapp.contextPath}” />
<property name=”virtualHosts” value=”${webapp.virtualHosts}” />
</bean>
<bean id=”web.handler”
class=”com.flashvisions.Application”
singleton=”true” />
<bean id=”streamFilenameGenerator”>
<property name=”playbackPath”>
<value>C:\</value>
</property>
<property name=”recordPath”>
<value>C:\</value>
</property>
</bean> </beans>
As per the above example …all streams will be recorded to/played from my c: drive. You can set your
account path instead of c:/ to use your own folders for streaming.

This tutorial was writen by Rajdeep Rath from Flash Visions

Why it takes so long to see my site using the domain? Is it a DNS propagation issue?

Youve registered your domain name, and paid for hosting with a web hosting company, and started uploading your site to the server. If this is all done, why cant you see the your site when you browse to your domain? What is this DNS propagation people keep telling you about? In order to understand DNS propagation, you must first understand a little about how DNS works.

When you set up your website with your hosting provider, they create a Master DNS record in their Domain Name Servers. Your domain registrar (the company you paid for the honor of owning your domain name) points to your web hosts DNS server as being the master authority of your domain. When any outside source wants to know how to find your website, they first go to the registration database to find out who the DNS authority is for your website. Then they visit your hosting providers DNS servers to find out what the IP Address is for your domain name, and from there your audience can now view your website.

The problem with this whole scheme is that in order to speed up the rate at which their customers can view the internet, each Internet Server Provider caches their DNS records. This means that they make their own copy of the master records, and read from them locally instead of looking them up on the Internet each time someone wants view a website. This actually speeds up web surfing quite a bit, by (1) speeding up the return time it takes for a web browser to request a domain lookup and get an answer, and (2) actually reducing the amount of traffic on the web therefore giving it the ability to work faster. The downside to this caching scenario and what makes it take so long for your website to be visible to everyone, is that each company or ISP that caches DNS records only updates them every few days.

This is not any kind of standard, and they can set this time anywhere from a few hours to several days. The slow updating of the servers cache is called propagation, since your websites DNS information is now being propagated across all DNS servers on the web. When this is finally complete, everyone can now visit your new website. Being that the cache time is different for all servers, as mentioned above, it can take anywhere from 36 to 72 hours for DNS changes to be totally in effect.