CES 2017 Impressions

Admin
Every year CES is the culmination of the latest and greatest in technology and invention. From TVs to cars, cellphones to virtual reality, industrial grade hardware to watches and players, everything is competing for consumer attention and it’s barely possible for a person to see everything displayed. CES 2016 was all about TVs, virtual reality and drones. 2017, while still following last year’s trend, moved towards the Smart Home, Smart Appliances, and Artificial Intelligence (AI). The entire IoT industry was there: starting from end-to-end solutions to wireless connectivity chips and platforms. This includes the well-positioned ZigBee Alliance booth, which included the products showcase powered by DSR with an impressive 105 products from 30+ companies for both Residential and Commercial markets.
CES2_1
This was the largest wireless ecosystem display in the entire show and is a true testament to ZigBee interoperability and presence on the market. The devices in the display were connected to DSR’s zHome IoT cloud and mobile apps, working through DSR’s low cost gateway. 
 
CES1_1
The discussion and questions at the ZigBee Alliance products demo were mainly around the gateway and ecosystem. The impressive wall also raised some questions if the products all truly  function together and they do. The impression from previous shows is that consumers as well as installers have experience with a mixed bag of installation and controls. Providing a single display demonstrated a cohesive and diverse ecosystem of interoperable products.
 
CES3_1
 
 
Some other interesting observations from the IoT/Smart Home space showed that Data and Security applications are as relevant as ever. Voice control, driven by the major push in AI is gaining major traction, with Alexa embedded in Echo leading over Google Home. The start-up area is always full of new and reinvented ideas, including speaker products, data analytics, energy consumption profiling, health sensors and apps, analytical mirrors, security and nursing products. Finally, a visible expansion in child caring and monitoring beyond the standard baby monitors and cameras are looking to address the growing needs and demands of the market and modern day parenthood. 
 
To conclude, CES 2017 was as big as ever and full of new, amazing, and improved. DSR was excited to be part of the experience and to also represent the products demo wall at the ZigBee Alliance booth, making it the largest display of products from different companies working together via a single protocol in one space. 
 
For more information about DSR products and services in IoT, please visit www.ioticity.solutions and www.dsr-zboss.com.

DSR`s ZBOSS ZigBee 3.0 stack is now part of ARM IOT offering

Admin

DSR is happy to announce that ARM has chosen DSR ZigBee 3.0 stack to support their new product, ARM® Cordio® radio IP. ARM® Cordio® radio IP belongs to the ARM family of 802.15.4 and Bluetooth 5 standards-based low-power wireless IP solutions. It provides a complete RF-to-Application solution for WPAN (Wireless Personal Area Networks) radios.

ARM reckons Cordio radio IP is the only fully integrated platform in the market and includes a transceiver, baseband, and link layer (LL) subsystem including firmware. Moreover, ARM claims devices using Cordio radios will last up to 60 percent longer between battery charges due to falling under the typical wireless circuits that run at 1.2 volts.

ZBOSS 3.0 – ZigBee 3.0 stack from DSR is now offered as the stack of choice for those willing to utilize ZigBee on top of the Cordio radio. Built with great attention to a fixed memory footprint, ZBOSS also provides optimized power consumption, making the end device last even longer.

More information about the ARM Cordio can be found here: https://www.arm.com/about/newsroom/arm-accelerates-secure-iot-from-chip-to-cloud.php.

For additional information about ZBOSS 3.0 ZigBee Stack, please visit: http://www.dsr-zboss.com/#!/.

DSR is an end-to-end IoT partner and is always ready to support your IoT solution. Feel free to contact us with any inquiries at contact@dsr-company.com.

Open Source Yeoman generator for AngularJS Is Released by DSR

Admin

DSR understands that open source community is what pushes the modern IT world forward. DSR is well known for ZBOSS, ZigBee® open source stack certified by the ZigBee® Alliance. Moreover, DSR continuously contributes bug fixes for issues found during development with various modern development platforms and technologies.

DSR understands the value of sharing tools, standards and best practices that we use internally. So recently DSR team released a Yeoman generator for AngularJS. It has some useful optional features, like JWT support, basic components, tools for responsive UI and some others, and, of course, good documentation. The source code is available here:

https://github.com/DSRCorporation/angular-generator/

This is only the beginning. Soon we’re going to release a Yeoman generator for Node.js, several advanced AngularJS UI components and many other fancy things. Stay in touch and sign up for our newsletter to get the latest updates from DSR or check out our blog.

To Mesh and Beyond

Admin

Not too long ago Bluetooth® SIG announced that Bluetooth® is going mesh, giving a rise to a new wave of interest to Mesh networking. Although the interest is growing rapidly, solutions available on the market keep using just the trusted star topology. But what are the real possibilities?

Mesh, Ad hoc and MANET

Most networks on the market are declared to be “mesh ad hoc,” so in most cases these terms are used together in turn blurring the difference between them. But there is a difference and it’s important to highlight it.

Mesh network is a kind of a network topology where all the possible connections between nodes are established. This leads to the main mesh network feature – self-healing, where broken routes can be restored using different access links between devices.

Ad hoc network is a decentralized wireless network that does not require any infrastructure to form and maintain. Nodes connection depends on its possibility. This network is self-configuring, which means that devices can join or form it on the fly.

In this way, mesh network is the most robust static type of ad hoc networks. But when both terms are used together, they typically mean ad hoc only. Mesh explains just the physical layer of wireless communication that is broadcasting from its nature where all devices that are close enough hear each other (i.e., connected) and form enough links for self-healing. To be completely accurate, it should be mentioned, that “ad hoc” means that the nodes are stationary. There is a term for mobile nodes – Mobile ad hoc networks (MANET’s). But today in PAN/LAN context (Wi-Fi, Bluetooth, ZigBee) nodes are assumed to be static due to their use cases, even if they can be moved sometimes from place to place.

Wi-Fi

Wi-Fi is an area that already has ad hoc solutions available through documents and open source. Official specification IEEE 802.11S is the less effective and innovative one. It introduces two new kinds of devices: Mesh portals and Mesh points. Mesh portals are ordinary Access points with wired connection to the Internet. Mesh points act as wireless routers between stations and portals. Everything that has “mesh” prefix is connected together where it is possible. The standard is completely the same as B.A.T.M.A.N. adv Wi-Fi mesh that is already included in the Linux core.

In parallel, open source community works on cjdns (Hyperboria) that is a real candidate for the DarkNet set of protocols. Cjdns is developed in the way to create a wireless mesh network that is totally disconnected from the Internet. Its core advantages are:

  • End-to-end encryption
  • Tunnels between segments over the Internet
  • Decentralized generation of IP addresses

The last one is a headache for all Wi-Fi ad hoc networks. Old DHCP conflicts with the essence of the ad hoc network and mobility.

Mesh networking using Wi-Fi sounds ready but not for small low-power devices. Thus, we better pay attention to Bluetooth® Low Energy (BLE) and ZigBee®.

Bluetooth®

The first thing that Mesh-network-sceptics say about Bluetooth® is that it was not designed for Mesh networking. However it is widely spread, so why not to try using it?

Existing solutions on BLE are nothing more than trying to sell things that we already have in ZigBee® under the “Mesh network” label. To build a “mesh” the customer should buy a BLE gateway that forwards packets to the cloud. All main-powered BLE devices act as routers and interconnected with each other, while battery powered devices talk to routers only. Nothing special.

But BLE wins in that it is already in devices that have the Internet connection through 3G, LTE, Wi-Fi, and even the cable. That means that in theory the customer can get more than one gateway connected by the Internet. Moreover, customer’s tablets and smartphones bring the mobility to such network.

The power of the Wi-Fi + BLE collaboration has already been explored by Apple: check out the Multipeer connectivity framework for iOS 7 and, for example, FireChat application that proudly announces “Internet is not needed to chat.”

ZigBee®

When talking about ZigBee® one thing should be kept in mind – it was initially designed to be ad hoc. The routing mechanism implemented in ZigBee® is called Ad hoc On-Demand Distance Vector (AODV). Although RFC is operating IP frames, there are no major differences. The algorithm is quite simple for CPU and gentle to ROM and is available even for a bulb or smart socket or any other main-powered device.

As it was mentioned earlier, ZigBee®-based systems on the market currently prefer to use star topology, even though it has everything to be a mesh network and should be used as such. When Wi-Fi or BLE implement mesh, it is not only a technological step forward, but a marketing reason. The truth is ZigBee® is already a step ahead in terms of technology, but maybe a step behind in terms of marketing.

One might mot like that ZigBee® network is not using IPv6. Well, neither does BLE, but it does not disturb it. Nevertheless, there is IEEE 802.15.4 + IPv6 + UDP solution called 6Lowpan and Thread or JupiterMesh built over it. Though they haven’t still made a splash on the market, probably nobody has positioned them as “mesh.”

As we can see, if the market wants mesh/ad hoc/MANET, there are all the pre-requisites for it. It is already around but the customer is not aware of it because either the market is too “shy” or that field has not yet been covered in depth. Anyway, the results will come soon and they will come from Wi-Fi, BLE, ZigBee or even a collaboration between them.

Why Scala Is an Awesome Programming Language

Admin

No one will argue that IT is one of the fastest developing areas of engineering. New tools, approaches and ideas complete or even supersede the existing ones. One of the quickest growing technology stacks is the Scala language stack.  In this blog we explore what makes this language awesome.

Language Design

Scala was designed to help write thread safe and laconic code. It overcomes some JVM limitations and provides features that could not be achieved in Java. Scala has a clean, expressive, and extensible syntax with lots of built-in shorthands for most common cases.

Since less code needs to be written to accomplish the same task, the programmer can now focus on the problem’s solution instead of spending the time for boilerplate code. It is especially nice if you pay your programmers for SLOC. Furthermore, Scala reduces the number of places mistakes can be made and hence improves implementation quality.

Here is a short list of Scala language and compiler features:

  • Type inference – in most cases compiler can automatically detect types of values:

val i = 1 // Int

val s = “Hello, world!” // String

  •  Named and default function arguments:

class Point(x: Int = 0, y: Int = 0)

new Point(y = 1) // Point(0, 1)

  •  Tail recursion optimization – recursive function self-calls transforms to loops – no more StackOverflowError.
  •  Support of both imperative object-oriented and functional programming – in Scala object composition, methods, state encapsulation and inheritance, traits and mixins combined with lazy evaluations, algebraic data types, pattern matching, type classes and, of course, first class functions.
  •  Lots of immutable and mutable, finite and infinite collections with many implemented transformations like map, reduce and filter:

users.filter(_.lastVisitDate before today).map(_.email).foreach(sendNotification)

// Sending notifications to all users that visited our  site   too long ago

  •  Concurrency through mechanisms of actors and futures:

val sum = sumActor ? List(1, 2, 3) // sum == Future(6)

val x = sum.map(_ * 2) // x == Future(12)

  •  Generics – JVM does use type erasure and knows nothing about real types of generics in runtime, but Scala keeps that information.
  •  Compile-time meta programming – in addition to runtime reflection, Scala compiler supports macroses – functions evaluated during compilation.

Distributed Computations and Big Data

One of the fields where Scala found its widest application is distributed computing. Scala has great mechanisms for working with data sequences even in a cluster, which is why it is frequently used by Big Data engineers and data scientists. Here is a list of the most well-known technologies that use Scala:

  • Akka –  a framework for creating distributed systems. It is based on actors model and makes it easier to implement concurrent applications without race conditions and explicit synchronization.
  •  Spark – a very popular batch data processing framework. Spark has integration with different data sources such as Cassandra, HBase, HDFS, and Parquet files. In addition, it has a Streaming extension that provides tools for building stream processing pipelines. One of the most powerful features of Spark is the ability to run quick ad-hoc tasks to check hypothesis. Such functionality is reached by Spark’s design that in some cases gives more than 100 times performance impact in comparison with Hadoop jobs.
  •  Kafka – a high performance message queue, one of the key middleware components in data streaming systems. It is distributed by design and usually acts like a data buffer in streaming systems on the different stages of the processing and as a media between different system parts.
  •  Samza – one more framework for stream processing. It is similar to Spark Streaming but works in a different way. It does not create micro batches as Spark does. Instead, it processes data pieces as soon as they arrive, which makes Samza more preferable in some cases.

In addition to these tools, it is also possible to use Scala for implementing good old Hadoop map-reduce jobs, directly or utilizing Scalding. Anyway Scala is a great choice for data processing and distributed computing.

Compatibility with Java

One more important thing is compatibility with libraries written in Java. Java code can be used in Scala directly and without limitations. This allows to keep existing modules without the need to re-implement them. It could be quite helpful when it is needed to use a rare library, legacy code, or API that have implementations only for Java.

Why Scala?

To sum it up, Scala is well designed and very extensible. It has special processes (SIP and SLIP) that let any Scala developer propose enhancements. In conjunction with the large community, Scala ecosystem has been growing rapidly. Scala has its own stack of tools and is compatible with existing Java code. It brings new effective approaches that give the  programmer an ability to do their job more efficiently. All these features make Scala one of the most attractive modern programming languages.

Contact us at contact@dsr-company.com to learn more or if you have a Scala project to discuss.

The Next Wave of Media and Entertainment Consumer Experience

Admin

The coming transformations in the media distribution space provide ample opportunity for both vendors and operators to work together to improve efficiencies and increase user satisfaction on the consumption experience.

DSR believes that after the failure in uptake on in-home 3D, the media & entertainment market is primed for the success of the next wave of consumer experience improvements, which we believe will be driven by high dynamic range (HDR) video, continued over-the-top streaming distribution (including 4K video resolutions) and virtual reality. Beyond the consumer experience, the backend of media operations can be substantially enhanced and prepared for these changes by embracing IMF, IP ingest & playout and virtualization of media processes.

As a software engineering provider for media & entertainment vendors for more than a decade, DSR is uniquely positioned to provide our expertise in building applications and backend services to assist companies ready to embrace these transitions.

IMF, HDR, & 4K Video

Consuming video wherever, whenever has become mainstream, and enabling those consumption habits has increased the workload on media transformation by several times in the last 5 years. IMF (a SMPTE standard for Interoperable Media Format) finally holds a promise to simplifying versioning for this wide array of consumer consumption channels.

IMF can simply your media workflows by using a single package to hold an original version video, along with all possible substitutions and exclusions referenced by composition play lists (CPL). Since additional CPL are just XML documents and substitutions and exclusions are much smaller than creating new additional versions for each distribution point, IMF not only promises simplicity in distribution, but also a possible reduction in media storage.

BroadcastingIMF_VR_VM_BlogDiagram_pptx

Within IMF, it is also possible to handle 4K video and coming soon, high dynamic range (HDR) content, along with downmix instructions, so that a single file package can hold the true master content, as well as the recipes for creating premium and lower cost versions.

DSR has already built tools for customers based upon IMF parsing, packaging and file playout, and we can bring that expertise to your project as well.

Virtual Reality

Consumer appetites for new and exciting video experiences appear to be increasing, and virtual reality experiences are poised to fulfill those desires. Several challenges exist in preparing content, however, including:

  • Camera rig creation and assembly
  • Video splicing/stitching for seamless visual experience during user pans
  • Spatial distortion correction

DSR’s wide array of experience in handling video for ingest and playout puts us in a position to help advise and create applications within the virtual reality space, particularly when dealing with video and audio layouts.

Backend Media Process Virtualization

In the last several years, DSR has helped many of our clients migrate and manage their applications from on-premise deployments to virtualized deployments, both on the cloud and in local datacenters. Our knowledge of multiple hypervisor technologies allows us to be agnostic in helping our clients migrate applications.

DSR has a wide range of expertise in refactoring applications, removing tight couplings between user interactions and data processing to enable the addition of web services. Our database expertise and API knowledge also helps speed the transition of applications from those dependent on single machine processing to those that can scale between multiple virtual machines.

Whether your organization is facing the challenges of:

  • application refactoring for virtual deployments,
  • handling multiple versions of media with IMF or HDR, or
  • needs to bring a virtual reality application online quickly,

DSR stands ready to help. We have over 10 years of experience in media & entertainment applications, working with enterprise application vendors and start-ups, with a stable team of engineers that understands video, audio, captions and containers (and English). Let us bring our engineering team to help in your next project.

Contact us at contact@dsr-company.com

Keep Calm and Implement ZigBee Security

Admin

At the end of last year, a group of researchers from Cognosec presented their “ZigBee exploited” report at the BlackHat conference in the USA. They demonstrated a tool that allows an intruder to open your doors, shut up motion sensors off and even turn the lights off in your bedroom, of course only if these devices are controlled via ZigBee. IT and for the most part non-IT sources repeated the news many times with excessive drama effect and as a result, we had got a categorical accusation of lack of security in ZigBee and even the entire IoT. Based on the forecast that there will be 29 billion of IoT devices in the not so far 2020, “experts” convinced their readers that it is not the problem of the future but the present and that all devices are vulnerable. Now when the panic has calmed down, let’s see what happened in terms of ZigBee.

First, let’s talk about silent motion detectors. Motion detection in the system that was hacked works the following way: when a sensor detects a movement it sends a ZigBee message to a gateway (you may call it smart hub, ZigBee hub, etc.), which uses TCP/IP to deliver this message to the user. Cognosec researchers used a jammer to break the ZigBee link between the sensor and the gateway. Even when the jammer had been turned off, the motion alarm was not retransmitted because the retransmit attempts were over or the sensor decided that the link was lost (we can only guess). Samsung, whose hub was attacked during the research, has already given the proper comment and we agree with it 100%: ZigBee Motion sensors are not designed to be a professional, highly secure alarm system. We wonder if anybody has already seen a professional alarm based on a wireless protocol. Although the jammer attack is not specially a weakness of ZigBee, it may be useful for those customers, who want to get an alarm but do not want to pay a high cost.

Moving on, now we are going to discuss the weakness that was introduced as a supermassive hole in the ZigBee security, but it is actually not ZigBee specification’s fault. The reality is that a large number of ZigBee devices available on the market use the default Trust center link key to encrypt active network key transport. This key is open and there is not much difference for security in sending the network key as plain text or encrypted by the default key. ZigBee specification warns developers about such threat and recommends out of band or not-by-the-air methods to deliver an initial master key to both the trust center and the device. Researchers criticize this recommendation because it is not a requirement when the required by the specification default trust center link key in its turn breaks the security. But why shouldn’t the not in-band key delivery be a part of wireless protocol specification? Moreover, as anybody, even researchers, agree, unsecured key transport is ideally performed only once, during an association and most likely is not a threat, of course unless a maniac with an enabled ZigBee sniffer is spying on your house 24/7. And here the thing that everyone is talking about comes to the surface. Assuming that a quick, low-power, unsecured key transmission is performed once, hackers enable their jammer again to force link loss. When the link is lost, there are two ways to get the key:

  • A “typical” user triggers association one more time when an intruder’s sniffer is enabled;
  • Device tries an unsecured rejoin (that is allowed by the specification).

Respectively, there are two ways to dispute:

  • Strictly saying a “typical” user will most likely reset the device, reset doesn’t mean a factory reset, just power off/on. The reset will trigger a rejoin process and now we move on to the second point;
  • Although ZigBee allows unsecured rejoin, secured one is not forbidden; it’s just a policy, an option that can be configured by the manufacturers. The problem wouldn’t exist if the devices under the test implemented secured rejoin. There also wouldn’t be any problem, if there weren’t high security requests to the devices that implement unsecured rejoin.

The main conclusion from our dispute is that the found exploit is not a “ZigBee” one, it’s “Current ZigBee implementation exploit.” It will not be superfluous to say that researchers from Cognosec are ZigBee users too and they pointed out that ZigBee specification provides all the good recommendations to build a secure system. But dramatic headlines and maybe mass hysteria turned the device problem into the core standard one. There won’t be any panic, if anybody interested in IoT (or ZigBee), based their opinion on the original source:

https://www.youtube.com/watch?v=9xzXp-zPkjU

https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf

Developing SPA with Angular Material

Admin

Fast, convenient, tricky. These are the first three words that come to mind if someone asks how it feels to develop with Angular Material. The project’s documentation states the following right on the first page: “For developers using AngularJS, Angular Material is both a UI Component framework and a reference implementation of Google’s Material Design Specification. This project provides a set of reusable, well-tested, and accessible UI components based on Material Design.” Let’s take a close look at whether it is 100% true based on our extensive experience of developing SPAs with Angular Material here at DSR Corporation.

 Fast

Well, let’s drop all these subjective metrics and talk features:

  • Angular Material is a flex-based framework which provides an impressive set of tools to manipulate the layout. What does it give us? We can drop a huge amount of CSS purposed to position our DOM elements the way we want. Position inside a block is set with well-documented directives right in our HTML, which makes it quite easy to read.
  • Built-in nice animated dialogs.
  • Built-in services and directives to work with font-icons and SVG pictures with ability to switch between different icon sets and modify the icon style quick and painless.
  • Built-in toasts.
  • Mobile-friendly date picker.
  • Basic support of swipe actions.
  • Resource-friendly list that reuses DOM elements to render long scrollable lists in order to improve performance.
  • Built-in tooltips.

 Convenient

As its name suggests, Angular Material implements Google’s Material Design Specification. So if you want to follow Google’s guidelines you’ll find that many things work right out of the box as expected. Just keep in mind that this is one of many ways to implement it. Get ready to be flexible in your design and to alter it in favor of keeping your code clean. With great power comes great responsibility. With many built-in features, directives, services, animations, and CSS’ rules comes a hard-to-modify predefined behavior. We are not saying it’s impossible to change the way things work in Angular Material, but it would take another dirty hack to do it.

After all, convenience is a very subjective thing so here are some key features that should make your life easier:

  • Adjustable autofocus for dialogs and navigation bars
  • Beautifully animated buttons
  • Custom designed checkboxes
  • Custom designed selects
  • Built-in chips
  • Built-in complex menus and navigation bars
  • Animated input containers with support of ngMessages for error displaying and built-in text’s length counter
  • Custom designed radio buttons
  • Built-in sliders
  • Built-in switches
  • Animated tabs with custom actions on select and deselect

Tricky

Here comes a fly in the ointment. Since Angular Material is pretty young, it has all expected “puberty” problems. At the moment of writing this article it has 1545 open issues and 90 pending pull requests. That’s for a good reason: as long as it works fairly good under Chrome, it starts showing teeth under Firefox and constantly fails here and there under Safari, especially mobile Safari. If your target platform is Mac OS, you still can keep your code more or less readable, but cascade of hacks can bring your app to its knees in case you must make it work under OS X. Not to say that it’s not going to work in the end, but you will have to sacrifice some built-in features or spend hours making custom overrides, which kind of undermines the whole idea behind using Angular Material.

To sum up all of the above we can say that Angular Material is a promising powerful tool that can help you a lot and drastically improve your performance. Just keep in mind its current limitations and issues in order to not build an unmaintainable monster.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

Modern Media and IP Video Systems: How to Choose the Best Formats and Technologies

Admin

Today there exist two standard ways of providing video content – “video on demand” and “live streaming.” “Video on demand” assumes that a client requests static media content from a server. “Live streaming,” means that media content is generated real-time and translated through a server to several clients.
In addition, media consumers use multiple types of devices for both ways of video playback:

  • Desktop browsers
  • Mobile devices
  • Smart TVs
  • Set-Top-Boxes
  • Game consoles

To cover most media traffic accessed via different methods and by different types of devices, it is important to cover the formats and technologies that make it possible.

MPEG-DASH Revolution

MPEG-DASH is Dynamic Adaptive Streaming over HTTP (DASH) technology that evolved since 2010 and was adopted by main hardware vendors and content providers. In 2016 this technology overpowered the Adobe Flash Player widely used in desktop browsers for media content playback, since all mainstream desktop browsers support MPEG-DASH.
The challenge remains for mobile devices and Apple TV that still do not support this technology well and primary use HTTP Live Streaming. Several custom MPEG-DASH implementations already exist for the main mobile platforms on the market, but it is not yet included in the native SDKs.

MP4 and WebM Formats

MPEG-DASH is format and codec agnostic, but currently the following formats and codecs are mostly used:

  • MP4 container with h.264 video and AAC audio codecs
  • WebM format with VP8/9 video codecs and Vorbis/Opus audio codecs

h.264 codec is well supported by software and hardware chips and it can be definitely the best choice today, but it imposes royalty fees if the provider charges customers for content.
VP8/9 is royalty free, but doesn’t have as wide of adoption as h.264, so it should be carefully checked if a particular target platform supports this codecs.

Choices for Desktop Media Systems

HTML5 UI that can be run from any mainstream browser is the most modern way to playback media content for desktop end-users. HTML5 standard provides special <video> and <audio> elements for native media playback support, but it works natively only for the “video on demand” approach. MP4 is supported in all mainstream browsers, while WebM is not supported in Internet Explorer, Microsoft Edge, and Safari.

So far HTML5 doesn’t have a standardized approach for “Live Streaming.” Before the end of 2015 Adobe Flash technology and RTMP (Real Time Messaging Protocol) were widely used to provide live streaming. Now, it is significantly changed. MPEG-DASH now supports all major desktop browsers via HTML5 Media Source Extensions and “DASH.JS” JavaScript library. YouTube and Netflix have been adapting this technology for the last several years and it seems MPEG-DASH has become a De facto standard for desktop browsers live streaming.

The important thing is that native HTML5 “video on demand” approach doesn’t support adaptive streaming. It means it cannot adopt media bitrate in accordance with client Internet bandwidth. This leads to MPEG-DASH technology being used for both “Video-on-demand” and “Live streaming” approaches.

Choice for Mobile Devices

HTTP Live Streaming (HLS) still remains the best choice for both “Video On Demand” and “Live Streaming” approaches for native applications on mobile platforms. Both Android and iOS platforms support this technology with their native SDKs and the stock browsers. HLS works with h.264/AAC codecs on iOS. Android is limited by h.264 baseline level 3.0 profile, but it allows other codecs including VP8/9.

Choice for Home Device Systems

SmartTV, Set-Top-Box and Game consoles usually support a wide range of formats, technologies and codecs. Despite the fact that several technologies cover most media traffic (over 75%), there is no best choice for such devices since it usually is a universal media player for many formats and content providers. Any modern home media device should support the technologies that are covered above without limiting the wide range of device capabilities.

Server Side Choice and Requirements

Both MPEG-DASH and HLS can use HTTP/HTTPS as transport protocol. That really simplifies the server side environment. Many HTTP servers support these formats or can be used as proxies to MPEG-DASH/HLS services.

Wowza streaming engine or an exclusive one built on open source software like FFMPEG and MP4Box can be used for transcoding and repackaging.

Both MPEG-DASH and HLS technologies assume streams bitrate adoption to fit client Internet bandwidth. This means that the access point must be able to simultaneously provide streams with different bitrates.

“Live Streaming” requires several encoding processes on the server side to meet the increased sever side hardware requirements, especially CPU core numbers. It may require several modern CPU cores to provide real-time transcoding of a single HD stream.

For the “Video-On-Demand” approach, streams with different bitrates must be prepared ahead of time and stored on the server side. This brings additional requirements for storage size, since several copies of the same original media with different bitrates must be stored.

In Conclusion

Any modern media and IP video system must consider most adopted and prominent technologies. Today these include MPEG-DASH, MP4 with h.264, and WebM with VP8/9. HLS is still strong and must be supported, but with MPEG-DASH continuously increasing pressure, it is not unlikely that MPEG-DASH may replace HLS in a few years.

Adobe Flash Player should no longer be used as a main player for any web content provider and it is likely that this technology will withdraw in the near future.

MPEG-DASH and HLS provide great ways for high quality media content services, but on other hand pose increased requirements for content processing and storage on the server side as well as higher complexity of a media system.

Hybrid Mobile Apps in the Real World

Admin

Nowadays most people have heard about hybrid mobile app frameworks and their advantages. There are so many of them and each promises everything you dreamed about for a cross-platform mobile applications development. The idea is nice and simple: hosting a web application inside of the user’s smartphone or tablet with the ability to have a single codebase, involve web developers, reduce costs, decrease time-to-market, and so on. However, we can see that most of the mobile applications are still native and platform specific. Why is that? Experienced developers (especially those who had a really hard time working with early hybrid applications) may notice that the real life cross-platform mobile app development process is far from perfect to make it a standard. DSR Corporation team has rich experience in PhoneGap application development and knows all (or almost all) pros and cons of this technology. In this blog we aim to summarize our experience and share the risks that should be considered when using a hybrid mobile app frameworks.

“Like Native” Still Doesn’t Feel Native

After your hybrid application is ready and deployed I bet the first complaint you will get is the performance. The modern day user has zero tolerance for even a slight delay, especially if he or she is expecting to be entertained. Just try to scroll a list in a native iOS application and then in a hybrid one: you will probably not say the hybrid has delays but it feels different and users notice that.

Additionally, if you want to use the same codebase for all platforms, then your application will look the same on all platforms. Sometimes it is good and desirable. Even if it is not, your application will still work fine. But as you may know the UX/UI guidelines are different for each platform and each user base has specific expectations on how apps work on their respective platforms. For example, an iOS user expects a “Back” button everywhere, where Android users may not find the search if you implement it using the iOS style. So when you are implementing the same UI, you are making a compromise or spending extra effort to make it different.

You Can’t Get Away from Debug

If it works on one platform, it does not mean it will work on another. Each hybrid app has its native part and framework development teams work hard to make them work the same way on all platforms so you could relax and concentrate on HTML, CSS, and Javascript. However, even if the framework you picked is “perfect,” each platform is assumed to have its own browser. Moreover, if you extended the native part, for example, by writing your own PhoneGap plugin, you will have to carefully port it to each platform. The situation gets more complicated when dealing with low cost or old devices: each one of them can have its own surprises. In this case you may need to research the Crosswalk pluggable webview (https://crosswalk-project.org/) to make it easier to maintain your app.

As a result, this is actually a normal case for multi-platform development when “write once, run everywhere” turns into “write once, debug everywhere.”

Platform-specific Nuances

In a perfect world a web developer can develop a cross platform mobile app without learning anything else. Meanwhile, using a hybrid framework, please make sure the team is armed with at least the following knowledge:

  • Environment configuration. At the very beginning, you can rely on a cloud build service. But sooner or later, even if you work on something simple, you will need to debug your application to make sure there will be no surprises the day before delivery.
  • Native support. It would be nice to rely on an experienced mobile application developer on your team. And it will be 100% necessary if your hybrid framework does not provide something you need.
  • Offline mode. Make sure you are developing a mobile application, not a mobile website. It will be nice if it works offline or at least provides a clear message that an Internet connection is required.
  • Guidelines. The users will very much appreciate if you meet their expectations. Everyone likes something he or she is used to and that feels natural with how they use their device.
  • Interact with others. Make sure you know and interact with typical platform applications that are used every day. Building good neighbor relationships is a good habit.
  • Deployment and approval. It can be a real pain for those who are doing it for the first time. You may need to read vendor requirements carefully even before you start the development: some rules can change your plans.

Keep it Simple

Please don’t expect too much from the hybrids. If you need something of flawless quality or great performance or exquisite look and feel – hybrid is probably not a good choice. Note that hybrid apps are fragile: the more complex architecture you have, the more effort you need to maintain it, especially if this is about interaction of HTML/Javascript part and the native part.

It’s Alive!

Considering the fact that you are still able to use native tools and controls you may think about combining web controls with native ones. Be careful not to create a Frankenstein: the application complexity can rise so significantly that it will become a nightmare to debug and maintain. First, the native control you used will need to be considered on other platforms (there is no guarantee that it will work the same way). Second, the integration part (between HTML/JS and native) is the “richest” source of bugs: the more complex the design is, the more “fun” you will have. Third, thinking about using native controls is a good signal that you need a native application. Consider your options and make the right choice for your app.

The Apple Dependency

Another risk that you may need to consider is a high dependency on the App Store Review Guidelines. The App Store is dominating the mobile apps market, so Apple can and does dictate its rules. The Review Guidelines change quite often and, although unlikely, it’s possible that hybrid apps can get banned from the App Store at some point in the future.

Now when you are aware of the risks you may wonder if there are any reasons for you to use hybrid applications. There are many of them!

Low Cost and Quick Time to Market

If you have a limited budget and need a mobile application, using a hybrid framework may be a solution. Easier UI development will give you a cost advantage even if you are planning iOS as your only platform. Make sure to keep it simple and that your single codebase can be easily ported to other platforms without significant changes. At the same time, reducing your effort can save you precious time, so you can deploy early and have the app ready before your competitors.

Startups and Explore

If you are planning to develop a serious application that requires a lot of effort for UX/UI you may consider prototyping it first. It will allow you to have better understanding of all application usage aspects and resolve problems early. Certainly, your prototype can be a quickly developed hybrid application you can use to get early adopter feedback and demo the concept.

Web Development Forces

If you or your team are good web developers, then you can use your experience in the mobile apps as well. Choose a hybrid mobile app UI framework you like the most and do the main implementation using your favorite tools. In most cases you will not need to learn a new programming language. At the same time, you will be able to develop for additional platforms improving your web development experience.

Better Than a Website

If you are thinking about developing a mobile website instead of a mobile app, then you should consider the serious advantages the mobile apps have:

  • Sales and distribution. Everyone knows about platform specific application stores that help users find what they want and allow developers to sell and distribute their apps with ease.
  • Usability. Mobile apps are optimized for use on mobile devices and users expect at least the same level of usability. It would be difficult to compete with a mobile application having only a browser application.
  • Works offline. Your users can work with the app even if the Internet connection is lost.
  • Using device capabilities. In contrast to websites, mobile apps can utilize a full set of device capabilities.
  • Popularity. Today it seems like a good habit to create a mobile app to meet user expectations.

Although we at DSR prefer to build native mobile apps because of their performance, seamless user interface, and best user experience, we have rich experience building cross-platform mobile apps as well. The latter can give you a serious advantage, but only if the related risks are considered. This is not a silver bullet, but it can be a powerful weapon on your side, if your project meets the parameters described above.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.