 Your new post is loading...
Your new post is loading...
With the rise of MPEG-DASH and the NAB-related announcements from both Microsoft and Adobe on the topic, we sat down with both companies to discuss the status of DASH support as well as their legacy ABR protocols, Smooth Streaming and HDS. In late 2012, Microsoft release the specification “DASH Content Protection using Microsoft PlayReady,” which explained how to use PlayReady with Common Encryption and MPEG-DASH. In June 2013, Windows Azure Media Servicesadded the support for MPEG-DASH as a new Dynamic Packaging output. At IBC 2013, Microsoft officially announced a new PlayReady version supporting HTML5, Encrypted Media Extensions, as well as new SDKs for iOS and Android. Their recent NAB 2014 announcements show how much work has been done under the hood to support DASH on the maximum number of platforms. We put a few questions to the Windows Azure Media Services team—namely senior digital media architect Kilroy Hughes, principal program manager lead John Deutscher, program manager for dynamic packaging Nick Drouin and program manager for client SDKs Cenk Dingiloglu. Here’s what they told us.
Via DASH Industry Forum
At NAB, taking place in Las Vegas April 8-11, Envivio will introduce
new products and showcase new developments in next-generation
software-based video processing that optimize the convergence of
traditional TV and multi-screen services : - An Ultra HD 4K technology demonstration
- HEVC HDTV video compression, enabling up to 50 percent bit-rate savings while preserving video quality
- HEVC video streamed to a tablet in MPEG-DASH format
- TV Anytime capabilities including applications such as Catch-up and Start-over TV, highlights creation, ad insertion and nPVR
- Introduction of a new product that further personalizes the multi-screen user experience
- High efficiency MPEG-2 and MPEG-4 AVC (H.264) statistical multiplexing
- Envivio True Motion Experience, a new technology for high-quality streaming in MPEG-4 AVC format to connected TVs
- Video packaged by Envivio Halo(TM) network media processor in the Adobe HTTP Dynamic Streaming (HDS) format, protected by Adobe Access
The Open Source Media Framework (OSMF) doesn’t respond well when you pass it a local F4M file path for playback. Playing back local HDS fragments is an edge case, but enough people have encountered this problem that I think it deserves a little attention.
DVEO, the broadcast division of Computer Modules, Inc. (CMI), is now shipping their new continuous streamer and VOD (video-on-demand) media server. The Infinity Streamer™ streams multiple HLS video files, plus audio files, from the on board .5 TB drive, with scheduled playlists. DVEO will demonstrate the new system at the International Broadcasting Convention (IBC) in Amsterdam, September 7-11, at Stand 2.A54. The Infinity Streamer is a streaming server for stored content. Input can be individual files or multiple files. File types supported are H.264 ts, flv, H.264 ps, .mov, VC-1 (.wmv), mkv, and others. The Infinity Streamer also supports loopable playback. The system has been tested to be compatible with the latest Adobe®, Wowza®, and Real Helix™ servers, and many CDNs.
Version 4.5.2 of Flash Media Server is now available. Besides numerous bug fixes, it includes a major improvement – robust HDS/HLS failover for origins. It’s not simply a “good-to-have”, but a “must-have” feature for HTTP streaming deployments. The key issues it addresses are liveness and dropout situations.
If you've been wondering what Adobe had in the works after laying Flash Player for mobile to rest, the wait is over. The outfit has unveiled the codenamed Project Primetime, the "industry's first fully integrated video technology platform" that will offer television-esque viewing sessions across your web-enabled devices. This tech plays nice with all "major" mobile platforms -- including iOS -- as well as desktop operating systems and smart TVs (Windows, Mac OS, Apple iOS, Google Android, Samsung SmartTVs and other platforms).
--PR highlights--
Adobe Access 4 software will support native iOS apps, extending its existing support for desktop operating systems, Android apps and connected TVs. Adobe Access support for HLS/iOS is expected to ship in spring 2012.
Adobe streaming technologies will support MPEG-DASH, a set of emerging standards for streaming multimedia content over the Web that will help reduce technology fragmentation. Support for MPEG-DASH, which is expected to become a profile of HDS, comes as Adobe continues to collaborate in this area with a large number of industry partners. At the same time, Adobe will continue to innovate and develop its HTTP streaming protocol, HTTP Dynamic Streaming (HDS), which is used by major broadcasters worldwide.
Read also InformiTV analysis : http://informitv.com/news/2012/02/27/adobepreparesprimetime/
Vous allez me dire, mais qu’est ce que ce titre signifie en réalité ? C’est assez simple, je vais décomposer : - HDS pour HTTP Dynamic Streaming est un protocole de diffusion des vidéos (créé par Adobe). Le principe est similaire au HTTP Live Streaming utilisé sur les iPhone et iPad (j’avais présenté ce protocole). - Late Binding Audio : comprenez par là la possibilité d’avoir plusieurs pistes audios associé à un flux vidéo - OSMF pour Open Source Media Framework, un framework Flex utilisé pour la gestion des vidéos.
With the number of devices supporting IP video continues to expand, content creators are seeking ways to reach consumers on as many screens and as many devices as possible. That’s the impetus behind cable’s TV Everywhere initiative, as well as Hollywood’s new UltraViolet video format. In order to cater to these customers, Akamai is rolling out new capabilities to its HD Network for video distribution that will make it even easier for content owners to securely distribute content to nearly any device.
Unless you work daily in the streaming business, it’s sometimes hard to get into the nuances of technologies, and what the impact is for your long term strategy. HLS and HDS are both HTTP based streaming protocols, and sound very similar, but are fundamentally very different.
HLS stands for HTTP Live Streaming and is Apple’s proprietary streaming format based on MPEG2-TS. It’s popular since it provides the only way to deliver advanced streaming to iOS devices. It often mistakenly gets defined as HTML5 streaming, but is not part of HTML5.
In our era of ubiquitous globalization and internationalization, most of Web projects are launched in multiple languages. This especially applies to online video projects. Videos with alternate audio tracks and subtitles often attract viewers by the very fact of their existence. Most of popular content is created outside Russia, so there is abundance of content with original audio tracks and subtitles. Such content allows you to enjoy video in the original quality and detail, and learn foreign languages. In this post, we will tell you how to implement this functionality in Flash video player using OSMF 1.6.
Part 1 of this series discussed HTTP Dynamic Streaming (HDS) at a fairly high level. The next few editions in the series will explore some of the more powerful features that make using this protocol advantageous. Multi-bitrate stream switching and file encryption are two important features that we’ll cover in the very near future, as they’re very big reasons to stream over any protocol. However, in this article I’d like to discuss a brand new feature of the Open Source Media Framework (OSMF) known as “late-binding audio”. Late-binding audio refers to the ability to stream videos with multiple associated audio tracks. This makes it possible to play an alternative audio track on the client-side using the same video file. There’s no need to encode, store, and deliver separate video + audio assets for each version you would like to provide. Say for example that you would like to provide video content with audio translated into multiple languages. Instead of creating separate video + audio files for each language, you instead encode the video only once, and include the alternate audio-only tracks along with the it. This represents a huge savings in time, storage, and bandwith that anyone making the switch to HTTP Dynamic Streaming can take advantage of.
|
Bridge Technologies has launched PocketProbe, an iPhone app that enables objective analysis of real network performance of streaming media, in a simple to use, easy to understand tool that technical staff can carry anywhere. PocketProbe contains the same OTT Engine found in the company’s VB1, VB2 and 10G VB3 series digital media monitoring probes, enabling confidence validation and analysis of http variable bit-rate streams from any location.
PocketProbe is available in two versions: the free application can validate five HLS streams in round-robin mode, provide analysis and manifest consistency alarms, play back media in the various profile bit-rates, and graphically display the actual chunk download patterns and bit-rates. The full version also offers the ability to validate HDS and SmoothStream manifest files and store twenty-five streams with all profiles.
I’ve always been curious about what is contained in the bootstrap data for HDS content. Recently, I had the chance to find out and do some fun development with Node.js. We’ve been kicking around the idea of building a tool set for Adobe Media Server using Node.js and possibly socket.io. Last weekend we got some of the ideas going and one of those was parsing the hds bootstrap data created when content is packages for HDS delivery. The bootstrap data can live in a couple of places: In the <metadata> node of an F4M fileIn an external .bootstrap file The .bootstap file contains binary data and the F4M file contains the same binary data that has been Base64 encoded. So, getting to the data is pretty trivial – either read in the .bootstrap file or un-encode the string in that is in the F4M. Getting to the data contained in the bootstrap binary data is the fun part.
It's all about DASH: Adoption is moving at a rapid pace, as industry insiders see a strong need to get DASH implemented in the field in the coming year. The Pantos spec, as it is known in the industry, is a series of working drafts for HLS submitted by two Apple employees as an information draft for the Internet Engineering Task Force. As of the time of this article, the Pantos spec is currently at informational version 10. Much has changed between the early versions and the most recent v10 draft, but one constant remains: HLS is based on the MPEG-2 Transport Streams (M2TS), has been in use for almost 2 decades, and is deployed widely for varied broadcast and physical media delivery solutions. In that time frame, however, little has changed for basic M2TS transport stream capabilities. For instance, M2TS still lacks an integrated solution for digital rights management (DRM). As such, all HLS versions cannot use "plain vanilla" M2TS, and even the modified M2TS used by Apple lacks timed-text or closed-captioning features found in more recent fragmented elementary stream streaming formats. Yet Apple has been making strides in addressing the shortcomings of both M2TS and the early versions of HLS: In recent drafts, the HLS informational draft allows for the use of elementary streams, which are segmented at the time of demand rather than beforehand. This use of elementary streams means that one Achilles' heel of HLS -- the need to store thousands, tens of thousands, or hundreds of thousands of small segments of long-form streaming content -- is now eliminated. Google, with its Android mobile operating system platform, has adopted HLS for Android OS 4. Some enterprising companies have even gone back and created HLS playback for earlier versions of Android OS-based devices.
In a real deployment scenario, playback should be as robust as possible in the face of server-side problems. As our architecture stands today, playback can suffer from two problems regardless of the amount of backend redundancy that is deployed. Those problems are liveness, where a packager advertises a stale view of live, and dropout, where a packager has gaps in its fragment list. HDS/HLS fail-over is the server side solution to solve the live-ness and dropout problems in HDS/HLS respectively. This article describes a basic failover setup with redundant packagers and Varnish as a reverse proxy. The article further provides users a step-by-step guide to writing a basic varnish configuration script to configure Varnish for the failover solution.
The actual OTT market uses Adaptive Bit Rate video format over HTTP (Smooth Streaming, HTTP Dynamic Streaming, HTTP Live Streaming and MPEG-DASH soon) to deliver the content. Although it excludes the DRMs system which is a big topic in itself, here is an overview of the different formats available for each platform and of the different solutions (self-hosted, CDN, Cloud) to handle it.
SPB TV Solution empowers 3D and regular 2D video formats encoding and streaming in multiple quality options, from mobile to HD, to provide the brightest user experience on a small phone as well as on a big modern TV. Due to anaglyph and side-by-side technology support, 3D video can be delivered to both 3D-enabled and usual screens. SPB TV pays great attention to the stability and quality of the video playback in any network capabilities, so its solutions support all major technologies of adaptive streaming: RTSP, Apple HTTP Live Streaming (HLS), Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming, as well as MPEG-DASH - a new unified adaptive bitrate standard developed by ISO.
The term adaptive streaming refers to technologies that encode multiple instances of a live or on-demand stream and switch adaptively among those streams to deliver the optimal experience to each viewer, taking into account both delivery bandwidth and playback horsepower. Producing for adaptive streaming involves two discrete analyses: how to choose the optimal number of streams and their configurations and how to customize the encoding parameters of the various streams to operate within each adaptive streaming technology. This article will explore both analyses.
The future of CDN-delivered video is cacheable, HTTP streaming, with MPEG DASH ultimately taking over, says Highwinds' Chris Bray.
Mobile devices are an increasingly popular method of viewing media content, and the availability of increasingly powerful devices pushes video playback to the top of the list of most desired features on mobile networks today and well into the future. This rapid growth underscores the need for encoding and transcoding guidelines to ensure that the content is optimized for the greatest compatibility and playback performance. Due to the wide variety of devices in the marketplace, we suggest two approaches to encoding for mobile delivery. One approach targets individual classes of mobile devices, optimizing encoding settings differently for each. The second approach services each of the diverse mobile phone devices through universally applicable encoding settings. Each of these approaches has its advantages and disadvantages.
This white paper focus specifically on Research in Motion (RIM) BlackBerry PlayBook, a QNX powered device. It is an addendum to the white paper, Video encoding cookbook and profile guidelines for the Adobe Flash Platform.
So I've been evaluating methods of HTTP Adaptive Streaming - namely Adobe HTTP Dynamic Streaming (HDS) and Apple HTTP Live Streaming (HLS).
The implementation of HDS seemed ugly and inefficient to me when I first learnt about it, and I thought it looked like it would not scale well. The main reason for this is that for every request, for every fragment of a movie, the origin must look up an index for that movie, and use information so-gained to open a media file (.f4v) and extract a byte range from it - seems like quite a bit of cpu, memory and io overhead right, especially compared to "just be a stupid web server and serve the file". I guess how often unique content is requested from an edge depends on things like how deep your edge caches are, entire size of your library etc, but it's reasonable to assume that often the exact requested fragment will not be cached on the Edge, which will have to ask the Origin.
So in order to actually test my suspicion (hey, perhaps it actually doesn't matter; perhaps the architecture actually scales OK) - today I've been benchmarking on a dev machine, to get an idea of the overhead and efficiency of the Apache module for HDS.
Back in early June, we reported on the pre-release of Adobe’s OSMF 1.6, and its support for late-binding audio. Adobe has been working hard to improve upon the upgrades they gave us with the OSMF 1.6, Sprint 5 release, and to add even more new features for mobile as well. Today Realeyes Media is pleased to announce that OSMF 1.6, and Strobe Media Playback 1.6 have been granted their final release status. OSMF 1.6 - In regards to late-binding audio, as promised, today’s release supports live playback as well as video on demand (VOD). - For mobile – offers Stage Video support for hardware-accelerated video presentation(requires Flash Player 10.2+). - DVR rolling window support, which allows you specify how far back from the live point viewers can rewind (requires the newly released FMS 4.5). Core Framework - Improvements to HTTP Dynamic Streaming as well as the ability to better manage bitrate profiles with multi-level manifests.
|
![Envivio to Showcase HEVC, Ultra HD and Other Advanced Technologies at NAB 2013 [PR] | Video Breakthroughs | Scoop.it](https://img.scoop.it/_t50FJglBNG29x5nzW-PcDl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
![SPB TV's "3D Video on 3 Screens" solution supports all ABR streaming protocols [PR] | Video Breakthroughs | Scoop.it](https://img.scoop.it/VsMI5yRgmCLYu155um0i1Dl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
