Adobe's Emerging Rich Media Ecosystem, Part 3: Marketing, Service Level Agreements, and Security

Monday May 5th 2008 by Marcia Gulesian

You need both technical expertise and business savvy to create and maintain a successful streaming media site.

EMarketer projects that nearly 80% of U.S. Internet users will watch online video at least once a month in 2008. A great indicator that online video has hit a mainstream audience is that 52.5% of all Americans, or 154 million, people will watch online video in 2008. By 2012, there will be an estimated 190 million video viewers.

So, if you are the publisher of one of these videos, you are probably interested in knowing the who, how, when, where, and so on about the viewers of your content.

For this, you need to carry out an online media analysis in order to find out whether your "marketing" strategy is working.

That's where Flash Media Server 3's powerful logging capabilities, which can be highly customized for your specific application and other optional analytics software, can help.

Analyses of this sort offer commercial contributors insights they can use to target their pitches.

For example, video producers who find their viewership peaks on Wednesdays could release new clips then. Likewise, producers who see their shows peaking after three weeks would know to release a new episode every three weeks, and someone whose material turns out to be popular in Spain might want to release the next video in Spanish.

A movie studio that uploads a trailer to your site could use geographic information to see where the clip is most popular and perhaps buy ads targeted to users in that region. They might want to gather additional information, such as how many times their video was viewed or commented on.

With this information, contributors can concentrate on creating compelling new content that appeals to their target audiences and post these videos on days they know these viewers are on the site.

Viewership breakdowns could count not only the number of times users start a video but also how many finish it. You might want to know information on how many viewers make it through 25 percent, 50 percent, or all of a video.

Access Logs

The access log of Flash Media Server 3 records information about connection requests by Flash Player and Flash Media Server application instances. The default configuration creates a single access log per server, called access.XX.log, which is located in the Flash Media Server logs directory. (Note: You also can configure Flash Media Server to create a separate access log for each virtual host.)

The access log will record data, such as:

  • Date and time a client connected to the server
  • How much total bandwidth was consumed during the session
  • Which streams were accessed by the connection
  • Whether the client published a stream
  • Whether the client jumped to a new location within a recorded stream

There are also application logs that record information about activities in application instances.

There is, of course, a cost to logging: The processor cycles you burn up for logging constitute a performance hit.

Server-Side ActionScript API

Because a progressive download is a simple download of a file, you can't easily log specific relevant statistics such as how long the video was viewed; whether the user navigated forward, backward, or paused the video; how many times the viewer played the video; if the viewer left the web page before the video completed playing; and so on. Streaming enables you to capture this important data easily.

To customize these tasks, there are many server-side programming options available in Flash Media Interactive Server and Flash Media Development Server. For example, methods like the following are available:

  • getInstanceStats()
  • getUsers()
  • getUserStats()

In addition, with Flash Media Interactive Server and Flash Media Development Server, you can use Server-Side ActionScript to connect to other systems, including Java Enterprise servers, .NET servers, and Web services. This connectivity allows applications to take advantage of external recourses such as DNS, LDAP, and database servers.

Google Analytics

There are ways of gathering analytics on web site usage as well. Remember, Flash Media Server is an RTMP, not an HTTP, server!

For example, Google Analytics, a web traffic analytics service, is a prototypical AIR application that is comprehensive, and totally free. It's a tool that can help you understand your traffic/visitors, measure performance of individual pages (or even ad units), identify low performing web pages, and more. Note: If your web site receives fewer than 50-100 K pageviews/monthly, any simpler analytics tool should be sufficient as well.

Bottom line: Marketing is a data-driven pursuit. To paraphrase Boswell, "Data, Sir, is like lace; every person should get as much of it as he or she can."

Service Level Agreements

Whether hosting or using a media server (or any other kind of server for that matter), the terms of service are sometimes provided in a document called an SLA, for service level agreement. This document details the fine print about how much uptime the service guarantees, how quickly and effectively the provider will respond to an outage, and whether it will compensate the user or reduce their fees if it does breech its service guarantee. In short, an SLA is a contract that dictates what level of service the provider is obligated to provide and what credits/remuneration, if any, is required when the terms of the SLA are not met.

SLAs can be between different businesses or between different parts of the same organization (such as the IT department and its users).

At its weakest, an SLA may be a simple oral understanding, documented by an exchange of letters. The best form is a formal legal agreement with the technical procedures and specifications annexed as separate schedules.

What happens if the terms of a service level agreement are broken? If the breach is fundamental, the party not in breach will be entitled to terminate the agreement and sue for the loss suffered as a result of the breach.

In other circumstances, there will be a system for measuring breach and apportioning cost. These systems range from an event-based system (if... then...) to a more sophisticated system of 'failure points' (if there are more than five examples of ... then ...).

The functions of such compensation systems vary from simply drawing attention to a problem to compensation for loss. Compensation for loss is difficult to quantify and, if it is excessive, will be unenforceable by a court (which will regard it as a penalty).

In practice, the right to withhold payment is a valuable weapon. The end (or slowing down) of payments into the supplier's accounts department is likely to put pressure on the supplier.

Escalation clauses are undervalued and should be more widely used. These provide for a problem to be escalated up the various tiers of management on both sides if it cannot initially be resolved.

Even the best SLA does not last forever and there must be a procedure for orderly termination and (if necessary) migration from the supplier's system to another system.

Migration is critically important in relation to facilities management contracts and, as a rule of thumb, a year is generally allowed for this. The supplier also should be required to provide all reasonable assistance to the client with the migration to another system.

SLAs Need Technical Expertise As Well As Business Savvy

The complexity of correctly mapping the requirements of a known media service workload into the corresponding system resource requirements and accurately sizing a media server cluster to handle the workload with specified performance requirements makes difficult the task of creating a good SLA.

Note: Because workload measurements of existing media services indicate that client demands are highly variable ("peak-to-mean" ratios may be an order of magnitude or more), it is not economical to overprovision the system using "peak" demand.

The SLA might specify the desirable system performance by stating two types of requirements:

i.) "basic capacity requirements" that define the percentage of time the configuration is capable of processing the applied load without performance degradation while satisfying bounds on system utilization; and ii) "performability requirements" that define the acceptable degradation of service performance during the remaining non-compliant time and in case of node failures during the service time.

To identify the number of nodes necessary to support the required service performance, the provider must consider bit rates, as well as amount of CPU, memory, and disk resources needed to handle a given workload. If you assume that a site's media content is encoded at a constant bit rate for a given workload, it is relatively easy to determine what network bandwidth is required. However, bit rate is usually variable.

As a result, determining the media service workload is a complicated, statistics-based task. The service provider must collect and then analyze media server access logs reflecting processed client requests and client activities at the site.

Sometimes, a high percentage of requests access a small subset of media files. Moreover, many clients do not finish the playback of a full video/audio clip. So, for example, you could discover that as much as 50%-60% of the accesses last less than 2 minutes. Therefore, many accesses to popular media objects can be served from server memory, even when the media server relies on traditional file system and memory support and does not have additional application level caching.

Scaling Flash Media Server 3

Servers have a finite capacity, so as traffic and throughput increases, applications need to be scaled to preserve quality of service. Flash Media Server offers several flexible options for the graceful scaling of high-traffic applications. Knowing that you can increase the capacity of your system when needed is an important detail when writing an SLA.

Cluster Deployment

You can deploy multiple servers behind a load balancer to distribute the application load evenly. Flash Media Server clustering enables you to scale an application to accommodate more clients reliably, and creates redundancy, which eliminates single points of failure. This approach is generally best for live or VOD streaming, where clients do not need to communicate with each other from within specific application instances.

Clustering can be achieved by using either Flash Media Streaming Server or Flash Media Interactive Server. Both provide an enterprise-ready architecture designed to simplify load balancing, failover, and clustering to ensure maximum availability over large regions—the Edge/Origin architecture shown in Figure 3.

Flash Media Server Intelligent Balancing

With the Flash Media Interactive Server, you can intelligently direct traffic to a multiple server cluster using server-side scripting. This option would typically be used for multi-way communication applications that require connections be routed to a specific server. However, this option does require the development of rather sophisticated server-side ActionScript to manage connections.

Edge/Origin Configurations

Flash Media Interactive Server software can serve as either an Origin or Edge server to enable virtually unlimited scalability.

Click here for a larger image.

Figure 1: Edge/Origin architecture

Edge/Origin server configurations improve performance by distributing the server load among many computers on a network. With an Edge/Origin deployment strategy, all connection requests from clients are redirected to an Edge server. The configuration also lets you maximize your network if you are supporting a large local network. By placing Edge servers in remote office locations, the Edge servers will cache media files locally so each stream does not need to access the Origin (host) server for each stream.

When a client request is received, the Edge server will handle the tasks it can, and then will make a connection to the Origin server for any additional data required. When the Origin server fulfills the request, the data is sent back to the Edge server, then on to the client. To the client, it appears that the connection is made directly to the application running on the Origin server.

The Edge server serves as a "traffic cop"—handling connection overhead, authentication, and other administrative duties—freeing up valuable system and network resources for the Origin server. Every connection and connection attempt consumes resources over and above the actual stream data flowing through the connection. As the number and frequency of connections increase, the load can be excessive; adversely affecting server performance.

The Edge server greatly reduces this load by aggregating connections. The Edge multiplexes the connections from a large number of clients into one connection to the Origin server. All communications between Edge and Origin servers are transparent to clients.

The Edge server also stores the prerecorded media content received from the Origin server in a cache, which is then made available to other clients that connect to the Edge server. Caching static content further reduces the load on the Origin server.

The Effects of Mobility on Wireless Media Streaming Performance

There are other examples that illustrated the need for and difficulty of capacity planning prior to the drafting of an SLA. In many cases, media is delivered from a streaming server on a wired network to mobile clients on a wireless LAN. There are two scenarios: with and without client mobility. Before releasing a new system, you should determine media streaming performance in best-case and worst-case scenarios for each case.

Two main points need to be understood: First, wireless media streaming performance can degrade significantly in the presence of user mobility. (Inconsistent wireless channel quality and intermittent connectivity can lead to excessive retransmissions, dynamic rate adaptation, and RTS/CTS negotiations on the WLAN. These delays degrade the performance of the wireless streaming application.)

Second, the performance degradation affects all clients in the WLAN, not just the clients who are mobile. This problem occurs because of the shared queue at the access point.

These observations highlight the many challenges for providing quality of service guarantees for wireless multimedia streaming. One possible solution is to use per-flow queuing at the access point, or a buffer management scheme that provides fairness.

Figure 2: Delivering media to mobile clients on a wireless LAN.

Another solution is to configure an access adaptor to accept or reject requests based on the number of clients currently connected or the amount of bandwidth currently being consumed.

The Recent FCC Auction of the 700 MHz Spectrum

The U.S. Federal Communication Commission (FCC) has been auctioning off part of the valuable 700 Mhz spectrum—this RF travels long distances and can penetrate thick walls—being "returned" by television broadcasters as they move to digital from analog signals in 2009. These frequencies will be accessible to customers using any device or software application.

At the same time, Google, Microsoft, and other tech companies are pushing for the ability to use these empty, unlicensed airwaves, known as white spaces, to provide high-speed Internet service that might be able to serve hard-to-reach rural regions and supplement other Internet services in cities. But opponents of this idea, namely television broadcasters who use adjacent airwaves, say white-space use can interfere with regular TV signals and could blot out over-the-air broadcasts.

I mention this controversy because, as we approach the next generation of wireless broadband services, there are new unresolved issues that could influence the quality of your broadcast media at its very source: For example, wireless microphones for sporting events, concerts, and churches, which use this unlicensed spectrum. TV broadcasters say this technology could put their productions at risk and support auctioning off those fallow airwaves and making them licensed in order to protect against interference. Stay tuned.


Flash Media Server distributes media streamed via RTMP, an Adobe-patented protocol that runs over TCP. Flash Media Server helps to further protect streamed media by encrypting it and tunneling it over HTTP. This new protocol is called RTMPE. Users view the streamed content via Flash Player. Similar in strength to Adobe's current SSL protocol (RTMPS), this enhancement can be leveraged by content owners and communication developers to add additional protection to their content. Additionally, SWF verification helps protect SWF files from being reused, modified, or hosted in alternate locations. And, Flash Media Server 3 also supports streaming of encrypted content to Adobe Media Player.

Figure 2 and the Appendix present an overview of the security options available in Flash Media Server 3.

Adobe's new Flash Media Rights Management Server (FMRMS) sits alongside the Flash Media Streaming Server or Flash Media Interactive Server and protects streaming content downloaded in FLV (Spark or VP6 codec) or MPEG4 (H.264 codec) format and played back on local desktops.

Click here for a larger image.

Figure 3: Flash Media Server security architecture.

Digital Rights Management

FMRMS runs on Windows Server and Red Hat Linux to offer content protection and business rules for playback and repurposing of offline content. FMRMS works with applications built on Adobe AIR, such as Adobe Media Player, to extend control of Flash content—even after it's been downloaded. Content owners can set customized restrictions including how long the content can be viewed, whether an ad needs to be watched first, and who can view it.

Content could be set to require confirmation of playback each time—meaning that a device would require an Internet connection each time "offline" content was accessed—or could be set to require a connection every so many days, weeks, or months.

Media broadcasters could potentially set the access requirements and expiration flags of content that is being streamed both on request, but more importantly dynamically after the file has been distributed.

The content owners I've referred to above include:

  • Enterprises who want to deliver video content securely to employees and partners
  • Film and television studios or producers or online video content creators
  • Content distributors such as Internet Service Providers or online video rental outlets
  • Companies with a significant Internet multimedia presence, such as sports and entertainment sites

Content owners and publishers can make money with FMRMS through advertising and licensing. FMRMS, by signing a digital playlist, locks advertising together with content so they always play together. Adobe Media Player offers additional branding opportunities with banners, in-rolls, and overlays. FMRMS, in conjunction with existing user authentication and order management systems, grants a license to individual users for a particular piece of content.

Digital Rights Management (DRM) for offline content isn't new. Apple implements it with every music purchase, but Adobe's approach gives the content holder more options. The DRM can be as restrictive as the content owner wants.

Note: I doubt that Adobe has any illusions that FMRMS will stop copyright infringement—any more than dozens of other DRM systems have done so—but the introduction of encryption does give Adobe and its customers a powerful new legal weapon against competitors and ordinary users through the Digital Millennium Copyright Act (DMCA). Under section 1204, penalties range up to a $500,000 fine or up to five years' imprisonment for a first offense, and up to a $1,000,000 fine or up to 10 years' imprisonment for subsequent offenses.


This article, the third in a series, was preceded by:

And, the series itself was preceded by:

Taken together, these four articles provide an overview of an evolving ecosystem for developing, deploying, and managing rich media applications, albeit an ecosystem from only one vendor. However, so far, this one vendor has a commanding lead in the marketplace and, so, in my opinion, anyone with responsibilities in this area ought to have at least passing familiarity with the topics covered above.


Flash Media Server

Delivering your content with Flash Media Server provides even more protection than that provided by Flash Player alone:

  • No client cache: Flash video and audio content delivered to Flash Player using a normal web server are delivered through progressive download. This content is cached on the end user's hard drive and can be easily accessed—and possibly stolen by the user. By contrast, video, audio and data streamed to Flash clients using Flash Media Server are not cached on local client machines. You can deliver MP3 files and other media safely and securely knowing that your web site visitors will not be able to go to their Temporary Internet Files folder and obtain your media file assets.
  • No exposed media on the server: When you deliver Flash audio and video using progressive download, the content is exposed on a web server. Savvy computer users may be able to obtain the URL of the web server on which the content is stored and access the content directly. In fact, there are a couple of services, such as KeepVid, which use this exact technique to capture Flash progressive download video and save it to a client's disk. With Flash Media Server, however, the content is not exposed to HTTP, FTP, or other transfer mechanisms, so media cannot be copied down from the server.
  • Note: Some services erroneously claim to capture "streaming" Flash video, but what they really mean is "HTTP streaming" or progressive download.
  • Proxy server capability: Content streamed from Flash Media Server is not only safe from being grabbed from a server, but Flash Media Server even comes in an Edge Edition that you can place on a server outside the firewall, making it act as a reverse proxy serving up content pulled from an Origin Edition on a server that is behind the firewall. This way, your media files are safely kept behind your firewall and no content is stored on a machine that is accessible to the Internet.
  • Unique transfer protocol limits stream ripping: By default, content delivered by Flash Media Server is wrapped inside the Adobe RTMP protocol. Because this is an unpublished, proprietary format, none of the RTSP stream ripping programs have the capability to rip media delivered over Flash Media Server. This minimizes the ability of unauthorized programs to capture a digital media stream from Flash Media Server to Flash Player.
  • Support for SSL and encrypted streams: Flash Media Server provides the ability to deliver encrypted streams to provide the tightest layer of security for delivering digital media. When you use this option, the server encrypts all audio, video, and data streams prior to transport. Once they are safely delivered to the client, Flash Player decrypts the content in real time and provides it to the user. This encryption is invoked when the client sends information to the server as well, providing the best way to protect content as it travels between the client and server.
  • Client information: When a client connects to Flash Media Server, Flash Player passes certain information about the client up to the server. Information such as the domain or IP address from which the client is connecting can be used to prevent deep linking and other thefts. You can also use this for syndicating content or a player and content to authorized partners.

Deep Linking

Deep linking is when people at other web sites use images on their web site but they are hosted on your server. At the very least, this costs you bandwidth. Some sites look at the referrer address and when the request isn't from the site's domain, provide a picture saying deep linking isn't allowed.

Some commercial web sites object to other sites making deep links into their content either because it bypasses advertising on their main pages, passes off their content as that of the linker or, like The Wall Street Journal, they charge users for its content. Sometimes, deep linking has led to legal action, such as in the 1997 case of Ticketmaster versus Microsoft, where Microsoft deep-linked to Ticketmaster's site from its Sidewalk service. This case was settled when Microsoft and Ticketmaster arranged a licensing agreement.

Ticketmaster later filed a similar case against, and the judge in this case ruled that such linking was legal as long as it was clear to whom the linked pages belonged. The court also concluded that URLs themselves were not copyrightable, writing: "A URL is simply an address, open to the public, like the street address of a building, which, if known, can enable the user to reach the building. There is nothing sufficiently original to make the URL a copyrightable item, especially the way it is used. There appear to be no cases holding the URLs to be subject to copyright. On principle, they should not be."

Note: Web sites that are built on rich web technologies such as Adobe Flash and AJAX often do not support deep linking. This can result in usability problems for people visiting such web sites. For example, visitors to these web sites may be unable to save bookmarks to individual pages or states of the site, web browser forward and back buttons may not work as expected, and use of the browser's refresh button may return the user to the initial page.

However, this is not a fundamental limitation of these technologies. Well-known techniques now exist that web site creators using Flash or AJAX can use to provide deep linking to pages within their sites. The References section contains links to additional information on this subject.

Client Authentication with Flash Media Server

Using Flash Media Server, there are a number of different ways that publishers can verify and authenticate users before a stream is delivered. Authentication methods available in Flash Media Server include the following:

  • Authentication at the SWF level: In this rather simple method of authentication, the publisher authenticates viewers using existing systems prior to serving the SWF file. Once a user passes authentication and the SWF file is served, audio and video content can be streamed. The benefit of this method is that it fits within your existing workflow, requires no additional changes, and yet authenticates users before serving up content.
  • Authentication at the stream level: With this method, a SWF file is served up without protection but users are authenticated when they connect to the server and request a stream. This authentication can be done two ways with Flash Media Server:
    • Scripting: Using a combination of client-side and server-side ActionScript, client information such as username, password, or even connection information can be passed to the server running Flash Media Server. Once that happens, that information can be used to authenticate users against back-end systems. Support for XML objects and Flash Remoting calls in the server facilitate this process.
    • Executing authentication applications: For the maximum level of control, a plug-in module with Flash Media Server enables publishers to run external applications that are responsible for providing access to the server and content. This is useful for providing access in pay-per-view scenarios or even to prevent rogue sites from deep-linking into your content or server.

The options listed above can be used to support a number of different authentication uses, including:

  • Support streaming in a single sign-on system
  • Authenticate users against an LDAP directory
  • Prevent unauthorized sites from deep-linking to your content
  • Prevent others from stealing bandwidth
  • Support pay-per-view content or events
  • Offer rights management or conditional access to streamed content

Adobe Flash Player 9 Security

Adobe Flash Player runs Flash applications (also referred to as SWF files). Flash Player content is delivered as a series of instructions in binary format to Flash Player over web protocols in the precisely described SWF (.swf) file format (described at The SWF files themselves are typically hosted on a server and then downloaded to, and displayed on, the client computer when requested.

SWF files consist of multimedia content (vectors, bitmaps, sound, and video) and binary ActionScript instructions. ActionScript is the ECMA standards-based scripting language used by Flash; it features APIs designed to allow the creation and manipulation of client-side user interface elements, and for working with data.

Flash Player is designed to allow all SWF file content to be viewable and available consistently across a broad range of platforms, browsers, and devices. Flash Player also is designed to provide a robust environment to ensure security and privacy for the author, user, host institutions, and any of their respective data.

Settings Manager

The Settings Manager is a special control panel that runs on your local computer but is displayed within and accessed from the Adobe web site. Adobe does not have access to the settings that you see in the Settings Manager or to personal information on your computer.

Figure 4: Flash Player security option settings (one of several dialogs)

The Flash Player Security Environment

The Flash Player client runtime security model has been designed around resources, which are objects such as SWF files, local data, and Internet URLs. Stakeholders are the parties who own or use those resources. Within the Flash Player security model, each stakeholder can exercise controls (security settings) over their own resources, and each resource has four stakeholders. Flash Player strictly enforces a hierarchy of authority for these controls, as Figure 5 shows:

Figure 5: Hierarchy of security controls

This means, for instance, that if an administrator restricts access to a resource, no other stakeholders can override that restriction. In Flash Player, it is common for multiple stakeholders to have the ability to control access to a resource, and for some stakeholders to formally delegate the right of control to a lower level in the hierarchy. For example, Administrators regularly allow users to make security decisions about their own environment.

Figure 6: Adobe Flash vis-à-vis other players on Internet-enabled PCs


About the Author

Marcia Gulesian is an IT strategist, hands-on practitioner, and advocate for business-driven architectures. She has served as software developer, project manager, CTO, and CIO. Marcia is author of well more than 100 feature articles on IT, its economics, and its management.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved