Scalable Media Delivery on the Web with HTTP Server Push

Total Page:16

File Type:pdf, Size:1020Kb

Scalable Media Delivery on the Web with HTTP Server Push Scalable media delivery on the Web with HTTP Server Push Presentation to W3C Web5G Workshop 10th May 2018 Lucas Pardue Scalable media delivery on the Web with HTTP Server Push Motivation Life for broadcasters used to be simple… • Broadcasting from a terrestrial transmitter has a fixed cost. • The cost doesn’t depend on how many people tune in. The Internet doesn’t work like this! Source: BBC Scalable media delivery on the Web with HTTP Server Push The iPlayer service keeps getting more popular • Usage of the BBC iPlayer service is climbing steadily. • 272M on-demand programmes requested per month in 2017. • First episode of Blue Planet II was requested 4.8M times. • CDNs charge per byte delivered by the edge cache. The cost of providing the service rises in proportion to its popularity. Scalable media delivery on the Web with HTTP Server Push On-demand viewing is gaining ground… • For the main TV channels in the UK, live viewing …but linear viewing still dominates represents only 85% of consumption. • The remaining 15% is DVR time-shifting, 85% downloading and on- demand streaming. • Time-shifting works best for genres like drama, 15% comedy, entertainment and documentary. But linear viewing still plays a major role for news, sport and big events. Source: BARB Scalable media delivery on the Web with HTTP Server Push Linear television is still popular for big events • The BBC’s biggest streaming event to date was England vs. Wales in Euro 2016 England vs. Wales the Euro 2016 (2016-06-16) 9,300,000 competition. 10,000,000 Super Bowl 52 (2018-02-04) 8,000,000 • 2.3M simultaneous users. 6,000,000 120,000,000 103,400,0 00 4,000,000 2,300,000 • About 20% of total peak. 2,000,000 100,000,000 0 • Super Bowl 52 was iPlayer BBC One 80,000,000 (Live peak) (Live peak) watched by nearly fifty 60,000,000 Source: Radio Times times as many viewers. 40,000,000 • Streaming represented only 3% of total audience. 20,000,000 3,100,000 The potential audience for 0 Internet streaming Live broadcast linear streaming is huge and (peak) (average) scary. Source: AdWeek; USA Today Scalable media delivery on the Web with HTTP Server Push There are more and more bits to shift! • Higher spatial resolution (SD, HD, UHD). • Improved colour fidelity (High Dynamic Range). • Better motion depiction (Higher Frame Rate). Not to mention: • New content experiences (3D, 360° Video, AR, VR). • Next Generation Audio. All this keeps driving up our CDN distribution costs. Scalable media delivery on the Web with HTTP Server Push Cellular is biting at our heels • MNOs are hungry and have deep pockets. • 800 MHz band auctioned in 2013 for 4G. • 700 MHz band due to be auctioned soon for 5G. • 3GPP has developed a technology stack called MBMS for media streaming over cellular UHF Band V UHF Band VI radio networks. 470 MHz 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 854 MHz 2013 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 X X X X X X X X Our ability to innovate in 790 MHz 2020 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 X X X X X X X X X X X X X X X X X X X X 694 MHz 700 MHz Band auction 800 MHz Band auction the broadcast space is now hampered by lack of available spectrum. Scalable media delivery on the Web with HTTP Server Push The challenge • How to reach 98% of the UK population without any terrestrial spectrum. 10×audience To put that into perspective: • The last Royal Wedding 5×encoded bit rate (April 2011) attracted a total UK live audience of more than 25M across all = distribution modes. Even if CDNs could deliver to that size of audience, we probably couldn’t afford to 50×load pay for it. Scalable media delivery on the Web with HTTP Server Push Scalable media delivery on the Web with HTTP Server Push What about IP multicast? Media streaming over IP multicast • Layer 3 packet replication reduces redundant transfer. • Particularly well suited for large scale audiences. • A great way to address the scalability challenge. • IPTV is deployed around the world today and is supporting pay TV services. • Specified by DVB and published as ETSI TS 102 034. • Works well for managed networks / vertical deployments. • 3GPP also makes use of IP multicast for its Multicast/Broadcast Multimedia Service (MBMS). Scalable media delivery on the Web with HTTP Server Push Media streaming over HTTP • Industry has embraced unicast HTTP-based streaming. • Enables delivery over many types of access network (managed and unmanaged), to many types of end-user equipment. • This is the basis of myriad over-the-top (OTT) Internet streaming services including the BBC iPlayer. • Success driven by use of existing network technologies and Content Delivery Networks (CDN). Scalable media delivery on the Web with HTTP Server Push Adaptive media streaming over unicast HTTP • Divide media stream into short duration segments. • Each segment is encoded at several bit rates. • Client-side adaptation between these encodings, to suit local network conditions. • Graceful changes with respect to network degradation or improvement. • Several proprietary streaming technologies exist: • Microsoft Smooth Streaming. • Adobe HDS. • Apple HLS. • Industry aligning toward MPEG-DASH. Scalable media delivery on the Web with HTTP Server Push Standardisation of adaptive media streaming over IP multicast • CableLabs specification for ABR Multicast on CATV networks. • 3GPP MBMS specification for enhanced television (enTV) on cellular mobile networks. • DVB specification on adaptive media streaming over IP multicast. • Commercial requirements driven by use cases. • Technical work undertaken by TM-IPI ABR Multicast task force led by Richard Bradbury, BBC R&D. • DVB BlueBook A176, released March 2018. Scalable media delivery on the Web with HTTP Server Push DVB reference architecture for adaptive media • Abstract reference, functions and streaming over IP multicast interfaces. • Implementations may CP metrics RPM capture combine multiple functions in a single deployable unit. RCP RS Provisioning • Conventional unicast case CP Network C Control CP control • Unicast-to-multicast and CMR CMS Multicast App back again P ′ in gateway Multicast server M Content preparation Oin L • Maintains technical Pin U′ M compatibility with existing Content Content Playback playback control hosting Unicast A U reception equipment. repair A B Scalable media delivery on the Web with HTTP Server Push CP metrics RPM capture • The Multicast server ConversionRCP between multicast and unicast in the RS function converts from data plane Provisioning unicast (Oin) to multicast CP Network C Control CP control (M) at the sending end. CMR CMS • The Multicast gateway Multicast App Pin′ function performs the gateway Multicast server M inverse conversion from Content preparation Oin L Pin multicast back to unicast. U′ M • This is presented to the Content Content Playback playback control hosting Unicast A U Content playback repair A function via reference point L. B • This is a conventional MPEG-DASH player. Scalable media delivery on the Web with HTTP Server Push Deployment model 1: Multicast gateway • Terminal device supports deployed in terminal device reception of IP multicast • e.g. MBMS Client in mobile phone. Network Home Terminal device • Multicast gateway and edge gateway device device Content playback CMR functions all in the RS Multicast terminal device. L M gateway Content Playback • Relies on support for control App U playback multicast in the core A network. B Scalable media delivery on the Web with HTTP Server Push Deployment model 2: Multicast gateway • Multicast gateway located on Customer Premises deployed in home gateway device Equipment • e.g. home router supplied by the ISP. Network Home gateway device Terminal device edge device • Multicast gateway can CMR serve several users in the RS Multicast same home network. L M gateway Content Playback • Suited more to fixed line control App U playback deployments. A B Scalable media delivery on the Web with HTTP Server Push Deployment model 3: Multicast gateway • Multicast gateway deployed in a network deployed in network edge device edge device. • e.g. MEC server node. Network edge device Home Terminal device • Multicast gateway can gateway device serve several users in the CMR same network service RS Multicast area. L M gateway Content Playback • e.g. all mobiles within a control App U playback cluster of cell sites. A • Suitable when terminal B device cannot receive IP multicast. • All traffic on access network is unicast. Scalable media delivery on the Web with HTTP Server Push HTTP over multicast QUIC • An independent Internet Draft that fills some gaps between IP unicast and multicast. • Based on a new transport protocol called QUIC. • Describes a means of service discovery using HTTP Alternative Services [RFC 7838]. • Bulk file delivery that intentionally supports a broad range of Use Cases. https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/ Scalable media delivery on the Web with HTTP Server Push Scalable media delivery on the Web with HTTP Server Push Server Push for unidirectional HTTP flows HTTP/2 • IETF RFC 7540 published in 2015. • Maintains existing HTTP semantics… HTTP • Request/response. • Metadata (Header fields) and payload.
Recommended publications
  • IP Multicast Routing Technology Overview
    IP Multicast Routing Technology Overview • Information About IP Multicast Technology, on page 1 • Additional References for IP Multicast, on page 15 Information About IP Multicast Technology This section provides information about IP multicast technology. About IP Multicast Controlling the transmission rate to a multicast group is not supported. At one end of the IP communication spectrum is IP unicast, where a source IP host sends packets to a specific destination IP host. In IP unicast, the destination address in the IP packet is the address of a single, unique host in the IP network. These IP packets are forwarded across the network from the source to the destination host by devices. At each point on the path between source and destination, a device uses a unicast routing table to make unicast forwarding decisions, based on the IP destination address in the packet. At the other end of the IP communication spectrum is an IP broadcast, where a source host sends packets to all hosts on a network segment. The destination address of an IP broadcast packet has the host portion of the destination IP address set to all ones and the network portion set to the address of the subnet. IP hosts, including devices, understand that packets, which contain an IP broadcast address as the destination address, are addressed to all IP hosts on the subnet. Unless specifically configured otherwise, devices do not forward IP broadcast packets, so IP broadcast communication is normally limited to a local subnet. IP multicasting falls between IP unicast and IP broadcast communication. IP multicast communication enables a host to send IP packets to a group of hosts anywhere within the IP network.
    [Show full text]
  • WAN-LAN PIM Multicast Routing and LAN IGMP FEATURE OVERVIEW and CONFIGURATION GUIDE
    Technical Guide WAN-LAN PIM Multicast Routing and LAN IGMP FEATURE OVERVIEW AND CONFIGURATION GUIDE Introduction This guide describes WAN-LAN PIM Multicast Routing and IGMP on the LAN and how to configure WAN-LAN PIM multicast routing and LAN IGMP snooping. The AlliedTelesis Next Generation Firewalls (NGFWs) can perform routing of IPv4 and IPv6 multicast, using PIM-SM and PIM-DM. Also, switching interfaces of the NGFWs are IGMP aware, and will only forward multicast steams to these switch ports that have received reports. IGMP snooping allows a device to only forward multicast streams to the links on which they have been requested. PIM Sparse mode requires specific designated routers to receive notification of all streams destined to specific ranges of multicast addresses. When a router needs to get hold of a given group, it sends a request to the designated Rendezvous Point for that group. If there is a source in the network that is transmitting a stream to this group, then the Rendezvous Point will be receiving it, and will forward it to the requesting router. C613-22042-00 REV A alliedtelesis.com x Products and software version that apply to this guide Contents Introduction.............................................................................................................................................................................1 Products and software version that apply to this guide .......................................................................2 Configuring WAN-LAN PIM Multicast Routing and LAN IGMP Snooping........................................3
    [Show full text]
  • Seamless Handover for Unidirectional Broadcast Access Networks in Mobile Ipv6
    46 JOURNAL OF COMMUNICATIONS, VOL. 2, NO. 6, NOVEMBER 2007 Seamless Handover For Unidirectional Broadcast Access Networks In Mobile IPv6 Ilka Miloucheva, Jens Mödeker, Karl Jonas Fraunhofer Institute, Schloss Birlinghoven, Sankt Augustin, Germany Email: {ilka.miloucheva, jens.moedeker, karl.jonas}@fokus.fraunhofer.de Dirk Hetzer T-Systems, Goslarer Ufer, Berlin, Germany Email: [email protected] Abstract-- Mechanisms and protocol interactions for - Intelligent access network selection for mobile nodes seamless handover of mobile multicast/broadcast services in converged heterogeneous infrastructures. using unidirectional access networks in heterogeneous Recent standardization efforts focused on multimedia Mobile IP infrastructures are discussed and proposed. QoS services and applications, such as IPDatacast [2] and based applications, such as content delivery, mobile TV, DIMS [3], are aimed to support convergence of carousel and reliable downloads, requiring interaction channel, are considered, as well as recent standardization unidirectional broadcast and Mobile IP services. efforts for converged broadcast and mobile IP Different architectures have been proposed for cost infrastructures. The proposed mechanisms are aimed to efficient support of content delivery, mobile TV and other support handover of interactive mobile services using interactive mobile multicast applications using broadcast unidirectional broadcast media (DVB-H) combined with media. bidirectional mobile access technologies (UMTS, WLAN, Examples are hybrid broadcast
    [Show full text]
  • Introduction to IP Multicast Routing
    Introduction to IP Multicast Routing by Chuck Semeria and Tom Maufer Abstract The first part of this paper describes the benefits of multicasting, the Multicast Backbone (MBONE), Class D addressing, and the operation of the Internet Group Management Protocol (IGMP). The second section explores a number of different algorithms that may potentially be employed by multicast routing protocols: - Flooding - Spanning Trees - Reverse Path Broadcasting (RPB) - Truncated Reverse Path Broadcasting (TRPB) - Reverse Path Multicasting (RPM) - Core-Based Trees The third part contains the main body of the paper. It describes how the previous algorithms are implemented in multicast routing protocols available today. - Distance Vector Multicast Routing Protocol (DVMRP) - Multicast OSPF (MOSPF) - Protocol-Independent Multicast (PIM) Introduction There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire subnetwork. A multicast address is designed to enable the delivery of datagrams to a set of hosts that have been configured as members of a multicast group in various scattered subnetworks. Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same “best-effort” reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. The only difference between a multicast IP packet and a unicast IP packet is the presence of a “group address” in the Destination Address field of the IP header.
    [Show full text]
  • IP Multicast
    Data Communication & Networks G22.2262-001 Session 10 - Main Theme IP Multicast Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Agenda Introduction to Multicast Multicast Addresses IP Multicast Reliable Multicast Pragmatic General Multicast (PGM) Reliable Multicast Protocol (RMP) Conclusion 2 Part I Introduction to Multicast 3 Cast Definitions Unicast - send to one destination (198.122.15.20) General Broadcast - send to EVERY local node (255.255.255.255) Directed Broadcast - send to subset of nodes on LAN (198.122.15.255) Multicast - send to every member of a Group of “interested” nodes (Class D address). RFC 1112 (an easy read!) 4 Why Multicast, Why Not Unicast? Unicast: Many applications require same message sent to many nodes (10, 100, 1000, n) Same message transits network n times. n messages requires n*(CPU time) as 1 message Need to deliver “timely” information. Message arrives at node n >> node 1 5 Why Multicast, Why Not Broadcast? Broadcast: Send a copy to every machine on the net Simple, but inefficient All nodes “must” process the packet even if they don’t care Wastes more CPU cycles of slower machines (“broadcast radiation”) General broadcast cannot be routed Directed broadcast is limited in scope (to machines on same sub-net or same domain) 6 Multicast Applications News/sports/stock/weather updates Software distribution Video-conferencing, shared whiteboards Distributed interactive gaming or simulations Email distribution lists Database replication 7 IP Multicast - Concepts Message sent to multicast “group” of receivers Senders need not be group members Each group has a “group address” Groups can have any size End-stations (receivers) can join/leave at will Data Packets are UDP (uh oh!) 8 IP Multicast Benefits Distribution tree for delivery/distribution of packets (i.e., scope extends beyond LAN) Tree is built by multicast routing protocols.
    [Show full text]
  • Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 2: Logical Link Control (LLC)
    Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 2: Logical Link Control (LLC) DVB Document A116-2 June 2016 3 Contents Contents .............................................................................................................................................................. 3 Intellectual Property Rights ................................................................................................................................ 5 Foreword............................................................................................................................................................. 5 Introduction ........................................................................................................................................................ 6 1 Scope ........................................................................................................................................................ 8 2 References ................................................................................................................................................ 8 2.1 Normative references ......................................................................................................................................... 8 2.2 Informative references ....................................................................................................................................... 9 3 Symbols and abbreviations ....................................................................................................................
    [Show full text]
  • Junos Multicast Routing (JMR)
    Junos Multicast Routing (JMR) Junos Multicast Routing (JMR) Engineering Simplicity COURSE LEVEL COURSE OVERVIEW Junos Multicast Routing (JMR) is an advanced-level This two-day course is designed to provide students with detailed coverage of multicast course. protocols including Internet Group Management Protocol (IGMP), Protocol Independent Multicast-Dense Mode (PIM-DM), Protocol Independent Multicast-Sparse Mode (PIM- SM), Bidirectional PIM, and Multicast Source Discovery Protocol (MSDP). AUDIENCE Through demonstrations and hands-on labs, students will gain experience in configuring and monitoring the Junos OS and monitoring device and protocol This course benefits individuals responsible for implementing, monitoring, and troubleshooting operations. This course utilizes Juniper Networks vMX Series devices for the hands-on multicast components in a service provider’s component, but the lab environment does not preclude the course from being applicable to other Juniper hardware platforms running the Junos OS. The Juniper Networks vMX network. Series devices run Junos OS Release 16.2R1.6. PREREQUISITES Students should have basic networking knowledge OBJECTIVES and an understanding of the Open Systems • Describe IP multicast traffic flow. Interconnection (OSI) model and the TCP/IP • Identify the components of IP multicast. protocol suite. Students should also have working knowledge of security policies. • Explain how IP multicast addressing works. • Describe the need for reverse path forwarding (RPF) in multicast. Students should also attend the Introduction to the • Explain the role of IGMP and describe the available IGMP versions. Junos Operating System (IJOS) and Junos • Configure and monitor IGMP. Intermediate Routing (JIR) courses prior to • Identify common multicast routing protocols. attending this class. • Explain the differences between dense-mode and sparse-mode protocols.
    [Show full text]
  • Ipv6 Segment Routing for Multicast @ Comcast
    IPv6 Segment Routing for Multicast @ Comcast John Jason Brzozowski IETF 96 LISP WG Why? • Because of the topology and relative volume of traffic compared to unicast; there is no benefit to running IP Multicast in the Backbone/Regional area networks – RAN is a hub and spoke architecture: multicast traffic needs to be on all links to the hubs receiving it – BB is a sparse topology with multiple Tb/s links • Multicast is a significant burden on - vendor silicon/code/testing – Comcast multi-vendor interoperability testing and Operations (estimates of 20% of silicon for bus/fabric chips) • Multicast is an obvious, very beneficial choice to move out of the Underlay Network and into x86, Software and Application control Simplicity • The IPv6 header has the capability of adding Option Headers for specific functions – The Segment Routing Header (SRH) is one; it is only processed if the Router is the destination of the packet being processed – The function of the header is very similar to the Loose Source Route (LSR) function in IPv4; the intermediate IPV6 addresses are SID’s – There was an original Option Header defined in IPv6 for this function that was deprecated; SR brings back the function with a new Option Header definition. IPv6 SR SUPPORT IS NOT REQUIRED BY ANY ROUTER/SWITCH/DEVICE not identified as a SID!!! IPv6 SR Solution Source and CMTS support SR x86 x86 Source X::1 Packet: Source X::1 DC/BB/CRAN Dest Y::1 SRH SID1 FF:/8 Packet on CMTS recv: Network Provides Recognize last SID Unicast Path Protection Move SID to Dest Bit set to strip SRH CMTS recognizes IPV6 CMTS: Y::1 CMTS multicast dest and CMTS process MLD forwards as a normal Joins as normal multicast originated locally Clients send MLD Packet: Joins as normal Source X::1 Dest FF:/8 Multicast Address: FF:/8 IPv6 SR Solution One Source, Multiple CMTS support x86 x86 Source X::1 DC/BB/CRAN Network Provides Unicast Path Protection CMTS Y::4 CMTS CMTS Y::1 CMTS CMTS Y::3 CMTS CMTS Y::2 CMTS.
    [Show full text]
  • Design Guide For: Streaming
    Crestron Electronics, Inc. Streaming Design Guide Crestron product development software is licensed to Crestron dealers and Crestron Service Providers (CSPs) under a limited non-exclusive, non transferable Software Development Tools License Agreement. Crestron product operating system software is licensed to Crestron dealers, CSPs, and end-users under a separate End-User License Agreement. Both of these Agreements can be found on the Crestron website at www.crestron.com/legal/software_license_agreement. The product warranty can be found at www.crestron.com/warranty. The specific patents that cover Crestron products are listed at patents.crestron.com. Crestron, the Crestron logo, Capture HD, Crestron Studio, DM, and DigitalMedia are trademarks or registered trademarks of Crestron Electronics, Inc. in the United States and/or other countries. HDMI and the HDMI logo are either trademarks or registered trademarks of HDMI Licensing LLC in the United States and/or other countries. Hulu is either a trademark or registered trademark of Hulu, LLC in the United States and/or other countries. Netflix is either a trademark or registered trademark of Netflix, Inc. in the United States and/or other countries. Wi-Fi is either a trademark or registered trademark of Wi-Fi Alliance in the United States and/or other countries. Other trademarks, registered trademarks, and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Crestron disclaims any proprietary interest in the marks and names of others. Crestron is not responsible for errors in typography or photography. This document was written by the Technical Publications department at Crestron.
    [Show full text]
  • Streaming Multicast Video Over Software-Defined Networks Kyoomars Alizadeh Noghani, M
    Streaming Multicast Video over Software-Defined Networks Kyoomars Alizadeh Noghani, M. Oğuz Sunay Özyeğin University, Department of Computer Science and Electrical Engineering, 34794 Istanbul, Turkey [email protected], [email protected] Abstract—Many of the video streaming applications in today's the multicast tree between a source and all its subscribers Internet involve the distribution of content from a CDN source to using a control application running on the logically centralized a large population of interested clients. However, widespread SDN-controller that has a global network view. The support of IP multicast is unavailable due to technical and programmable nature of SDN allows for immediate economical reasons, leaving the floor to application layer deployability, scalability, adaptability, and updatability - traits multicast which introduces excessive delays for the clients and all previously associated with ALM and not IP multicast. In increased traffic load for the network. This paper is concerned this paper, we present an IP multicast application running on with the introduction of an SDN-based framework that allows the SDN controller that also keeps track of the subscription the network controller to not only deploy IP multicast between a source and subscribers, but also control, via a simple northbound activities via a simple northbound interface and illustrate its interface, the distributed set of sources where multiple- performance advantage. description coded (MDC) video content is available. We observe IP Multicast is an ideal approach to mitigate the traffic load that for medium to heavy network loads, relative to the state-of- generated by streaming video services. A more efficient the-art, the SDN-based streaming multicast video framework delivery of the video packets reduces the congestion increases the PSNR of the received video significantly, from a probability in the network, which in turn improves the level that is practically unwatchable to one that has good quality.
    [Show full text]
  • Multicast for Enterprise Video Streaming
    WHITE PAPER MULTICAST FOR ENTERPRISE VIDEO STREAMING Protocols and Design Guide This document provides a network equipment neutral, technical overview of multicast protocols and a discussion of techniques and best practices for implementing multicast video on an Enterprise Network. CONTENTS VIDEO STREAMING ON IP NETWORKS �������������������������4 Multicast on Enterprise Networks ��������������������������5 Multicast Addressing ������������������������������5 Multicast on Layer 2 �������������������������������7 IGMP �������������������������������������7 IGMP Snooping ��������������������������������7 Example �����������������������������������8 Multicast on Layer 3 �������������������������������9 PIM �������������������������������������9 PIM Sparse Mode (PIM-SM) ���������������������������9 Multicast Session Example ���������������������������� 11 Other Relevant Network Configurations ���������������������� 13 Spanning Tree �������������������������������� 13 Storm Control �������������������������������� 13 IMPLEMENTING MULTICAST VIDEO STREAMING ������������������� 14 Network Preparation ������������������������������ 14 Best Practices �������������������������������� 14 Scenario 1 Enterprise IPTV ��������������������������� 16 Best Practices �������������������������������� 16 MULTICAST FOR ENTERPRISE VIDEO STREAMING | WHITE PAPER | © 2015 HARMAN | v.01.2015 Page 2 of 38 Scenario 2 Room Overflow ���������������������������� 17 Best Practices �������������������������������� 17 Scenario 3 Non-Routed Multicast �������������������������
    [Show full text]
  • DVB); Generic Stream Encapsulation (GSE); Part 1: Protocol
    ETSI TS 102 606-1 V1.2.1 (2014-07) TECHNICAL SPECIFICATION Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 1: Protocol 2 ETSI TS 102 606-1 V1.2.1 (2014-07) Reference RTS/JTC-DVB-338-1 Keywords broadcasting, DVB ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]