EBU Networks 2008 Report FINAL Tcm6 62796

1

© EBU Networks 2008 Seminar / 23 - 24 June 2008 Reproduction prohibited without written permission of the EBU Technical Department & EBU International Training

Network Technology Seminar 2008 "Media Networks in Action"

EBU, Geneva, 23 and 24 June 2008

organized with EBU Network Technology Management Committee (NMC)

Report Jean-Noël Gouyet, EBU International Training

Revised and proof-read by the speakers

2


Opening round table…………………………………………………………………………………4

1 IP and MPLS ................................................................................................................ 6

1.1 Concepts and protocols ................................................................................................ 6

1.2 Traffic engineering ........................................................................................................ 7

1.3 Video over IP - Maintaining QoS ................................................................................... 8

1.4 Practical application ...................................................................................................... 9

2 Audio Contribution over IP ...................................................................................... 10

2.1 The ACIP standard - A tutorial .................................................................................... 10

2.2 Implementing and testing ACIP using open source software ...................................... 11

2.3 Interoperability in action .............................................................................................. 13

2.4 Demos ........................................................................................................................ 14

3 Video contribution over IP ....................................................................................... 15

3.1 Video contribution over IP – The EBU project group N/VCIP ...................................... 15

3.2 Real-time transport of television using JPEG2000 ...................................................... 16

3.3 France 3's new contribution network over IP ............................................................... 17

4 HD over Networks ..................................................................................................... 18

4.1 HD contribution codecs ............................................................................................... 18

4.2 Practical thoughts and wishes… or whishful thinking! ................................................. 19

4.3 Eurovision experience in HD contribution ................................................................... 20

5 Real world applications: the News .......................................................................... 21

5.1 The use of COFDM for ENG applications ................................................................... 21

5.2 Getting News to base, or 'Only connect'? ................................................................... 22

5.3 How to connect your Video Journalists (VJ) ................................................................ 22

6 Real world applications - Production and Broadcast ............................................. 23

6.1 Architecting a fully-networked production environment ............................................... 23

6.2 Bringing the BBC's networks into the 21st century ....................................................... 25

6.3 DVB-H small gap fillers: home repeaters improving indoor coverage .......................... 26

List of abbreviations and acronyms………………………………………………………..……28 Table 1: Towards lossless video transport - Deployment scenarios……………………………………….35 Table 2: Practical measurement and practical network performance………………………………...……37 Table 3: HD contribution codecs……………………………………………………………………………….39 Table 4: The ovewhelming crowd of networks worldwide!......................................................................41

3


Notice

This report is intended to serve as a reminder of the presentations for those who came to the seminar, or as an introduction for those unable to be there. So, please feel free to forward this report to your colleagues! It is not a transcription of the lectures, but a summary of the main elements of the sessions. The tutorial-like presentations and tests results are more detailed. The speakers‟ presentations are available on the following EBU FTP site via browser: ftp://uptraining:[email protected] The slides number [in brackets] refer to the slides of the corresponding presentation.

To help "decode" the abbreviations and acronyms1 used in the presentations' slides or in this report, a list is

provided at the end of this report. Web links are provided in the report for further reading. Many thanks to all the speakers and session chairmen who revised the report draft. Special thanks to Peter Calvert-Smith (Siemens), Andrea Metz (IRT) and Martin Turner (BBC), who kindly allowed us to use their personal presentation notes (§ 1.2 - § 2.2 - § 5.2). Nathalie Cordonnier, project manager, and Corinne Sancosme (EBU International Training) made the final revision and editing. The Networks 2005 / 2006 / 2007 seminar reports are still available on the EBU Web site: http://www.ebu.ch/CMSimages/en/NMC2005report_FINAL_tcm6-40551.pdf http://www.ebu.ch/CMSimages/en/EBU_2006_Networks_Report_tcm6-45920.pdf http://www.ebu.ch/CMSimages/en/EBU-Networks2007-Report_tcm6-53489.pdf

1 More than 325!

ftp://uptraining:[email protected]/

http://www.ebu.ch/CMSimages/en/NMC2005report_FINAL_tcm6-40551.pdf

http://www.ebu.ch/CMSimages/en/EBU_2006_Networks_Report_tcm6-45920.pdf

http://www.ebu.ch/CMSimages/en/EBU-Networks2007-Report_tcm6-53489.pdf

4


Opening round table - strategic opportunities and issues

Rhys LEWIS, Chief Enterprise Architect, Technology Direction Group, BBC and Chairman of the EBU Network Technology Management Committee "The strongest Networks seminar programme I've seen!"… with NMC members and session chairmen: Chris CHAMBERS (BBC), Mathias COINCHON (EBU), Lars JONSSON (SR), Marc LAMBEREGHS (EBU) and Anders NYBERG (SVT). The opening 'round table' answered the question: 'What are the strategic opportunities and issues posed for broadcasters by developments in network technology?' It also highlighted some of the work going on in the EBU to address these challenges. Strategic opportunities tend to break into:

either do the same old things but better and/or cheaper

or, do new things.

The use of IP (Internet Protocol) supports:

Production based on file transfer. It nowadays represents the bulk of the Broadcast work and requires massive resources at the storage side and at the network level.

On-demand delivery

New and cheaper ways of covering sports and other events and of connecting to foreign correspondents. For

example, SVT Swedish Radio by using Audio over IP (AoIP) for Ice Hockey championships2 has gained in the

order of 10 000 euros for 1-2 week transmission, compared to the cost of ISDN, while keeping good or even better audio quality in stereo.

Offering more universality, with a lot of applications around IP, more flexibility and possibly lower costs in the long term.

New solutions for the Eurovision and Euroradio satellite path, without forgetting that the EBU fiber betwork based on DTM offers a good QoS (quality of service) for audio and video transmissions

The issues facing EBU members: Making it work… well!

Standards and Inter-operability

o Standards for managing the devices attached to the network3 and ease adding equipment to the network. It becomes a nightmare to manage hundreds of them, with various proprietary APIs. But a lot of manufacturers are not so much interested in those particular areas of standards. o Some of the standards, e.g. Audio over IP (AoIP), which are released are not 'certified'. The challenge is to define the minimum requirements, to keep the standard as simple as possible in order to be adopted by all manufacturers and implemented in the right way. It's then a constant effort to verify, to organise plug tests, workshops, to improve inter-operability.

QoS

Many EBU members have trouble when they order IP networked solutions. They expect a given QoS specified in the contract and later note different performances in real operational conditions. There is an issue of speaking the same language between broadcasters and the networks operators, and also of having the right way to measure the QoS and to define it in a Service Level Agreement (SLA) in the contract. A new EBU project group, N/IPM, is in charge of defining the good measurement methods. Keeping it work!

Security & Business continuity

o We still don't have the same reliability with IP as we had in the old system, but it's constantly improving. This is an ongoing process - we are testing new equipment and end units, doing research and measurements on various types of IP networks. o Some concerns about 'having too many eggs in a single technology basket'. A lot of work to do to make sure we don't have a sudden collapse of the entire network. Network engineering can ensure business continuity and it has to be looked throughinto.

2 cf. § 2.3

3 cf. EBU Networks2006 seminar report § 2.1and § 2.2 and EBU Networks2005 seminar report § 2.2 and § 2.3

5


Evolution of the Internet

o The Internet may change. Traffic shaping, for example, can affect us. There may be also some tariff on the Internet - if one day I can't download as many Gigabytes as I want, it will change our way of watching programmes. o And what will come after IP? Which technology will it be and what are we missing today?

"Technology is our word for something that doesn't quite work yet" (Danny Hillis, Douglas Adams). New network technology is something that we have, which offers us a lot of opportunites but that don't quite work yet with many challenges to ensure the expected performance, in a number of environments for a number of different reasons. One of the role of the EBU Network Management Committee is to help to make it work, and this seminar should contribute.

6


1 IP and MPLS

IP and MPLS has been the network technology hailed as the method of delivering high QoS media services across both metro and wide area networks for some years now. This first session explores both the theory and the practicalities of actually trying to achieve the business needs of the broadcast and production markets when using this network protocol along with the lessons learned up to now. (Reminder from the Networks 2007 seminar report § 3.3) MPLS is short for Multiprotocol Label Switching, an IETF initiative that integrates Layer 2 information about network links (bandwidth, latency, utilization) into Layer 3 (IP) in order to improve IP-packet exchange. MPLS gives network operators a great deal of flexibility to divert and route traffic around link failures, congestion, and bottlenecks. It has been developed since 1999. It is complex to operate and configure for the service provider, but is simple as a "data socket" on the wall for the user. The main features of MPLS are:

The MPLS Integrated Services (IntServ) "explicit routing" allows to manually create individual tunnels, taking different paths through the network, for different types of application data.

If fast rerouting (FRR) is necessary, either end-to-end back-up tunnels (created manually before the failure occurs) are automatically switched over globally ("global repair"), or backup tunnels are automatically created for each segment of the primary tunnel and switched locally ("local repair").

Differentiated Services (DiffServ) and DiffServ-Aware Traffic Engineering offers a dynamic path selection using OSPF (Open Shortest Path First), the network knowing globally about available resources.

1.1 Concepts and protocols

Thomas KERNEN, Cisco4, Switzerland

This presentation focuses on techniques to minimise network based outages. First, what are the video Service Level Agreement (SLA) requirements?

Throughput: requirement addressed through capacity planning and QoS (i.e. Diffserv).

Jitter: important for studio quality content. The delay variation is absorbed by the receiver buffer, which has to be minimised in order to improve responsivity, especially in contribution environment. It is controlled with Diffserv, a mature technology known to offer ~ <1msec network induced jitter end-to-end.

Latency: important mainly for live or conversational 2-way content.

Service Availability: the proportion of time for which the specified throughput is available within the bounds of the defined delay and loss - a compound of the other networks and core network availability.

Packet Loss: extremely important. One lost packet may contain up to 7 MPEG Packetized Elementary Stream packets. For example [9], with a 12-frame GOP (and a I:P:B data size ratio of 7:3:1), the I-frame loss probability varies from 30 % to 100 % for an outage duration from 50 ms to around 400 ms. Controlling loss is the main challenge. The 4 primary causes for packet losses are:

o Excess delay: renders media packets essentially lost beyond an acceptable bound. Can be prevented with appropriate QoS (i.e., Diffserv). o Congestion: considered a catastrophic case, i.e. a fundamental failure of service. Must be prevented with appropriate QoS and admission control. o Physical-Layer errors: apply to core (less occurence) and access. Assumed insignificant compared to losses due to network failures. o Network reconvergence: occur at different scales based on topology, components and traffic. Can be eliminated with high availability (HA) techniques.

The core impairment contributors are: Trunk failures ( .0010 / 2 h) + Hardware failures ( .0003 / 2 h) + Software failures ( .0012 / 2 h) + Software upgrades / Maintenance ( .0037 / 2 h) = a total of .0062 Impairements / 2 hours i.e. 1 impairment every two weeks. Note that the average mean time between errors on a DSL line is in the order of

4 http://www.cisco.com/

http://www.cisco.com/

7


minutes if no protection is applied, and that calculations across several Service Providers show a mean time between core failures affecting video is greater than 100 hours. The impact of outage can be reduced but requires smart engineering. Aiming at lossless video transport, the following deployment scenarios can be implemented, classified in Figure 1 in terms of lossless or not, of cost and complexity of network design and deployment and application infrastructure. The corresponding techniques are detailed in the Table 1 (Annex).

Figure 1: Deployment scenarios for lossless video transport

Multi-Topology Routing (MTR)

+

Live / Live

Lossless 1 GOP Impacted

No

netw

ork

Re-e

ng

ineeri

ng

Netw

ork

Re-e

ng

ineeri

ng

Muticast-only Fast Reroute

+

Live / Live

Fast Convergence

Muti-Protocol Label Switching (MPLS)

Traffic Engineering (TE)

Fast Reroute (FRR)


(MoFRR)

Traffic Engineering

+

Live / Live

MPLS TE FRR

+

FEC or Temporal Redundancy

Fast Convergence

+


Increasing Loss

Increasing Cost and Complexity

Multi-Topology Routing (MTR)

+

Live / Live

LosslessLossless 1 GOP Impacted1 GOP Impacted

No

netw

ork

Re-e

ng

ineeri

ng

No

netw

ork

Re-e

ng

ineeri

ng

Netw

ork

Re-e

ng

ineeri

ng

Netw

ork

Re-e

ng

ineeri

ng


+

Live / Live

Fast Convergence

Muti-Protocol Label Switching (MPLS)

Traffic Engineering (TE)

Fast Reroute (FRR)


(MoFRR)

Traffic Engineering

+

Live / Live

MPLS TE FRR

+


Fast Convergence

+


Increasing Loss

Increasing Cost and Complexity

1.2 Traffic engineering

Peter Calver-Smith, Siemens IT Solutions and Services5, UK

The aim is to deliver a glitch-free, resilient and reliable media stream with minimal latency running over networks shared with unpredictable business data traffic. Of the many requirements for an IP media circuit, these have been found critical to the successful implementations:

Fixed IP latency

Low IP jitter

Practically zero IP packet loss and reordering.

Minimum overall latency.

The fundamental means of meeting this requirement in IP is Quality of Service (QoS). Traffic is segregated by setting QoS levels, either at the router port or in the coder. Our practice is to set the QoS at the router port to protect the integrity of the network. The broadcast media traffic and VolP traffic are both given a QoS setting which is labelled Expedited Forwarding (EF). Table 2 (Annex) presents the experience of broadcasting engineers regarding the practical measurement [5]-[12] of key parameters and the practical network performance [14]-[20].

The lessons learnt

It is cutting edge technology. The Broadcasters use of IP networks for streaming with low latency (and also for large media file transfer) is very different from “normal IT” e.g. MS office, Web browsing.

Interoperability is important – Hence EBU N/ACIP (§ 2) and N/VCIP (§ 3)

5 5 www.siemens.co.uk/it-solutions http://www.siemens.com/index.jsp?sdc_p=c0u2m0p0

http://www.siemens.co.uk/it-solutions

http://www.siemens.com/index.jsp?sdc_p=c0u2m0p0

8


IP router and broadcast experts need to work together in the design and testing of equipment and systems. IP measurement is not refined for media use, hence the new EBU N/IPM project group started 1 April 2008.

How to install media IP network

Plan your network: Physical layer, Capacity, VLANs / ACLs / Address ranges

Know your IP network equipment: Codecs, Switches, Routers, etc.

Know your Telco and its equipment

Know and inform your users (operators…) that Audio and Video over IP has limitations

Test off-line – you will find out the limitations without prejudicing service

Ensure the network is very well managed and “clean”

Ensure a QoS structure is set and maintained

Use good planning and change control6 to add or change codecs and network structure.

Monitor the network for unauthorised additions.

1.3 Video over IP - Maintaining QoS

Jeremy DUJARDIN, VP Engineering, Genesis, U.S.A.

Genesis Networks7 provides end-to-end video transmission solutions to world Broadcasters, combining Video over IP, fiber optic [8] and satellite-based technologies, with over 170 Points of Presence in more than 20 countries and connections to 17 teleports worldwide [7]. It has a network architecture built on a highly reliable Layer 2 Ethernet infrastructure overlaid onto underlying capacity, large multi-Gigabit network support from the edges of the network, multiple layers of service protection including route & nodal diversity using MPLS, and multiple carriers networks for added resiliency.

IRIS8 is the software enabling customer control over remote bandwidth provisioning, point-to-multipoint routing and

transmission scheduling. It provides the user with real time monitoring, alarming and fault reporting [6]-[7]. The challenge brought by video broadcasting is to maintain the QoS with the stress of a relatively small number of flows but with large bandwidth requirements (from 2 Mbit/s up to 1.5 Gbit/s). If all IP networks are not created equally, most IP Networks are designed for many simultaneous connections, with low bandwidth requirements per stream,. i.e. 100 000 and more IP flows, each under 1Mbit/s. There are two major components to manage QOS on any network:

Classification of traffic and ensuring it is carried through the entire network

Bandwidth management, ensuring no oversubscription of high priority flows.

In order to classify and prioritize traffic, different items are available at (Figure 2 -top):

Layer 2 (Data Link) : VLAN tags, MAC adresses

Layer 3 (Network): Source IP, Destination IP, Source Port, Destination Port, Type of Service (TOS) bits. TOS flags (4 bits) in the IP Header allow prioritization and classification of traffic on a per service basis, give the most flexibility, and are supported by most video codec manufacturers in each IP flow. The classes of network service available are: Normal/Low delay, Normal/High throughput, Normal/High reliability, Normal/Minimize monetary cost.

But what is 'inside the cloud', through the rest of the network (Figure 2 - bottom)? The IP flow is connection-oriented: series of packets are transmitted based on source and destination addresses. After a router looks up the first packet, the route is pushed to the line cards, in the hardware tables along with the appropriate address. This is be enhanced by using basic policy based routing and/or MPLS (Multi-Protocol Label Switching. MPLS Label Switched Paths (LSP‟s) can be used for traffic engineering, allowing complete control of bandwidth and routing for each classification of service. (Figure 2 - bottom/1) The Switch CPU looks up the first packet, determines the classification and priority, then all subsequent packets matching the same criteria will be forwarded in hardware. (Figure 2 – bottom/2) Using MPLS, the traffic can be pushed on different paths based on classification.

6 A formal method of tracking and recording proposed and actual changes to a system

7 http://www.gen-networks.com/

8 http://www.gen-networks.com/content/iris/index.aspx

http://www.gen-networks.com/

http://www.gen-networks.com/content/iris/index.aspx

9


Guaranteeing availability is part of QoS. It is therefore critical to implement diverse protected circuits and switches and to build redundant Label Switched Paths (LSP) using MPLS and Classification. This allows Fast Reroute (shorter than 50 ms) and simultaneous IP Services (hardware manufacturers, such as Harris and Medialinks, will support receiving multiple IP Flows and do protection in the end video devices). Bandwidth management - An MPLS enabled network allows the creation of Label Switch Path‟s (virtual circuit) that can tunnel traffic through the network. The Traffic Engineering implements deterministic routing and enables proper bandwidth management. The Network Manager needs to ensure no oversubscription of high-priority flows. An external system, such as IRIS, is required to properly manage broadcasts. This system must: know and understand the network topology, accept and manage all high priority data on the network, understand all future bandwidth that will be placed on the network.

Figure 2: Classifing and prioritizing traffic & Inside the 'cloud'

Dedicated private line circuits

SONET / Dark Fiber / SDH /

Wavelengths / Ethernet

Inside the ‘cloud’

Dedicated private line circuits

SONET / Dark Fiber / SDH /

Wavelengths / Ethernet

Inside the ‘cloud’

1.4 Practical application

Gérard LOTTE, TDF, France

The TDF company is a group of French and European subsidiaries9 [3], present all along the digital production and

contribution/emission chain [4]. In 2006 it started to design a Digital Multi-Service Distribution Network, the 'TMS' (Transport Multi-Service), completely implemented in July 2008. It is a new MPLS Ethernet (Layer 2) network, composed of 150 routers spread in 42 POPs all over France. No layer 3 routing is currently used in this network. The inter-POP links are based on 5 Gigabit (1 to 4) optical fiber loops [5] and the access mainly on Ethernet microwave links (155 Mbit/s), some fibers too. The QoS management enables different levels of services on the same link, without any risk of interaction between services and customers. 350 services are running on this network, including:

Digital distribution for regional Digital Terrestrial Television (DTT) programs [8] from the 24 regional studios of the French regional network France 3 over 92 regional transmitters, using MPLS, RSVP and FRR.

Collecting 24 France 3 regional programs back to the national FR3 central studio in Paris [9], using the same protocols.

Digital distribution of France 3 national programs to regional TV regional production centers for play-out [10], using MPLS, VPLS, RSTP and PIM (at he head ends).

9 http://www.tdf.fr/groupe-tdf/filiales/

http://www.tdf.fr/groupe-tdf/filiales/

10


Exchanges of programs between regional studios [11], using MPLS, VPLS and RSVP.

Backbone network for voice and data services (eg for a Wimax service provider) [12], with MPLS, VPLS and LDP.

Distribution of HD programmes to DTT transmitters [13], with MPLS, VPLS, RSVP and FRR.

Transport of 18 DVB satellite multiplex to the TDF‟s teleport uplinks in Nantes (Brittany) [14], with MPLS and RSVP.

Digital distribution of radio programs from 24 regional studios to 92 regional FM or T-DMB transmitters [15], with MPLS, VPLS (point-to-point) and and RSVP (point-to-multipoint).

Pro WiFi contribution access network for journalists [16]: up to 100 access points, 2 Mbit/s guaranteed, and up to 10 Mbit/s in best effort for the access, MPLS, VPLS and LDP used.

Connecting remote cameras, placed on the transmitters sites, to the studios for live weather illustration or for regional use [17]; with MPLS and VPLS.

Transport of COFDM ENG services from the receiving HF point to the play-out studio [18], with MPLS and VPLS.

The next step is to extend this multi-service network to the European level [19].

2 Audio Contribution over IP

Audio over IP equipment from one manufacturer has until now not been compatible with another manufacturer‟s unit. This session covers applications and real-life use of audio over IP with demonstrations and hands-on.

2.1 The ACIP standard - A tutorial10

Mathias COINCHON, EBU, Switzerland

The EBU has worked in a project group, N/ACIP (Audio Contribution over IP)11

to create a standard for

interoperability. This standard, EBU–TECH 3326 (revision 3) published in April 200812

was jointly developed by

members of the EBU-group and manufacturers. The audio coding algorithms, which 'must', 'should' or 'may' be used, are:

Mandatory audio codecs Recommended audio codecs Optional audio codecs

ITU-R G.711 A-Law & µ-Law (U.S.A. + Japan)

64 kbit/s

MPEG-4 AAC Low Complexity

Profile Enhanced APT-X

13

ITU-R G.722 64 kbit/s MPEG-4 AAC-LD MPEG-4 HE-AACv2

MPEG-1 Layer II

64 / 128 / 192** / 256** / 384** kbit/s

32 / 48 kHz

MPEG2 Layer II

64 / 128 / 192** / 256** / 384** kbit/s

16 / 24 /32 / 48 kHz

MPEG-1 Layer III

64 / 128 / 192** / 256** kbit/s

32 / 48 kHz

MPEG-1 Layer III

64 / 128 / 192** / 256** kbit/s

16 / 24 /32 / 48 kHz

Dolby AC-3

Linear PCM (raw)

16 / 20 / 24 bits

3GPP AMR-WB+

(Adaptive Multi-Rate Wideband)

** Optional for portable equipment

The transport protocol used is RTP on top of UDP [8], as in many real-time IPTV systems. For the session management, 3 protocols are used: SDP: Session Description Protocol (RFC4566), SIP: Session

10

See also EBU - TECH 3329 'A Tutorial on Audio Contribution over IP'. May 2008

http://www.ebu.ch/CMSimages/en/tec_doc_t3329-2008_tcm6-59851.pdf Lars JONSSON and Mathias COINCHON 'Streaming audio contributions over IP' EBU Technical Review - 2008 Q1 http://www.ebu.ch/en/technical/trev/trev_2008-Q1_jonsson%20(aoip).pdf 11

http://www.ebu-acip.org 12

EBU - TECH 3326 (revision 3) 'Recommendation for interoperability between Audio over IP equipment'. April 2008

http://www.ebu.ch/CMSimages/en/tec_doc_t3326-2008_tcm6-54427.pdf 13

http://www.aptx.com

http://www.ebu.ch/CMSimages/en/tec_doc_t3329-2008_tcm6-59851.pdf

http://www.ebu.ch/en/technical/trev/trev_2008-Q1_jonsson%20(aoip).pdf

http://www.ebu-acip.org/


http://www.aptx.com/

11


Initiation Protocol (RFC3261) and SAP: Session Announcement Protocol (RFC2974). For the signalling, SIP, commonly used for Voice over IP, allows to establish, maintain and end the session [13].The hosts listen to messages and respond. SIP also negotiates the audio coding parameters. To facilitate interoperability, SIP servers

associate names with IP addresses and allow a reporter14

to be found, whatever the location, whatever the device!

Audio Contribution over IP should rely on managed (private) IP networks, allowing QoS. QoS can be expressed in Service Level Agreement (SLA) contracts with providers, but requirements must be clearly expressed concerning: transmission performances (latency, jitter...), network availability (99.9% 99.99%), provisioning delay (1 week? 1 month?). The definition of the measurement method is also important (EBU N/IPM group is working on profiling, measurement). A variety of 'last mile' access methods are available with different performances:

Fiber optic Copper with xDSL Mobile (3G/UMTS, Wimax, LTE)

Satellite Wireless

High quality but expensive

SDSL: Symetrical uplink / downlink

Bit errors lead to packet losses

Increasing bit rates but unreliable

No solutions with guaranteed QoS nowadays

HSDPA / HSUPA shared channel

Long delays, often shared bandwidth

Inmarsat BGAN, DVB-RCS providers (Eurovision in the future?)

Wifi: no guaranty due to frequency sharing

'Audio Contribution over IP' Recommendations has already been implemented by many audio codecs manufacturers [16]. A recent test (February 2008) between 9 manufacturers proved that earlier incompatible units can connect with professional audio formats using the standard. Some are still premature prototypes, and not yet EBU compliant. Marketing is very aggressive. Units are still under development. An open source reference implementation by IRT / BBC R&D is in development (§ 2.2).

2.2 Implementing and testing ACIP using open source software

Andreas METZ, IRT, Germany and Peter STEVENS, BBC, UK The goals of this reference software, are:

to implement all the mandatory features of the EBU standard – protocols, bit rates, commands, etc. at the same

time as manufacturers were working to the same standard (will not cover recommended or optional features).

to provide independent interoperability testing to check compliance [3].

At this point, this reference software will be the BASE point and will be released onto Sourceforge

15. Therefore it

doesn‟t prevent anyone from taking the source code and developing and producing a software (commercial) version to maybe include other recommended and/or optional features. It is jointly developed by BBC (interfaces, network, packetization, logging, etc) and IRT (codecs) A suitable open source code that supported G.711 and already well documented has been found , but needed to support the

additional mandatory codecs G.722 and MPEG-2 Layer II (codec extension of PJSIP16

). Suitable audio interfaces

(analogue, digital, consumer, professional) to support the many possible requirements, are also available.

A 'plug test' was arranged by the EBU and held at IRT, Munich, in February 2008. Nine manufacturers17

took part. All bought one unit for testing. All units tested against each other and also to the EBU reference over a three day period [17]-[21]. Participants actively discussed details in the EBU Tech 3326 document

12 and this resulted in some

clarifications and updates (re-published April 2008). The test network structure required the same subnet and only a central switch, not a router [10]. Each of the five tables arranged as shown and manned by an EBU member, plus a central analysis point.

14

e.g. - sip:[email protected] or telephone number 15

http://sourceforge.net/index.php 16

http://www.pjsip.org/ 17

AEQ (Spain) http://www.aeq.es/eng/index.htm , AETA (France) http://www.aeta-audio.com , AVT (Germany) http://www.avt-

nbg.de/homepage_engl/start.htm , Digigram (France) http://www.digigram.com , Mayah (Germany) http://www.mayah.com/ , ORBAN (Germany) ) http://orban-europe.com, Prodys (Spain) http://www.prodys.net , Telos (U.S.A.) .) http://telos-systems.com, Tieline (Australia) http://www.tieline.com/ip/index.html

http://sourceforge.net/index.php

http://www.pjsip.org/

http://www.aeq.es/eng/index.htm

http://www.aeta-audio.com/

http://www.avt-nbg.de/homepage_engl/start.htm

http://www.avt-nbg.de/homepage_engl/start.htm

http://www.digigram.com/

http://www.mayah.com/

http://www.prodys.net/

http://www.tieline.com/ip/index.html

12


Advantages:

Easily see full traffic between both codecs under test and SIP communications with accurate timing of data

Only one protocol analyser required at each of the five test station positions

RTP travels directly between codecs, via hub

No involvement in testing or ensuring that router configuration is correct

Disadvantages:

Codecs and Config PC‟s have to move around testing station positions – minimal movement regime determined

Potentially, other test stations could see communication traffic to/from SIP server from codecs not involved in test – in practice, not a problem

The testing consisted of 11 rounds of 45 permutations of devices under test for each of 4 mandatory codecs. More

than 180 tests were undertaken including reruns of some tests. G.711 was tested using an Asterisk18

SIP server;

G.722, MPEG Layer II and Linear PCM were tested without the SIP proxy. All rounds were recorded (2 GB of data

stored) using the open source Wireshark19

protocol analyser [15] [16].

The test results in short: Of the four mandatory audio coding formats: most units were capable of connecting G.711 audio, some units were also capable of connecting with G.722, MPEG Layer II and Linear PCM. 137 total connections successfully made (G.711: 45 total = 39 audio + 6 failed / G.722: 36 total = 30 audio + 6 failed / MPEG Layer II: 36 total = 29 audio + 7 failed / Linear PCM: 20 total = 10 audio + 10 failed). Minor improvements in software versions were undertaken and reruns operated in this case – but the time was limited for too many. Some encountered problems, concerning:

Protocols' usage: SIP - some connection closures due to poor command handling. SDP (re-invite, options request) - mandatory attributes not supplied, and ignoring media stream port in SDP message.

Codecs: G.711 - only µ-Law handled by some. G.722 - audio not received by some units, some related to protocol usage. MPEG Layer II - bit rate and channel limitations; poor channel handling. Linear PCM - no support; packet size handling now mandated to 4ms.

The lessons learnt with the SIP Gateways. Although not strictly part of the interoperability document, are a necessary part of infrastructure requirements for broadcasters.

Asterisk was used, although others are also available, but with a number of unexpected behaviours (for example: INVITE queries not relayed correctly; media stream sometimes altered, promotion of G.711 to G.722; unexpected disconnections; odd behaviour of BYE request; response by codecs handling Gateway codec presence checking – is codec still there?).

The SIP infrastructures need to be able to handle Audio over IP, cell phones and Voice over IP units… and Video over IP as well? Some ongoing work for broadcasters required in this area.

At the end January 2008 the BBC Festival of Technology20

took place at BBC Television Centre, London, with the

first public demonstration of the reference software with 'real' devices [23]. So, what could we do with this in the future? Some thoughts:

Allow video codecs. Decide on good broadcast (hopefully Open Source) codecs for audio, even codecs not in the EBU standard. Include surround sound codecs.

Could produce a stand alone SIP client, with the following needs:

o Use broadcast quality codecs. o Able to communicate to an EBU SIP server (if implemented). o Able to communicate with most Hardware codecs. o Both for on-the-road usage and in-studio usage. o Maybe Java-client? (What about latency?) o Ease of use. In the ultimate situation the following one-button control performs the following:

o Confirm connection to SIP server. o Set up temporary communication to other end (studio?).

18

http://www.asterisk.org/ 19

http://www.wireshark.org/ 20

http://www.bbc.co.uk/rd/fot/handouts.shtml

http://www.asterisk.org/

http://www.wireshark.org/

http://www.bbc.co.uk/rd/fot/handouts.shtml

13


o Test line speed to other end. o Choose appropriate codec. o Reconnect using new codec. o Automatic Fallback to lower bandwidth codec if bad line during transmission. o Built in simple Audio mixer, for microphone and playback of files. o Open text chat window with studio for easy communication. o And so on…

2.3 Interoperability in action

Björn WESTERBERG, SR, Sweden What kinds of networks have we been testing and using?

Wired networks Wireless networks

Unmanaged Managed

with QoS

'Unmanaged' Managed

Technology: xDSL

Bit rate: 256 kbit/s - < 10 Mbit/s

Latency (very important for a good performance of Audio

over IP): 20 ms - ~150 ms

Jitter: 5 ms - 30 ms

Technology: MPLS (Multi-Protocol Label Switching)

Key parameters:, bandwidth, latency, jitter

Service Level Agreement, important when you contract with an ISP

The Eurovision Fiber Network FiNE (EBU) is a good example, used a couple of times for 2 Mbit/s transmission from Helsinki – worked perfectly. Also for Beijing SOG with 3 different capacities

Technologies:

- '3G': UMTS/WCDMA (100-200 kbit/s average bit rate

'3.5G': HSPA ('Turbo 3G' > 500 kbit/s) coming now….

'3G'-networks & operators in Sweden (Tele2, Telia, Telenor, Tre) offering very good performance (but at very low bit-rate); 600 000+ subscribers / 9 million people

- CDMA2000 (common in the U.S.A.), and UTRA TDD

Operators: IceNet (offering 1.8 Mbit/s upwards and 4 Mbit/s downwards all over the country), Generic Mobile

- Long Term Evolution ('4G')

2.6 GHz band in major cities; mobile WiMAX

3G-Operators offer ”Virtual Private Network – service for own 'Accelerated Private Network' ??? good for security but with no bandwidth guaranty

The ICE-net (CDMA2000) offers access priority to subscribers, i.e. 2-10 times (but 50 times more expensive!) higher priority to available subcarriers then other users in the same sector

Lot of hot-spots in Sweden

Don't forget one of the Internet basic principle: the Best effort!!

The “bottleneck” for the wireless is the radio layer access - you have to get a very good signal to your device. Also, too many users on the same cell reduces the available individual bit rate. And it is not yet stable for Audio over IP, because of high delay.

Devices in action Hardware-housed software versus all-software codecs:

Hardware codecs, are very easy to interface within the Broadcasting house, offer a lot of functionalities, but are harder to handle for non-technicians and require upgrade attention.

Software codecs, have a friendly Graphic User Interface, are easy to use for reporters and non-technicians, offer less functionalities, but can easily be integrated in the portable laptop.

Our activities in the last two years:

Icehockey World Championship Final in Moscow (2007): the reporters had a very nice quite expensive ISDN

14


connection but decided to try using the available IP and found they were able to transmit stereo with 256 kbit/s MPEG Layer II 25 hours for 10 matches. In Quebec (2008) a 384 ??? kbit/s connection was used with no errors at all.

Swedish Icehockey National series (October to April, with 3-4 matches 2 times a week at the peak period) – audio contribution over IP mainly for Web and 3G distribution (10 000 ('listeners').

Opera transmission - 3 hours, with a 48 kHz, 20-bit PCM signal; it was risky, but we tested a couple of days before – so we got a good idea of the traffic shape – and there was satellite backup.

University of Gothenburg: professors participate live over IP in current affairs programmes. The AoIP equipment was financed by the University.

All Swedish Radio‟s foreign correspondents are IP-enabled, so transporting less expensive equipment - where IP available.

Alltogether, 30 external companies contribute to SR Radio programmes. For the past 6 months some have been delivering music live streams over IP at a fairly good rate (384 kbit/s).

Final questions and answers

Can the Internet be used and recommended in general for audio contribution? Of course not yet! It is not secure yet! Only as a last option - if you don't have anything else, try it! Recommendations: keep the packets size very large large (800 bytes or more) and see that you have a 50 % bit rate overhead.

What can wireless networks be used for? For file transfer mainly, because the delay and the jitter are too much out of control to be used for live transmissions.

Which codecs are the best? Software codecs have a future, but inside the Broadcasting house hardware codecs will remain, because they are easily interfaced with the rest of the infrastructure.

2.4 Demos

Figure 3: Audio over IP network over satellite with DVB-RCS (future Euroradio!)

APTAPT

APTAPT

Figure 4: Audio over IP codecs and SIP

15


„Commander G3‟

Tieline (Australia)

(Unit in Geneva)

„PortaNet‟

Prodys (Spain)

(Unit in

Geneva)

SIP

Proxy and

Registrar

Server

(Unit in UK)

„Scoop4+‟

AETA, (France)

(Unit in UK)

„Scoop4+‟

AETA, (France)

(Unit in

Germany)

„Scoopy‟

AETA, (France)

(Unit in

Geneva)

„IRT/BBC

Reference‟

(Unit in

Geneva)

„Commander G3‟

Tieline (Australia)

(Unit in Geneva)

„Commander G3‟

Tieline (Australia)

(Unit in Geneva)

„PortaNet‟

Prodys (Spain)

(Unit in

Geneva)

„PortaNet‟

Prodys (Spain)

(Unit in

Geneva)

SIP

Proxy and

Registrar

Server

(Unit in UK)

SIP

Proxy and

Registrar

Server

(Unit in UK)

„Scoop4+‟

AETA, (France)

(Unit in UK)

„Scoop4+‟

AETA, (France)

(Unit in UK)

„Scoop4+‟

AETA, (France)

(Unit in

Germany)

„Scoop4+‟

AETA, (France)

(Unit in

Germany)

„Scoopy‟

AETA, (France)

(Unit in

Geneva)

„Scoopy‟

AETA, (France)

(Unit in

Geneva)

„IRT/BBC

Reference‟

(Unit in

Geneva)

3 Video contribution over IP

This session gives an overview of the work and first results of the EBU 'Video Contribution over IP Networks' (N/VCIP) project group and two practical use cases for video contribution over IP networks.

3.1 Video contribution over IP – The EBU project group N/VCIP

Markus BERG, IRT, Germany

The European Broadcasting Union (EBU) has established a Video Contribution over IP Networks (N/VCIP) project group to:

To identify users‟ requirements for real-time video over IP transmission, relating to broadcast contribution applications. A questionnaire was sent to EBU members.For file transfer, N/FT-AVC created a report: EBU Tech

331821

.

To analyse all standards and protocols available to support the transmission of video over IP, including multicast and resource reservation.

To propose a recommended set of protocols and of common features to ensure equipment compatibility for video contribution over IP in the EBU (for example between different EBU members).

Different manufacturers already provide solutions for real-time video transport over IP. Interoperability of equipment is of paramount importance. A first meeting took place with manufacturers in Geneva in March 2008. A presentation of the ongoing N/VCIP work and discussion with manufacturers is planned at IBC (September 2008). An agreement on profiles (see below) should follow with interoperability tests. The publication of a Technical specification is planned for mid/end 2009. A draft of VCIP profiles (minimum set of required parameters for interoperability) is currently under specification, including the following ones:

21

EBU – TECH 3318 'File Transfer Guidelines'. June 2008



16


Profile 1 Profile 2 Profile 3 Profile 4

Uncompressed video (SD, HD) over IP

Compressed high bit rate profile:

Transport Stream over IP

according to Recommendation SMPTE

202222

MXF over IP Low bit rate:

ISMA 2.0

(Internet Streaming Media Alliance)

Estimated

bandwidth

requirements

incl. possible overhead

(draft)

~ 300 Mbit/s for SD (576i25)

~ 1,6+ Gbit/s for HD (1080I25, 720p50)

~ 3,2+ Gbit/s (3.5 w. FEC) for HD (1080p50)

This profile will be chosen when Profile 1 is too expensive or bandwidth not available

~ 7 - 30 Mbit/s for SD (576i25)

~ 30 - 300 Mbit/s for HD (1080i25, 720p50)

~ 30 - 500 Mbit/s for HD (1080p50)

depending on the compression technology

Between profile 1 and 2 (uncompressed or compressed)

~ 3 - 15 Mbit/s for SD (576i25) for News…

FEC FEC - still to be cross checked with existing specifications

FEC level B (row and column) To be defined No FEC specified yet - ISMA standard has to be enhanced with FEC

Positive points

Supports TS with constant bit rates

In the future other compression formats beside MPEG-2 and MPEG-4 AVC / H.264 may be transported in MPEG-2 TS

Suitable for compressed and uncompressed video

Very efficient lower bit rate profile

Pending questions

No complete standard available at the moment

Transmission networks expensive?

Capacity available?

Video Services Forum (VSF) proposal is under evaluation

SMPTE???

No standard available yet - Standard has to be created!

Useability for HD to be determined

This profile has raised a lot of questions from the manufacturers

Some topics are still to be covered:

Signalling: is the usage of SIP recommandeable?

Network profiles for video contribution, in relation with the newly created (April 2008) N/IPM project group in charge of:

o Reviewing any relevant work defining network QoS classification for broadcast contribution feeds o Specifying and conducting tests of IP network components o Gathering information on IP measurement methods and tools o Specifying classification for IP networks suitable for use by European public service broadcasters o Developing network measurement methods suitable for verifying the various classes of services levels defined for IP broadcast networks

Scrambling (encryption)

3.2 Real-time transport of television using JPEG2000

Helge STEPHANSEN, Chief Technology Officer, T-VIPS23

, Norway

A JPEG2000 'Refresher'[2]-[8], underlined its following benefits:

Low latency thanks to a picture by picture compression

Compression based on wavelet filtering provides high efficiency over a wide quality range

Compression is uniform for all pixels (no pattern from DCT blocks) - well suited for image post-processing

Lossless and near lossless modes

Marginal distortion on multiple generations

22

SMPTE 2022-1-2007 Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks

SMPTE 2022-2-2007 Unidirectional Transport of Constant Bit Rate MPEG-2 Transport Streams on IP Networks 23

http://www.t-vips.com/

http://www.t-vips.com/

17


JPEG2000 MXF storage format defined (SMPTE 422M24

)

JPEG2000 is already in use in production (for example, Thomson Grass Valley HD/SD Infinity camcorder25

and a

number of video servers)

JPEG2000 offers 3 operational modes for TV broadcasting:

Normal mode (irreversible) with floating point filter, optimised quantisation and codestream with bit rate limitation. The typical compression ratio: is 10-20 %.

Lossless mode with bit rate limitation. This mode applies integer filter, no quantisation and codestream limitation with bit rate limitation. The typical compression ratio is 40-60%.

Lossless mode. This mode applies integer filter, no quantisation and all coefficients included in the codestream. Bit rate will be unrestrained.

The JPEG2000 bit rate characteristics are, after compression: 20-25 Mbit/s from SDI 270 Mbit/s, 60 – 120 Mbit/s from HD-SDI 1.485 Gbit/s, 200 – 250 Mbit/s from HD 3G , Digital Cinema uses 250 Mbit/s. The lossless mode allows a bit rate reduction of 30 to 60 %. JPEG2000 is by nature VBR - the number of bits produced by the compression may be less than the bit rate configured. This may be used to save bit rate on transmission. JPEG2000 combined with MXF / FEC / RTP / UDP/ IP provides a good solution for transport over IP [18] MXF does provide a frame-based (progressive or interlaced scanned) wrapping of JPEG2000 picture, plus sound, VANC and HANC data, and can handle synchronisation of video & audio [19]-[21]. ]. In the T-VIPS implementation Preamble and Post-amble are skipped in order to reduce overhead (Typical overhead: 6-8 % incl. Ethernet and IP headers).

The Forward Error Correction (FEC) [22] corresponds to the Pro-MPEG Forum Code of Practice #426

or to the

SMPTE 202227

matrix. For Variable Bit Rate (VBR), operation the FEC matrix being of fixed size, stuffing packets

are inserted [23]. The IP encapsulation supports a bit-rate range from 1 to 1000 Mbit/s,VBR, FEC, and preserves low latency. This contribution service has already been used for:

Euro 2008: 2 HD feeds at 250 Mbit/s and 3 SD feeds between Vienna (Austria) and Scandinavian broadcasters in Stockholm, Copenhagen and Bergen. The high bit rates were used as an STM-4 connection was available.

Transmission of ice hockey competitions from 12 arenas: 1 HD and 2 SD at 100 Mbit/s, with integration into Content Management Systems

Primary Distribution of the the Norwegian DVB-T since September 2007. The network was installed and is operated by the telecom operator Telenor. It comprises 3 multiplexes with MPEG-4 coded SD video. JPEG2000 were preferred as an alternative to MPEG-2 in order to use a higher compression on MPEG-4 and provide the same resulting quality to the viewers.

3.3 France 3's new contribution network over IP

Jean-Christophe AUCLERC, France3, France

The challenges to meet for this project were to: connect 110 sites over the French territory, make possible any-to-any communications, keep and adapt our Network Management System (NMS), use a network operated by a data oriented Telco (NeufCegetel), design with the provider a 'broadcast real-time' service on the network, select and deploy more than 130 encoders and decoders.

The network [7] comprises two types of network for two types of contribution:

IP/VPN/MPLS (with QoS) for corporate data and file exchange (and managing of our NMS).

IP/VPN for real-time contribution (with MPEG2 compression): NGN28

range network, IP-based network (Layer 3)

and native multicast (no tunneling). Used for live and rushes transmission (from/to spots where files exchange

24

SMPTE 422M-2006 Material Exchange Format – Mapping JPEG2000 Codestreams into the MXF Generic Container 25

http://www.thomsongrassvalley.com/products/infinity/camcorder/ 26

Peter Elmer and Henry Sariowan – 'Interoperability for Professional Video Streaming over IP Networks'

www.broadcastpapers.com/whitepapers/paper_loader.cfm?pid=221 27

SMPTE 2022-1-2007 Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks 28

http://www.itu.int/ITU-T/ngn/

http://www.thomsongrassvalley.com/products/infinity/camcorder/

http://www.broadcastpapers.com/whitepapers/paper_loader.cfm?pid=221

http://www.itu.int/ITU-T/ngn/

18


don‟t exist).

Both services (called Data and Real-time) are delivered on a mutualized infrastructure (optical fiber) for cost efficiency. The separation of services is logical (VLAN) and in the shaping of the bandwith. The Real-time Network has following characteristics:

By choice, there is no QoS! There are 'only' real-time streams on this network!

The bandwith is 100 % guaranteed by the provider (+ 10% of over-provisionning).

Our NMS manages equipment generating CBR. So we can indirectely manage bandwith and prevent congestion.

All streams are in multicast, making it easier to manage for

the transmitters and for multi-receivers. Therefore only decoders have to subscribe to multicast streams (very similarly to Set-Top Box in IPTV).

Encoding equipment

The MPEG-2 encoders / decoders 'ViBE' are products from Thomson Grass Valley29

, with Ethernet Interfaces

Typically, the MPEG-2 MP@ML encoding profile requires about 8 Mbit/s (IP level). The normal delay (about 900 ms, end-to-end) is used for rushes transmission. The low delay (about 450 ms) is used for live. There is no FEC implementation at the moment. Example of the network management at the level of a Regional Center: the network bandwith is of 24 Mbit/s and is managed with 8 Mbit/s one-way, making it possible to have 3 input/output links. The NMS will authorize 3 live receptions, but will first refuse the fourth. All links being managed by a 'Scheduler', the fourth link will be proposed after, or the operator must stop one of the 3 links. Among the evolution foreseen:

For the monitoring of the Network, Media Delivery Index (RFC 444530

) probes are in evaluation.

Implementation of FEC (probably 1D), depending on the results of the network load increase.

Implementation of Video servers, in order to be able to record MPEG/IP streams directly through Ethernet decoders interfaces.

Development of an interface between our NMS and our Production Media Asset Management for a better performance of our workflow.

4 HD over Networks

This session is about current status and new key technologies for High Definition Television Production in a networked environment. The high bandwidth demand of uncompressed HD signals often necessitates some kind of signal compression in order to enable storage on hard disks and transport over networks. This session brings some more insight into what is lying ahead of us as well as some experience that can be gained from current real world HD-TV production and emission.

4.1 HD contribution codecs

Adi KOUADIO, Engineer Dipl. EPFL; presented by Marc LAMBEREGHS, EBU, Switzerland

'Contribution' is the exchange of video content from one broadcaster to another or between the regional facilities of one broadcaster. It covers 3 main applications:

News Gathering (SNGs) implying priority to the event with best effort quality).

Off-line content exchange with high quality expected.

Live event contribution High quality expected and low delay).

It relies on 3 types of networks:

Via satellite, with limited bandwidth (depending on the transponder and the modulation technique).

Via copper links, usually for internal facility contribution, with the bit.-rate limited by cable technology.

29

http://www.thomsongrassvalley.com/products_disttrans/ 30

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

http://www.thomsongrassvalley.com/products_disttrans/

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

19


Via fiber, offering an unlimited bandwidth, but being not efficient for multi-point contribution.

HD content suggests a higher viewing experience for end users compared to SD, and therefore HD contribution should then meet following challenges:

Higher data rate to handle efficiently in bandwidth limited networks

Lower latencies or at least the same as in the SD world

Higher bit depth (at the moment up to 10-bit)

Multiple image formats (SD, 720p/50, 1080i/25 and potentially 1080p)

Frame rate conversion for overseas transmissions

Robustness to cascades

Etc.

The Table 3 (Annex) details the characteristics, advantages and disadvantages of the choice of codecs. The selection of the codec should be made based on...

Product disponibility

Experience / knowledge of the technology

Comparisons with other systems

Recommendations on adequate settings...

Suitability for specific applications and/or networks: SNG, live (sports, documentary...), off-line exchange versus via satellite / fiber / copper

Costs concerning IPR issues, scalability for futureproofness, backward compatibility with older compression systems...

And how can the EBU Technical Department help you make this choice clearer ? The ongoing work concerns:

EBU Technical department: study of HDTV format conversion over contribution link (with BBC and IRT) - Evaluation of contribution codecs (H.264/AVC, Dirac ...) in the I/HDCC group - Evaluation of the SVC potential for HDTV broadcast applications in the D/SVC group.

WBU ISOG with EBU: interoperability test for MPEG-4 AVC / H.264 compression system

BBC: evolution of the Dirac Pro codec (SMPTE VC-2)

4.2 Practical thoughts and wishes… or whishful thinking!

Lars HAGLUND, Senior R&D engineer and Video Production, SVT, Sweden

SVT produced it‟s own demanding, but not unduly so, multi-genre TV-program “Fairytale” in 3840x2160p50 (hence

1080p, 1080i, 720p and 576i).. 3 reference sequences31

"CrowdRun", "ParkJoy" and "InToTree" can be downloaded

from the EBU Web site32

or from the ITU-VQEG FTP site33

. All sequences from this set were filmed in 50 fps with

professional, high-end 65mm film equipment by SVT in October 2004. ITU-R BT.112234

indirectly says that, for

distribution, 75 % of such a program should stay in “excellent-range”, but 25 % (demanding scenes) may go down to “middle of good-range”. Considering that Blu-ray has no artefacts at all, SVT believes that any scene in Fairytale should stay for contribution in “excellent-range” to reduce cascading artefacts.

In our SVT's national WAN35

[5], we would like to use... an I-frame based codec to reduce latency in interviews,

and a codec using 4:2:2, 10-bit for further processing robustness. For the time being SVT is using the JPEG2000-based T-VIPS products (§ 3.2) that need about 150 Mbit/s (for 720p50, 4:2:2, 10-bit), with only 100 ms in latency (versus 2 seconds in MPEG-2 GOP at 200 Mbit/s!). SVT believes that MPEG-4 AVC / H.264 products for

31

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf 32

http://www.ebu.ch/en/technical/hdtv/test_sequences.php

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/ 33

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/ 34

ITU-R BT.1122-1 (10/95) User requirements for emission and secondary distribution systems for SDTV, HDTV and

hierarchical coding schemes http://www.itu.int/rec/R-REC-BT.1122/en 35

See also the EBU Networks2005 seminar report § 1.1.2

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/SVT_MultiFormat_v10.pdf

http://www.ebu.ch/en/technical/hdtv/test_sequences.php

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

http://www.itu.int/rec/R-REC-BT.1122/en

20


contribution need to be developed for 4:2:2, 10-bit with both I-frame based mode and GOP-mode! Concerning international (HD) contribution SVT has received the 2006 summer football contribution from Germany, skiing and athletics from Sapporo/Osaka, Song Contests etc... All bit rates have been too low! You can see degradation on a 1st generation Omneon server recording (MPEG-2 GOP at 100 Mbit/s is too low). A contribution at 45 Mbit/s (hopefully greater than 60 Mbit/s) before that server isn‟t an “excellent” cascading situation. Use MPEG-4 AVC/H.264 for contribution (4:2:2, 10-bit) but not to reduce the “too low” MPEG-2 bit rates of today by 20-30 %, but to gain robustness! Push-up the AVC/H.264 GOP-based bit rates to more than 70-100 Mbit/s! Format conversions... may happen before or after contribution. SVT prefers to perform any format conversion before contribution, as we did in Sapporo (1080i29.97 to 720p50), we have the bandwidth and can do better de-interlacing thzan at the consumer side. Big bulky frame rate-converters

(59.94 to 50) with good performance36

should be cheaper and card-based, please! Card-based de-interlacers

(50Hz-1080i to 50Hz-720p) should offer better performance, please! Down-converters to SD (re-interlace) should have separate H and V “sharpness” settings, please! – to reduce interline twitter when performing the always needed sharpening. Re-insertion of VANC (e.g. timecode) and Dolby E should work without problems, please! 1080p50 (and 59.94) contribution? The S/N ratio in 1080p-camera CCD sensors is problematic, (but not in native 720p CCD sensors). Although 1080p50 production may become marketed during 2009, CMOS sensors may give us good (that means better than CCD) S/N ratio first in 2011. But although the real take-off may not start until 2012, there is a realistic growing need from 2009. So, please... offer us MPEG-4 AVC/H.264 codecs Level 4.2 (SVC is not needed for contribution) codecs, with 4:2:2, 10-bit, both I-frame based high bit rate and GOP.

4.3 Eurovision experience in HD contribution

Didier Debellemniere, Eurovision, Switzerland

Eurovision has already a quite substantial experience with HD contribution [10], using MPEG2 4:2:2P bit rates from

3437

to 60 Mbit/s:

For the coverage of big events, occasional use of satellite and fiber: 2006 Winter Olympic Games from Torino using 20 HD encoders and 40 receivers, 2006 World cup from Germany, Euro 2008 from Switzerland and Austria, 2008 Summer Olympic Games from Beijing using 90 HD encoders and 150 receivers

For permanent connections with NHK for European customers and US networks for sports events: fiber circuits, with a cheaper bandwidth, but still expensive on long distances, and it's easier to improve the transmission parameters.

The bandwidth is expensive and sometimes rare. For example, for the Summer Olympic Games in Beijing fifteen 36 MHZ transponders and 7 dedicated STM4 fiber circuits have been booked! The current parameters in use for big events: On a satellite transponder 36 MHz bandwidth using MPEG2 4:2:2P@HL and DVB-S2: video 1080i/50 at 56.217 Mbit/s, Audio1 at 384 Kbit/s, Audio2 DolbyE multiplex at 2.304 Mbit/s - total data rate of 60.4 Mbit/s. Some issues are daily to be solved: frame rate conversion (50Hz-60Hz), Progressive or Interlaced scanning (720p/1080i), compression cascading in contribution-distribution. Some trends remain clear: the market is not ready to pay more for contribution links - there is an increased demand for exclusive circuits due to the bandwidth limitations on satellite – and the cost for long distance circuits is still high. This leads to MPEG-4 AVC/H.264 to replace MPEG-2 for live HD in the middle term (with a 50% benefit expected). JPEG2000 will be limited to fiber or file transfer. Tests have to be conducted (EBU, ISOG…) on: compression cascading, compression/standard conversion

36

For example, from Teranex 37

Very low for HD contribution, only on request from the client

21


sequence, interoperability. Finally the market will decide. Since MPEG-4 AVC/H.264 equipment range for contribution is not fully available, so MPEG-2 will survive for some time…And anyway how much broadcasters are ready to pay? File transfer is an alternative with lower costs (and increased picture quality?).

5 Real world applications: the News

The final two sessions will outline some recent developments in using new network technologies to support the broadcast environment. The first session looks at the impact of networks on news-gathering kicking off with a use case looking at the application of COFDM for ENG application, with particular attention to the monitoring of the quality of the signals. This will be followed by some real examples of some of the innovative techniques being used by journalists to deliver material to supporting their story-telling.

5.1 The use of COFDM for ENG applications

Michael MOELANTS, Project manager, VRT, Belgium

VRT has implemented 'TNG' - Terrestrial News Gathering - which is ENG (Electronic News Gathering) via COFDM transmitters and receivers (DVB-T) for real-time audio/video. This application uses camera link equipment from Link

Research Ltd38

Coded Orthogonal Frequency Division Multiplexing (COFDM) is a proven technique, used for DAB, DVB-T, WiMAX… (OFDM for WiFi/WLAN 802.11a/g…). It has the following characteristics:

Double-stage FEC (Reed-Solomon and convolutional code): detects and corrects faults, but increases the end-to-end delay by adding extra bits and data rate processing.

Orthogonal multiple carriers (2048) [6], to avoid dead spots. Choosing the correct inter-carrier distance, leading to limiting/suppressing the interference between them.

A guard interval on the time axis, waiting to start a new symbol to avoid interference of echoes due to multi-path.

A multiple antenna diversity reception is used, with packet diversity. Each receiving antenna signal is demodulated to ASI. The new HD/SD equipment (not used by VRT yet) uses the better performing maximal-ratio combining, where all signals are multiplied by a weighting factor and afterwards added - the weighting factor is function of a quality measure (amplitude, SNR…) [8]. The equipment include on the transmitter side: a MPEG-2 codec (100 or 200 mW) and modulator, a 1 W amplifier on the wireless camera. In the TNG van, a 5 W amplifier. The transmit antennas [11]+[14] are omnidirectionnal on the wireless camera and on the van, and directional which can be mounted at the van rear outside. Network. At VRT, 2 frequencies in the 2.2 GHz band are used: 1 dedicated to VRT and 1 shared between VRT and RTBF Sports. The A/V bit-rate is 6 Mbit/s (QPSK modulation) or 12 Mbit/s (16-QAM modulation), with a 1/2 FEC (highest possible) and a 1/32 guard interval (smallest possible). There are 5 receiving points [15]: 2 in Brussels, 1 in

Antwerp, Ghent and on the Belgian Coast39

. The transport of the signal to VRT Headquarters [16] occurs over VRT

optical fiber (+ CWDM) in Brussels (ASI) and Antwerp (SDI), via a microwave radio link in Ghent and then over an IP-MPLS service to Brussels (16]. Performances [17]. From the TNG van, transmission is possible in cities within a 6-8 km radius area (non line-of-sight) and up to 60 km (in line-of-sight), the van becoming in this last case a "virtual feeding point". From the wireless camera to a receiving site: 2-3 km (non LOS) or tens of km (LOS) - or hundred meters to a TNG (or SNG) van, used as a repeater. The quality of the received signal is monitored using an application [18] [19]. The system is easy to operate and offers a high uptime. TNG is used for feeding items and for live “talking head” broadcasts (end-to-end delay 40 ms) for news. The TNG teams draw maps indicating virtual feeding points and green/orange/red working areas in the cities.

38

http://www.linkres.co.uk/ 39

Belgian coast network is not yet operational but will be soon

http://www.linkres.co.uk/

22


5.2 Getting News to base, or 'Only connect'?

Martin TURNER, Head of Operation for News gathering, BBC, United Kingdom

This presentation is intended to explain the challenges facing broadcasters in a networked world and to demonstrate some of the ways the BBC is changing its workflows and technology to try to meet those challenges. In former times it used to be simple… television journalists and crews gathered the news, processed it and delivered it to base – either by hand, circuit or satellite. Of course, in reality it wasn‟t simple - up until the early 90s the BBC issued its reporters with what it charmingly called “mutterboxes” connected with crocodile clips to a phone handset or to its wall socket. Satellite equipment was bulky, it went wrong, the delivery cost a small fortune and unaccountably, suspicious airplane passengers would sometimes refuse to accept a big bag of tapes… Communications were difficult so for much of the time you were out of touch with head office. The return path was rudimentary and often amounted to little more than a telex or a fax telling you how your piece had gone down. And then everything changed. Satphones40 became more portable, speeds increased and the first store and forward devices emerged on the scene. They were affordable, reasonably easy to use and they worked more or less. Of course, these had an extraordinary effect on our ability to report from the scene. And then came the M4

satphone, the videophone, the undreamt of speed of 128 kbit/s. And now the BGAN41

, the new Thuraya system42

,

Streambox43

, Quicklink44

, vPoint45

and so on. And in many places HSDPA/&UPA, WiMAX and, even in remote

areas, within months, 384 kbit/s of bandwidth. But again it‟s not that simple, because it‟s no longer a one-way street, and what we have been building is a network. We have been extending the newsroom into the field so that many of the activities that might once have taken place at base are now happening on the ground. A demo video demonstrates how a reporter in the field can proceed to a federated search into the BBC's Jupiter Media Asset Management system, import on-demand Flash Video archives files to the field and export its own files

after editing with a tool based on Rhozet46

transcoding solution.

The ability to access material in this way has revolutionised what gets on air. All this is an extraordinary opportunity for better story-telling, but it‟s also represents a gigantic challenge both editorially and technically:

We risk overloading staff in the field with an ever-increasing amount of information which leaves them no time to go and find things out – no time to actually be journalists. Increasingly, the point of publication will get closer to the newsgathering process and we will need to ensure that editorial standards are upheld.

The technical challenges are just as significant. Staff is expected to have an extraordinary range of skills. Both journalists and technicians need a comprehensive knowledge and understanding of networking principles. We run the risk of allowing technical quality to degrade as the public become increasingly capable of creating and delivering high-quality video themselves. We face the challenge of mixed standards, of concatenating codecs, of equipment that simply doesn‟t perform as we expect it to. And we will often be using equipment that offers nothing approaching the robustness of the broadcast equipment to which we have been accustomed.

The future is the network and the networking of knowledge. Audiences are beginning to experience a truly interactive relationship with the news – and this requires the extension of the network into the field. So getting news to base is the easy part. The challenge for the future is to ensure that we exploit the network effect to create a new form of journalism.

5.3 How to connect your Video Journalists (VJ)

Mattthias HAMMER, IRT, Germany How can I connect my Video Journalists best? …as flexible as possible! VJs should always be able to use the best

40

For example, with the the 'Toko', manufactured by Toko Japan (http://www.toko.co.jp/top/en/index.html ), a device that digitally

compressed video, stored it and forwarded it through a telephone or a satellite phone. 41

See EBU Networks 2007 seminar report § 5.3 42

http://www.thuraya.com/ 43

http://www.streambox.com/ 44

http://www.quicklink.tv/ 45

http://www.vcon.com/ 46

Carbon Coder http://www.rhozet.com

http://www.toko.co.jp/top/en/index.html

http://www.thuraya.com/

http://www.streambox.com/

http://www.quicklink.tv/

http://www.vcon.com/

http://www.rhozet.com/

23


connection - whenever they need to. Why does a VJ need a network connection? Because the basic rule for news is: faster = hotter. The main advantage of VJs is the spontaneous acquisition in difficult areas and locations. What is the payload? It's more “ready files” than streaming. For audio, the typical bit rate is less than 200 kbit/s (max about 1.5 Mbit/s) - bidirectional Internet streaming can work for it. For video (incl. audio) the bit rates are multiple times of audio < 4 Mbit/s... 12 Mbit/s …. 25 Mbit/s - video streaming over open Internet is difficult (no way!). IRT is testing Multiple Description Coding (MCD) and Scalable Video Coding (SVC) solutions. There are numerous ways for a VJ to get connected. The common network interfaces of the VJ equipment are: Ethernet (≤ 1 Gbit/s), WiFi (nominal up to 56 Mbit/s), mobile (phone) connections (UMTS, HSPA…), WiMAX. Table 4 (Annex) lists the overwhelming crowd of networks worldwide and actual bit rates measured on some relevant networks. VPN security is important for VJs. It is useful for the protection of the reporter identity, for very critical material - especially in 'monitored' networks (China & Co.), for full LAN-integration (with all the administrative overhead), and for securing applications with low security levels (like FTP). But:

Transfers can be secure enough if native mechanisms are used: HTTPs, sFTP, file encryption and signing, dedicated input server (in DMZ).

The security overhead can have massive negative impact on the transfer-throughput. Therefore individual performance-tests are essential. For example [14], a 3.4 Mbit/s bit rate through a no VPN circuit, will become

3.3 Mbit/s with CryptoGuard VPN47

software (with AES encryption) and decrease to 1.9 Mbit/s with OpenVPN48

,

an open source SSL VPN solution.

The VPN throughput is important for daily VJ-business, even very low bit rates are challenging the available connections. Here is an example of calculation: A 5-minute video material coded at 4 Mbit/s will deliver 1.2 Gbit in 5 minutes (30 MByte/minute)

25 Mbit/s will deliver 7,5 Gbit in 5 minutes (187 MByte/minute) The Table 4 (Annex) indicates the corresponding transfer duration of this 5-minute material on relevant networks. Finally: how to connect? Every region and continent has its own focus: e.g. Europe develops more UMTS, Asia more WiMAX. But up to now there is no “always fitting” connection-type. Fixed line is still the best choice - and worldwide available, with DSL - WiFi, or cable, or Ethernet connection. Most promising for now and especially in the future:

WiMAX, LTE (4G)

UMTS-HSUPA, especially in Europe

Fixed line (xDSL including local WiFi)

6 Real world applications - Production and Broadcast

In earlier sessions of this seminar, you will have learned about the latest technologies which permit the construction of networks designed to allow contribution transmissions for television production. This final session will provide examples of the impact of new network technology on television production and broadcast.

6.1 Architecting a fully-networked production environment

David SHEPHARD, Avid, UK In a production environment, with file-based acquisition – production – delivery, the network is the link between the 'clients' (desktop applications for journalists, researchers, producers, editors, librarians…) and storage (real-time online / high-performance neartime / library archive) [2]-[7].

47

http://www.compumatica.de/cms/data/index.php?id=21&L=0 48

http://openvpn.net/

http://www.compumatica.de/cms/data/index.php?id=21&L=0

http://openvpn.net/

24


Conventional network design does not apply here because of the specific constraints. For example, real-time video collaborative editing is very demanding and requires such networks as Unit Media network with Fibre Channel (initially 1Gbit/s but grew to be 2Gbit/s and currently 4Gbit/s supporting) or Gigabit Ethernet (for 'lower' resolutions such as DV25 or IMX30) or 10GE coming soon for uncompressed HD [9]-[11]. The associated Unity ISIS storage system allows up to 160 GbE and 20 10GE ports [12] and enables the use of higher resolutions IMX50/DV50 and even DNxHD over Gigabit Ethernet with 10GE coming soon for uncompressed HD [12]-[13]. Gigabit Ethernet end-to-end uses UDP instead of TCP. Just like VoIP this type of video protocol should let the application decide if it needs to re-request the data. A Fast Ethernet connection (100 Mbit/s) results in dissatisfied users, especially if they move between machines with Gigabit Ethernet interfaces. Editing application can co-exist with Video over IP corporate solutions if these are designed correctly. Should we transfer jumbo frames or fragmented packets? Video data is in large blocks on the disks, so it should be ideal! It is more efficient to send larger segments of data, especially with UDP, but it only sustainable in a controlled environment (e.g. server room). Fragmented datagrams can pass over non-jumbo frames enabled networks but need on-board memory in network interface cards (NIC). The aggregation of multiple micro-servers requires flexible, expandable buffering [17]. Big chassis-based Gig-E switches have different cards with different abilities - every interface card matters! Different chassis-based switch models from same manufacturer have different abilities - biggest is not always the best! NIC (Network Interface Card) - The buffers (or descriptors) required for this application would have been considered server class just a couple of years ago, but now this class of adapter can be found on high and medium grade platforms. On board memory is needed for fragmented packets - 32 KB on low cost NIC implementations is insufficient. If a TCP-based data flow is used there will be lots of CPU requirement unless ToE

49-enabled NIC is

used. A separate production network is best for the core systems and high bandwidth clients. Corporate network based clients are possible for less demanding application and resolutions, if the corporate infrastructure can cope and has the right products in the correct place. Separate the Network into zones from the core highest bandwidth zone 1 (with direct storage connection) to the lowest bandwidth (customer network) zone [21]-[23]. In a video production environment QoS

50 generally relates to available bandwidth, latency & jitter. Vendors provide

different QoS tools that you should use on edge and backbone routers to support QoS. Some QoS mechanisms are aimed at VoIP networks and low bandwidth circuits, but others apply equally to LAN. Example of QoS mechanisms for Video over IP are: LLQ (low latency queuing), PQ (priority queuing), WFQ (weighted fair queuing), CQ (custom queuing), PQ-WFQ, CBWFQ (class-based weighted fair queuing). A good old fibre channel is very deterministic and at 5ms latency the effect begins to show. Design the Gigabit Ethernet system with sufficient capacity to ensure the necessary QoS. In a corporate network ensure sufficient QoS exists - the corporate network may need to be re-configured to correctly recognise and prioritize video traffic. Firewalls present many challenges. They are not good at bursty, high bandwidth, fragmented real-time flows. In a production environment we deal with REAL TIME VIDEO, not a streaming VC-1 file! Again, contain the network design into zones and locate externally facing clients in the higher number zone, or even in the corporate network. Buffers, buffers, buffers! Switches with dynamically shared buffers are a better choice - some manufacturers provide 1U or 2U condensed versions of popular mid-range chassis-based switches. Switches with statically assigned buffers limit the design scope - this limit affects some large chassis-based switches from some MAJOR manufacturers, while smaller chassis-based models have shared buffers and are an excellent choice. Buffers in the network cards are also critical. In conclusion, understand every link in the chain (some design examples are presented [29]-[31]) and where that link exists! Every switch, every speed change, every aggregation point MATTERS, and that includes the NIC in the

49

TCP offload Engine -a technology used in network interface cards to offload processing of the entire TCP/IP stack to the

network controller. It is primarily used with high-speed network interfaces, such as Gigabit Ethernet and 10- Gigabit Ethernet, where processing overhead of the network stack becomes significant. 50

http://www.techweb.com/encyclopedia/defineterm.jhtml?term=QoS&x=&y=

http://www.techweb.com/encyclopedia/defineterm.jhtml?term=QoS&x=&y

25


client!

6.2 Bringing the BBC's networks into the 21st century

Paul LEWIS, SIS (IT Solutions and Services) Project Director, Siemens and Nick JUPP, Head of SI Solutions & Raman Technical Design Authority, Cable&Wireless, UK The BBC network objective was to provide a shared infrastructure for all user requirements that delivers the cheapest overall solution, for:

BBC Distribution Services ensuring the real time carriage of Vision & Audio (with multiple platforms to be connected to the interchange points with the Transmission provider).

BBC Contribution Services: real time studio-to-studio carriage of Vision and audio; packet network for media and business applications; Storage Area Network; telephony

English Region Cluster Sites (ERCS) - 52 sites across the UK - to enhance services and capacity in line with core sites.

The scale of the implemented network [4] is huge: Large national & regional sites: 18 core sites + 11 associated sites and 1000+ circuits London BBC Sites: 10 sites and 1000+ circuits District offices & local Radio sites: 60 small sites plus approximatively 60 further minor sites and 600+ circuits International sites – International Bureau: 30 sites and 100+ circuits. Raman name comes from the optical amplication technology which provides on each fiber 240 DWDM wavelengths (=channels) x 10 Gbit/s each [5], on each „Raman Arc‟ between two RIPs (Raman Interconnect Point). Raman technology provides both high density wavelength multiplexing and the ability to drive over much higher distances without re-amplification. The double star topology [9] offers high geo-resilience, allowing each site to be connected through two routes. Implementation and testing. From 2005 to October 2007 Cable&Wireless (C&W) and Siemens SIS designed, built and tested the network [6].

C&W managed Raman, IP WAN, Broadcast & IP Network Services, Audio

Siemens SIS managed the integration to Core Raman sites, the integration to BBC systems, LAN, and IP telephony

C&W uses SDH transport over the Raman transport layer with following equipment [7]: Marconi SDH multiplexers with 10G, 2.5G, STM-1, 2Mbit/s & GbE interfaces; Scientific Atlanta iLynx for SDI, PAL & ASI interfaces; utilise existing ATM switches for ATM services - audio, both analogue and AES3 (delivered via ATM AES47); the packet network terminal equipment is Cisco “Catalyst” in C&W core, Foundry at edges. SIS & C&W undertook 12 weeks of circuit testing with 20 resources working with the BBC: 1300 circuits tested; bit error tests performed; port tests performed; break tests of fibre; impacts all Layers to highlight issues ???; IP network early gateway connection to confirm monitoring tools ??? Through this methodology the Raman network was clean of technical issues ready for migration and it was a key work package to ensure the success of the project. 1200 individual tests were performed over 4 months. In order to test monitoring tools and service proces gateway connection was made in advance of migration. The tests focused on Operational Interfaces and a gap analysis conducted on what we need to do differently. The joint SIS-C&W-BBC approach in the design and the implementation of the tests saved time and ensured a comprehensive testing strategy. The operational model followed the ITIL industry standard framework (Information Technology Infrastructure Library), providing a common framework and language to all organisations. Migration. The Broadcast Migration took 9 weeks; and the IP Network 6 weeks. Both activities were run in parallel with the IP network starting two weeks before broadcast migrations. All migrations conducted between 20:00 & 05:30 hour. These migrations were all complete without any service outages and impact to the BBC, thanks to working in partnership, to the SIS and C&W knowledge of the BBC‟s Transmitter, Broadcast & IT network (old and new), and to planning… planning and more planning! The project has been delivered according to time and budget. The network is fully operational and performing to design requirements. English Regions Cluster Sites - This was the first transformation project after Raman. It addressed the connectivity needs of BBC local Radio sites, to consolidate Telephony, Data and Broadcast Services, enabling initiatives such as programme share, enabling multicast data and audio in the future. It consisted of the migration from multiple discrete services to a fully managed, converged solution with resilient IP over Ethernet WAN service, offering QoS, multicast, support of multiple applications, inntegration to Raman Core

26


sites.

The IP Data Service ensured the transition:

o From a point-to-point E1-based service, with ISDN2 backup, unicast, and no QoS; o To a managed IP solution on a 10M/100M main link, with 2M/10M backup link, multicast, QoS, scalable, integrated with Raman Core sites and between Siemens and C&W Management systems.

The Broadcast Audio Service, with a transition:

o From a Musicline2000 product, unmanaged point-to-point audio, 15 kHz mono, J.41, over E1 - limited scale; o To a C&W Audio-over-IP solution using the APT Oslo platform, a managed solution, multicast, scalable, with enhanced APT-x low latency coding, 22 kHz stereo audio, supporting 5.1 configuration (if required by BBC), and potential for future integration with BBC-wide scheduling systems.

The Telephony Service with a transition:

o From fractional E1 voice links with legacy TDM PBX‟s o To a Siemens Managed IP Telephony solution, with the central HiPath 8000 system, IP handsets, the VoIP traffic using the new IP WAN infrastructure.

6.3 DVB-H small gap fillers: home repeaters improving indoor coverage

Davide MILANESIO, Centro Ricerche e Innovazione Tecnologica, RAI, Italy DVB-H is a system specified for bringing broadcast services to battery-powered handheld receivers. It is an extension of the DVB-T system [3], transmitted in the UHF band, allowing multi-channel, robust with respect to disturbances and for reception indoor, pedestrian and at high speed (train), designed to reduce the battery consumption. The video is encoded in MPEG-4 AVC/H.264:

either in CIF format (352x288), carrying 10 - 11 channels (with QPSK modulation and ½ FEC), at a bit rate between 350 - 400 kbit/s.

or in QCIF format (176x144), carrying 15 - 30 channels (with QPSK modulation and ½ FEC), at a bit rate between 128 - 256 kbit/s.

The H.264 video data is transported over RTP/UDP/IP with an additional Multi-Protocol Encapsulation FEC protection (MPE-FEC) and interleaving. The IP streams are then encapsulated in a DVB MPEG-2 Transport Stream.

DVB/H supports the datacast of files using the FLUTE protocol51

.

DVB-H is already operational worldwide: in Italy (since 2006), Finland (since 2007), Austria-Switzerland (June 2008), Albania, Asia (India, Malaysia, Philippines, Vietnam) and Africa (Kenya, Namibia, Nigeria). But these networks are mainly planned for outdoor coverage not for indoor! Therefore traditional DVB-T network planning is not sufficient for DVB-H, because indoor DVB-H reception requires higher electromagnetic field strength, since the receiving antenna is integrated in the terminal and not on the roof! [6] To improve indoor coverage, the main transmitters could be completed by a number of low power urban transmitters. But electromagnetic radiation limits have to be respected and there is a risk of interference on traditional TV services in the existing MATV distribution systems [7]. DVB-H 'small gap fillers' are another way to improve indoor coverage using low-power on-channel home repeaters. These consumer-grade devices can be autonomously installed by final users in their private homes, without the help of a professional installer. It is connected to the existing in-building cable distribution system [8], Its coverage area is this of a standard apartment, i.e. about 100 m2 enabling the interested users to be immediately reached by DVB-H services. Standardisation – Since these devices are radiating in the UHF band, without a specific regulation, a licence would be needed. Therefore a new standard is necessary, also to avoid that low quality (illegal) devices appear on the market, potentially causing dangerous interference on existing services (e.g. analogue or digital TV). The DVB-H Small Gap Fillers Task Force, with 21 companies involved (Broadcasters, network operators, regulation authorities, manufacturers), has prepared a Technical Specification. It has been approved by the DVB Steering Board, in June 2008, for publication as a DVB Blue Book. It will then be submitted to ETSI/CEPT for publication as European Norm (requiring voting by National Standards Organisations).

51

http://www.ietf.org/rfc/rfc3926.txt

http://www.ietf.org/rfc/rfc3926.txt

27


The DVB-H Small Gap Filler includes two sections [10]: Signal processing section (for on-channel filtering and amplification) and a built-in DVB-H receiver for output signal quality monitoring. This last stage integrates an automatic power control mechanism [12], based on the measured quality, in order to avoid interferences on existing services, even in case of failure of the device electronics or mistakes of the user. The frequency response [11] shows a high attenuation of the adjacent channels. Out-of-band emissions are according to existing regulations. Validation. The Technical Specifications have been validated in laboratory trials on real hardware prototypes [13]

and in the framework of the European Project 'CELTIC B21C'52

.

Coverage tests were conducted in the Rai-CRIT laboratories and in a real flat and proved an adequate coverage in standard apartments (e.g. 100 m2) [14]. The disturbance on adjacent TV channels was tested using 2 reference scenarios [15], with positive results [16].

Scenario Results

1 TV / STB connected to another plug of the in-building cable distribution network

Video SNR degradation within 1 dB, not noticeable on picture

2 TV / STB in another room, connected to an indoor amplified antenna

1 wall separation, 3 m distance

Video SNR degradation within 2 dB if using 2 SAW filters, not noticeable on picture.

Degradation within 5 dB with more relaxed masks (out of standard)

OK also in pessimistic condition:

Adjacent analogue TV channel received by the repeater with level 30 dB higher than DVB-H

No visible impairments using repeaters with 2 SAW filters

A CATV network could allow for a possible future extension of the DVB-H Small Gap Filler concept. The DVB-H multiplex could be transported on the CATV network on behalf of the broadcaster [17]. The indoor DVB-H coverage will be improved in areas where TV aerials are not very popular but where a CATV network is available. CATV would be used only as a carrier, no DVB-C signals being involved. This would allow to reduce the DVB-H network deployment costs. But this involves an additional requirement, the possibility of frequency conversion. Since the CATV network might not cover the full UHF band. Therefore, the coherence of the output frequency has to be guaranteed, i.e. the output frequency has to be cross-checked with the Network Information Table of the incoming stream. Moreover the network operator should guarantee the synchronisation with the traditional DVB-H transmitters as in a standard SFN [18]. Currently, frequency conversion is not included in the Specification.

52

Celtic (‘Cooperation for a sustained European Leadership in Telecommunications’) - Broadcast for the 21st

Century http://www.celtic-initiative.org/Projects/B21C/abstract.asp

http://www.celtic-initiative.org/Projects/B21C/abstract.asp

28


Abbreviations and acronyms

Note: Some terms may be specific to a speaker or/and his/her organization * points to another definition

10GE 10-Gigabit Ethernet

16-QAM 16 Quadrature amplitude modulation

1D 1-dimensional

2.5G Enhanced 2nd

generation of wireless communication systems (GPRS*, EDGE*)

2D 2-dimensional

3.5G Enhanced 3rd generation of wireless communication systems (HSDPA*)

3G 3rd

generation of wireless communication systems (UMTS*, WCDMA*)

3GPP 3rd Generation partnership project

4G 4th

generation of wireless communication systems (LTE*)

a.k.a. also known as

A/V Audio/Video, Audiovisual

AAC Advanced Audio Coding

AAC-ELD AAC* Enhanced Low Delay

AAC-LD AAC* Low Delay (MPEG-4 Audio)

AC-3 Audio Coding technology (Dolby)

ACK Acknowledge-ment message

ACL Access Control List

ADSL Asymmetric Digital Subscriber Line

AES Audio Engineering Society

AL Application Layer

AMR-WB Adaptive Multi-Rate WideBand (G.722.2)

AoIP Audio over IP (broadband audio)

APN Accelerated Private Network

ASI Asynchronous Serial Interface (DVB*)

ATM Asynchronous Transfer Mode

AVC Advanced Video Coding (MPEG-4)

AVC-I AVC* - Intra

B Bidirectional predicted picture (MPEG)

BER Bit Error Ratio

BGAN Broadband Global Area Network (Inmarsat) - cf. EBU Networks2007 seminar report § 5.3

BGP Border Gateway Protocol (Internet)

BW Bandwidth

C&W Cable & Wireless http://www.cw.com/new/

CABAC Content-based Adaptive Binary Aritmethic Coding (MPEG-4 AVC)

CATV Cable TV

CAVLC Context-based Adaptive Variable Length Coding (MPEG-4 AVC)

CBR Constant Bit Rate

CBWFQ Class-Based Weighted Fair Queuing

CCD Charge Coupled Device

CDMA Code-Division Multiple Access

CEPT Conférence Européenne des administrations des Postes et Télécommunications - European Conference of Postal and Telecommunications Administrations

cf 'Confer', consider, compare

CIF Common Intermediate Format (352*288 pixels)

http://www.cw.com/new/

29


CJI Cognacq-Jay Image (TDF* subsidiary)

CMOS Complementary Metal-Oxide Semiconductor

CMS Content Management System

COFDM Coded OFDM*

CoP# Code of Practice number… (Pro-MPEG Forum)

CPU Central Processing Unit

CQ Custom Queuing

CRIT Centro Ricerche e Innovazione Tecnologica (RAI)

CSRC Contribution Source (in RTP*)

CWDM Coarse Wavelength Division Multiplex(ing)

D-Cinema Digital Cinema

D/SVC Scalable Video Coding (EBU Project Group)

DAB Digital Audio Broadcasting

DCI Digital Cinema Initiative

DCM Dynamic Channel Path Management

DCT Discrete Cosine Transform

DiffServ Differentiated Services

DMB Digital Multimedia Broadcasting

DMZ DeMilitarised Zone

DNxHD High Definition encoding (Avid)

http://www.avid.com/resources/whitepapers/DNxHDWP3.pdf?featureID=882&marketID=

DoS Denial-of-service attack

DRM Digital radio Mondial

DSCP Differentiated Services Code Point

DSL Digital Subscriber Line

DTT(B) Digital Terrestrial Television (Broadcasting)

DV Digital Video cassette recording and compression format

DVB Digital Video Broadcasting

DVB-C DVB - Cable

DVB-H DVB - Handheld

DVB-RCS DVB with Return Channel via Satellite

DVB-T Digital Video Broadcasting - Terrestrial

DVB-T DVB - Terrestrial

DWDM Dense Wavelength Division Multiplex(ing)

DWT Discrete Wavelet Transform

e.g., eg exempli gratia, for example

e.m., EM Electro-magnetic

E/S Earth Station

E1 European PDH system level 1 (2.048 Mbit/s)

EDGE Enhanced Data rates for GSM Evolution

EF Expedited Forwarding

EN European Norm/Standard (ETSI*)

END 6.3.6 ???

ENG Electronic News Gathering

ERCS English Region Cluster Sites (BBC)

ERP Effective Radiated Power

ETSI European Telecommunications Standards Institute

FC Fibre Channel

FDM Frequency Division Multiplexing

FEC Forward Error Correction

http://www.avid.com/resources/whitepapers/DNxHDWP3.pdf?featureID=882&marketID

30


FiNE Fiber Network Eurovision (EBU)

http://www.netinsight.net/pdf/040823_Casestudy_EBU_2.pdf

FLUTE File delivery over Unidirectional Transport (RFC 3926)

FM Frequency Modulation

FRR Fast Reroute

FTP File Transfer Protocol

G.711 Pulse code modulation (PCM*) of voice frequencies (ITU-T)

G.722 7 kHz audio-coding within 64 kbit/s

Gb/s, Gbps Gigabit per second, Gbit/s

GbE, GE 1-Gigabit Ethernet

GOP Group Of Pictures (MPEG)

GPRS General Packet Radio Service

GPS Global Positioning System

GSM Global System for Mobile Communication

GUI Graphical User Interface

H Horizontal

H/W, HW Hardware

HA High Availibility

HANC ANCillary data in the Horizontal video blanking interval

HBA Host Bus Adapter

HD(TV) High-Definition (Television)

HDRR Haut Débit Réseau Régional (TDF* subsidiary)

HD-SDI High Definition SDI (1,5 Gbit/s)

HE Head-End (Cable TV)

HE-AAC High Efficiency AAC* (MPEG-4 Audio)

HF High Frequency

HFC Hybrid Fiber/Coaxial

HL High Level (MPEG-2)

HQ Headquarters

HSDPA High-Speed Downlink Packet Access

HSPA High-Speed Packet Access

HSUPA High-Speed Uplink Packet Access

HTTP HyperText Transfer Protocol

HTTPs HTTP* using a version of the SSL* or TLS* protocols

I Intra coded picture (MPEG)

i.e., ie id est, that is to say

I/HDCC High Definition Contribution Codec (EBU Project Group)

IBC International Broadcasting Convention

ICE-net Nordisk Mobiltelefon

ICT Irreversible Color Transform

IDCT Inverse DCT*

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol

IGP Interior Gateway Protocol

IMS IP Multimedia Subsystem

IMX (MPEG-) Digital Video Tape Recorder recording and compression (MPEG-2 422P@ML) format (Sony)

iNews Newsroom Computer System (Avid)

IOS-XR Self-healing and self-defending operating system (Cisco)

http://www.netinsight.net/pdf/040823_Casestudy_EBU_2.pdf

31


IP Internet Protocol

IPoDWDM IP over DWDM*

IPR Intellectual Property Rights

IPTV Internet Protocol Television, Television over IP

IRD Integrated Receiver-Decoder (-> STB*)

IRT Institut für Rundfunktechnik (Germany)

ISDN Integrated Services Digital Network

ISIS Infinitely Scalable Intelligent Storage (Avid)

ISMA Internet Streaming Media Alliance

ISO International Organization for Standardization

ISOG (WBU*-) International Satellite Operations Group

http://www.nabanet.com/wbuArea/members/ISOG.html

ISP Internet Service Provider

IT Information Technology („informatique‟)

ITIL Information Technology Infrastructure Library

ITU International Telecommunication Union

JP2K, J2K JPEG2000

KLV Key-Length-Value coding (MXF*)

Lambda Wavelength of light ( WDM*)

LAN Local Area Network

LDP Label Distribution Protocol

LLQ Low Latency Queuing for VoIP*

LOF Loss of Frame

LOS Line-of-sight

LPCM Linear PCM*

LSP Label Switched Path

LSR Label Switch Router

LTE Long Term Evolution (4G mobile system)

MAC Medium Access Control layer

MAN Metropolitan Area Network

MATV Master Antenna Television

Mb/s, Mbps Megabit per second

MDC Multiple Description Coding

MF-TDMA Multi-Frequency Time Division Multiplex Access

MDI Media Delivery Index (RFC*4445)

MIB Management Information Base (SNMP*)

ML Main Level (MPEG-2)

MoFRR Multicast-only Fast Reroute

MOSPF Multicast extension to OSPF

MP Main Profile (MPEG-2)

MP2 MPEG-1 Audio Layer II

MPE Multi-Protocol Encapsulation (DVB-H*)

MPEG Motion Picture Experts Group

MPLS Multi-Protocol Label Switching

MS Microsoft

MTR Multi-Topology Routing

MXF Material eXchange Format

n/a Not applicable / not available

N/ACIP Audio Contribution over IP (EBU Project Group)

N/IPM IP Measurements (EBU Project Group)

http://www.nabanet.com/wbuArea/members/ISOG.html

32


N/VCIP Video Contribution over IP (EBU Project Group)

NAT Network Address Translation

NC Network Connection

NGN Next Generation Networks

NHK Nippon Hoso Kyokai (Japan)

NIC Network Interface Card

NIT Network Information Table (DVB - SI)

NLOS Non line-of-sight

NMS Network Management System

MRC Maximal-Ratio Combining

NOC Network Operations Center

OB Outside Broadcasting

OFDM Orthogonal Frequency Division Multiplex(ing)

ORT Operational Reliability Testing

OSI Open Systems Interconnection

OSPF Open Shortest Path First

P Predicted picture (MPEG)

PBX Private Branch eXchange

PCM Pulse Coded Modulation

PCM Pulse Code Modulation (audio)

PDH Plesiochronous Digital Hierarchy

PE Provider Edge

PHY Physical Layer (OSI* model)

PIM Protocol Independent Multicast

PJSIP VoIP* GPL free software

PoE Power over Ethernet

POP Point Of Presence

PPP Point-Point Protocol

PQ Priority Queuing

PSTN Public Switched Telephone Network

QC Quality Control

QCIF Quarter Common Intermediate Format (176*144 pixels)

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RCS Return Channel per Satellite (DVB)

RF Radio Frequency

RFC Request For Comments (IETF standard)

RGB Red-Green-Blue (colour model)

RSTP Rapid Spanning Tree Protocol

RSVP Resource Reservation Protocol

RT Real-Time

RTBF Radio-Télévision Belge Francophone

RTCP Real-Time Control Protocol (Internet)

RTP Real-time Transport Protocol (RFC*3550)

RTSP Real-Time Streaming Protocol (Internet)

Rx Receiver

S/N, SNR Signal-to-Noise ratio

S/W, SW Software

SAN Storage Area Network

SAP Session Announcement Protocol (RFC*2974)

33


SAW (filter) Surface Acoustic Wave

SCSI Small Computer System Interface

SD(TV) Standard Definition (Television)

SDH Synchronous Digital Hierarchy

SDI Serial Digital Interface (270 Mbit/s)

SDLC Symmetric Digital Subscription Line

SDP Session Description Protocol (RFC4566)

SDSL Symmetric Digital Subscriber Line

SFN Single Frequency Network (DVB-T)

SFTP SSH (Secure Shell) FTP

SGF Small Gap Filler

SI System Information (DVB)

SIP Session Initiation Protocol (RFC*3261)

SIS Siemens IT Solutions and Services

SLA Service Level Agreement

SMPTE Society of Motion Picture and Television Engineers

SMTP Simple Mail Transfer Protocol

SNG Satellite News Gathering

SOG Summer Olympic Games

SONET Synchronous Optical Network (SDH* in U.S.A.)

SP Service/System Provider

SPH Service Points Hauts (TDF*)

SR Service Router

SR Swedish Radio

SRT Service Readiness Test

SSL Secure Socket Layer

SSM Source Specific Multicast http://www.ietf.org/ids.by.wg/ssm.html

SSO Stateful Switchover

STB Steering Board

STB Set-top box (-> IRD*)

STM-1 Synchronous Transport Module Level 1 (155 Mbit/s)

STM-4 Synchronous Transport Module Level 4 (622 Mbit/s)

SVC Scalable Video Coding

T-VIPS Norwegian company

tbd To be determined

TCP Transmission Control Protocol (Internet)

TDD Time Division Duplex(ing) (UMTS*)

TDF Télé-Diffusion de France

TDM Time Division Multiplex(ing)

TE Traffic Engineering

TLS Transport Layer Security

TMS Transport Multi-Services (TDF*)

TNG Terrestrial News Gathering (VRT)

ToE (card) TCP/IP offload Engine. An iSCSI TOE card offloads the Gigabit Ethernet and SCSI packet processing from the CPU.

TOS Type-Of-Service

TR Temporal Redundancy

TS Transport Stream (MPEG-2)

Tx Transmitter

UA Unit Address

http://www.ietf.org/ids.by.wg/ssm.html

34


UAT User Acceptance Test

UDP User Datagram Protocol (RFC*768)

UHF Ultra High Frequency

UID Universal IDentifier

UTRA TDD UMTS Terrestrial Radio Access Time Division Duplex

UMTS Universal Mobile Telecommunications System

UPA(HS) Uplink Packet Access (High-Speed)

V Vertical

VALID Video and Audio Line-up and Identification (http://www.pro-bel.com/products/C132/ )

VANC ANCillary data in the Vertical video blanking interval

VBR Variable Bit Rate

VC-2 SMPTE code for the BBC's Dirac Video Codec

VCEG Video Coding Experts Group (ISO/IEC-MPEG + ITU-T)

VJ Video Journalist

VLAN Virtual LAN*

VLC Variable Length Coding

VoIP Video over IP

VoIP Voice over IP(narrowband audio)

VP Virtual Path

VPLS Virtual Private LAN Services

VPN Virtual Private Network

VQEG Video Quality Experts Group (ITU)

VRT Vlaamse Radio- en Televisieomroep, Flemish Radio- and Television Network (Belgium)

vs. versus; against, compared to

VSAT Very Small Aperture Terminal

VSF Video Services Forum http://videoservicesforum.net/index.shtml

W Watt

w. With

WAN Wide Area Network

W-CDMA, WCDMA Wideband CDMA*

WBU World Broadcasting Unions

http://www.nabanet.com/wbuArea/members/about.asp

WC World Championship

WDM Wavelength Division Multiplexing ( Lambda*)

WFQ Weighted Fair Queuing

WiFi Wireless Fidelity

WiMAX Worldwide Interoperability for Microwave Access (IEEE 802.16)

WLAN Wireless LAN IEEE 802.11(a,b & g)

WOG Winter Olympic Games

xDSL x DSL* (x = Asymetrical or Symetrical uplink/downlink)

YCbCr Digital luminance and colour difference information

http://www.pro-bel.com/products/C132/

http://videoservicesforum.net/index.shtml

http://www.nabanet.com/wbuArea/members/about.asp

35


Tableau 1: Towards lossless video transport - Deployment scenarios (§ 1.1) [© Cisco]

1) Fast Convergence

or Fast Reroute

(FRR)

[8]

2) Application Layer

Forward Error Correction (FEC)

[15]

3) Temporal Redundancy

(TR)

[16]

4) Spatial (Path) Diversity

("live / live")

[18]

5) Multicast-only Fast Reroute

(MoFRR)

[20]

Network reconverges** / reroutes*

on core network failure (link or node).

Adds redundancy to the transmitted data to allow the receiver to detect and correct errors (within some bound), without the need to resend any data.

The transmitted stream is broken into blocks, each block is then sent twice, separated in time.

If block separation period is greater than the loss of connectivity, at least one packet should be received and video stream play-out will be uninterrupted.

Two streams are sent over diverse paths between the sender and receiver

Deliver two disjoint branches of the same PIM (Protocol Independent Multicast) SSM (Source Specific Multicast) tree to the same Provider Edge

The Provider Edge locally switch to the backup branch upon detecting a failure on the primary branch

http://www.nanog.org/mtg-0802/farinacci.html

Lowest bandwidth requirements in working and failure case

Lowest solution cost and complexity

The simplest and cheapest design / operational approach for a Service Provider is to have such behaviors optimised by default in the software and hardware implementations and is applicable to all its services.

Supports hitless recovery from loss due to core network failures if loss can be constrained

No requirement for network path diversity - works for all topologies

Supports hitless recovery from loss due to core network failures if loss can be constrained

No requirement for network path diversity – works for all topologies

Supports hitless recovery from loss due to core network failures if have network stream split and merge functions (e.g. Dynamic Channel path Management)

Lower overall bandwidth consumed in failure case compared to FEC

Introduces no delay if the paths have equal propagation delays

Hitless: The Provider Edge uses the two branches to repair losses and present lossless data to its IGMP (Internet Group Management Protocol) neighbors

A simple approach from a design and deployment and operations perspective

Requires fast converging network to minimize visible impact of loss

Requires fast converging network to minimize AL-FEC overhead

Requires fast converging network to minimize block separation period

May require network-level techniques to ensure spatial diversity, MoFRR (5), Multi-Topology Routing, Traffic Engineering; required techniques depend upon topology

MPLS and Multi-Topology Routing are options in topologies that do not support MoFRR

Is not hitless - will result in a visible artifact to the end users

Higher overall bandwidth consumed in failure case compared to "live / live" (4)

Incurs delay - longer outages require larger overhead or larger block sizes (more delay)

Incurs 100% overhead

Incurs delay - longer outages require larger block separation period



36


(*) According to the number of multicast groups 400 - 800 - 4000, the median / max reconvergence time for all channels following a network failure may amount to 200/290 ms – 260/380 ms (no more than 1 frame loss) – 510/880 ms [11]. To improve it, prefix prioritisation allows important groups (e.g. premium channels) to converge first, and developments with IP optical integration can further reduce the outage to sub 20ms in many cases (lossless in some cases) by identfying degraded link using optical data and signaling before the traffic starts failing [12].

(**) Fast rerouting: the routing protocol detects the failure and computes an alternate path around the failure [10]. But loss of connectivity is experienced before the video stream connectivity is restored.

37


Tableau 2: Practical measurement and practical network performance (§ 1.2) [© Siemens]

Practical measurement Practical Network performance

Audio latency

and

lip-sync

With a commercially available Lip-sync measurement system; VALID from Pro-Bel. It uses a test signal with time markers in the picture and sound by which a VALID reader can measure the audio to video timing and display the result directly in millisecond [7] [8]. For latency measurement [6], the generator's video signal is connected direct to the reader while the audio is passed through the system under test. The measurement is therefore the latency of the audio path. This is applicable to both sound only and sound with vision circuits.

It is still routine to find codecs that make only a modest effort to get lip-sync correct. ln all cases dealt with, the IP packets carry Transport Stream and there really is no good reason for getting it wrong. Some have had large errors that are clearly unacceptable. Some have fixed errors that on their own are acceptable but add to the perennial lip-sync problems. A few just get it exactly right.

Network latency The simple approach is to measure the round trip latency [10]. Ping is a simple and effective tool but has to be used with care. If QoS is used - essential when the route is shared with data traffic - the Ping traffic through another port is unlikely to receive the same QoS marking as the media traffic. However, it can still be used when the connection is being set up and before business traffic is carried. The media stream can be run over the connection before any other traffic is routed.

It is possible to measure latency over a single route using test equipment with GPS references at each end [9]. So far these tests have confirmed the round trip latency is simply double the one way latency. This goes wrong if there are unexpected constraints in the network configuration but these are very likely to show up in other ways, usually as severe packet loss.

Siemens is currently delivering an audio network specified as better than 50ms one way but it is accepted that the measurement is round trip and therefore better than 100ms. The route distances range up to 400km but it is really the number of routers in the circuit that determine the IP latency. The overall latency is dependent on compression system and settings, other things being equal. ln the case of audio, the lower bit rate, the more time is required to make up an IP packet. Live vision circuits have to be timed so a synchroniser is required. This can be built into the codec or separate but either way it will add to the overall latency.

Network jitter Again, Ping is a useful tool if used appropriately [15]-[17]. Networks have a tendency to suffer 'data storms' - a useful catchall phrase for sudden and unpredictable changes in the latency and jitter. If the ping time is stable while the media traffic is running, it is a very good sign. As ping time jitter starts to rise, the likelihood is media traffic is affected as well. I have captured the effects of data storms on ping time and correlated them with damage to the media stream. Sometimes however, network operators are reluctant to accept this simple test as evidence of problems.

More sophisticated testers can measure the performance with full bit rate data in both the Expedited Forwarding and the Best Effort QoS levels. Ideally, this type of testing is done as part of the acceptance testing of a network connection by the service provider.

There is no clear cut definition of jitter in this context. The issue is the variation in IP packet transit time so as to exceed the decoder buffer capacity. Some coding systems can deliver a very steady flow of IP data. Others have a steady long term average but show substantial variation in the short term.

Video jitter Some codecs maintain their IP buffers at the mid point by pulling the output video frequency. If there is a significant jump in the IP latency, as may happen when switching to a backup route, the output video can become so far off frequency that downstream equipment cannot follow it. Unfortunately, there is no clear cut specification for SDI clock frequency tolerances in the broadcast standards for manufacturers to follow. A synchroniser is normally needed anyway and they accept the widest frequency range.

[19] [20]

38


Practical measurement Practical Network performance

This type of codec is deriving the SDI clock frequency from the IP data rate so SOI clock jitter can occur if the design is not sufficiently careful.

Decoders with built in synchronising have a reference input and deal with these problems internally but add cost and latency.

Glitches A fixed tone signal passed through the circuit is filtered using typically a distortion analyser to remove the fundamental [11]. Any pulses over and above noise and distortion marks a glitch. The pulses from the distortion analysis can trigger a digital storage scope, providing a record of the glitch in the tone and a count of the events [12]. The test is run for an agreed period, 12 to 48 hours. ln practice though, if glitches are really a problem, they will usually start within the first few minutes. The exception is where the test is run in conjunction with less predictable traffic over the same route.

The users naturally want zero audible and visible glitches and we have tested audio circuits on this basis. While this is good goal to achieve, it is not practical in a managed service. The circuit has to be taken out of service for a long period just to make the measurement and this is after the event that a customer had cause to complain about.

It is more realistic therefore to translate this requirement to the performance of the network and codecs. ln practice, this information can only be measured by the decoder. So coders with good traffic analysis and logging are an advantage.

When comparing with pre-existing circuits, e.g. E1/T1, it is interesting to note that the maximum permitted bit error rate for the connection is often quoted as 1 in 10e9. This would imply 2 glitches an hour in a high quality audio circuit but in reality, E1 normally performs several orders of magnitude better than this so user expectations are much higher.

The audibility of glitches is a highly contentious subject. The relationship between network events, the technical effect on the audio path and the audibility of the effect in real program material of different types could be the subject of a huge survey.

39


Tableau 3: HD contribution codecs (§ 4.1) [© EBU]

MPEG-2 MPEG-4 AVC / H.264 JPEG2000 Dirac Pro MPEG-4 SVC / H.264

Standard ISO/IEC 13818 ISO/IEC 14496 ISO 19446-1 SMPTE VC-2

(Developped by BBC Research)

Amendment to H.264/AVC standard

Principle DCT based system

Spatial and temporal prediction with variable length statistical coding (VLC)

Spatial and temporal compression with a choice between context adaptive arithmetic coding (CABAC) or variable length (CAVLC)

Wavelet based (DWT) compression system coupled to an arithmetic coder.

Lossless and lossy compression

Mixing the advantages of the wavelet transform and motion compensation.

Similar wavelet filters to JPEG2000

Structure 6 Profiles (prediction tools supported) and 4 levels (image formats and max bit-rate supported)

For contribution:

Main profile (4:2:2) I,P and B frame prediction

@ High level (1920x1080) up to 80 Mbit/s

7 Profiles and 5 levels

For contribution (at the moment):

High profile 4:2:2 – 10bit

Level 4.1 (1080i and 720p)

Only DCI profiles exist at the moment.

Broadcast application profiles under investigation in JPEG.

Follows H.264 profiles.

Scalability (provided SVC amendment)

Highly scalable

Spatially – Wavelet transform.

Temporally – I frames

Quality – statistical coder

Spatially scalable due to the wavelet.

Scalability on top of H.264 High coding efficiency

Scalability is provided layer-wise:

Base layer H.264/AVC compatible.

Enhancement layer SVC decodable.

Pros Several products available.

Well known technology

Cheap

Proven 50% benefit compared to MPEG-2 in primary distribution bit-rate range

State of the art codec (using context based arithmetic coding)

High compression capability with good quality at low bit

Already in use by some broadcasters for internal contribution

Used by DCI for 2k and 4k image format archival.

Scalability might be useful to embbed several spatially different streams in the same feed.

Strong error resillience of the codestream useful for transmission in error prone channels enabled by synchronisation

Strong sustainability to cascadings

Open source and License free – no commercial risk.

Very low latency (order of 6ms) since it use variable length coding for entropy coding.

Support for 10 bit depth 4:2:2

Product available

All pros of H.264/AVC

Backward compatible with H.264/AVC

Primarily considered for distribution but might appear useful in contribution; needs 10 to 30% less bit rate than simulcast.

40


MPEG-2 MPEG-4 AVC / H.264 JPEG2000 Dirac Pro MPEG-4 SVC / H.264

rate.(suitable for SNGs)

Enhanced Error resilience with synchronization mechanism in the codestream

High bit depth range.

I frame only – no interdependence between frames ; valuable for editing

Visually friendly artifacts.

Low latency (approx 45ms)

Part – 1 of the standard IPR free – no license fees

Proof of better performances than AVC-I for high quality large images. [] (reference software)

(Hardware & software)

Handles formats from 720p/50, 1080i25, 1080p/50, to 4K. (Futureproof.)

Lossless and visually lossless compression

Cons Not anymore state of the art compression system.

Better technologies exist (H.264/AVC; DIRAC etc.) but the gain is still unknown

Bandwidth greedy for High quality sequence exchange [see BBC presentation - EBU Production Technology 2007 seminar report § 1.2]

80Mbit/s needed for high quality content exchange => too expensive on satellite

GoP based system

Potential for emphasised GoP Pumping visual effect in video sequences (pulsing loss of resolutions) in cascades.

Additional decoding delay due to inter-frame coding

DCT based => blocky artifacts not visually friendly

Not that many products avalaible with the full contribution profile tools (Hi422 Level 4.1)

High coding Latency (over 800ms)

GoP-based

Additional decoding delay for post production.

GoP pumping effect.

Gain over MPEG-2 in high bit rates (contribution) not yet defined.

Needs very High bit rates to provide very good visual quality (over 100Mbit/s) depending on the image format) under cascaded and shifted generations

Not that many products available.

No comparison with other systems made till now

All cons of H.264/AVC

No product available yet

41


Tableau 4: The ovewhelming crowd of networks worldwide! [© IRT]

Acccess technique Bit rate (uplink) Performance of relevant networks

(measured)

Transfer duration

of a 5-minute material

(4 Mbit/s material)

Fixed line

Tel. modem 56 kbit/s

ISDN 128 kbit/s

ADSL 640 kbit/s

SDSL 4.6 Mbit/s Arcor Business ~ 1.95 Mbit/s ~ 10 min.

VDSL 50 Mbit/s T-Home/IRT ~ 2.94 Mbit/s ~ 6.7 min

Cable network 40 Mbit/s

Powerline (PLC) 200 Mbit/s

Wireless

WLAN (802.11b/g) 11 / 54 Mbit/s InternetCafe Munich

EBU WiFi

~ 870 kbit/s

~ 3.55 Mbit/s

~ 30 min.

~ 5.6 min.

Satellite link 1 Mbit/s

GSM 12 kbit/s

GPRS 171.2 kbit/s

HSCSD 57.6 kbit/s

EDGE 473 kbit/s

CDMA One 14.4 kbit/s

UMTS 128 kbit/s Vodafone ~ 120 kbit/s ~ 180 min.

HSUPA 5.8 Mbit/s

CDMA2000 144 kbit/s

EV-DO 5.4 Mbit/s

Flash OFDM 900 kbit/s

LTE / HSUPA 50 Mbit/s Vodafone ~ 1.35 Mbit/s ~ 14.5 min

WiMAX (mobile) 7 Mbit/s IRT-TESTnet ~ 1.15 Mbit/s ~ 17 min.

iBURST 346 kbit/s

EBU Networks 2008 Report FINAL Tcm6 62796

Documents

Transcript of EBU Networks 2008 Report FINAL Tcm6 62796