IPTV and Over-the-Top Video · IPTV and Over-the-Top Video: ... Super Headend (SHE) Video Hub Office (VHO) Regional Headend (RHE) ... Internet Core Network HFC.

IPTV and Over-the-Top Video: Managed and Unmanaged Video Delivery

Ali C. Begen

BRKSPV-1999

© 2015 Cisco and/or its affiliates. All rights reserved.BRKSPV-1999 Cisco Public 3

• Have a Ph.D. degree from Georgia Tech, joined Cisco in 2007

• Works in the area of architectures for next-generation video transport and distribution over IP networks

• Interested in

– Networked entertainment

– Internet multimedia

– Transport protocols

– Content distribution

• Senior member of the IEEE and ACM

Presenter Today – Ali C. BegenVisit http://ali.begen.net for Publications, Presentations, etc.

© 2015 Cisco and/or its affiliates. All rights reserved.BRKSPV-1999 Cisco Public

• Part I: IPTV

• IPTV – Architecture, Protocols and SLAs

• Video Transport in the Core Networks

• Video Distribution in the Access Networks

• Improving Viewer Quality of Experience

• Part II: Internet Video and Adaptive Streaming

• Example Over-the-Top (OTT) Services

• Media Delivery over the Internet

• Adaptive Streaming over HTTP

• MPEG DASH Standard

Agenda

4


First Things FirstIPTV vs. IP (Over-the-Top) Video

IPTV IP Video

Best-effort delivery

Quality not guaranteed

Mostly on demand

Paid or free service

Managed delivery

Emphasis on quality

Linear TV plus VoD

Paid service


Experiences Consumers Want NowYet Service Providers Struggle to Deliver

Multi-screen TV

Experience

Online Content on

TV/STB

Intuitive Unified Navigation

for All Content

Web 2.0 Experiences on

TV/STB

Support an increasing variety of services on an any device and

deliver a common experience everywhere


Three Dimensions of the ProblemContent, Transport and Devices

Managed and Unmanaged Content

Managed andUnmanaged Transport

Managed andUnmanaged Devices


From Totally Best-Effort to Fully-Managed OfferingsChallenge is to Provide a Solution that Covers All

Design to the most general case

Optimize where appropriate

Part I: IPTV


What Is IPTV?The Fundamental Component for Connected Homes

Broadband

IP Access

IPTV = IP Network-delivered Television

- Switched digital video (SDV)

- Video recording (DVR/PVR/nDVR)

- Video-on-demand (VoD)

- Interactive TV applications

- Targeted (advanced) advertising


Growth for IPTV

0

20

40

60

80

100

120

140

160

2009 2010 2011 2012 2013 2014 2015

Mill

ion

s

CALA North America EMEA APAC

Source: Infonetics Research, 2011


Pay TV Subscribers by Service Type

0

100

200

300

400

500

600

700

800

900

1,000

CY12 CY13 CY14 CY15 CY16 CY17 CY18

Mill

ion

s

Telco Cable Satellite

Source: Infonetics Research, 2014


Trends Driving IPTV Adoption

• Subscribers want more choice and control– New generation grew up computer/Internet savvy

– Customized for me – One bill, one provider, integrated services

• Codec, access, server and CPE technologies are improving– Codec (H.264 and H.265) improvements, new xDSL, FTTx, DOCSIS 3.x access technologies

– Moore’s law advancements in processing and memory

• Competition is increasing among service providers– No longer limited by access

– Traditional markets are going away, e.g., VoIP is almost free

Video is driving next generation service provider network designs

IPTV – Architecture, Protocols and SLAs


End-to-End IPTV Network Architecture

15

Metro Aggregation &

Distribution NetworkIP/MPLS

Core Network

Transcoders

Encoders

Vault

Streamers

IPTV Content

Manager

IPTV Service

Assurance

CA/DRM

National

Content Acquisition

Core

Router

Core

Router

Aggregation

Router

Access

Network

Aggregation

Router

VoD Servers

CA/DRM

Transcoders

Encoders

Regional

Content

Acquisition

Streamers

VoD Servers

Back Office

Billing

Ad Insertion

STB

STB

STB

STB

STB

STB

STB

STBDSLAM

uBR

CMTS

Metro

Ethernet

FTTx

Core Distribution/Aggregation Access

Super Headend (SHE) Video Hub Office (VHO)

Regional Headend (RHE)Video Switching

Office (VSO)

Retransmission

Servers

Home


Unicast vs. Multicast

16

Unicast

Source

Multicast

Source


Broadcast IPTV = IP Multicast• Various Transports

– Native IP multicast, MPLS, L2, optical

• SSM: Source-Specific Multicast (RFCs 4604 and 4607)

– Receivers subscribe (S,G) channels to receive traffic only from source S sent to group G

– Primarily introduced (by IETF) for IPTV-like services

• IP Multicast Endpoints

– Sources: Encoder, transcoder, groomer, ad-splicer

– Receivers: Transcoder, groomer, ad-splicer, eQAM, IP STB

• IETF standardized

– Receiver-to-Router Protocols: IGMPv3 (IPv4) and MLDv2 (IPv6) with (S,G) signaling

– Router-to-Router Protocols: PIM-SSM, IGMPv3 Proxy Routing, Snooping on HAG and L2 devices

• Transport Challenges

– Packet loss, out-of-order delivery, packet duplication

(We cannot use TCP for IP multicast)


Real-Time Transport Protocol (RTP)

• Basics– First specified by IETF in 1996, later updated in 2003 (RFC 3550)– Runs over any transport-layer protocol (Typically over UDP)– Runs over both unicast and multicast– No built-in reliability

• Main Services– Payload type identification– Sequence numbering– Timestamping

• Extensions– Basic RTP functionality uses a 12-byte header– RFC 5285 defines an RTP header extension mechanism

• Control Plane – RTCP– Provides minimal control and identification functionality– Enables a scalable monitoring functionality (Sender, receiver, extended reports)

http://tools.ietf.org/html/rfc3550

18


RTP Transport of MPEG2 Transport Streams

19

Application

Presentation

Session

Transport

Network

Data Link

Physical

IPTV Application

MPEG2-TS

RTP

UDP

IP

IGMP/MLD

Religion

Politics


Packetization into MPEG2 Transport StreamsSingle Program Transport Streams (SPTS)

20

Vid

eo

Video

PES

Au

dio

Audio

PES

Additional Audio Tracks

Application Data

PAT (PID=0), PMT Video

PES

Audio

PES

Additional Audio Tracks

Application Data

PAT (PID=0), PMT

Depacketizer

Vid

eo

Video

Decoder

MP

EG

2-T

S D

em

ux

Depacketizer

Au

dio

Audio

Decoder

PacketizerVideo

Encoder

MP

EG

2-T

S M

ux

PacketizerAudio

Encoder

SPTS

SPTS


RTP Transport of MPEG2 Transport Streamshttp://tools.ietf.org/html/rfc2250

21

Default IP header size is 20 and 40 bytes for IPv4 and IPv6, respectively

IP Encapsulation

UDP Encapsulation

RTP Encapsulation

MPEG2-TS Payload

RTP MPEG2-TS Payload

UDP RTP MPEG2-TS Payload

IP UDP RTP MPEG2-TS Payload

8 bytes

20/40 bytes

N 188-byte MPEG2-TS Packets. . . . . .. . .

V=2 P X CC M PT Sequence Number

Timestamp

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

…


Video Headend Building BlocksA

CQ

UIS

ITIO

N Satellite reception

Off-air reception

Fiber reception

Signal conversion

EN

CO

DIN

G MPEG-2

AVC

HEVC

SD

HD

Audio encoding

PR

OC

ES

SIN

G Transcoding

Transrating

Splicing

Multiplexing

Ad insertion

MA

NA

GE

ME

NT CAS/DRM

Remote ops

Metadata

Billing

VoD servers

Video apps


Role of IPTV Middleware

• Middleware provides interoperability for system components

• Middleware enables

– Revenue producing IPTV services

– Differentiation for service providers

– Consistent and extensible consumer experience

– Delivery of rich media to consumers

– Compelling GUIs

• Middleware ties together all parts of an end-to-end IPTV system

– EPG, content navigation

– CAS/DRM, VoD servers, asset management, service packaging

– EAS, STB support, network management

– Billing, triple-play integration, subscriber management


Telco IPTV System Reference Architecture

24

IP Content and Delivery over Fiber/xDSL Access

OLT/DSLAM

CA/DRMSystem

OSS/BSS

IPTVApplication

Platform

VoDBackoffice

System

ContentProvider

ONT/ Modem

CA/DRM

IPTV

Client

Platform

IP STB

UserInterface

VideoHeadend

ContentDeliverySystem

IPTVNetworkServer

IPTVApplication

Server

Fiber/

CopperCore NetworkInternet


Cable IPTV System Reference Architecture

25

IP Content and Delivery over DOCSIS (VDOC)

CMTS

CA/DRMSystem

OSS/BSS

IPTVApplication

Platform

VoDBackoffice

System

ContentProvider

CableModem

CA/DRM

IPTV

Client

Platform

IP STB

UserInterface

VideoHeadend

ContentDeliverySystem

IPTVNetworkServer

IPTVApplication

Server

HFCCore NetworkInternet


Efficiency Gains From IPTV in Cable Delivery

• VBR provides a bandwidth savings of 40-60%

• IPTV is the best choice for narrowcast statmux and AVC statmux

Variable Bitrate

• Switching is the way to offer unlimited channels

• IPTV provides built-in switching functionality

Switched Video

• AVC provides a bandwidth savings of 50% over MPEG2

• IPTV solves the problem of slow channel change

Advanced Coding

• Convergence provides further bandwidth savings

• We can share QAMs for VoD and SDV as well as for video and DOCSIS

QAM Sharing


Types of Video Services

• Transport (Contribution and Primary Distribution)

• IPTV /CATV (Secondary Distribution)

– IP multicast distribution from centralized super headends

– (Driving enhanced multicast features and functions)

• VoD (Secondary Distribution)

– Distributed architecture for better scalability

– Non-real-time content distribution to caches

• Enterprise

– mVPN based

• Over-the-Top (e.g., Hulu, Apple TV, Netflix)

– Adaptive streaming methods are ubiquitous


IPTV must Deliver Entertainment-Caliber Video Tolerance is One Visible Artifact per Movie

28

Access

IP/MPLS

Core

Contribution

Network

IP/MPLS

Core

Primary

Distribution

IP/MPLS

Core

Secondary

Distribution

Super

Headend

(x2)

National Content

Acquisition

Encoders

Vault

Regional

Headend

(x10s)

Regional Content

Acquisition

Encoders

Streamers

Video

Switching Office

(x100s)

Ad Insertion

Back Office/Billing

VoD Servers

Streamers

Final

Studio

Studio

Mobile

Studio

Studio

Homes

(Millions)

Reliability is more

difficult to achieve here


Taxonomy of Video Service Providers

29

Contribution

PrimaryDistribution

SecondaryDistribution

Owner to ProviderCompressed (High quality)

P-to-P P-to-Mp

Studio to StudioUncompressed/Lossless compression

- SD: 270 Mbps (SMPTE 259M)

- HD: 1.5 – 3 Gbps

(SMPTE 292M, 372M, 424M)

P-to-P P-to-Mp

Provider to SubscriberCompressed

- SD: 2 – 6 Mbps

- HD: 6 – 16 Mbps

P-to-P for VoD

P-to-Mp for IPTV

May be wholesaled

Stricter Requirements

Hig

he

r B

an

dw

idth


Digital Video BandwidthsUncompressed Digital Video

SDTV (480i CCIR 601 over SD-SDI SMPTE 259M) 165.9 – 270 Mbps

HDTV (1080i or 720p over HD-SDI SMPTE 292M) 1.485 Gbps

HDTV (1080p over Dual Link HD-SDI SMPTE 372M or 3G-SDI SMPTE 424M) 2.970 Gbps

UHDTV (2160p) 11.88 Gbps

MPEG-2 Compressed Video

SDTV Broadcast (3.75 Mbps for Cable VoD) 3 – 6 Mbps

HDTV Broadcast (19.3 Mbps for ATSC DTV) 12 – 20 Mbps

SDTV Production (Contribution – 4:2:2 I-frame only) 18 – 50 Mbps

SDTV Production (Contribution – 4:2:2) 20 – 30 Mbps

HDTV Production (Contribution – 4:2:2) 34 – 60 Mbps

JPEG-2000 HDTV Production (Contribution – 4:4:4 I-frame only) 150 - 300 Mbps


Digital Video BandwidthsMPEG-4 AVC / H.264 Compressed Video

SDTV Broadcast (~50% less than MPEG-2) 1.5 – 3 Mbps

HDTV Broadcast (1080i) 6 – 9 Mbps

MPEG-H Part 2 HEVC / H.265 Compressed Video

High-end 4KLive Sports (50/60 fps) 35 Mbps

Low-end 4K Movies (24 fps) 12 – 15 Mbps


Video SLA Requirements

• Throughput

– Addressed through capacity planning and QoS (i.e., Diffserv)

• Delay/Jitter

– Controlled with QoS

– Absorbed by de-jittering buffer at IP STB• We desire to minimize buffer sizes to improve responsiveness

• Jitter originating in the core is rather insignificant

• Packet Loss

– Controlling loss is the main challenge

• Service Availability

– Proportion of time for which the specified throughput is available within the bounds of the defined delay and loss

Video Transport in the Core Networks


Four Primary Causes for Packet Loss

• Excess Delay

– Renders media packets essentially lost beyond an acceptable bound

– Can be prevented with appropriate QoS (i.e., Diffserv)

• Congestion

– Considered as a catastrophic case, i.e., fundamental failure of service

– Must be prevented with appropriate QoS and admission control

• PHY-Layer Errors

– Apply to core and access – Occurrence in core is far less

– Considered insignificant compared to losses due to network failures

• Network Reconvergence Events

– Occur at different scales based on topology, components and traffic

– Can be eliminated with high availability (HA) techniques


Impairment Rate

Trunk failures .0010 /2h

Hardware failures .0003 /2h

Software failures .0012 /2h

Non-stop forwarding (NSF) and

Stateful switch-over (SSO) help here

Software upgrades (Maintenance) .0037 /2h

Modular code (IOS-XR) helps here

Total .0062 /2h

(One every two weeks)

Note that average mean time between errors on a DSL line is in the order of

minutes when no protection is applied

What are the Core Impairment Contributors?

35

Back of envelope calculations across several SPs show mean time between core failures affecting video is > 100 hours

Source: Data from industry standards, customers and assumptions


Unequal Importance of Video PacketsA Simple MPEG Video Group of Pictures (GoP)

36

I B

B

B

B

P

B

BP

P


MPEG Frame Impact from Packet Loss

0

20

40

60

80

100

50 100 150 200 250 300 350 400 450 500 550 600

I-F

ram

e L

os

s P

rob

ab

ilit

y (

%)

Outage Duration (ms)

GoP Size: 500 ms (I:P:B = 7:3:1)

37

FUD on 50-ms Requirement

- Legacy telco voice requirement

- Artifact of SONET/SDH

FACTS

- IP multicast is UDP based

- The only acceptable loss is 0%

- At 50 ms outage, an I-frame will

be impacted with a chance of 34%


Fast Convergence or Fast Reroute

• Network reconverges (reroutes) on a network (link or node) failure

• Fast Convergence (FC) – Fast Reroute (FRR)

Lowest bandwidth requirements in working and failure cases

Lowest solution cost and complexity

! Requires fast converging network to minimize visible impact of loss

Is NOT hitless – Loss of connectivity before connectivity is restored

Video

Source

Core

Router

Core

Router

Edge

DistributionCore

Router


Multicast (SSM) Fast Convergence on CRS-1

0 100 200 300 400 500 600 700 800 900 1000

400

800

4000

Reconvergence (ms)

Nu

mb

er

of

IPT

V C

ha

nn

els

Max of Max

Median of Median

Convergence Time Following A Failure

39

Tested with 2500 IGP prefixes and 250k BGP routes

No more than one I-frame is

lost even in the worst case


Forward Error Correction (FEC)

• FEC adds redundancy to the source data to allow to detect and repair losses

• FEC Is hitless from loss due to core network failures if loss can be constrained

Does not require path diversity – Works for all topologies

! Requires fast converging network to minimize FEC overhead

Incurs delay – Longer outages require larger overhead or larger block sizes (More delay)

Video

Source

Core

Router

Core

Router

Edge

DistributionCore

Router


Temporal Diversity (Redundancy)

• Let Q (ms) denote the max outage duration that is intended to be repaired

• Packets are transmitted twice, each separated by Q-ms delay

• Temporal diversity Is hitless from loss due to core network failures if loss can be constrained

Does not require path diversity – Works for all topologies

! Requires fast converging network to minimize Q

Introduces 100% overhead and Q-ms delay

Video

Source

Core

RouterCore

RouterEdge

Distribution

Primary Stream

Delayed Stream


Spatial (Path) Diversity – Live/Live

• Two streams are sent over diverse paths in the core

• Spatial diversity Introduces no delay if the paths have equal propagation delays

Requires network-level techniques to ensure spatial diversity

Incurs 100% overhead – May not be an issue where redundant capacity is normally provisioned– E.g., dual-plane core networks

Video

Source

Core

RouterCore

RouterEdge

Distribution

Primary Stream

Primary Stream


Increasing Cost

and Complexity

Toward Lossless IPTV TransportAttend BRKSPV-1919

43

Increasing

Loss

Lossless One GoP Impacted

No

Netw

ork

Re

-en

gin

eeri

ng

Netw

ork

Re

-en

gin

eeri

ng TE +

Live / Live

MTR +

Live / Live

MPLS TE

FRR + TD

MoFRR +

Live / Live

FC +

FEC or TD

MPLS TE

FRR

MoFRR

FC


Toward Lossless IPTV TransportReading

44

“Toward lossless video transport,”

IEEE Internet Computing, Nov./Dec. 2011

“Designing a reliable IPTV network,”

IEEE Internet Computing, May/June 2009

Video Distribution in the Access Networks


VQE – A Unified QoE Solution

• IPTV viewers have two criteria to judge their service

– Artifact-free audiovisual quality• Loss may be correlated in spatial and/or temporal domain, must be recovered quickly

• Loss-repair methods must be multicast friendly

– Short and consistent zapping times• Compression and encryption used in digital TV increase the zapping times

• Multicasting in IPTV increases the zapping times

• Service providers need a scalable unified solution that

– Is standards-based and interoperable with their infrastructure

– Enables versatility, quick deployment and visibility into the network

– Extends the service coverage area, and keeps CapEx and OpEx low

Glitch-Free Audiovisual Quality, Short and Consistent Zapping

46


A Simplified Model

• Each TV channel is served in a unique (SSM) multicast session

– IP STBs join the respective multicast session for the desired TV channel

– Retransmission servers join all multicast sessions

• Unicast feedback from IP STBs are collected by the feedback target

– NACK messages reporting missing packets, rapid channel change requests

– RTCP receiver and extended reports reporting reception quality

STB

STB

Transport &

DistributionAccess

Network

STB

STB

STB

Retransmission Server

(w/ Feedback Target)

Aggregation

Router

Channel 1

Channel 2

RTP Source

DSLAM

DSLAM

VQE Server

VQE Client

VQE Client

VQE Client

VQE Client

VQE Client


Impairments in xDSL Networks

• Twisted pair is subject to

– Signal attenuation: Use shorter loops

– Cross talk: Use Trellis Coding and RS-based FEC

– Impulse noise: Use RS-based FEC with interleaving

• There are three types of DSL impulse noise

– REIN: Short burst of noises (< 1 ms)

– PEIN: Individual impulse noise (> 1 ms, < 10 ms)

– SHINE: Individual impulse noise (> 10 ms)

• We observe different noise characteristics

– Among different SP networks

– Among different loops in the same SP network


ADSL Transmitter Reference ModelITU-T Recommendation G.992.1

49

MU

X/S

yn

c

DMT

Symbols

CRCScrambler

& FEC

CRCScrambler

& FECInterleaver

To

ne O

rde

rin

g

Interleaved Path

Fast Path

AS0AS1AS2AS3

LS0LS1LS2

OAM


ADSL and ADSL2+ ConfigurationsADSL ADSL2+

Data bytes per RS codeword, K 239 bytes 69 bytes

Parity bytes per RS codeword, R 16 bytes 10 bytes

Correctable byte errors per RS codeword, T = R / 2 8 bytes 5 bytes

Total bytes per RS codeword, N = K + R 255 bytes 79 bytes

# of RS codewords per DMT symbol, 1/S 1 11

DMT duration, t 250 us 250 us

Line data rate, LDR = N / S / t 8.0 Mbps 27.4 Mbps

Net data rate, NDR = LDR x K / N 7.5 Mbps 24 Mbps

Interleaver depth, D 32 352

Size of required memory, B = (N–1) x (D–1) 7874 bytes 27378 bytes

Interleaving delay, ID = B / LDR 7.87 ms 7.97 ms

Block size (Protection period), PP = N x D / LDR 8.16 ms 8.10 ms

Correctable error burst length, BL = D x T 256 bytes 1760 bytes

Impulse noise protection, INP = floor( BL / (N / S)) 1 2


Example: Interleaving of RS Codewords

• Interleaving

Spreads a bursty error among multiple codewords

Allows the decoder to repair the error with fewer parity bytes

Introduces delay

Renders the whole block useless upon a decoding failure

1 2 3 4 1 2 3 4

1 1 2 2 3 3 4 4

Original RS Codewords

Interleaved RS Codewords

Data bytesParity bytes

1 2 3 4 1 2 3 4


Fast vs. Interleaved Path

• Assumptions

– One impulse noise arrives every 15 seconds

– 2% of these impulses cause an error

• Conditional Probability of (DMT error | There is an error)

– 85% probability for one DMT in error

– 12% probability for two DMTs in error

– 3% probability for three or more DMTs in error

• Fast Path

– ADSL/ADSL2+: One (maybe two) IP packet loss in every 750 seconds

• Interleaved Path (Interleaving delay: 8 ms)

– ADSL: Up to 7 IP packet losses (at the net rate) in every 5000 seconds

– ADSL2+: Up to 19 IP packet losses in every 25000 seconds


• Source Block Size: D x L

• 1-D Column FEC (for Bursty Losses)

– Each column produces a single packet

– Overhead = 1 / D

– L-packet duration should be larger than the (target) burst duration

• 1-D Row FEC (for Random Losses)

– Each row produces a single packet

– Overhead = 1 / L

• 2-D Column + Row FEC

– Overhead = (D+L)/(DxL)

First-Line of Defense in Loss Repair1-D/2-D Parity Forward Error Correction

53

C2 C3C1

XOR

L

FEC Packets

1 2 3

4 5 6

7 8 9

10 11 12

D

XO

R

FE

C P

acketsR1

R2

R3

R4


First-Line of Defense in Loss Repair

• Each TV channel may be associated with one or more FEC streams

– FEC streams may have different repair capabilities

– IP STBs may join the respective multicast sessions to receive FEC stream(s)

• General Remarks FEC scales extremely well with upfront planning, easily repairs spatially correlated losses

Longer outages require larger overhead or larger block sizes (More delay)

FEC requires encoding/decoding operations

1-D/2-D Parity Forward Error Correction

54

STB

STB

Transport &

DistributionAccess

Network

STB

STB

STB

Channel 1

FEC for Channel 1

Aggregation

RouterRTP Source

DSLAM

DSLAM




Second-Line of Defense in Loss Repair

• There is a (logical) feedback target for each TV channel on the retransmission server

– If optional FEC cannot repair missing packets, IP STB sends an RTCP NACK to report missing packets

– Retransmission server pulls the requested packets out of the cache and retransmits them

• General Remarks

Retransmission recovers only the lost packets, so no bandwidth is wasted

Retransmission adds a delay of destination-to-source-to-destination

• Protocol suite comprises RFCs 3550, 4585, 4588 and 5760

RTP Retransmissions

55

STB

STB

Transport &

DistributionAccess

Network

STB

STB

STB

Channel 1

Feedback and retransmissions for Channel 1

Aggregation

RouterRTP Source

DSLAM

DSLAM



Improving Viewer Quality of Experience


TV Viewers Love ZappingResults are Based on 227K+ Users in NA

57

Min 1

Mean 726

Std 814

90th Percentile 1672



Max 24186


Zappings are Correlated in Temporal Domain

3000

4000

5000

6000

7000

8000

0 10 20 30 40 50 60

Nu

mb

er

of

Us

ers

Tu

ne

d

Time (Minutes)

On a Sunday between 8:00 – 9:00 PM

58


Delay Elements in Multicast MPEG2-TS Video

• Multicast Switching Delay

– IGMP joins and leaves

– Route establishment (Generally well-bounded)

• Reference Information Latency

– PSI (PAT/CAT/PMT) acquisition delay

– CAS (ECM) delay

– RAP acquisition delay

• Buffering Delays

– Loss-repair, de-jittering, application buffering

– MPEG decoder buffering

Reference information latency and buffering delays aremore critical in MPEG-based AV applications


Typical Zapping Times on DSL IPTVUnit Time Total Time

IP STB sends IGMP Leave < 100 ms

IP STB sends IGMP Join < 100 ms

DSLAM gets IGMP Leave < 100 ms

DSLAM gets IGMP Join < 100 ms ~ 200 ms

DSLAM switches streams 50 ms ~ 250 ms

Latency on DSL line ~ 10 ms ~ 260 ms

IP STB receives PAT/PMT ~ 150 ms ~ 400 ms

Buffering

De-jittering buffer ~ 150 ms ~ 550 ms

Wait for CA < 50 ms ~ 600 ms

Wait for I-frame 0 – 3 s 0.5 – 3.5 s

MPEG decoding buffer 1 – 2 s 1.5 – 5.5 s

Decoding < 50 ms 1.5 – 5.5 s


M u l t i c a s t D a t aTime

Time the IP STB needs to wait

to start processing multicast data

RAP RAP

A Typical Multicast Join

61

IP STB

(1) Join

RAPs might be far away from each otherRAP data might be large in size and non-contiguous


(2) Unicast retransmission

Concurrent Multicast Join and Retransmission

62

Data the IP STB needs to get

from the retransmission server

(1) Retransmission requestRetransmission

Server


RAP RAP(1) Join

IP STB

If the residual bandwidth remaining from the multicast stream is small,retransmission may not be able to provide any acceleration


Retransmission Followed by Multicast Join

63

Data the IP STB needs to get

from the retransmission server

(3) Join


RAP RAP

(2) Unicast retransmission

(1) Retransmission requestRetransmission

ServerIP STB

More data are retransmitted due to deferred multicast joinHowever, IP STB ultimately achieves a faster acquisition


Proposed Solution

• IP STB says to the retransmission server:

“I have no synch with the stream. Send me a repair burst that will get me back on the track with the multicast session”

• Retransmission server

– Parses data from earlier in the stream and bursts faster than real time

– Coordinates the time for multicast join and ending the burst

• This solution uses the existing toolkit for repairing packet losses

– RFC 3550 (RTP/RTCP)

– RFC 4585 (RTP AVPF)

– RFC 4588 (RTP Retransmissions)

– RFC 5760 (RTCP Extensions for SSM)

Unicast-Based Rapid Acquisition

64


Unicast Burst

Acquisition request for Ch. YD

ow

nstr

eam

Ch

an

nels

So

urc

e

Join Ch. Y

Retr

an

sm

issio

n

Serv

er

IP S

TB

Decoder priming, join time, burst description

Leave Ch. X

Multicast StreamMerge & Discard duplicates

Unicast-Based Rapid Acquisition (RAMS) http://tools.ietf.org/html/rfc6285

65


How to Prime the MPEG Decoder?

• Transport Stream Random Access Point (TSRAP) may include

– PAT: Program Association Table, PMT: Program Map Table

– PCR: Program Clock Reference used to initialize the decoder and STB clocks

– SEQ: Sequence Header (MPEG2 video)

– SPS: Sequence Parameter Set (H.264 video), PPS: Picture Parameter Set (H.264 video)

– ECM: Entitlement Control Messages

http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble

66

MP

EG

2-T

S

for

Channel #8

PAT PAT PAT

PMT PMT

CA CA CA CA

CA CA CA CA

V V V


MPEG Data Cache

for Channel #8

RAP Cache for Channel #8

MPEG2-TS Parser

PAT PMT CA CATSRAP #N

PAT PMT CA CATSRAP #1


Experimental Setup

• Comparison

– One IP STB with non-accelerated channel changes

– One IP STB with accelerated channel changes

• Video Streams

– Encoded with AVC at 2 Mbps and 30 fps• One stream with 15 frames per GoP (Short-GoP)

• One stream with 60 frames per GoP (Long-GoP)

• Transport

– 1356-byte RTP packets (7 TS packets plus RTP/UDP/IPv4 headers)

– 20% additional bandwidth consumption for bursting

– 500 ms loss-repair buffer in each IP STB


Short-GoP Results

68

Min Mean Std 95th 99th Max

Non-accelerated 1323 2785 645 3788 4101 4140

Accelerated 501 1009 260 1345 1457 1965

~65%

Reduction


Long-GoP Results

69

Min Mean Std 95th 99th Max

Non-accelerated 1831 3005 575 3920 4201 4300

Accelerated 536 1013 265 1377 1521 1937

~65%

Reduction


When Acceleration is Disabled

TSRAP Acquisition Delay: Time for IP STB to receive all TS-related information

Channel change times depend on

- The time of zapping request

- The frequency of the TSRAP points

Inconsistent zapping times


When Acceleration is Enabled

Age of TSRAP: Denotes how far TSRAP is behind multicast session when the burst starts

Loss-repair buffer size Loss-repair buffer size + TSRAP period

No correlation

No correlation

Channel change times DO NOT depend on

- The time of zapping request

- The frequency of the TSRAP points

Consistent zapping times


Unicast-Based Rapid Acquisition Reading

72

“Scaling server-based channel-change acceleration to millions of IPTV

subscribers,” Packet Video Wksp. 2012

“Reducing channel-change times with the real-time transport protocol,”

IEEE Internet Computing, May/June 2009


Companion-Stream ApproachThe Basic Idea

73

I I I I

I I

Zapping

High-quality

Multicast Stream

Low-quality

Multicast Stream

Join Splice and leave the multicast session

Continue with Full

High QualityQuality Issues

due to Drift


• VQE-S collects RTCP reports and outputs them to the management application

• Management application– Collects raw data from exporter

– Organizes database– Conducts data analysis, trends– Create alerts

• Management application supports standards-based north-bound interfaces

• Reports and analysis can be granular to– Regions, edge routers– DSLAMs, access lines– Home gateways

– Set-tops

• Set-tops can support RTCP reporting and TR-069 (or TR-135) concurrently

VQE QoS/QoE MonitoringTools to Isolate and Pinpoint the Problematic Locations

74

TCP Export Interface

RTCP Reports

North-bound Interfaces

Web Interface

RTCP Reports


RTCP Sender/Receiver/Extended Reports

• RTCP Sender Reports provide info on data sent recently

– Wallclock time and the corresponding RTP timestamp

– Total number of packets/bytes sent

• RTCP Receiver Reports summarize the reception quality

– Timestamp of (and delay from) the last received sender report

– Highest sequence number seen so far

– Number and fraction of the lost RTP packets

– Estimate of the interarrival jitter

• RTCP Extended Reports (XR) provide

– Detailed transport-level stats

– Application-specific information about RTP transport


Access

Core/Aggregation

Network

Four RTCP Flows, Two RTCP Loops

76

Media Source Media Source

Distribution SourceDistribution Source

Feedback Target

Feedback Target

Source Receivers

Forward control information for lip-synchronization,

to indicate liveness and to identify the source

Feedback Target Receivers

Forward control information to manage feedback rates

Feedback Targets Source

Reception quality reports reporting

quality of the path from source to the

feedback target and summarizing

reception quality for receivers Receivers Feedback Target

Reception quality reports


RTCP XR Framework

• Provides several advantages over traditional and proprietary monitoring solutions

• Easily extensible to report on

– Packet-level loss events/patterns, mean time between losses, loss durations, etc.• Correlation engines identify, characterize and isolate the problems

– Audiovisual reception quality

– Effectiveness of the loss-repair methods• Loss-repair methods can be adapted depending on the network conditions

– Effectiveness of channel change acceleration


RTCP XR Example: Loss RLE Reportshttp://tools.ietf.org/html/rfc5725

78

RTP Receiver

Pre

-repair

Bu

ffe

r

Received/recovered

packets

Post-repair Loss RLEPre-repair Loss RLE

(RFC 3611)

The difference tells us the aggregated

performance of the loss-repair methods

Source and repair dataLoss-repair

Methods

#1, #2, …, #K

Ap

plic

atio

n

Po

st-re

pair

Bu

ffer


Fault Isolation through Network TomographyMonitoring Viewer QoE with No Human Assistance

79

DS

X4

X6X5X3X2

R1 R2 R3 R5 R6 H7 R8

RTP

X1

Aggregated

RTCP

R71 R72

FT2

FT3FT1

RTP

R41 R42

H4

Unicast

RTCP

Unicast

RTCP


Fault Isolation through Network TomographyReading

80

“On the scalability of RTCP-based network tomography for IPTV

services,” IEEE CCNC 2010

“On the use of RTP for monitoring and fault isolation in IPTV,”

IEEE Network, Mar./Apr. 2010

Part II: Internet Video and Adaptive Streaming


Internet Video Essentials

• Reach all connected devicesReach

• Enable live and on-demand delivery to the mass marketScale

• Provide TV-like consistent rich viewer experienceQuality of Experience

• Enable revenue generation thru paid content, subscriptions, targeted advertising, etc.

Business

• Satisfy regulations such as captioning, ratings and parental control

Regulatory


Creating Revenue – Attracting Eye Balls• High-End Content

– Hollywood movies, TV shows

– Sports

• Excellent Quality

– HD/3D/UHD audiovisual presentation w/o artifacts such as pixelization and rebuffering

– Fast startup, fast zapping and low glass-to-glass delay

• Usability

– Navigation, content discovery, battery consumption, trick modes

• Service Flexibility

– Linear TV

– Time-shifted and on-demand services

• Reach

– Any device, any time

• Auxiliary Services

– Targeted advertising, social network integration


• Areas most important to overall TV experience are:

– Content

– Timing control

– Quality

– Ease of use

• While traditional TV surpasses Internet TV only in quality, it delivers better “overall experience”

Internet TV vs. Traditional TV

When comparing traditional and Internet TV, which option is better?

Traditional Internet

Content 7% 79%

Timing / Control 7% 83%

Quality 80% 16%

Ease of Use 23% 52%

Control (FF, etc.) 9% 77%

Portability 4% 92%

Interactivity 31% 52%

Sharing 33% 56%

Overall Experience 53% 33%

Source: Cisco IBSG Youth Survey, Cisco IBSG Youth Focus Group Sessions, 2010

Example Over-the-Top (OTT) Services


The Lines are Blurring between TV and the Web

86

HBO NOW

Comcast XFINITY

AmazonBBC iPlayer

AT&T U-verse Verizon FiOS


HBO GO and HBO NOW

• Subscribers can watch HBO content thru HBO GO service

– First launched in Feb. 2010 with Verizon FiOS

– Later expanded to other provides including AT&T U-Verse, DirecTV, DISH Network, Comcast XFINITY, TWC, etc.

• Starting in April 2015, HBO has been serving consumers directly thru HBO NOW service

Delivery of TV Content to IP-Enabled Devices

87


Netflix

88

Content

Over 100K titles (DVD)

Shipped 1 billionth DVD in 02/07

Shipped 2 billionth DVD in 04/09

Today: HD, 3D and UHD

Revenue

Most recent Quarter: $1.5B in Q1/2015

FY (2014-10): $5.5B, $4.3B, $3.6B, $3.2B, $2.1B

Streaming Subscribers

41.4M (US) by Q1 2015 (20.8M in 40 countries)

[6M DVD subscribers in the US by Oct. 2014]

Competitors

Hulu+, Amazon Prime, HBO GO, HBO NOW

Difficulties

ISP data caps

ISP/CDN throughput limitations

Plans

Unlimited streaming 1-stream plan for $7.99

HD 2-stream plan for $8.99, and 4K 4-stream plan for $11.99

1 DVD out at-a-time for $7.99

Blu-rays for an additional $2 per month (US)

Big Data at Netflix

Library: 3PB

Ratings: 4M/day, searches: 3M/day, plays: 30M/day

5B hours streamed in Q3 2013 (2B in Q4 2011, 3B in Q3 2012)


Netflix’s Expansion to International MarketsRed: Available, Orange: Announced / Coming Soon

89


Comparing Broadcast, Cable and OTT

Source: 7 DEADLY SINS: WHERE HOLLYWOOD IS WRONG ABOUT THE FUTURE OF TV


Hulu• Summary

– Available in the US and Japan

– Ad-supported subscription service business model• 6M+ Hulu Plus subscribers by Q2 2014

– Revenue of $1B (2013), $700M (2012), $420M (2011), $263M (2010), $108M (2009) and $25M (2008)

• Content

– Catch-up TV (60000+ episodes, 2300 TV series)

– 50000+ hours of video

– 430+ content partners

– Encoded at 480, 700, 1000, 2500 and 3200 Kbps

• Devices

– Primarily PC and Mac

– Smartphones and tables (only w/ Hulu Plus)

– Internet-connected TV (only w/ Hulu Plus)


BBC iPlayer

• Statistics for April 2015

– Total Requests

• 218M for TV programs (9% of the requests were for live streams)

• 53M for radio programs (73% of the requests were for live streams)

– Devices

• 31% computers (~), 23% tablets (~), 24% mobile devices (+), 9% TV platform operators (-), %3 game consoles (~)

• Impact of the World Cup 2014: http://www.bbc.co.uk/mediacentre/latestnews/2014/iplayer-performance-pack-july

• Xmas 2014 Surge: iPlayer had the best month on record with 343M requests (264M for TV) in Jan. 2015

Available (Almost) Globally

92

Source: http://downloads.bbc.co.uk/mediacentre/iplayer/iplayer-performance-apr15.pdf


Internet Video (Desktop) in the US

Unique Viewers (x1000)

Google Sites 152,781

Facebook 83,549

Yahoo Sites 55,445

Maker Studios Inc. 43,653

VEVO 43,131

Vimeo 37,365

AOL, Inc. 37,156

Fullscreen 34,200

Comcast NBCUniversal 32,659

CBS Interactive 30,499

Total 191,019

April 2015

93

Source: comScore Video Metrix


Internet Video in the US

Unique Viewers (x1000) Videos (x1000) Minutes per Viewer

Google Sites 155,613 11,069,548 294.0

Facebook 88,424 4,592,878 79.9

AOL, Inc. 69,385 1,314,206 49.5

Yahoo Sites 55,674 579,452 63.1

NDN 50,945 558,226 81.3

Blinkx 43,660 600,692 29.4

Turner Digital 39,765 392,635 53.1

Vimeo 37,975 170,131 33.1

Amazon Sites 37,659 164,205 25.0

AnyClip.com 36,626 437,140 51.0

Total 187,791 46,637,320 1,066.8

April 2014

94



Internet Video in the US

Unique Viewers (x1000) Videos (x1000) Minutes per Viewer

Google Sites 164,819 16,595,857 506.5

Facebook 70,055 1,365,771 33.5

AOL, Inc. 62,273 1,276,425 79.5

NDN 50,555 603,047 86.9

VEVO 49,608 650,227 42.5

Amazon Sites 44,287 191,849 25.6

Yahoo Sites 42,334 357,063 69.5

Microsoft Sites 38,895 697,377 49.6

Vimeo 32,851 131,600 31.1

Maker Studios Inc. 30,475 517,104 62.7

Total 188,976 49,080,851 1,330.1

October 2013

95



Open Digital Media Value Chain

96

Create Content

Aggregate

Monetize

Distribute Content

Consume Content

Any Content Any Storefront Any Network Any Device

CDNsMedia Protocols

Internet Transport

DRMEncoding

EncapsulationDynamic

Ads

Clients

http://images.google.com/imgres?imgurl=http://www.psi.toronto.edu/~inmar/wiml/2008/wiml_images/google_logo.jpg&imgrefurl=http://www.psi.toronto.edu/~inmar/wiml/2008/index.html&usg=__B-dDIDWRlVktnPpyidzoUUYmXlQ=&h=1500&w=3600&sz=277&hl=en&start=1&um=1&itbs=1&tbnid=o78WRIXSFwEmKM:&tbnh=63&tbnw=150&prev=/images?q=google+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.psi.toronto.edu/~inmar/wiml/2008/wiml_images/google_logo.jpg&imgrefurl=http://www.psi.toronto.edu/~inmar/wiml/2008/index.html&usg=__B-dDIDWRlVktnPpyidzoUUYmXlQ=&h=1500&w=3600&sz=277&hl=en&start=1&um=1&itbs=1&tbnid=o78WRIXSFwEmKM:&tbnh=63&tbnw=150&prev=/images?q=google+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://thelinernotes.files.wordpress.com/2009/05/napster.jpg&imgrefurl=http://thelinernotes.wordpress.com/2009/05/&usg=__H19VPJK4-F_gVqNmNByJzOYEsr8=&h=242&w=270&sz=8&hl=en&start=2&um=1&itbs=1&tbnid=ST0w9262OzItTM:&tbnh=101&tbnw=113&prev=/images?q=napster+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://thelinernotes.files.wordpress.com/2009/05/napster.jpg&imgrefurl=http://thelinernotes.wordpress.com/2009/05/&usg=__H19VPJK4-F_gVqNmNByJzOYEsr8=&h=242&w=270&sz=8&hl=en&start=2&um=1&itbs=1&tbnid=ST0w9262OzItTM:&tbnh=101&tbnw=113&prev=/images?q=napster+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.cl.cam.ac.uk/~awm22/research/pic/att_logo.jpg&imgrefurl=http://www.cl.cam.ac.uk/~awm22/research/&usg=__w_Gxiv4PpjPXIh52ToLR1MXnAYM=&h=520&w=900&sz=125&hl=en&start=2&um=1&itbs=1&tbnid=DIdBYZi1xmcSNM:&tbnh=84&tbnw=146&prev=/images?q=att+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.cl.cam.ac.uk/~awm22/research/pic/att_logo.jpg&imgrefurl=http://www.cl.cam.ac.uk/~awm22/research/&usg=__w_Gxiv4PpjPXIh52ToLR1MXnAYM=&h=520&w=900&sz=125&hl=en&start=2&um=1&itbs=1&tbnid=DIdBYZi1xmcSNM:&tbnh=84&tbnw=146&prev=/images?q=att+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://pulse2.com/wp-content/uploads/2009/05/verizon-logo.png&imgrefurl=http://pulse2.com/category/bill-jones/&usg=__qtOPGK6Zqbwmv6UplXs5Mns32kc=&h=312&w=527&sz=43&hl=en&start=2&um=1&itbs=1&tbnid=zSmk85kpdLOFQM:&tbnh=78&tbnw=132&prev=/images?q=verizon+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://pulse2.com/wp-content/uploads/2009/05/verizon-logo.png&imgrefurl=http://pulse2.com/category/bill-jones/&usg=__qtOPGK6Zqbwmv6UplXs5Mns32kc=&h=312&w=527&sz=43&hl=en&start=2&um=1&itbs=1&tbnid=zSmk85kpdLOFQM:&tbnh=78&tbnw=132&prev=/images?q=verizon+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.rpsm-artandwine.info/800px-Comcast_Logo_svg.png&imgrefurl=http://dylan.clancrg.net/lcastdte/?p=167&usg=__me1u5atLc-LOnYt2grFl847UCNk=&h=205&w=800&sz=20&hl=en&start=3&um=1&itbs=1&tbnid=Tu-Wxwox0UwCVM:&tbnh=37&tbnw=143&prev=/images?q=comcast+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.rpsm-artandwine.info/800px-Comcast_Logo_svg.png&imgrefurl=http://dylan.clancrg.net/lcastdte/?p=167&usg=__me1u5atLc-LOnYt2grFl847UCNk=&h=205&w=800&sz=20&hl=en&start=3&um=1&itbs=1&tbnid=Tu-Wxwox0UwCVM:&tbnh=37&tbnw=143&prev=/images?q=comcast+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://i.zdnet.com/blogs/sprint_logo_color.jpg&imgrefurl=http://blogs.zdnet.com/gadgetreviews/?p=9004&usg=__okawZP-C4993whW0xgCzN1HM8Vo=&h=1021&w=2052&sz=77&hl=en&start=1&itbs=1&tbnid=Ogvgmy0giqF8EM:&tbnh=75&tbnw=150&prev=/images?q=sprint+logo&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://i.zdnet.com/blogs/sprint_logo_color.jpg&imgrefurl=http://blogs.zdnet.com/gadgetreviews/?p=9004&usg=__okawZP-C4993whW0xgCzN1HM8Vo=&h=1021&w=2052&sz=77&hl=en&start=1&itbs=1&tbnid=Ogvgmy0giqF8EM:&tbnh=75&tbnw=150&prev=/images?q=sprint+logo&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://3lcell.com/images/t_mobile_logo.jpg&imgrefurl=http://3lcell.com/&usg=__7N2N2u61YypNneLffFQqjTOvUN4=&h=376&w=1268&sz=25&hl=en&start=1&itbs=1&tbnid=C-8ojSWD5p_hfM:&tbnh=44&tbnw=150&prev=/images?q=tmobile+logo&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://3lcell.com/images/t_mobile_logo.jpg&imgrefurl=http://3lcell.com/&usg=__7N2N2u61YypNneLffFQqjTOvUN4=&h=376&w=1268&sz=25&hl=en&start=1&itbs=1&tbnid=C-8ojSWD5p_hfM:&tbnh=44&tbnw=150&prev=/images?q=tmobile+logo&gbv=2&hl=en

http://www.rogers.com/web/Rogers.portal?_nfpb=true&_pageLabel=Home

http://www.rogers.com/web/Rogers.portal?_nfpb=true&_pageLabel=Home

http://images.google.com/imgres?imgurl=http://www.networkcommunications.com.au/userimages/Lg Logo.gif&imgrefurl=http://www.networkcommunications.com.au/page.php?intid=24&usg=__G4jfiSTIpPal3bFVzEJtn4fANuY=&h=312&w=618&sz=63&hl=en&start=1&um=1&itbs=1&tbnid=QkrsoJIiWVZknM:&tbnh=69&tbnw=136&prev=/images?q=lg+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://www.networkcommunications.com.au/userimages/Lg Logo.gif&imgrefurl=http://www.networkcommunications.com.au/page.php?intid=24&usg=__G4jfiSTIpPal3bFVzEJtn4fANuY=&h=312&w=618&sz=63&hl=en&start=1&um=1&itbs=1&tbnid=QkrsoJIiWVZknM:&tbnh=69&tbnw=136&prev=/images?q=lg+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://itsnothingserious.files.wordpress.com/2009/07/sony-logo.jpg&imgrefurl=http://itsnothingserious.wordpress.com/2009/07/06/sony-what-the-heck-man/&usg=__8DXxPD6d0-t54ND6O4SSGyD7jsk=&h=422&w=1756&sz=27&hl=en&start=1&um=1&itbs=1&tbnid=smt_xPJ1Kt0UBM:&tbnh=36&tbnw=150&prev=/images?q=sony+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://itsnothingserious.files.wordpress.com/2009/07/sony-logo.jpg&imgrefurl=http://itsnothingserious.wordpress.com/2009/07/06/sony-what-the-heck-man/&usg=__8DXxPD6d0-t54ND6O4SSGyD7jsk=&h=422&w=1756&sz=27&hl=en&start=1&um=1&itbs=1&tbnid=smt_xPJ1Kt0UBM:&tbnh=36&tbnw=150&prev=/images?q=sony+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://mediaatlantic.files.wordpress.com/2009/05/xbox360-logo.jpg&imgrefurl=http://mediaatlantic.wordpress.com/2009/05/29/xbox-joins-forces-with-sky-%E2%80%93-could-this-signal-the-end-for-set-top-boxes/&usg=__iNyuaFuD8xlN5oaCu8zGzGyoZ1I=&h=495&w=800&sz=41&hl=en&start=1&um=1&itbs=1&tbnid=hgvZR3RMAP0q_M:&tbnh=88&tbnw=143&prev=/images?q=xbox+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://mediaatlantic.files.wordpress.com/2009/05/xbox360-logo.jpg&imgrefurl=http://mediaatlantic.wordpress.com/2009/05/29/xbox-joins-forces-with-sky-%E2%80%93-could-this-signal-the-end-for-set-top-boxes/&usg=__iNyuaFuD8xlN5oaCu8zGzGyoZ1I=&h=495&w=800&sz=41&hl=en&start=1&um=1&itbs=1&tbnid=hgvZR3RMAP0q_M:&tbnh=88&tbnw=143&prev=/images?q=xbox+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://pulse2.com/wp-content/uploads/2009/12/dell-logo.jpg&imgrefurl=http://pulse2.com/2009/12/09/dell-makes-6-5-million-in-sales-through-twitter/&usg=__7gXx_ngHqLHOMrm1J1qU5o_QgZQ=&h=314&w=320&sz=26&hl=en&start=2&um=1&itbs=1&tbnid=A8R_g31lWlNacM:&tbnh=116&tbnw=118&prev=/images?q=dell+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://pulse2.com/wp-content/uploads/2009/12/dell-logo.jpg&imgrefurl=http://pulse2.com/2009/12/09/dell-makes-6-5-million-in-sales-through-twitter/&usg=__7gXx_ngHqLHOMrm1J1qU5o_QgZQ=&h=314&w=320&sz=26&hl=en&start=2&um=1&itbs=1&tbnid=A8R_g31lWlNacM:&tbnh=116&tbnw=118&prev=/images?q=dell+logo&hl=en&um=1

http://images.google.com/imgres?imgurl=http://ceoworld.biz/ceo/wp-content/uploads/2009/03/nokia-logo.bmp&imgrefurl=http://ceoworld.biz/ceo/tag/nokia&usg=__q5hnZNPwJmndiKhsv9qzFyCL55U=&h=315&w=628&sz=580&hl=en&start=1&itbs=1&tbnid=qRuBYh9PCjM8BM:&tbnh=69&tbnw=137&prev=/images?q=nokia+logo&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://ceoworld.biz/ceo/wp-content/uploads/2009/03/nokia-logo.bmp&imgrefurl=http://ceoworld.biz/ceo/tag/nokia&usg=__q5hnZNPwJmndiKhsv9qzFyCL55U=&h=315&w=628&sz=580&hl=en&start=1&itbs=1&tbnid=qRuBYh9PCjM8BM:&tbnh=69&tbnw=137&prev=/images?q=nokia+logo&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://pcwin.com/media/images/screen/Websmartz_Website_Builder_2171.jpg&imgrefurl=http://pcwin.com/Multimedia___Design/Flash_Tools/Websmartz_Website_Builder/screen.htm&usg=__8WER437MSNFbM-YsJWtTjhUGwUg=&h=480&w=640&sz=236&hl=en&start=4&itbs=1&tbnid=4IYjraFgr_DMuM:&tbnh=103&tbnw=137&prev=/images?q=website&gbv=2&hl=en






Media Delivery over the Internet


Push and Pull-Based Video Delivery

Push-Based Delivery Pull-Based Delivery

Source Broadcasters/servers like

Windows Media

Apple QuickTime, RealNetworks Helix

Cisco VDS/DCM

Web/FTP servers such as

LAMP

Microsoft IIS

Adobe Flash

RealNetworks Helix

Cisco VDS

Protocols RTSP, RTP, UDP HTTP, RTMPx, FTP

Video Monitoring and

User Tracking

RTCP for RTP transport (Currently) Proprietary

Multicast Support Yes No

Caching Support No Yes for HTTP


Time (s)

DESCRIBE rtsp://example.com/mov.test RTSP/1.0

SETUP rtsp://example.com/mov.test/streamID=0 RTSP/1.03GPP-Adaptation:url=“rtsp://example.com/mov.test/streamID=0”;size=20000;target-time=50003GPP-Link-Char: url=“rtsp://example.com/mov.test/streamID=0”; GBW=32

SDP

PLAY rtsp://example.com/mov.test RTSP/1.0

RTP

RTCP Reports

RTSP OK

RTSP OK

Client BufferClient Buffer Model

Sessio

n S

etu

pS

tream

ing

Push-Based Video Delivery over RTSP3GPP Packet-Switched Streaming Service (PSS)

99


Pull-Based Video Delivery over HTTP

• Server sends a file as fast as possible

• Client starts playout after a certain initial buffering

Progressive Download

• Server paces file transmission

• Client can seek

• Some metadata is required

Pseudo Streaming

• Client requests small chunks enabling adaptation

• Live streaming and dynamic ads are supported

Adaptive Streaming

Progressive Download vs. Pseudo and Adaptive Streaming

100


Progressive DownloadOne Request, One Response

101

HTTP Request

HTTP Response


What is Streaming?

102

Streaming is transmission of a continuous content from a server

to a client and its simultaneous consumption by the client

Two Main Characteristics

1. Client consumption rate may be limited by real-time constraints as opposed

to just bandwidth availability

2. Server transmission rate (loosely or tightly) matches to client consumption

rate


Common Annoyances in StreamingStalls, Slow Start-Up, Plug-In and DRM Issues

Adaptive Streaming over HTTP



• Imitation of Streaming via Short Downloads

– Downloads desired portion in small chunks to minimize bandwidth waste

– Enables monitoring consumption and tracking clients

• Adaptation to Dynamic Conditions and Device Capabilities

– Adapts to dynamic conditions anywhere on the path through the Internet and/or home network

– Adapts to display resolution, CPU and memory resources of the client

– Facilitates “any device, anywhere, anytime” paradigm

• Improved Quality of Experience

– Enables faster start-up and seeking (compared to progressive download), and quicker buffer fills

– Reduces skips, freezes and stutters

• Use of HTTP

– Well-understood naming/addressing approach, and authentication/authorization infrastructure

– Provides easy traversal for all kinds of middleboxes (e.g., NATs, firewalls)

– Enables cloud access, leverages existing HTTP caching infrastructure (Cheaper CDN costs)

Adapt Video to Web Rather than Changing the Web

105


Multi-Bitrate Encoding and Representation Shifting

106

Contents on the Web Server

Movie A – 200 Kbps

Movie A – 400 Kbps

Movie A – 1.2 Mbps

Movie A – 2.2 Mbps

. . .

. . .

Movie K – 200 Kbps

Movie K – 500 Kbps

Movie K – 1.1 Mbps

Movie K – 1.8 Mbps

. . .

. . .

Time (s)

Start quickly

Keep requesting

Improve quality

Loss/congestion detection

Revamp quality

. . .

. . .

Segments



107

…………

HTTP GETs

Media BufferDecoding and

Presentation

HTTP

Server

Streaming

Client


Example Representations

108

Encoding

Bitrate

Resolution

Rep. #1 3.45 Mbps 1280 x 720

Rep. #2 2.2 Mbps 960 x 540

Rep. #3 1.4 Mbps 960 x 540

Rep. #4 900 Kbps 512 x 288

Rep. #5 600 Kbps 512 x 288

Rep. #6 400 Kbps 340 x 192

Rep. #7 200 Kbps 340 x 192

Source: Vertigo MIX10, Alex Zambelli’s Streaming Media Blog, Akamai

Vancouver 2010 Sochi 2014

Encoding

Bitrate

Resolution

Rep. #1 3.45 Mbps 1280 x 720

Rep. #2 1.95 Mbps 848 x 480

Rep. #3 1.25 Mbps 640 x 360

Rep. #4 900 Kbps 512 x 288

Rep. #5 600 Kbps 400 x 224

Rep. #6 400 Kbps 312 x 176

Encoding

Bitrate

Resolution

Rep. #1 3.45 Mbps 1280 x 720

Rep. #2 2.2 Mbps 1024 x 576

Rep. #3 1.4 Mbps 768 x 432

Rep. #4 950 Kbps 640 x 360

Rep. #5 600 Kbps 512 x 288

Rep. #6 400 Kbps 384 x 216

Rep. #7 250 Kbps 384 x 216

Rep. #8 150 Kbps 256 x 144

FIFA 2014


An Example Manifest FormatList of Accessible Segments and Their Timings

109

MPD

Period id = 1start = 0 s

Period id = 3

start = 300 s

Period id = 4

start = 850 s

Period id = 2

start = 100 s

Adaptation Set 0subtitle turkish

Adaptation Set 2audio english

Adaptation Set 1BaseURL=http://abr.rocks.com/

Representation 2

Rate = 1 Mbps

Representation 4

Rate = 3 Mbps

Representation 1

Rate = 500 Kbps

Representation 3

Rate = 2 Mbps

Resolution = 720p

Segment Info

Duration = 10 s

Template:

3/$Number$.mp4

Segment Access

Initialization Segmenthttp://abr.rocks.com/3/0.mp4

Media Segment 1

start = 0 shttp://abr.rocks.com/3/1.mp4

Media Segment 2

start = 10 shttp://abr.rocks.com/3/2.mp4

Adaptation Set 3audio german

Adaptation Set 1video

Period id = 2

start = 100 s

Representation 3

Rate = 2 Mbps

Selection of components/tracks

Well-defined media format

Selection of representations

Splicing of arbitrary content like ads

Chunks with addresses and timing


Smart Clients

110

Client manages

- Manifest(s)

- HTTP transport

- TCP connection(s)

Client monitors/measures

- Playout buffer

- Download times and throughput

- Local resources (CPU, memory, screen, etc.)

- Dropped frames

Client performs adaptation

Request

Response


Microsoft Smooth Player Showing Adaptationhttp://www.iis.net/media/experiencesmoothstreaming

111


Example Request and Response

• Client sends an HTTP request– GET 720p.ism/QualityLevels(572000)/Fragments(video=160577243) HTTP/1.1

• Server 1. Finds the MP4 file corresponding to the requested bitrate

2. Locates the fragment corresponding to the requested timestamp

3. Extracts the fragment and sends it in an HTTP response

Microsoft Smooth Streaming

112

Fil

e T

yp

e (

ftyp

)

Movie Metadata(moov)

Movie Fragment Random Access(mfra)

Fragment

Mo

vie

Fra

gm

en

t(m

oo

f)

Me

dia

Da

ta

(md

at)

Fragment

Mo

vie

Fra

gm

en

t(m

oo

f)

Me

dia

Da

ta

(md

at)


Initial and Current Players in the Market• Move Adaptive Stream (Now Echostar)

– http://www.movenetworks.com

• Microsoft Smooth Streaming

– http://www.iis.net/expand/SmoothStreaming

• Apple HTTP Live Streaming

– http://tools.ietf.org/html/draft-pantos-http-live-streaming

– http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/

• Netflix

– http://www.netflix.com

• Adobe HTTP Dynamic Streaming

– http://www.adobe.com/products/httpdynamicstreaming/

• bitmovin

– bitdash: http://dash-player.com/


Where does the Market Stand Today? Fragmented!

114

Codecs

- H.264 (Standard)

- HEVC (Coming soon)

- WebM (Hype?)

- VC-1 (Dead)

DRM *

Microsoft PlayReady -

Adobe Flash Access -

Marlin -

NDS VGC -

Clients

- iOS/Android devices

- HTML5 browsers

- Connected TVs

- Game consoles

Protocols

Apple HLS -

Microsoft Smooth -

Adobe HDS -


• Fragmented architectures

– Advertising, DRM, metadata, blackouts, etc.

• Investing in more hardware and software

– Increased CapEx and OpEx

• Lack of consistent analytics

• Preparing and delivering each asset in several incompatible formats

– Higher storage and transport costs

• Confusion due to the lack of skills to troubleshoot problems

• Lack of common experience across devices for the same service

– Tricks, captions, subtitles, ads, etc.

What does This Mean?

Higher Costs

Less Scalability

Smaller Reach

Frustration

Skepticism

Slow Adoption


More Details Later…

116

DASH intends to be to

the Internet world …

what MPEG2-TS has been to

the broadcast world


Adaptive Streaming is not w/o Its Problems10 Microsoft Smooth Clients Competing on a 10 Mbps Link

117

10 Mbps


10 Microsoft Smooth Clients Competing on a 10 Mbps Link

0

200

400

600

800

1000

1200

1400

0 100 200 300 400 500

Bit

rate

(K

bp

s)

Time (s)

Client1 Client2 Client3

Streaming “Big Buck Bunny” (Three Clients are Shown)

118

Wide-Range Shifts

Changes in resolution

Changes in quality

Available Representations: 300, 427, 608, 866, 1233, 1636, and 2436 Kbps

Attend BRKSPV-2999Adaptive Streaming Deployments: Challenges and Solutions


End-to-End Over-the-Top Adaptive Streaming DeliveryAttend BRKSPV-2160

120

Production Preparation and Staging Distribution Consumption

News

Gathering

Sport Events

Premium

Content

Studio

Multi-bitrate

Encoding

Encapsulation

ProtectionOrigin Servers

VoDContent &Manifests

LiveContent &Manifests

CDN


Adaptive Streaming Content Workflow

121

Source Transcoding Encapsulation EncryptionOrigin

Server

HelperDistribution

Client

Linear: Multicast

VoD: FTP, WebDAV, etc.

Unicast HTTP PUSH,

WebDAV, FTP, etc.

HTTP GET small objects

Single highest-bitrate

streamMultiple streams at

target bitrates

Multiple streams at

target encapsulation formats

Large video/virtual

files and manifests

MPEG DASH Standard


Where We were

123

Source: http://xkcd.com/927/


MPEG – Dynamic Adaptive Streaming over HTTP

• Goal

– Develop an international, standardized, efficient solution for HTTP-based streaming of MPEG media

• Some Objectives

– Do the necessary, avoid the unnecessary

– Be lazy: reuse what exists in terms of codecs, formats, content protection, protocols and signaling

– Be backward-compatible (as much as possible) to enable deployments aligned with existing proprietary technologies

– Be forward-looking to provide ability to include new codecs, media types, content protection, deployment models (ad insertion, trick modes, etc.) and other relevant (or essential) metadata

– Enable efficient deployments for different use cases (live, VoD, time-shifted, etc.)

– Focus on formats describing functional properties for adaptive streaming, not on protocols or end-to-end systems or implementations

– Enable application standards and proprietary systems to create end-to-end systems based on DASH formats

– Support deployments by conformance and reference software, implementation guidelines, etc.

A New Standard: ISO/IEC 23009

124


CfT Issued Apr. 2010

18 Responses and Working Draft (WD)

July 2010

Committee Draft (CD)

Oct. 2010

Draft International

Standard (DIS)

Jan. 2011

Final Draft International

Standard

Nov. 2011

Published as International

Standard

Apr. 2012

ISO/IEC 23009-1 Timeline

• Other Relevant Specifications– 14496-12: ISO Base Media File Format

– 14496-15: Advanced Video Coding (AVC) File Format

– 23001-7: Common Encryption in ISO-BMFF

– 23001-8: Coding-Independent Code Points

– 23001-10: Carriage of Timed Metadata Metrics of Media in ISO Base Media File Format

Fastest time ever that a standard was developed in MPEG to address the demand of the market


Scope of MPEG DASHShown in Red

126

HTTP Server DASH Client

Control Engine

Me

dia

En

gin

es

HTTP ClientHTTP 1.1

Segment

ParserMPD TransportMPD

Parser

MPDMPD

MPD

. . .

. . .

. . .


Major Functional Components – Data Model• Provide information to a client, where and when to find the data that composes A/V MPD

• Provide the ability to offer a service on the cloud and HTTP-CDNs HTTP-URLs and MIME Types

• Provide service provider the ability to combine/splice content with different properties into a single media presentation Periods

• Provide service provider to enable the client/user selection of media content components based on user preferences, user interaction device profiles and capabilities, using conditions or other metadata Adaptation Sets

• Provide ability to provide the same content with different encodings (bitrate, resolution, codecs) Representations

• Provide extensible syntax and semantics for describing representation/adaptation set properties Descriptors

• Provide ability to access content in small pieces and do proper scheduling of access Segments and Subsegments

• Provide ability for efficient signaling and deployment optimized addressing Playlist, Templates, Segment Index

• Provide ability to enable reuse of existing encapsulation and parsing tools MPEG2-TS and ISO-BMFF


Major Functional Components – Timing

• Common Media Presentation Time

– Provide ability to present content from different adaptation sets synchronously

– Provide ability to support seamless switching across different representations

• Switching Support Features

– Signaling of Stream Access Points

– Segment Alignment to avoid overlap downloading and decoding

• Playout Times per Segment and Track Fragment Decode Times

– Provide ability to randomly access and seek in the content

• Segment Availability Time

– Mapped to wall-clock time

– Expresses when a segment becomes available on the server and when ceases it to be available

– Provide ability to support live and time-shift buffer services with content generated/removed on the fly


Major Functional Components – Operations• Provide ability for personalized access to media presentation, e.g. targeted advertisement MPD

Assembly with xlink

• Provide ability to provide redundant content offering Multiple Base URLs

• Provide ability to announce unforeseen/unpredictable events in live services MPD Updates

• Provide ability to send events associated with media times In-band and MPD-based Event Messages

• Provide the ability to log and report client actions DASH Metrics

• Provide ability to efficiently support trick modes Dedicated IDR-frame Representations and Sub-representations

• Provide ability to signal collection of a subset/extension of tools Profiles and Interoperability Points


ISO/IEC 23009 Parts

• 23009-1: Media Presentation Description and Segment Formats

– 2nd edition has been published

– 1st amendment (high profile and availability time synchronization)

– 2nd amendment (spatial relationship description, generalized URL parameters, etc.)

– 3rd amendment (authentication, MPD linking, callback event, period continuity, etc.)

• 23009-2: Conformance and Reference Software

– 1st edition has been published

– WD for 2nd edition is in progress (w15221)


ISO/IEC 23009 Parts

• 23009-3: Implementation Guidelines

– 1st edition is done, will be published soon

– 2nd edition is in progress

– 1st amendment is in progress

• 23009-4: Segment Encryption and Authentication

– Published by ISO in 2013

• 23009-5: Server and Network Assisted DASH (SAND)

– WD is in w15226

• 23009-6: DASH over Full Duplex HTTP-based Protocols (FDH)

– WD is in w15220


Ongoing Work in MPEG DASH (as of MPEG 111)• Currently Running Core Experiments

– Server and Network Assisted DASH

– DASH over Full Duplex HTTP-based Protocols

– URI Signing for DASH

– SAP-independent Segment Signaling

– Content Aggregation and Playback Control

• Technologies under Consideration

– Support for 3DV with Depth (Pending file format discussions)

– Support for Controlled Playback in DASH (moving to CE)

– Descriptive Information Label for Adaptation Set and Representation

– Simplified On-demand Multi-period Content

– On Use of HTTP Headers

– Start-up Representations

– Trick Mode Support

– On HTTP Caches, CDN and Media Origin (Part 3)

– Service-level Service Protection Using Segment Encryption


Organizations Working on DASH• MPEG DASH

– http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

– Mailing List: http://lists.uni-klu.ac.at/mailman/listinfo/dash

• DASH Industry Forum

– http://dashif.org

• 3GPP PSS and DASH

– http://ftp.3gpp.org/specs/html-info/26234.htm

– http://ftp.3gpp.org/specs/html-info/26247.htm

• DECE – UltraViolet

– http://www.uvvu.com/

• HbbTV (Hybrid Broadcast Broadband TV)

– http://www.hbbtv.org/pages/about_hbbtv/specification.php

• Digital TV Group (DTG)

– http://www.dtg.org.uk/publications/books.html

• Digital Video Broadcasting (DVB)

– http://www.dvb.org


Various Stats about Market Shares

75%

25%

10%

5%5%

Encoding.com (Global Media Format Report 2015)

HLS Smooth Streaming Wowza DASH HDS

63%

17%

9%

5%4%

JW Player (Trends in Online Video 2014)

PD HLS and HDS WebM RTMP FLV


Summary

• Part I: IPTV

– IPTV – Architecture, Protocols and SLAs

– Video Transport in the Core Networks

– Video Distribution in the Access Networks

– Improving Viewer Quality of Experience

• Part II: Internet Video and Adaptive Streaming

– Example Over-the-Top (OTT) Services

– Media Delivery over the Internet

– Adaptive Streaming over HTTP

– MPEG DASH Standard


Participate in the “My Favorite Speaker” Contest

• Promote your favorite speaker through Twitter and you could win $200 of Cisco Press products (@CiscoPress)

• Send a tweet and include

– Your favorite speaker’s Twitter handle

– Two hashtags: #CLUS #MyFavoriteSpeaker

• You can submit an entry for more than one of your “favorite” speakers

• Don’t forget to follow @CiscoLive and @CiscoPress

• View the official rules at http://bit.ly/CLUSwin

Promote Your Favorite Speaker and You Could Be a Winner

136

http://bit.ly/CLUSwin


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.

• Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect.

137


Continue Your Education

• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Table Topics

• Meet the Engineer 1:1 meetings

• Related sessions

138

Thank you

Further Reading and References



• Overview Articles– “Not all packets are equal, part I: streaming video coding and SLA requirements,” IEEE Internet Computing, Jan./Feb.

2009

– “Not all packets are equal, part II: the impact of network packet loss on video quality,” IEEE Internet Computing, Mar./Apr. 2009

– “Deploying diffserv in backbone networks for tight SLA control,” IEEE Internet Computing, Jan./Feb., 2005

• Special Issues– EURASIP Signal Processing: Image Communication (August 2011)

– IEEE Network (March 2010)

– IEEE Transactions on Broadcasting (June 2009)

– IEEE Internet Computing (May/June 2009)

– IEEE Communications Magazine (Multiple issues in 2008)

IPTV Basics – Architecture, Protocols and SLAs

141



• Overview Articles– “Toward lossless video transport,” IEEE Internet Computing, Nov./Dec. 2011

– “Designing a reliable IPTV network,” IEEE Internet Computing, May/June 2009

• Standards and Specifications– http://tools.ietf.org/html/rfc2475

– http://tools.ietf.org/html/rfc2205



Video Transport in the Core Networks

142



• Overview Articles– “Error control for IPTV over xDSL networks,” IEEE CCNC 2008

– “IPTV service assurance,” IEEE Communications Magazine, Sept. 2006

– “DSL spectrum management standard,” IEEE Communications Magazine, Nov. 2002

• Standards and Specifications– “Asymmetric digital subscriber line (ADSL) transceivers,” ITU-T Rec. G.992.1, 1999

– http://www.dvb.org/technology/standards/index.xml#internet






Video Distribution in the Access Networks

143



• Overview Articles– “Scaling server-based channel-change acceleration to millions of IPTV subscribers,” Packet Video Wksp. 2012

– “Reducing channel-change times with the real-time transport protocol,” IEEE Internet Computing, May/June 2009

– “On the scalability of RTCP-based network tomography for IPTV services,” IEEE CCNC 2010

– “On the use of RTP for monitoring and fault isolation in IPTV,” IEEE Network, Mar./Apr. 2010

• Standards and Specifications– http://www.broadband-forum.org/technical/download/TR-126.pdf

– https://www.atis.org/docstore/product.aspx?id=22659

• Open Source Implementation for VQE Clients– Documentation

• http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_6/user_guide/VQE_3_6.html

– FTP Access• ftp://ftpeng.cisco.com/ftp/vqec/

Improving Viewer Quality of Experience

144



• SCTE Standards– SCTE 30: Digital Program Insertion Splicing API

– SCTE 35: Digital Program Insertion Cueing Message for Cable

– SCTE 130: Digital Program Insertion – Advertising Systems Interfaces

– URL: http://www.scte.org/standards/Standards_Available.aspx

Targeted Advertising

145



• Light Reading: Cisco Put to the Video Test– http://www.lightreading.com/document.asp?doc_id=177692&site=cdn

• EANTC Experience Provider Mega Test – http://www.cisco.com/en/US/solutions/ns341/eantc_megatest_results.html

• IPTV & Digital Video QoE: Test & Measurement Update– http://www.heavyreading.com/insider/details.asp?sku_id=2382&skuitem_itemid=1181

Industry Tests

146



• Overview Articles

– “Watching video over the Web, part 2: applications, standardization, and open issues,” IEEE Internet Computing, May/June 2011

– “Watching video over the Web, part 1: streaming protocols,” IEEE Internet Computing, Mar./Apr. 2011

• VideoNext Workshop in ACM CoNEXT 2014

– http://conferences2.sigcomm.org/co-next/2014/Workshops/VideoNext/

• Special Issue on Adaptive Media Streaming

– IEEE JSAC – Apr. 2014

• Special Session in Packet Video Workshop 2013

– Technical program and slides: http://pv2013.itec.aau.at/

• Special Sessions in ACM MMSys 2011

– Technical program and slides: at http://www.mmsys.org/?q=node/43

– VoDs of the sessions are available in ACM Digital Library• http://tinyurl.com/mmsys11-proc (Requires ACM membership)

• W3C Web and TV Workshops

– http://www.w3.org/2013/10/tv-workshop/

– http://www.w3.org/2011/09/webtv

– http://www.w3.org/2010/11/web-and-tv/

Adaptive Streaming

147



• DASH Industry Forum– http://dashif.org/software/

• Open Source Implementations/Frameworks– http://dash.itec.aau.at/

– http://gpac.wp.mines-telecom.fr/

– https://github.com/bitmovin/libdash

– https://github.com/google/shaka-player

• Microsoft Media Platform: Player Framework– http://playerframework.codeplex.com/

• Adobe OSMF– http://sourceforge.net/adobe/osmf/home/Home/

• JW Player– https://github.com/jwplayer/jwplayer

Source Code for Adaptive Streaming Implementations

148



• DASH– http://dash-mse-test.appspot.com/dash-player.html

– http://dashif.org/reference/players/javascript/index.html

– https://github.com/google/shaka-player

• Akamai HD Network– http://wwwns.akamai.com/hdnetwork/demo/flash/default.html

– http://wwwns.akamai.com/hdnetwork/demo/flash/hds/index.html

– http://wwwns.akamai.com/hdnetwork/demo/flash/hdclient/index.html

– http://bit.ly/testzeri

• Microsoft Smooth Streaming– http://www.iis.net/media/experiencesmoothstreaming

– http://www.smoothhd.com/

• Adobe OSMF– http://blogs.adobe.com/osmf/

• Apple HTTP Live Streaming (Requires QuickTime X or iOS)– http://devimages.apple.com/iphone/samples/bipbopall.html

• bitdash– http://www.dash-player.com/

Adaptive Streaming Demos

149

IPTV and Over-the-Top Video · IPTV and Over-the-Top Video: ... Super Headend (SHE) Video Hub Office (VHO) Regional Headend (RHE) ... Internet Core Network HFC.

Documents