Strategic Consulting

Recently RealEyes joined the Varnish Software family, and became the first North American reseller and training partner. This is a very exciting partnership and runs in line with our goals and vision for effective delivery of streaming media. The Varnish Plus product is an amazing tool for caching your website and streaming media.

In June we delivered our first public Varnish Administration Class and we, as well as the attendees, were thrilled with the results. That said, we are proud to be able to offer more training sessions within the balance of this year. On September 18th and 19th in Boston, MA and on November 13th and 14th in Denver, CO, we will hold live public classes. These classes will feature a combination of lecture and hands on training, and with the additional option of taking the Varnish certification test at the end of the second day. On August 21st and 22nd, we’ll have an online class. The online class offers the same course material, but no certification test at the end of the course. As always, the sessions will provide valuable and resourceful information for users of Varnish with a heavy emphasis on implementation, deployment, customization, and monitoring. This is a great opportunity for Varnish users of all skill levels to become better users.

If you’re still curious about what Varnish does in general, please have a look at the New York Times website, and be sure to pay attention to the load times of the images and other media. It also works wonders for on-demand content, as well. Check out Vimeo.

Still not convinced? OK, take a quick look at VG (Verdens Gang), which is Norway’s largest newspaper.  VG is leveraging Varnish for their exclusive, real time article cloud:

“Some months later @ VG Multimedia 12 squid servers hit the dust and were replaced by 1 server running Varnish. One server handling all requests (45 Million a week) faster than before and with a noticeable carbon footprint reduction.”

If you want even more in depth technical info, check out this article on data visualization the most read articles at VG with Varnish:

Want to learn more about Varnish and how you can use it to make your website fly? Contact us today and we’ll get you going with Varnish!

I’ve been asked a lot of questions and have done a lot of work recently around security hardening for HTTP Streaming with Adobe Media Server (AMS) and Apache. Content protection and sever security and hardening is an evolving beast and the best thing to do is to keep in mind what needs to be secure and how it can possibly be circumvented. However, there’s some basic things to know and a couple tips I can shed some light on within the span of a blog post.

First, with HTTP streaming I think of security in three major categories:

  1. Server security
  2. Content protection over the wire
  3. Content protection while at rest and preventing unauthorized access

Server Security

When considering the origin of your content, you need to follow the general server hardening and security processes:

  • Decreasing access to root level accounts.
  • Protecting authentication info such as passwords and certs. Changing them from time to time as well.
  • Keeping the Operating System and server applications patched.
  • Using firewalls to decrease the network attack surface of your server.
  • Auditing the server files and logs and using some IDS systems.
  • The list goes on…

After you’ve done due diligence when it comes to your server, then next you need to concern yourself with AMS and Apache as well. Here’s a couple tips to keep in mind:

Adobe Media Server

Apache Server

The version of Apache bundled with AMS is 2.2.x. Unfortunately, due to the modules needed for HTTP Streaming you can’t upgrade to a newer version of Apache such as 2.4. However, you can lock 2.2 down as far as you need. Here’s some tips on that:

AMS and Apache – Ongoing

A really good way to see how well your lockdown efforts are going is to run a vulnerability scanner against your server. This not only will give you an idea of what’s still exposed, but it’s also a good way to check your server from time to time as new vulnerabilities are found. Here’s a scanner that I like using:

Content Protection Over the Wire

Now that your server is secure, you need to figure out how to protect your content as it traverses the network between your AMS/Apache origin and the end-user’s video player. SSL is always an option, but did you know that AMS has some built-in DRM protection that doesn’t need to use SSL?

Content Protection While at Rest and Preventing Unauthorized Access

How do we prevent unauthorized access and protect the content that the end user has streamed to their local machine?

Prevent Unauthorized Access

There’s a number of things you can do to prevent unauthorized access. Without going too far into implementation details, this step requires:

  1. Some co-ordination with the application developers on your team to basically create a binding between the video player and the wrapping application. For instance, the video player would require some kind of token to be passed in before it will play back content. This token can be anything from a shared secret to some information acquired through a valid SSO sign-on.
  2. If you’re using PHDS, once the player is bound to your system, then you can leverage Protected SWF Verification for PHDS to make sure only your player can play back the PHDS content:
  3. If you’re using HLS, it’s much trickier and not quite as all encompassing, but someting you might keep in mind is locking down requests for content through token rewrites that have a short expiration ttl:

Content Protection While at Rest

This one’s easy…for now. If you use PHDS or PHLS as mentioned in the previous section, the data itself is protect with DRM. Basically, a simple AMS bundled version of Adobe Access DRM. :)

Closing thoughts

Don’t consider this article and the referenced links as an end-all be all to HTTP Streaming Security with AMS/Apache. It’s just a quick summary of some of the things to consider.

In my consulting experience, I’ve had a wide variety of consulting clients each with varying needs for security. Some implement everything, some a subset and most of the time there’s custom development, consulting, and testing involved. Also, security is a trade-off, the more secure you make something the less functionality there will be for you to leverage. So, implement your security while keeping your required functionality in mind. And test, Test, TEST your configurations against your production use cases.

Hope you enjoyed the read. If you’re ever in need of advice or help with implementing your HTTP Streaming Security, feel free to drop us a line:

Last month we had the pleasure of attending the NAB 2014 conference in Las Vegas, Nevada.

I even came out of Lost Wages a little ahead, so for now I can still call it Las Vegas. We’ll just have to wait until my next visit to see what I call it after I leave.

Since this was my first time in attendance, I wanted to see as much as I possibly could without saturating my brain with products and information. When you’re at a conference with 90,000+ attendees and hundreds of exhibitors, it’s easy to get overwhelmed. With that in mind, I made a little mental agenda to focus on relevance versus irrelevance.

What’s really cool about working for a small software development, consulting, training, and integration company like RealEyes, is that we get to deal firsthand with many real world use cases that are never the same. It keeps all of us on our toes and helps us be more knowledgeable in our niche.

Now back to NAB. To anyone who is reading this blog post and has been there before or is familiar with the conference overall knows that it’s the big leagues. Companies from all over the world that either already have an impact or are trying to have an impact are there. From hardware to software and everything in between, they’re there.

One thing I had never considered was how many moving parts go into broadcasting. It’s insane. Since my primary focus deals in streaming solutions, encoding and web collaboration, I never think about what it takes to produce the content, just how to get it out there and deliver it successfully. And since I don’t think we’re going to be delving into video and/or broadcast production any time soon (or are we?), we have to be resourceful with best practices for content delivery.

Varnish Plus is what we feel will offer the proverbial, “icing on the cake” for our end-to-end solution approach. What is it exactly? It’s an HTTP accelerator. Simply put, it’s like supercharging your car. While it’s already been established as the web accelerator of choice in Europe, we are excited to be the premiere Varnish Plus resale, implementation and training partner here in the United States.

Please contact us directly to find out how you can supercharge your content delivery.

On Tuesday, May 13th, David Hassoun spoke about Varnish Plus at the Varnish Software Summit in NYC. The topic was Varnish Plus – Building an Enterprise CDN for HTTP Dynamic Streaming. Feel free to check out the live stream recording: David’s talk starts 31 minutes in.

Adobe has recently released some new versions of Adobe Media Server. However, if you discussed them or noticed that they’ve been released you may be encountering confusion around the versions 5.0.4 and 5.0.5.

Adobe Media Server – Version 5.0.4

AMS 5.0.4 runs in the cloud on Amazon Web Services. Here’s a list of the AMIs and a link to the help documentation. (Note: The documentation still says 5.0.3 and the AWS product page still says 5.03)

Adobe Media Server – Version 5.0.5

AMS 5.0.5 is a maintenance update released on 3/31/14 to address product issues and is the on-premise version of AMS. You can download the updater from the AMS/FMS Updaters Index. Feel free to take a look at the issue fix list in the release notes to see if this update applies to your situation. (Note: There is no 5.0.5 branded documentation as far as we know, so for now you can reference the AMS 5.0.3 documentation.)

So there you have it, a breakdown on the current AMS 5.x versions and some helpful links to curb the confusion. Enjoy!

I was recently asked how the Varnish Plus cache interacts with the objects created to support HTTP Dynamic Streaming (HDS) via a backend origin Apache/Adobe Media Server.

This was a valid question, especially when you think of how HDS delivery works. In a nutshell, HDS delivery consists of a manifest(s) file and then a large number of HDS fragment files. Due to the number of files involved in streaming just one video it’s important to have a basic understanding of how an edge cache works.

Here’s some quick tips to keep in mind when using Varnish Plus with Apache/AMS:

1.  Varnish Plus uses an object time to live (ttl) to determine expiration and then a least recently used (lru) algorithm to decide what to boot when the cache is full and the remaining objects haven’t yet expired. Here’s some more details.

2. When monitoring your Varnish Plus server, you can keep an eye on how often things are being purged with the varnishstat command’s  n_lru_nuked field. Monitoring this counter will allow you to know when the size of your cache needs to be increased.

3. When sizing your Varnish Plus cache, you need to keep in mind that Varnish Plus has a tracking overhead of about 1k per object. This means that for any video you need to factor in the overhead. Take for instance, a 5 minute video being streamed via HDS. With a default Apache/AMS configuration streaming that 5 minute video will require an F4M manifest file and then 75 fragment files. (The AMS/Apache default fragment size is 4 seconds) So for that video there will be about 76k of overhead.

Using the tips above, you should be able to calculate the size of cache you need and keep an eye on it as well. However, if you find yourself in need of any Varnish Plus or Apache/AMS consulting, feel free to reach out to us!

We’ve been assisting a client with implementing a secure HTTP streaming Enterprise Content Delivery Network (eCDN). We utilize Adobe Media Servers (AMS) with the bundled Apache server to stream via HTTP using the Protected HTTP Dynamic Streaming protocol (PHDS) and Protected SWF Verification from behind a hardware load balancer at the origin. In addition, end clients are accessing the streams via Varnish caching servers via reverse proxy.

During our testing with the client we ran into an issue where the Varnish servers were returning PHDS fragments that resulted in unsuccessful video playback. (Black screen) We worked with the client to troubleshoot the issue and determined that it happened when the origin load balancer would hop traffic from one of the backend AMS/Apache servers to another AMS/Apache server. The weird thing was, when using the dev tools in Chrome we could see that the client was receiving the PHDS fragments successfully. (Chrome dev tools was showing HTTP 200 status codes for the fragments)

The 200 status codes made us suspect that something was going on with PHDS so we turned off PHDS and tested with unprotected HDS. With standard HDS the players were playing back content successfully even with origin server hopping.

Here’s where the quick tip comes into play. When using PHDS, there is a file that is used to derive the Content Encryption Key used by AMS to DRM protect the HDS fragments served via PHDS. This file is created by the AMS Installer and so it will differ from one install to the next. It’s called common-key.bin and is located in {AMS_INSTALL_ROOT}/creds

PHDS Info in AMS 5.0.3 Docs

Quick Tip: In the case of PHDS with multiple AMS/Apache servers clustered at the origin, you need to make sure that all of them have the same common-key.bin file. Otherwise fragments from each server will be protected with different Content Encryption Keys and video playback will fail on the first server hop.

In closing, as soon as we synced up the common-key.bin files on each of the AMS/Apache servers and cleared caches, the eCDN was back in business and the video players were happy as clams.

Part 2: 2014 RealEyes Speaks!

Posted on February 12, 2014 at 1:04 pm in Strategic Consulting

In January we listed out the first three places we’re scheduled to talk in 2014. Today we’re glad to announce that we’ve been invited to speak at the premiere conference for managing the configuration and deployment of your infrastructure and applications:

ChefConf 2014

On Thursday, April 17th at 2:35PM Pacific, our own Jun Heider will be giving a lightning talk about how to utilize Expect to script interactive installers such as Adobe Media Server.

Title - Automation: What to expect When Expecting Your Interactive Installers

Description - Chef is an excellent platform for automating the deployment and configuration of your infrastructure. However, there will be times when some annoying interactive installer will throw a monkey wrench into the works. Try in vain to make it play nice and there’s not one command line argument that can make it run in an unattended fashion.

Enter expect.

As defined by the manpage expect is a “programmed dialogue with interactive programs”. During this session you will learn how to leverage expect in your Chef recipes to automate the un-automatable through working example and walkthrough. By the end of the session you will have the knowledge and samples needed to get your feet wet with expect to automate your interactive installers.

Register now with an early bird discount – expiring 2/28 – to see what Jun and the rest of the Chef community has to offer at a $300 discount!

Wowza is at it again, folks. But this time they’re teaming up with Microsoft to bring content protection to the next level and reach even more users than they already do. But in this case, they’re using MPEG-DASH (Dynamic Adaptive Streaming over HTTP) for live broadcast streaming delivery with Common Encryption. This is a big plus in the streaming media world and a big win for Wowza and its customers.

Why is this so important? Because it’s shaping the next level of delivery standards for both live and on-demand content.

When I am discussing use case(s) with customers, content protection (also referred to as DRM) is brought up about 95% of the time.

Way back when the Internet was in its infant stages (remember Prodigy?!). And I will admit that I wasn’t very familiar with DRM (or any other three letter acronyms; aka TLA’s for that matter) until about eight years ago.  I knew about the emergence of file sharing networks such as Kazaa, LimeWire, and eDonkey2000, but that’s about as far as it went. Oh, and who could forget Metallica’s lawsuit against Napster?

So here we are now, and the immediate need for content protection seems to be at an all-time high. Why is that? YouTube doesn’t need to leverage any encryption on their content, right? Their motto is ‘Broadcast Yourself.’ Well, not so fast. Have you ever wondered what kind of rights you’re potentially surrendering if you upload a video that you recorded of your kid smacking a baseball into your nether regions to publicly available sites like YouTube? You did take the video – and the shot to the groin – so it’s safe to say that it’s your intellectual property. However, my father always taught me to think before I speak and to consider the consequences before I take action, and that’s how I approach life. So even with something like uploading a video to YouTube, I might want to take a gander at the digital rights management that applies on YouTube.

In the last few years, I guess have become a little obsessed with DRM schemes and technologies, the reason being because documentation was few and far between in terms of availability. But, since online delivery of content is at an all-time high and definitely not going away any time soon, knowing how the content I upload and put online is going to be protected is paramount.

When an entire digital business model revolves around on-demand content being at your fingertips, it isn’t that simple.  The gang at Netflix has managed to garner an exponentially higher customer base due to their reach with an online distribution business model. With that said, the majority of the content that they’re distributing is not proprietary, so they apply an industry-approved DRM technology to the content to ensure protection. And it works.

One thing I’ve learned in my researching DRM is that it truly isn’t just about applying protection. It’s about protecting your intellectual, proprietary property.

I had the pleasure of speaking to Danielle Grivalsky at a couple of weeks ago about DRM, and she directed me to their descriptions of the available DRM technologies, and I must say that they nailed it.

Don’t hesitate to contact us to find out more about how leveraging Wowza and MPEG-DASH can work for you!

Captivate vs. Presenter: Which one to choose

When should I use Presenter and when should I use Captivate?

That is a great question. But, the answer isn’t very clear. However there are some clear differences between the tools that we can use to isolate the best use case, and hopefully get building projects, instead of scratching your head.

Adobe Captivate versus Adobe Presenter: The Ultimate Showdown


Let’s start with Presenter, it is a simpler tool.

What is Adobe Presenter?

It is a plug-in to PowerPoint (2003-2010) that allows you to and add audio, video, flash and quiz functionality to a Power Point presentation. It will then output the presentation to a web-ready format to be delivered delivered with Adobe Connect or a web server. There are also additional output format – a PDF file, which displays the interactive portion in a single page PDF.

OK, great Captivate can do that too right? Yes and no.

Captivate can add audio, video, flash and quiz functionality to a Power Point, but some control and quality is lost.. Because Presenter is a plugin and work inside of PowerPoint, you can maintain control of the slides and changes, update and modifications are simple. Updates in captivate are a little more involved.

Presenter Point #1 : If your content is in PowerPoint, or can be easily created in PowerPoint, then use Presenter.

Think simple, don’t over-complicate the process. If the above statement applies to your eLearning project, then stick with Presenter, no if’s, and’s or but’s about it.

Presenter Point #2: Use simplicity to your advantage.

You can build text and image based presentations in Captivate, and I know groups that have walked away from PPT/Presenter to use Captivate exclusively so they only deal with one software application, but, honestly, it is easier in PPT and Presenter. Simplicity is Presenter’s main attraction to me.


Captivate is a wonderful and powerful tool for producing eLearning content. Captivate is a screen/workflow capture application that allows you to create interactive or non-interactive eLearning projects. This is where people can get themselves in trouble. Captivate can tempt users down a road of over-complication and update-nightmares. To simplify the concept - Captivate’s bread and butter functionality is the workflow capture.

Captivate Point #1: Do you need to show or simulate software? Yes? Use Captivate.

Sure, you could do it in PPT and Presenter. Think about all the screen shots and text you’d have to write and arrange. What could take you days in Presenter/PPT will take a few minutes in Captivate.

Captivate Point #2: Looking for more advanced animations, widgets, or branched scenarios? Use Captivate.

If you are looking for more robust animations, better video support, the ability to use widgets, or any of the many additional features that Captivate offers, don’t fight with Presenter, use Captivate.

Now, Presenter vs. Captivate isn’t the best way to think about these two tools. Using the tools together can enhance your eLearning content and make your life easier. Use both tools to save time, and create some top-notch content.

Are you interested in learning more? Do you need help creating content with these tools?

We provide expert training for both Presenter and Captivate or we can create your content for you. Contact Us for more info.