Feeds:
Posts
Comments

Archive for the ‘Technical’ Category

We often get asked how Mydeo differs from Amazon S3 – so here’s a quick summary.

Amazon S3 is a storage system, whereas Mydeo provides Content Delivery via a Content Delivery Network (CDN). The CDN Mydeo use exclusively is Limelight Networks, one of the leading global CDNs optimised for rich media delivery.

The focus of S3 is not to get the content to the client as fast as possible, it is to have it available to them when they need it. A CDN incorporates both of these things, the content is always available and the network is designed to get it to the customer as fast as possible. There is also no chance of any down time on a CDN because of the numerous server clusters around the world. With a CDN, if a data centre were to go down, the content would just be delivered from a different location. Amazon’s S3 has been known to go down in the past for hours at a time, on one occasion it was down for over 24 hours – and no explanation was ever given as to why from Amazon.

Amazon’s pricing can be complicated. While it will be cheaper than a CDN it is not a cheap as it may first appear – you must pay for connections as well as throughput.

Amazon’s S3 is a great system for what it is designed to do but that is not streaming video delivery. A CDN is designed for video delivery primarily and the files are delivered from appropriate servers – flash files from an FMS etc.

I would therefore always recommend using a CDN for any streaming media delivery where viewers would, rightly, expect excellent delivery performance and 100% availability.

Read Full Post »

Live streaming: Push vs. Pull

When encoding video or audio, you have two options. You can either ‘push’ the stream or ‘pull’ the stream. Each method has advantages and disadvantages which we will discuss here and help you to choose the method best for your circumstances.

Pushing a stream:

With a push stream, the local machine running the encoder is initiating the connection. This connection has to be made with a streaming server.

The main advantage of pushing a stream is that router port forwarding and firewall exceptions do not have to be made. A static IP address is not required to push a stream which would be necessary with the pull method. Static IP addresses are less common than they used to be and with some ISPs they have to be paid for. On an internet connection with no static IP address available, pushing the stream will be your only option. A push stream is generally less stable than a pull stream and would consume more local bandwidth because it is constantly connected to the streaming server that it is pushing to.

A push stream would normally be used for short one off webcasts rather than 24/7 webcasting because of its inherent bandwidth overheads.

Pulling a stream:

With a pull stream, a streaming server (or a viewer) initiates the connection with the encoding machine. It is possible to webcast without the use of a streaming server using the pull method; however, if more than 2 or 3 people connect to the stream simultaneously it will suffer and not be delivered properly to any of the viewers. When a streaming server is ‘pulling’ from the local encoder it would be possible to have hundreds of thousands of viewers without the stream suffering at all.

One of the big advantages of pulling a stream is that the server will only connect to the encoder when the stream is requested by a viewer. This means that you will be limiting your local bandwidth usage by using this method because you will not have to be constantly connected to the server. This obviously makes it much more suitable for constant 24 hour streaming. It is possible to restrict access to the encoder by IP address – which means you can only allow the streaming server to connect and restrict any unauthorised access. Windows media encoder also records and IP address of connections so you can see who is connected at any time.

One disadvantage of using this method is that in order for the streaming server to connect to the encoder, port forwarding and firewall exceptions will have to be set up. Using the pull method is ideal for streaming from a static location where the configuration of the network stays constant.

Conclusion:

When choosing the method you are going to use, the best thing to do is ask yourself a few questions before you start.

1.       Do I have a static IP address?

2.       Am I going to be broadcasting for longer than a few hours at a time?

3.       Do I have access to the router to set up port forwarding or firewall exceptions?

4.       Will I be broadcasting from more than one network?

If you answered no to the first question then pulling a stream will not be an option for you. If you are going to be broadcasting for more than a few hours pulling the stream would be the obvious choice because you will save on bandwidth use. Without access to the router (or someone who does have access) you will not be able to set up the port forwarding properly and the streaming server will not be able to connect to your encoder with the pull method which mean, you will have to push. When you are broadcasting from more than one network, the settings are likely to be different on each network. Pushing the stream would most definitely be a better option here because it will work regardless of the network security in most instances.

Read Full Post »

FLV Seek

Many of our customers at Mydeo have asked us about the concepts of FLV Seek. It is useful to remember that FLV Seek and Streaming are two different things but appear to the end user as being the same. Limelight Networks have provided some useful information about FLV Seek and how you can utilise the benefits:

FLV Seek

When you deliver your Flash video files via progressive download, it’s usually an all or nothing deal. You pay for delivering the entire file, even if your user skips most of the content. But with the FLV Seek feature of LimelightDELIVER, you can let your audience jump to any point in the media. Not only does this eliminate unnecessary delivery costs, but it provides a better user experience. For example, if a viewer wants to skip the first half of a video, FLV Seek jumps to the second half of the file, resulting in a smaller download and faster user access.

Seek and deploy

All you need to do to deploy FLV Seek is update your metadata to include keyframe and offset locations. When your user skips ahead, your embedded player will start playing from the closest keyframe relative to his scrub point. In this way, FLV Seek simulates Flash video streaming for progressive download scenarios.

Perfect for social media and other user-generated content, FLV Seek offers an economic way to provide a great user experience.

We hope that this article has helped to create a better understanding of FLV Seek. Remember, Mydeo offers full support for videos using FLV Seek, so no need to look any further!

Thanks for reading.

www.mydeo.com

Read Full Post »

Embedding live streams with Flowplayer

Previously, we discussed embedding flash videos into a webpage for on-demand content here – http://blog.mydeo.com/2009/04/24/flowplayer-quick-start-guide/. While this article covers both RTMP streaming and HTTP delivery methods it does not include instruction for how to get live flash streams to work with flowplayer.

The basics for this remain the same:

Please note that the .js and .swf files referenced in the code below could be a different version to the ones you’ve just downloaded in the Flowplayer pack. Make sure you reference the correct versions of these files in your code.

Flowplayer now needs to be told that the video is a live stream and for viewing stream from the limelight FMS the stream needs to be subscribed to. The code below explains how to do this:

<html>
<head>
<script src="flowplayer-3.1.0.min.js"></script>
</head>
<body>
<div>
<a style="display: block;height:400px;width:600px;background-color: #ffffff;border: solid 1px #ccc;" id="rtmp_player"></a>

<!-- Note: the property of the above tag (rtmp_player) must match the first parameter of the script below -->

<script>
                $f("rtmp_player", "flowplayer-3.2.5.swf", {
                    clip: {
                       url : 'stream1', //this is the name of the stream assset in the encoder
                       live : true,  // tell flowplayer it's live
                       provider: 'rtmp'
                 },

                plugins: {
                  rtmp: {
                  url: 'flowplayer.rtmp-3.2.3.swf',
				  netConnectionUrl: 'rtmp://xyz.fc.llnwd.net/xyz' ,  //this is the rest of the URL excluding the stream name that you set in the encoder
				  subscribe:true  //subscribe to the stream
                      }
                 }
              });
</script>
</div>
</body>
</html>

With all that in place you should have no problem viewing your live flash streams in Flowplayer.

As usual, if you have any questions or problems, please feel free to contact us on m3@mydeo.com and we will do our best to help you.

Read Full Post »

The main benefit of using a CDN such as Limelight Networks (via mydeo.com) is that your content is accessible much faster than if it was self-hosted. This is because, in addition to having your content stored globally on a network of high-speed servers interconnected by high-bandwidth connections (a “private internet”), it is also cached.

Why is it cached?

When you upload your content to us, you’re actually uploading it to a local network of redundant servers called ‘origin servers’. Depending on where you are in the world, the origin servers will change. When someone on the public internet requests your content, that file is then ‘copied’ (although, not physically) to the nearest endpoint that Limelight Networks has in relation to the person making the request of your content. This second copy is known as a ‘cached copy’, and it is for all intents and purposes a snapshot of your file at a particular point in time.

By caching your file for subsequent requests, considerable performance gains can be harnessed.

The period of time for which your file resides in cache is known as ‘TTL’, or ‘Time To Live’ – and that will be the subject of our next article coming soon.

Is that why a file I deleted is still accessible on the CDN?

Generally speaking, if you’ve deleted a file from either mydeo.com or your mydeo FTP account, and it is still accessible using it’s URL, then yes – caching is in effect. But don’t worry, your content will disappear off the network soon. If it’s an emergency, however, and you need the content to be removed quicker than allowing it to expire ‘naturally’, you can contact us and we can request a purge of the cached content on the network. This process generally takes 2-4 hours from the time the request is made, but in some circumstances can take up to 24 hours to complete.

Read Full Post »

At mydeo, our crossdomain.xml file is not stored at the root of our domain(s). If you’re trying to access http://ht.cdn.mydeo.net/crossdomain.xml or http://mydeo.vo.llnwd.net/crossdomain.xml and wondering why they aren’t working, that’s because they’re not there!

Mydeo does not use a wildcard crossdomain.xml file, meaning that if your domain is not already listed in our crossdomain.xml, you will need to request it is added first. Then, follow the steps below to get your Flash application working correctly.

If the files you want to access are hosted on any of the following domains, you will need to append “/o1/u/m3/crossdomain.xml” to the root paths:

It is common belief that crossdomain.xml needs to be at the root of a domain, but this requirement can be worked around by utilizing the following commands in your application:

  • System.security.allowDomain()
  • System.security.loadPolicyFile()

These two commands were designed to allow the crossdomain.xml file to be loaded from anywhere within the domain tree and should be used as follows (choose based on the URL of the content you are attempting to access):

These must commands must be executed prior to loading any objects inside your SWF or it will have non-deterministic results (almost certainly failure to load).

Additionally, in Flash 10, the default header has been changed to ‘Master-Only’, this is the only significant change that has been made.

To deal with this, Limelight Networks does a header injection for calls to the crossdomain.xml on the root domain file which adds the following:

  • X-Permitted-Cross-Domain-Policies: all

 This header permits Flash to look in the location specified for the crossdomain.xml file in the o1/u/m3 subdirectory.

Read Full Post »

We are proud to announce the release of a new feature, available free of charge to all Mydeo customers:   

Introducing Quick Share

Quick Share makes it easy to share your media with the world without having to cut and paste code or even have a web site. 

   

Quick Share adds a link next to compatible media files in Media Manager that creates a unique, publically accessible player page (complete with social network sharing links) so that you can share that file with anyone you choose.   

Easily share your media with social media links!

Benefits

  • No need to host your own web site to share your media
  • No coding necessary
  • 1-click setup
  • No need to license third-party players

Just click the button next to the file you want to share, and we generate a unique link that you can give out to anyone you want to see share your video or pictures with.   

Supported media formats

At the moment, our player page supports media of the following types:   

  • Windows Media (.wmv, .avi)
  • Flash (.flv)
  • JPG, GIF, BMP, PNG
  • QuickTime (.mov, .qt)

The player page does not support ‘non-media’ formats, such as .ZIP or .TXT, for instance.   

How to create your player page

Follow these steps to create your unique player page:   

  1. Log in to your Mydeo account (if you don’t have one, you can get a free 15-day trial account).
  2. Go to Media Manager. If you don’t have any media yet, upload one of the supported media types above.
  3. Click the “Preview” link next to the file you want to share in Media Manager.
  4. This will generate a unique player page for your media, and you can share it with the world using the link provided!

Customising the width and height of your player

Windows Media, Flash and QuickTime players can have their height and width adjusted manually. To do this, you must alter the URL that you give people.   

For instance, let’s say your sharing page is http://m3.mydeo.com/play/?f=123456   

To customise the height and width, you would append the URL parameters ‘h’ and ‘w’, and set them to the values you want, like this:   

http://m3.mydeo.com/play?f=123456&w=500&h=350   

In this example, the URL will set the player width to 500 pixels and the height to 350 pixels.   

Suppressing the “Share this!” links

Added: 30th April 2010

To turn off sharing, simply append the query string parameter hideSharing with a value of y to your URL. For example:

http://m3.mydeo.com/play?f=123456&w=500&h=350&hideSharing=y  

Let’s hear your feedback!

This new feature is in BETA – so we’d love to hear your feedback. Let us know what you think – good and bad, so we can improve!

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.