Content Delivery
2.1 Large-Scale Content Delivery
In recent years, the amount of traffic generated by video streaming has been steadily rising. Year after year more large 
distribution sites are also added via the streaming services that IIJ provides. The Visual Networking Index (VNI)*1 also 
published by Cisco forecasts that video-based traffic will continue growing. According to this index, the total amount of video 
traffic is expected to account for between 80% and 90% of global consumer traffic by 2018.
As this demonstrates, video streaming is continuing to grow in scale. In fact, to our surprise even live broadcasts of minor 
events sometimes draw more views than expected. Forecasting streaming traffic is difficult even for those with experience, 
but in more and more cases the number of hits turns out to be higher than anticipated.
The widespread use of mobile devices is undoubtedly responsible for streaming seeing this kind of popularity. While 
subscriber numbers for fixed communication networks (fiber optic lines and CATV, etc.) have stagnated, mobile phone 
penetration surpassed 100% of the population by the end 2011, and stands at 118% as of June 2014. The increase in wireless 
speeds for mobile devices, and smartphones in particular, also cannot be overlooked. Trial calculations published for the fifth 
generation (5G) technology currently in development put its download speed at 100 times that of 2010 under ideal conditions. 
The traffic generated by mobile devices may even exceed that of past fixed communication networks in the future.
This makes mobiles devices an attractive segment for content holders. It has become more and more common to see people 
using mobile devices while traveling on public transport, or during short periods of waiting. Many content holders are 
considering and implementing delivery to mobile devices to take advantage of this disposable spare time.
*1 Cisco VNI (http://www.cisco.com/c/en/us/solutions/service-provider/visual-networking-index-vni/index.html).
2. Content Delivery
Here we discuss video streaming, which is generating an increasing amount of traffic,  
and also give an overview of the H.265, 4K, and MPEG-DASH standards.
Additionally, we present a case study of the National High School Baseball Championship at Koshien Stadium.
The Latest Streaming Technology
Figure 1: HTTP Live Streaming
Server
streaming segmenter
MPEG-2transport stream
media encoder
Distribution
Client
origin web server
Index file
Audio/Videoinputs
Content Delivery
2.2 Mobile Topics
A few technical obstacles had to be cleared before delivery to mobile devices was possible. A typical example of this is the 
streaming formats supported by devices. To deliver content to a client using a format not supported by the OS, the library for 
that streaming format must be incorporated into an app. Because this method leads to higher licensing and production costs, 
it is far from ideal. Consequently, it is necessary to address the question of which streaming formats should be pre-installed 
as standard on mobile OSes.
Apple has supported streaming to its mobile devices since iOS 3.0, which was released in 2009. This was around the 
time when the iPhone 3GS was released, a year after the iPhone 3G went on sale in Japan. This marked the period when 
downlink speeds reached a theoretical 7.2 Mbps through support for the HSDPA standard, making streaming to mobile 
devices more practical. Very few models of the feature phones prevalent at the time were capable of receiving streamed 
data. Streaming delivery to iPhones only required a Web server, and an increasing number of models were compatible 
with streaming encoders, so it did not take long for streaming to catch on. People embraced the experience of viewing 
video content on smartphones.
For Android, the situation differs greatly depending on the OS version. Adobe put out their Flash Player for Android 2.2 
and 2.3 when these OSes were released, so most video content was delivered using Flash technology (RTMP: Real Time 
Messaging Protocol). However, in 2011 Adobe announced they were terminating development of Flash Player for mobile 
devices. Because HLS (described later) was supported on Android 4.0, which was released around the same time, HLS 
subsequently became the most common format for delivery.
2.3 The Emergence of H.265 and 4K
The digital processing of video entails a constant battle with data volumes. To illustrate it simply, the higher the image 
quality, the larger that data will be. The only way to keep data volumes in check is to reduce the picture field (screen size), or 
make do with lower image quality. The technology for reducing data volume while subjectively keeping the degradation of 
image quality to a minimum is known as a codec. Codec is a portmanteau of “coder-decoder,” and indicates the playback-
side decoding of content coded (or encoded) on the transmission side. This technology is widely used in DVDs and terrestrial 
digital broadcasting. Currently, the most commonly used codec is a standard known as H.264*2.
H.264 is a standard developed jointly by the ITU and ISO. It was completed in 2003, so it already has a history of over ten years. 
Over this period CPU performance has increased, and manufacturers have made improvements to their algorithms. H.264 is 
merely a standard, and the programming of the compression portion is implemented independently by each manufacturer. 
Partly as a result of this, the video produced by recent encoders has much higher image quality than the early encoders that 
came out. In the past I have spoken with researchers who said that H.264 still has a lot of room for improvement. However, 
even with improvements to H.264 performance, it was difficult to bring it in line with 4K.
In response to this, the new H.265*3 codec appeared. During the development of H.265, it was given the name High Efficiency 
Video Coding (HEVC). H.265 and HEVC refer to the same standard. As the name suggests, this standard enables highly 
efficient compression, and it was designed based on the advances in CPU technology over the past ten years, in anticipation 
of the increased computational complexity required for video compression. H.265 is said to be twice as efficient as H.264. 
Double the efficiency basically means that twice the amount of data can be sent using the same amount of bandwidth as 
H.264, and file sizes are halved even with quality equivalent to H.264.
*2 H.264 : Advanced video coding for generic audiovisual service (http://www.itu.int/rec/T-REC-H.264/e).
*3 H.265 : High efficiency video coding (http://www.itu.int/rec/T-REC-H.265/e).
Content Delivery
Manufacturers that have codex technology are currently pouring all their efforts into improving the performance of H.265. In 
other words, it’s unlikely that these companies will have any part in the further development of the H.264 codec in the future 
(as the same developers are involved). As a result, it could be said that the H.264 codec is quite mature at this stage.
2.4 4K
4K generates far more data than HD (High Definition), with a quadruple-sized picture field and double the frame rate. This results 
in a total of eight times as much data. As-is, it would be utterly impossible to deliver video via broadcast or communications.
The highly-efficient compression of data over communication 
paths that have only limited bandwidth makes it possible 
to deliver this data to more users. Aside from the 
communications world, bandwidth limits also affect 
broadcasting. To allow for as many channels as possible, 
each channel should ideally take up minimal bandwidth. In 
Japan the H.265 standard has been officially adopted for 
4K broadcasts, and test broadcasts are already underway. 
H.254 codecs are also being adopted for a series of 
communications-based 4K video services that are set to 
appear in the future. In both cases, H.265 is considered 
essential for 4K content delivery. This demonstrates how 
H.265 has become an enabler for 4K.
2.5 MPEG-DASH
Meanwhile, Internet-based delivery methods are going through a period of dramatic change. In the 2000s, RTSP (Real Time 
Streaming Protocol) standardized by the IETF as well as the MMS (Microsoft Media Server) and RTMP (Real Time Messaging 
Protocol) proprietary methods developed by manufacturers were widely used. These generally utilized UDP to transport 
data, along with HTTP encapsulation when it was necessary to traverse a firewall. However, in the 2010s there was a shift to 
delivery methods that use HTTP directly for streaming, or in other words protocols that don’t use UDP.
The HTTP Live Streaming (HLS)*4 protocol developed by Apple was the pioneering architecture that implemented streaming 
over HTTP. Apple has submitted this standard to the IETF since 2009, but it has not been adopted by the working group. Apple 
have documented it as an Internet Draft*5 independently, so it has not yet reached RFC status. It uses an extremely simple 
configuration, in which video data is divided into segments of a few seconds each and placed on a Web server, and then 
URIs (called manifests) for playing back these segment files are sent to clients in list form. It is not very hard to implement, 
and many manufacturers have provided support for this method. Meanwhile, HLS remains a standard governed solely by 
Apple that has not become an RFC Internet standard. There is also no prescribed DRM, which is considered necessary for 
streaming, and only the most basic encryption has been defined. When completely dependent on it, you have no other option 
but to follow Apple’s policies. In my personal view, Apple sometimes unilaterally takes actions that change the rules. I believe 
that many companies are looking at whether or not this risk will have an impact on HLS.
For example, HTTP streaming was also adopted in the Smooth Streaming*6 protocol proposed by Microsoft. However, since 
Microsoft began promoting MPEG-DASH, new adoptions of HTTP streaming have slowed down. Smooth Streaming was 
developed as a part of the Silverlight Rich Internet Application (RIA), but with development of this application terminated, 
you could say it’s reached the end of its life as a format.
*4 HLS: HTTP Live Streaming (https://developer.apple.com/streaming/).
*5 HTTP Live Streaming draft-pantos-http-live-streaming (https://datatracker.ietf.org/doc/draft-pantos-http-live-streaming/).
*6 IIS Smooth Streaming Technical Overview (http://www.microsoft.com/en- us/download/details.aspx?id=17678).
Figure 2: Resolution Comparison
576or 4800
4K UHD
8K UHD
Content Delivery
The same applies to the HTTP Dynamic Streaming (HDS)*7 proposed by Adobe. If technology developed by a certain 
company without going through the process of standardization is adopted across the board, there is a risk of vendor lock-in. 
Furthermore, the streaming industry has only just begun migrating from proprietary protocols to HTTP in the past few years. 
The desire for a clean technology that allows you to oversee everything yourself may be stronger in the end.
MPEG-DASH*8 came about as an antithesis to this kind of situation. Although the technologies are similar, HLS, Smooth 
Streaming, and HDS each use different segmenting methods and manifests. This means that despite the similarities between 
these HTTP streaming formats, playback clients and STBs are forced to either implement all of them, or make a choice on 
which to implement. In light of this situation, the MPEG (Moving Picture Experts Group) ISO/IEC working group decided to 
develop a standard independent of the formats created by specific manufacturers. A Request For Proposal was issued in 
2009, and ultimately the method proposed by the 3GPP (Third Generation Partnership Project) was adopted. MPEG-DASH 
is short for Dynamic Adaptive Streaming over HTTP. The HTTP standard was adopted for the streaming protocol. It also 
incorporates adaptive bitrate streaming, which enables streams to be selected based on the client’s downstream bandwidth 
status. By simply preparing streams for multiple bandwidths on the server side, it is possible for clients to switch streams 
on their own initiative. The adaptive bitrate streaming technique has gained broad acceptance, because there is no need for 
server-side implementation, and it is possible to respond to subtle changes in the overall client-side environment. MPEG-
DASH also meets a range of current content delivery requirements, such as enabling a number DRM methods to be applied.
*7 HDS: HTTP Dynamic Streaming (http://www.adobe.com/products/hds-dynamic-streaming.html).
*8 MPEG-DASH “ISO/IEC 23009-1:2014 Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats”: 
(http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=65274).
Figure 3: MPEG-DASH
Media Presentation on HTTP Server
HTTP/1.1
The red blocks are in MPEG-DASH’s scope.
Segment
Segment
Segment
Segment
DASH Client
HTTP Access Client
on-time HTTP requests to segments
Media EnginesResources located by HTTP-URLs
Media Presentation Description
DASH Control Engine
Content Delivery
MPEG-DASH caught on in Europe first, and it is now being adopted in rapid succession worldwide. It is currently in the 
limelight, with its adoption being promoted by an organization called the DASH Industry Forum*9, while seminars have 
also been held for it at large broadcast industry conferences such as the NAB Show and IBC. In Japan, IIJ was the first to 
implement streaming delivery using MPEG-DASH and H.265 at the Spring Festival in Tokyo, which took place in March 2014. 
This cutting edge trial applied the latest technologies in the field ahead of anyone else, and was achieved by combining 
technology from a number of manufacturers. The number of encoders and servers that support MPEG-DASH is also on the 
rise. Going with a standard specification led to a large number of manufacturers adopting the technology, which creates 
more options for users and promotes competition. It is fair to say that MPEG-DASH is creating a market, and it is on the verge 
of widespread adoption.
2.6 Summer Koshien Case Study
IIJ provides streaming delivery services for the National High School Baseball Championship at Koshien Stadium, which is 
produced by Asahi Broadcasting Corporation. Every year the special website set up by Asahi Broadcasting Corporation gets 
large numbers of hits, with most involving the receipt of live streamed content. IIJ offers its large-scale CDN services (IIJ 
Contents Delivery Service / Multi Device Streaming / Live) to provide streaming without congestion.
In 2014, we used the HLS (for mobile devices) and HDS (for PCs) delivery protocols. These two protocols were distributed 
from a single platform. Asahi Broadcasting Corporation encodes the video, then IIJ uploads it to the ingest servers. At this 
stage the RTMP protocol is used. IIJ’s servers read requests from clients, and switch between HLS and HDS on the fly. The 
customer doesn’t need to prepare two separate streams using the HLS and HDS protocols, and they can continue using their 
existing RTMP-compatible encoder, so this is a popular feature.
*9 DASHIF: DASH Industry Forum (http://dashif.org/). 
Figure 4: August 25, 2014 - Traffic Graph for High School Baseball Summer Championship Final Broadcast
(Bandwidth)
(Time)
12:0013:0014:0015:0016:00
You can see that traffic increases as the innings go by. Peak instantaneous bandwidth on the day was recorded at 108 Gbps.
Content Delivery
This year the ad insertion technology attracted the most attention. Asahi Broadcasting Corporation triggered the insertion of 
advertisement videos in between innings. The same ads were inserted for all users this time, but by pairing this technology 
with the client’s IP address, cookies, or technology such as user authentication, it would be easy to personalize the ads 
shown. As indicated above, delivery to mobile devices will be a large market for streaming business in the future. Mobile 
devices are extremely personal things, so we believe being able to customize the insertion of ads for devices such as these 
offers vast business potential.
This was also Asahi Broadcasting Corporation’s first attempt at broadcasting the National High School Baseball Championship 
to mobile devices. Stable delivery is what supports these kinds of attempts. When delivery is disrupted straight away, users 
spend less time watching a stream. This leads directly to lost business opportunities, so service providers like us must take 
extreme care and do our utmost to provide stable server operation.
2.7 Conclusion
As shown here, streaming technology is established in standard specifications, and will continue to grow in scale. The 
advantages of HTTP include improved CDN compatibility, and the fact that it is NAT and firewall friendly. It is also thought to 
have high affinity with cache servers. Additionally, there are currently moves to evaluate streaming using HTTP/2. Meanwhile, 
MPEG-DASH has the benefit of facilitating better support from industries that support international standards (through tools 
or solutions being provided). The same goes for H.265.
IIJ will continue striving to stay abreast of the latest technologies such as these and roll out services and solutions. We will 
also work on collaborations with the IIJ Research Laboratory to study technology for larger-scale streaming delivery and 
more stability.
Author:
Bunji YamamotoMr. Yamamoto is a Senior Engineer in the Product Promotion Department Corporate Planning Section of the Product Division, IIJ. He joined IIJ Media Communications in 1995. He has worked at IIJ since 2005. He is mainly involved with the development of streaming technology. Among his contributions to development of the market is the organization of the Streams-JP Mailing List, which discusses this technology.