Notes from the Trenches: A DP Blog

2014 – The year of open standards?

Posted At: January 24, 2014 9:44 AM | Posted By: Jeff Tapper
Related Categories: Uncategorized

With each passing year, web technologies are moving to more open standards, and this is a good thing. For decades, many industries have relied on Open standards to facilitate interoperability, but have often been frustrated by their attempts to modernize and bring their business to the web because of the lack of open standards.

The broadcast industry is one example where this is clearly the case. Open standards have allowed for interoperability between cameras, switching boards, multiplexers, and even all the way down to the radios and televisions in consumer’s homes. Even as broadcasters migrated from analog to digital broadcasts, a suite of standards, DVB (Digital Video Broadcasting) was in place to accompany the change.

However, as broadcasters work to bring their content and their business online, they are faced with several competing standards, few of which are open. Internet media delivery today tends to happen in one of two ways, either through the use of Real Time Protocols (such as RTP, RTSP, RTMP, etc.) or through the use of HTTP Delivery. The HTTP delivery option is the most popular today, for a variety of reasons, including the robust internet infrastructure already existing to support HTTP traffic. However, there are several competing non-open standards which comprise the vast majority of HTTP Delivery today.

Among the popular closed standards are Apple’s HTTP Live Streaming (HLS), Adobe’s HTTP Dynamic Streaming (HDS) and Microsoft’s Smooth Streaming (MSS). Each of these standards is viable, and in extensive usage today, they all have strengths and weaknesses, but they all share a single common weakness – none are an open standard.

There is hope on the horizon. MPEG-DASH exists as an open alternative to these closed standards. Two of the three companies with proprietary closed standards have been actively involved in the formation and promotion of DASH. These efforts have been clearly successful, as DASH delivery of content is becoming more and more prevalent – for example, Netflix, Hulu and YouTube have all released versions of their content via DASH delivery. Through the efforts of Browser manufacturers, Media Source Extensions (another open standard), have become available in many browsers allowing delivery of DASH content without any additional plugins required.

Unfortunately, HLS remains the most common delivery format in the US, and Apple (the author/owner of HLS) has shown no interest in supporting MSE in their browser. A tipping point is clearly on the way, which will see a massive growth in DASH delivery. Eventually Apple will be forced to embrace the current open standard, or risk losing content which has made their platform so appealing. The irony of course is that Apple has done so much marketing touting themselves as leaders of the “open web” movement, and they are the long holdout stalling the success of this open standard.

My wish for the New Year is that companies continue to embrace open standards, and bring about an ecosystem where all industries can easily participate in the web economy.

Comments (1)

Streaming Content to Google Chromecast with MPEG-DASH

Posted At: August 27, 2013 2:45 PM | Posted By: Jeff Tapper
Related Categories: Chromecast, Connected TV, DASH.js, HTML5, JavaScript, MediaSource Extensions, Video

A few weeks ago Google released Chromecast, a device which plugs into the HDMI port of a TV, and can stream content directly to the TV, with controls from either a mobile device or a computer.

The Chromecast device is a powerful tool that utilizes the latest features HTML5 to provide an environment capable of rich media playback. The Chromecast is specifically designed for this task, as evidenced by the great YouTube and Netflix applications that are already available.

The idea is that the Chromecast is a small dedicated computer that is capable of playing media all by itself; it simply needs somebody else to tell it what to play.

There are two pieces to the Chromecast puzzle.

1) The sender application.

The sender application can be written in several languages. The available options are Android, iOS, or JavaScript (running from a Chrome browser with the ChromeCast extension installed). For Android and iOS you’ll include a framework into a native project. For JavaScript you’ll need to add a bit of code to the html node of the page which prompts the ChromeCast extension to inject the required JavaScript methods into the page.

2) The receiver application.

The receiver application is always written is HTML/JavaScript/CSS. A particular javascript file will be included which has the ChromeCast code. Our application, and Google’s samples, are written in AngularJS. The receiver application is hosted by its owner on a web address that is shared with Google. Google will give the developer an application ID which is mapped to this known web address.

Receiver bits.

You’ll need to include the javascript file at https://www.gstatic.com/cast/js/receiver/1.0/cast_receiver.js to get the ChromeCast API methods. Somewhere on your page you’ll want a video tag to display your content. You can add anything else you want to this page. We are using a fancy animated CSS3 loading spinner (among other UI pieces).

After the page has loaded you’ll want to start up ChromeCast by creating, setting up, and starting a Receiver object.

The ChromeCast opens up a socket between the Sender and Receiver applications. Channels can be created on the socket to send messages back and forth between the two applications. The default media player uses a RAMP channel to communicate media messages. I haven’t been able to piggyback onto the default RAMP channel yet. Our application creates a new channel and sends messages there.

Creating a custom channel is fairly straightforward. You create a ‘protocol’ which is really just a string value. Both the receiver and sender then open a channel using the protocol value then they can send messages with data over the channel.

After the receiver starts up and the channels are configured, the application will just wait for the sender to say what media to play. Once the sender has provided that information the receiver application needs to load the media into the video element.

Sender bits.

For an HTML sender, the html node has to have the data-cast-api-enabled attribute added and set to true. This prompts the Chrome ChromeCast extension to inject the JavaScript for the API into the page.

After the page has loaded the sender needs to create an instance of the ChromeCast API and ask what ChromeCast devices are on the network. When asking for available ChromeCast devices you need to provide the application id that your sender wants the device to load.

When looking for devices the Google servers are going to verify that the ChromeCast devices on the network are eligible to load the requested application. At the moment this means that your device must be whitelisted for that app id on the Google server.

After all known devices are collected, the Cast API sends out an event for the sender to catch. The list needs to be presented to the user so that they can select which device to cast to.

After the device has been chosen, the application is launched on the device by sending a LaunchRequest to the api’s launch() method. The LaunchRequest contains the app id and the desired device. This will tell the device to ask google what the URL is that corresponds to the app id, and then that URL is loaded by the device. The pipes between the sender and receiver are then opened.

At this point the sender simply needs to send messages to the receiver and listen for messages from the receiver.

DASH bits.

For those that don’t know, MPEG-DASH is a fragmented HTTP streaming protocol. This means that a single video file is divided into many discrete chunks of video/audio data. These media fragments are then loaded as needed by the player and fed directly into a video buffer.

The fragments can be fed to the buffers using the HTML5 MediaSource Extensions (MSE). The MSE implementation on the Chromecast is very close, if not identical, to the implementation on desktop Chrome. In fact, the MSE implementation on the Chromecast is likely more advanced as it also supports Smooth Streaming and various DRM protocols that desktop Chrome does not.

Luckily we already had a DASH player written in JavaScript (dash.js). It was ported with zero code changes to the Chromecast and it generally plays really well. It looks like there are some potential bottlenecks with the processing power of the device as evidenced by streams stuttering more often on the Chromecast than on the desktop. Also, it appears that desktop Chrome has more robust codec support.

You can debug the ChromeCast device by going to a Chrome browser and navigating to :9222. This will open a page with a link to the running application. Click on it and you’ll see Chrome debug tools. You can do pretty much everything you can normally with the Chrome debug tools, including seeing full console output and using breakpoints.

You can see this running on your own Chromecast as long as you have Chrome with the Chromecast extensions installed.

The relavent urls are:

Dash.JS receiverwww.digitalprimates.net/dash/chromecast/index.html

Dash.JS senderhttp://www.digitalprimates.net/dash/chromecast/sender/index.html

Some useful references are here:

Developer guide – https://developers.google.com/cast/

Google examples – https://github.com/googlecast

Thanks to Nathan who wrote most of this article.

Comments (1)

Streaming Video to HTML

Posted At: May 16, 2013 3:25 PM | Posted By: Jeff Tapper
Related Categories: DASH.js, HTML5, JavaScript, MPEG-DASH, Video

I had the opportunity to present about HTML Streaming solutions to the cf.objective conference today.  I was thrilled to have a very engaged audience, who asked lots of intelligent, thought provoking questions.  As promised, the slides are available here.

 

Comments (0)

Digital Primates helps TVOne with Content Management

Posted At: February 12, 2013 10:22 AM | Posted By: Jeff Tapper
Related Categories: Uncategorized

SearchContentManagement wrote a great article today about TVOne’s quest for a viable content Management solution, and how DigitalPrimates were able to help solve their problems.  You can read the article here.

Comments (0)

Lots of new prereleases from adobe

Posted At: October 25, 2010 3:40 PM | Posted By: Jeff Tapper
Related Categories: ActionScript, actionscript3, adobe, Adobe Flex, AIR, as3, flash, flex, flex4

Late last night adobe released several new betas on the labs.adobe.com site, including: • 64 bit Flash Player (Code Named “Square”) • Flex 4.5 SDK (Code Named “Hero”) • Flash Builder Next (Code Named “Burrito”) • Flash Catalyst Next (Coe Named “Panini”) Square is obviously very interesting, as more and more end users now have 64 bit machines, it is great that the flash player will now be able to leverage the full power of the underlying operating system. It seems that 64 bit players are now available for Windows, Mac and Linux. Hero is another great release, with Adobe continuing to move the flex sdk forward. In this release, many of the components which were not migrated to the spark architecture in the 4.0 release have now been completed, including the DataGrid, Form, and Image components. Even more interesting is the rework done to make to make Flex applications run well on mobile devices. Having done a few AIR for Android applications using AS3 without the flex framework, I look forward the increased productivity I can realize by leveraging flex on these devices as well. Burrito and Panini are both improved tools to allow developers and designers increased productivity with the new SDK. In addition to supporting the latest SDK, Burrito also includes a workflow to ease development of mobile applications, a series of coding improvements, such as the introduction of templates, metadata code hinting and more. All told, these new releases promise to push the flash platform forward, and increase the world of possibilities for those of us who develop for the platform.

Comments (1)

What’s under your skin

Posted At: September 21, 2010 1:52 PM | Posted By: Jeff Tapper
Related Categories: actionscript3, adobe, as3, flash, flashplayer, flex4, fp10, skins, Speaking Conferences

At 360|Flex DC yesterday, I presented my “Whats under your skin” presentation, all about architecting components with skins and layouts. I had a great audience, who was very engaged and asked lots of pertinent questions.

For anyone interested, here are the slides. The code for the ShoppingList component can be found below from the download link. The code for the Clocks are proprietary, and can not be shared. Sorry. Download

Comments (0)

Apple, Adobe, and all that nonsense

Posted At: April 9, 2010 2:04 PM | Posted By: Jeff Tapper
Related Categories: adobe, apple ipod ipad iphone mobile flash10.1

By now you have surely heard all the hullabaloo around Apple Adobe and iPhone/iPad development. Until recently, Apple’s position was understandable from a business perspective, in that, if they allowed Flash applications to run on the iPhone, iPhone customers could use free Flash applications over the web, and not have to buy them from the Apple store. While this position sucks for apples customers, they remain a loyal bunch, who continue to seek out new ways to tithe to their mothership. Adobe has been quietly pleading with Apple to reverse this position, but has been working on alternative ways of allowing developers to build applications which can be deployed to the Web, Desktop, or any Mobile device, including those by Apple. Chief among these efforts was the Creative Suite 5 Packager for iPhone which is scheduled for release in the next few days. Yesterday (4/8/2010) apple announced the iPhone OS4, and release a new set of Terms of Service, which amongst other things, explicitly forbids iPhone/iPad development with 3rd party tools (such as the CS5 packager mentioned above). This is clearly going to far. Its bad enough that developers who want to build apps for apple devices already need to pay $99 + 30% of all revenue to Apple. Now, they also need to use apples tools to build these applications. The reaction to this has been varied. The followers of the “Cult of Apple” see this, and everything else Steve Jobs does, as as good move, which will save humanity from itself. Adobe supporters have reacted with outrage, including (but not limited to) Jesse (TheFlashBum) Freeman calling on Adobe to stop developing software for MacOS. Oddly, many of the MacOS fans I know first switched to Apple from Windows because they despised Microsoft’s anti-competitive practices. Funny, of all the anti-competitive steps MS has ever taken have been much less harmful than those taken by Apple recently. Of course, Apple claims they won’t support flash because its not “open.” This is hilariously hypocritical, as Apple’s devices are the least open things out there. To write an iPhone application, you need to use approved development tools, get apples approval on the software you write, and sell it through apples store. Which of these things seems open to you? Did I mention that the Adobe opened the source code for the Flash Player, when they donated it to the Tamarin project (http://www.mozilla.org/projects/tamarin/). Strange how the closed can criticize the open for lack of openness, and be believed by so many. As I’m not a MacOS person, I have no Mac to burn in effigy, but instead of buying a new iPod, as I had planned, instead I picked up a ZuneHD. In short, if Apple wants to screw over their customers, I simply see that as between them and their customers, and can only react by not being a customer. However, I wonder where all the new iPhone apps will come from, after Apple is done alienating all the developers of the world.

Comments (4)

Ouch, it hurts when i do that

Posted At: March 10, 2010 2:03 PM | Posted By: Jeff Tapper
Related Categories: actionscript3, as3, flash, flash9, flashplayer, flex, flex3, flex4, fp10, Speaking Conferences

As promised, here are the slides for “Ouch! It hurts when i do that.” presentation first delivered at 360Flex San Jose, March 10th, 2010.

Comments (3)

Flex 4 for Flex 3 developers

Posted At: February 26, 2010 2:02 PM | Posted By: Jeff Tapper
Related Categories: flash, flashplayer, flex, flex3, flex4

Today, I presented my Flex 4 for Flex 3 developers presentation at FlashCamp Chicago. For those that wanted the slide deck, you can find it here. In this, I discuss a number of differences between flex 3 and flex 4, and what an existing Flex 3 developer will need to know to start being productive in Flex 4.

Comments (1)

Flex 360 tickets selling fast

Posted At: December 17, 2009 12:12 PM | Posted By: Jeff Tapper
Related Categories: actionscript3, flash, flashplayer, flex, flex3, flex4, FlexUnit4, fp10, fp9, Speaking Conferences

Down to the last 5 (Cheap) tickets left for 360|Flex. Register now, save $100 and get the same awesome content for a little less coin. Act fast, these last tickets won’t last. When they’re gone, the regular price of $599 kicks in. Come on out and hear me give advice how not to hurt yourself with code, in my “Ouch, it hurts when i do that” talk.

Comments (0)