EBU Networks 2008 Report FINAL Tcm6 62796

1
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-Nol Gouyet, EBU International Training Revised and proof-read by the speakers
EBU Networks 2008 Seminar / 23 - 24 June 2008 Reproduction prohibited without written permission of the EBU Technical Department & EBU International Training
2
Opening round table4
1 1.1 1.2 1.3 1.4 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.3 4 4.1 4.2 4.3 5 5.1 5.2 5.3 6 6.1 6.2 6.3
IP and MPLS ................................................................................................................ 6 Concepts and protocols ................................................................................................ 6 Traffic engineering ........................................................................................................ 7 Video over IP - Maintaining QoS ................................................................................... 8 Practical application ...................................................................................................... 9 Audio Contribution over IP ...................................................................................... 10 The ACIP standard - A tutorial .................................................................................... 10 Implementing and testing ACIP using open source software ...................................... 11 Interoperability in action .............................................................................................. 13 Demos ........................................................................................................................ 14 Video contribution over IP ....................................................................................... 15 Video contribution over IP The EBU project group N/VCIP ...................................... 15 Real-time transport of television using JPEG2000 ...................................................... 16 France 3's new contribution network over IP ............................................................... 17 HD over Networks ..................................................................................................... 18 HD contribution codecs ............................................................................................... 18 Practical thoughts and wishes or whishful thinking! ................................................. 19 Eurovision experience in HD contribution ................................................................... 20 Real world applications: the News .......................................................................... 21 The use of COFDM for ENG applications ................................................................... 21 Getting News to base, or 'Only connect'? ................................................................... 22 How to connect your Video Journalists (VJ) ................................................................ 22 Real world applications - Production and Broadcast............................................. 23 Architecting a fully-networked production environment ............................................... 23 Bringing the BBC's networks into the 21st century ....................................................... 25 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
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:ft4train@ftp.ebu.ch The slides number [in brackets] refer to the slides of the corresponding presentation. To help "decode" the abbreviations and acronyms 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.
1
Many thanks to all the speakers and session chairmen who revised the report draft. Special thanks to Peter CalvertSmith (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
More than 325!

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 2 example, SVT Swedish Radio by using Audio over IP (AoIP) for Ice Hockey championships 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 3
cf. 2.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.
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, Cisco , 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 4
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
Increasing Cost and Complexity

Traffic Engineering + Live / Live Multi-Topology Routing (MTR) + Live / Live MPLS TE FRR + FEC or Temporal Redundancy Muticast-only Fast Reroute + Live / Live Fast Convergence + FEC or Temporal Redundancy Muti-Protocol Label Switching (MPLS) Traffic Engineering (TE) Fast Reroute (FRR)
Network Re-engineering
Increasing Loss
No network Re-engineering
Muticast-only Fast Reroute (MoFRR)
Fast Convergence
Lossless
1 GOP Impacted
1.2 Traffic engineering

Peter Calver-Smith, Siemens IT Solutions and Services , 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)
55 www.siemens.co.uk/it-solutions http://www.siemens.com/index.jsp?sdc_p=c0u2m0p0 EBU Networks 2008 Seminar / 23 - 24 June 2008 Reproduction prohibited without written permission of the EBU Technical Department & EBU International Training 5
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. 8 IRIS 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 (LSPs) 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 7 8
A formal method of tracking and recording proposed and actual changes to a system 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 Paths (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'
Inside the cloud

Dedicated private line circuits SONET / Dark Fiber / SDH / Wavelengths / Ethernet
1.4 Practical application

Grard LOTTE, TDF, France The TDF company is a group of French and European subsidiaries [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 9
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 TDFs 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].
Audio Contribution over IP
Audio over IP equipment from one manufacturer has until now not been compatible with another manufacturers 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) to create a standard for 12 interoperability. This standard, EBUTECH 3326 (revision 3) published in April 2008 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 ITU-R G.711 A-Law & -Law (U.S.A. + Japan) 64 kbit/s ITU-R G.722 64 kbit/s 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 Linear PCM (raw) 16 / 20 / 24 bits ** Optional for portable equipment Recommended audio codecs MPEG-4 AAC Low Complexity Profile MPEG-4 AAC-LD 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 3GPP AMR-WB+ (Adaptive Multi-Rate Wideband) Optional audio codecs Enhanced APT-X
13 11
MPEG-4 HE-AACv2 Dolby AC-3
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
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 14 associate names with IP addresses and allow a reporter 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 High quality but expensive Copper with xDSL SDSL: Symetrical uplink / downlink Bit errors lead to packet losses Mobile (3G/UMTS, Wimax, LTE) Increasing bit rates but unreliable No solutions with guaranteed QoS nowadays HSDPA / HSUPA shared channel Satellite Long delays, often shared bandwidth Inmarsat BGAN, DVBRCS providers (Eurovision in the future?) Wireless 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 . Therefore it doesnt 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 16 additional mandatory codecs G.722 and MPEG-2 Layer II (codec extension of PJSIP ). 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 manufacturers took part. All bought one unit for testing. All units tested against each other and also to the EBU reference over a three day 12 period [17]-[21]. Participants actively discussed details in the EBU Tech 3326 document 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.
17
15
14 15 16 17
e.g. - sip:reportername@sr.se or telephone number http://sourceforge.net/index.php http://www.pjsip.org/
AEQ (Spain) http://www.aeq.es/eng/index.htm , AETA (France) http://www.aeta-audio.com , AVT (Germany) http://www.avtnbg.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
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 PCs 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 18 than 180 tests were undertaken including reruns of some tests. G.711 was tested using an Asterisk SIP server; G.722, MPEG Layer II and Linear PCM were tested without the SIP proxy. All rounds were recorded (2 GB of data 19 stored) using the open source Wireshark 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 Technology 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 19 20 20
http://www.asterisk.org/ http://www.wireshark.org/ http://www.bbc.co.uk/rd/fot/handouts.shtml

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

Bjrn WESTERBERG, SR, Sweden What kinds of networks have we been testing and using?
Wired networks Unmanaged 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 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 Managed with QoS Technology: MPLS (MultiProtocol Label Switching) Wireless networks 'Unmanaged' Technologies: - '3G': UMTS/WCDMA (100200 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 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. Managed 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
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 Radios 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!)
APT APT
Figure 4: Audio over IP codecs and SIP
15
IRT/BBC Reference (Unit in Geneva)
Commander G3 Tieline (Australia) (Unit in Geneva)
Scoopy AETA, (France) (Unit in Geneva)
SIP Proxy and Registrar Server (Unit in UK)
Scoop4+ AETA, (France) (Unit in UK)
Scoop4+ AETA, (France) (Unit in Germany)
PortaNet Prodys (Spain) (Unit in Geneva)
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 21 3318 . 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 http://www.ebu.ch/CMSimages/en/tec_doc_t3318-2008_tcm6-60595.pdf

16
Profile 1 Uncompressed video (SD, HD) over IP Profile 2 Compressed high bit rate profile: Transport Stream over IP according to Recommendation SMPTE 22 2022 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 FEC level B (row and column) To be defined No FEC specified yet - ISMA standard has to be enhanced with FEC Very efficient lower bit rate profile Profile 3 MXF over IP Profile 4 Low bit rate: ISMA 2.0 (Internet Streaming Media Alliance) Between profile 1 and 2 (uncompressed or compressed) ~ 3 - 15 Mbit/s for SD (576i25) for News
Estimated bandwidth requirements incl. possible overhead (draft) FEC
~ 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) FEC - still to be cross checked with existing specifications
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 No complete standard available at the moment Transmission networks expensive? Capacity available? Video Services Forum (VSF) proposal is under evaluation SMPTE???
Suitable for compressed and uncompressed video No standard available yet Standard has to be created!
Pending questions
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-VIPS , 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 23
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/
17 24 JPEG2000 MXF storage format defined (SMPTE 422M ) 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). 26 The Forward Error Correction (FEC) [22] corresponds to the Pro-MPEG Forum Code of Practice #4 or to the 27 SMPTE 2022 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-toany 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 25 26 27 28 SMPTE 422M-2006 Material Exchange Format Mapping JPEG2000 Codestreams into the MXF Generic Container
http://www.thomsongrassvalley.com/products/infinity/camcorder/ Peter Elmer and Henry Sariowan 'Interoperability for Professional Video Streaming over IP Networks' SMPTE 2022-1-2007 Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks http://www.itu.int/ITU-T/ngn/
www.broadcastpapers.com/whitepapers/paper_loader.cfm?pid=221
18
dont 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 29 The MPEG-2 encoders / decoders 'ViBE' are products from Thomson Grass Valley , 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.
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 30
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 its own demanding, but not unduly so, multi-genre TV-program Fairytale in 3840x2160p50 (hence 31 1080p, 1080i, 720p and 576i).. 3 reference sequences "CrowdRun", "ParkJoy" and "InToTree" can be downloaded 32 33 from the EBU Web site or from the ITU-VQEG FTP site . All sequences from this set were filmed in 50 fps with 34 professional, high-end 65mm film equipment by SVT in October 2004. ITU-R BT.1122 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 WAN [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 JPEG2000based 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 32 35
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/ 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
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 isnt 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 36 (59.94 to 50) with good performance 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 37 34 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 37
For example, from Teranex 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 timeAnd anyway how much broadcasters are ready to pay? File transfer is an alternative with lower costs (and increased picture quality?).
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 38 Research Ltd 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-toend 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 39 Antwerp, Ghent and on the Belgian Coast . 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-ofsight) 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 39
http://www.linkres.co.uk/ Belgian coast network is not yet operational but will be soon
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 wasnt 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 41 42 satphone, the videophone, the undreamt of speed of 128 kbit/s. And now the BGAN , the new Thuraya system , 43 44 45 Streambox , Quicklink , vPoint and so on. And in many places HSDPA/&UPA, WiMAX and, even in remote areas, within months, 384 kbit/s of bandwidth. But again its not that simple, because its 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 46 after editing with a tool based on Rhozet 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 its 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 doesnt 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 43 44 45 46
http://www.thuraya.com/ http://www.streambox.com/ http://www.quicklink.tv/ http://www.vcon.com/ Carbon Coder 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 47 48 3.3 Mbit/s with CryptoGuard VPN software (with AES encryption) and decrease to 1.9 Mbit/s with OpenVPN , 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)
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 48
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 49 insufficient. If a TCP-based data flow is used there will be lots of CPU requirement unless ToE -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 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 reconfigured 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
50
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=
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 BBCs 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 PBXs 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. 51 DVB/H supports the datacast of files using the FLUTE protocol . 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
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] 52 and in the framework of the European Project 'CELTIC B21C' . 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 TV / STB connected to another plug of the in-building cable distribution network TV / STB in another room, connected to an indoor amplified antenna 1 wall separation, 3 m distance Results Video SNR degradation within 1 dB, not noticeable on picture 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
28
Abbreviations and acronyms

Note: Some terms may be specific to a speaker or/and his/her organization * points to another definition
10GE 16-QAM 1D 2.5G 2D 3.5G 3G 3GPP 4G a.k.a. A/V AAC AAC-ELD AAC-LD AC-3 ACK ACL ADSL AES AL AMR-WB AoIP APN ASI ATM AVC AVC-I B BER BGAN BGP BW C&W CABAC CATV CAVLC CBR CBWFQ CCD CDMA CEPT cf CIF 10-Gigabit Ethernet 16 Quadrature amplitude modulation 1-dimensional Enhanced 2
nd
generation of wireless communication systems (GPRS*, EDGE*)
2-dimensional Enhanced 3rd generation of wireless communication systems (HSDPA*) 3 generation of wireless communication systems (UMTS*, WCDMA*) 3rd Generation partnership project 4 generation of wireless communication systems (LTE*) also known as Audio/Video, Audiovisual Advanced Audio Coding AAC* Enhanced Low Delay AAC* Low Delay (MPEG-4 Audio) Audio Coding technology (Dolby) Acknowledge-ment message Access Control List Asymmetric Digital Subscriber Line Audio Engineering Society Application Layer Adaptive Multi-Rate WideBand (G.722.2) Audio over IP (broadband audio) Accelerated Private Network Asynchronous Serial Interface (DVB*) Asynchronous Transfer Mode Advanced Video Coding (MPEG-4) AVC* - Intra Bidirectional predicted picture (MPEG) Bit Error Ratio Broadband Global Area Network (Inmarsat) - cf. EBU Networks2007 seminar report 5.3 Border Gateway Protocol (Internet) Bandwidth Cable & Wireless http://www.cw.com/new/ Content-based Adaptive Binary Aritmethic Coding (MPEG-4 AVC) Cable TV Context-based Adaptive Variable Length Coding (MPEG-4 AVC) Constant Bit Rate Class-Based Weighted Fair Queuing Charge Coupled Device Code-Division Multiple Access Confrence Europenne des administrations des Postes et Tlcommunications - European Conference of Postal and Telecommunications Administrations 'Confer', consider, compare Common Intermediate Format (352*288 pixels)
th rd
29
CJI CMOS CMS COFDM CoP# CPU CQ CRIT CSRC CWDM D-Cinema D/SVC DAB DCI DCM DCT DiffServ DMB DMZ DNxHD DoS DRM DSCP DSL DTT(B) DV DVB DVB-C DVB-H DVB-RCS DVB-T DVB-T DWDM DWT e.g., eg e.m., EM E/S E1 EDGE EF EN END ENG ERCS ERP ETSI FC FDM FEC Cognacq-Jay Image (TDF* subsidiary) Complementary Metal-Oxide Semiconductor Content Management System Coded OFDM* Code of Practice number (Pro-MPEG Forum) Central Processing Unit Custom Queuing Centro Ricerche e Innovazione Tecnologica (RAI) Contribution Source (in RTP*) Coarse Wavelength Division Multiplex(ing) Digital Cinema Scalable Video Coding (EBU Project Group) Digital Audio Broadcasting Digital Cinema Initiative Dynamic Channel Path Management Discrete Cosine Transform Differentiated Services Digital Multimedia Broadcasting DeMilitarised Zone High Definition encoding (Avid) http://www.avid.com/resources/whitepapers/DNxHDWP3.pdf?featureID=882&marketID= Denial-of-service attack Digital radio Mondial Differentiated Services Code Point Digital Subscriber Line Digital Terrestrial Television (Broadcasting) Digital Video cassette recording and compression format Digital Video Broadcasting DVB - Cable DVB - Handheld DVB with Return Channel via Satellite Digital Video Broadcasting - Terrestrial DVB - Terrestrial Dense Wavelength Division Multiplex(ing) Discrete Wavelet Transform exempli gratia, for example Electro-magnetic Earth Station European PDH system level 1 (2.048 Mbit/s) Enhanced Data rates for GSM Evolution Expedited Forwarding European Norm/Standard (ETSI*) 6.3.6 ??? Electronic News Gathering English Region Cluster Sites (BBC) Effective Radiated Power European Telecommunications Standards Institute Fibre Channel Frequency Division Multiplexing Forward Error Correction
30
FiNE FLUTE FM FRR FTP G.711 G.722 Gb/s, Gbps GbE, GE GOP GPRS GPS GSM GUI H H/W, HW HA HANC HBA HD(TV) HDRR HD-SDI HE HE-AAC HF HFC HL HQ HSDPA HSPA HSUPA HTTP HTTPs I i.e., ie I/HDCC IBC ICE-net ICT IDCT IEC IEEE IETF IGMP IGP IMS IMX (MPEG-) iNews IOS-XR Fiber Network Eurovision (EBU) http://www.netinsight.net/pdf/040823_Casestudy_EBU_2.pdf File delivery over Unidirectional Transport (RFC 3926) Frequency Modulation Fast Reroute File Transfer Protocol Pulse code modulation (PCM*) of voice frequencies (ITU-T) 7 kHz audio-coding within 64 kbit/s Gigabit per second, Gbit/s 1-Gigabit Ethernet Group Of Pictures (MPEG) General Packet Radio Service Global Positioning System Global System for Mobile Communication Graphical User Interface Horizontal Hardware High Availibility ANCillary data in the Horizontal video blanking interval Host Bus Adapter High-Definition (Television) Haut Dbit Rseau Rgional (TDF* subsidiary) High Definition SDI (1,5 Gbit/s) Head-End (Cable TV) High Efficiency AAC* (MPEG-4 Audio) High Frequency Hybrid Fiber/Coaxial High Level (MPEG-2) Headquarters High-Speed Downlink Packet Access High-Speed Packet Access High-Speed Uplink Packet Access HyperText Transfer Protocol HTTP* using a version of the SSL* or TLS* protocols Intra coded picture (MPEG) id est, that is to say High Definition Contribution Codec (EBU Project Group) International Broadcasting Convention Nordisk Mobiltelefon Irreversible Color Transform Inverse DCT* International Electrotechnical Commission Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Group Management Protocol Interior Gateway Protocol IP Multimedia Subsystem Digital Video Tape Recorder recording and compression (MPEG-2 422P@ML) format (Sony) Newsroom Computer System (Avid) Self-healing and self-defending operating system (Cisco)
31
IP IPoDWDM IPR IPTV IRD IRT ISDN ISIS ISMA ISO ISOG (WBU*-) ISP IT ITIL ITU JP2K, J2K KLV Lambda LAN LDP LLQ LOF LOS LPCM LSP LSR LTE MAC MAN MATV Mb/s, Mbps MDC MF-TDMA MDI MIB ML MoFRR MOSPF MP MP2 MPE MPEG MPLS MS MTR MXF n/a N/ACIP N/IPM Internet Protocol IP over DWDM* Intellectual Property Rights Internet Protocol Television, Television over IP Integrated Receiver-Decoder (-> STB*) Institut fr Rundfunktechnik (Germany) Integrated Services Digital Network Infinitely Scalable Intelligent Storage (Avid) Internet Streaming Media Alliance International Organization for Standardization International Satellite Operations Group http://www.nabanet.com/wbuArea/members/ISOG.html Internet Service Provider Information Technology (informatique) Information Technology Infrastructure Library International Telecommunication Union JPEG2000 Key-Length-Value coding (MXF*) Wavelength of light ( WDM*) Local Area Network Label Distribution Protocol Low Latency Queuing for VoIP* Loss of Frame Line-of-sight Linear PCM* Label Switched Path Label Switch Router Long Term Evolution (4G mobile system) Medium Access Control layer Metropolitan Area Network Master Antenna Television Megabit per second Multiple Description Coding Multi-Frequency Time Division Multiplex Access Media Delivery Index (RFC*4445) Management Information Base (SNMP*) Main Level (MPEG-2) Multicast-only Fast Reroute Multicast extension to OSPF Main Profile (MPEG-2) MPEG-1 Audio Layer II Multi-Protocol Encapsulation (DVB-H*) Motion Picture Experts Group Multi-Protocol Label Switching Microsoft Multi-Topology Routing Material eXchange Format Not applicable / not available Audio Contribution over IP (EBU Project Group) IP Measurements (EBU Project Group)
32
N/VCIP NAT NC NGN NHK NIC NIT NLOS NMS MRC NOC OB OFDM ORT OSI OSPF P PBX PCM PCM PDH PE PHY PIM PJSIP PoE POP PPP PQ PSTN QC QCIF QoS QPSK RCS RF RFC RGB RSTP RSVP RT RTBF RTCP RTP RTSP Rx S/N, SNR S/W, SW SAN SAP Video Contribution over IP (EBU Project Group) Network Address Translation Network Connection Next Generation Networks Nippon Hoso Kyokai (Japan) Network Interface Card Network Information Table (DVB - SI) Non line-of-sight Network Management System Maximal-Ratio Combining Network Operations Center Outside Broadcasting Orthogonal Frequency Division Multiplex(ing) Operational Reliability Testing Open Systems Interconnection Open Shortest Path First Predicted picture (MPEG) Private Branch eXchange Pulse Coded Modulation Pulse Code Modulation (audio) Plesiochronous Digital Hierarchy Provider Edge Physical Layer (OSI* model) Protocol Independent Multicast VoIP* GPL free software Power over Ethernet Point Of Presence Point-Point Protocol Priority Queuing Public Switched Telephone Network Quality Control Quarter Common Intermediate Format (176*144 pixels) Quality of Service Quadrature Phase Shift Keying Return Channel per Satellite (DVB) Radio Frequency Request For Comments (IETF standard) Red-Green-Blue (colour model) Rapid Spanning Tree Protocol Resource Reservation Protocol Real-Time Radio-Tlvision Belge Francophone Real-Time Control Protocol (Internet) Real-time Transport Protocol (RFC*3550) Real-Time Streaming Protocol (Internet) Receiver Signal-to-Noise ratio Software Storage Area Network Session Announcement Protocol (RFC*2974)
33
SAW (filter) SCSI SD(TV) SDH SDI SDLC SDP SDSL SFN SFTP SGF SI SIP SIS SLA SMPTE SMTP SNG SOG SONET SP SPH SR SR SRT SSL SSM SSO STB STB STM-1 STM-4 SVC T-VIPS tbd TCP TDD TDF TDM TE TLS TMS TNG ToE (card) TOS TR TS Tx UA Surface Acoustic Wave Small Computer System Interface Standard Definition (Television) Synchronous Digital Hierarchy Serial Digital Interface (270 Mbit/s) Symmetric Digital Subscription Line Session Description Protocol (RFC4566) Symmetric Digital Subscriber Line Single Frequency Network (DVB-T) SSH (Secure Shell) FTP Small Gap Filler System Information (DVB) Session Initiation Protocol (RFC*3261) Siemens IT Solutions and Services Service Level Agreement Society of Motion Picture and Television Engineers Simple Mail Transfer Protocol Satellite News Gathering Summer Olympic Games Synchronous Optical Network (SDH* in U.S.A.) Service/System Provider Service Points Hauts (TDF*) Service Router Swedish Radio Service Readiness Test Secure Socket Layer Source Specific Multicast http://www.ietf.org/ids.by.wg/ssm.html Stateful Switchover Steering Board Set-top box (-> IRD*) Synchronous Transport Module Level 1 (155 Mbit/s) Synchronous Transport Module Level 4 (622 Mbit/s) Scalable Video Coding Norwegian company To be determined Transmission Control Protocol (Internet) Time Division Duplex(ing) (UMTS*) Tl-Diffusion de France Time Division Multiplex(ing) Traffic Engineering Transport Layer Security Transport Multi-Services (TDF*) Terrestrial News Gathering (VRT) TCP/IP offload Engine. An iSCSI TOE card offloads the Gigabit Ethernet and SCSI packet processing from the CPU. Type-Of-Service Temporal Redundancy Transport Stream (MPEG-2) Transmitter Unit Address
34
UAT UDP UHF UID UTRA TDD UMTS UPA(HS) V VALID VANC VBR VC-2 VCEG VJ VLAN VLC VoIP VoIP VP VPLS VPN VQEG VRT vs. VSAT VSF W w. WAN W-CDMA, WCDMA WBU WC WDM WFQ WiFi WiMAX WLAN WOG xDSL YCbCr User Acceptance Test User Datagram Protocol (RFC*768) Ultra High Frequency Universal IDentifier UMTS Terrestrial Radio Access Time Division Duplex Universal Mobile Telecommunications System Uplink Packet Access (High-Speed) Vertical Video and Audio Line-up and Identification (http://www.pro-bel.com/products/C132/ ) ANCillary data in the Vertical video blanking interval Variable Bit Rate SMPTE code for the BBC's Dirac Video Codec Video Coding Experts Group (ISO/IEC-MPEG + ITU-T) Video Journalist Virtual LAN* Variable Length Coding Video over IP Voice over IP(narrowband audio) Virtual Path Virtual Private LAN Services Virtual Private Network Video Quality Experts Group (ITU) Vlaamse Radio- en Televisieomroep, Flemish Radio- and Television Network (Belgium) versus; against, compared to Very Small Aperture Terminal Video Services Forum http://videoservicesforum.net/index.shtml Watt With Wide Area Network Wideband CDMA* World Broadcasting Unions http://www.nabanet.com/wbuArea/members/about.asp World Championship Wavelength Division Multiplexing ( Lambda*) Weighted Fair Queuing Wireless Fidelity Worldwide Interoperability for Microwave Access (IEEE 802.16) Wireless LAN IEEE 802.11(a,b & g) Winter Olympic Games x DSL* (x = Asymetrical or Symetrical uplink/downlink) Digital luminance and colour difference information
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/mtg0802/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. Requires fast converging network to minimize visible impact of loss
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 MPLS and Multi-Topology Routing are options in topologies that do not support MoFRR
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
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 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. 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. 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. 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. Practical Network performance 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
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.
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.
[19] [20]
38
Practical measurement 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. Practical Network performance
39
Tableau 3: HD contribution codecs ( 4.1) [ EBU]
MPEG-2 Standard ISO/IEC 13818 MPEG-4 AVC / H.264 ISO/IEC 14496 ISO 19446-1 JPEG2000 Dirac Pro SMPTE VC-2 (Developped by BBC Research) Principle DCT based system Spatial and temporal prediction with variable length statistical coding (VLC) 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 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 layerwise: 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 bitrate 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. Spatial and temporal compression with a choice between context adaptive arithmetic coding (CABAC) or variable length (CAVLC) 7 Profiles and 5 levels For contribution (at the moment): High profile 4:2:2 10bit Level 4.1 (1080i and 720p) 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 Only DCI profiles exist at the moment. Broadcast application profiles under investigation in JPEG. Follows H.264 profiles. MPEG-4 SVC / H.264 Amendment to H.264/AVC standard
40
MPEG-2 MPEG-4 AVC / H.264 rate.(suitable for SNGs) Enhanced Error resilience with synchronization mechanism in the codestream JPEG2000 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) 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 Dirac Pro (Hardware & software) Handles formats from 720p/50, 1080i25, 1080p/50, to 4K. (Futureproof.) Lossless and visually lossless compression MPEG-4 SVC / H.264
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 ISDN ADSL SDSL VDSL Cable network Powerline (PLC) Wireless WLAN (802.11b/g) Satellite link GSM GPRS HSCSD EDGE CDMA One UMTS HSUPA CDMA2000 EV-DO Flash OFDM LTE / HSUPA WiMAX (mobile) iBURST 11 / 54 Mbit/s 1 Mbit/s 12 kbit/s 171.2 kbit/s 57.6 kbit/s 473 kbit/s 14.4 kbit/s 128 kbit/s 5.8 Mbit/s 144 kbit/s 5.4 Mbit/s 900 kbit/s 50 Mbit/s 7 Mbit/s 346 kbit/s Vodafone IRT-TESTnet ~ 1.35 Mbit/s ~ 1.15 Mbit/s ~ 14.5 min ~ 17 min. Vodafone ~ 120 kbit/s ~ 180 min. InternetCafe Munich EBU WiFi ~ 870 kbit/s ~ 3.55 Mbit/s ~ 30 min. ~ 5.6 min. 56 kbit/s 128 kbit/s 640 kbit/s 4.6 Mbit/s 50 Mbit/s 40 Mbit/s 200 Mbit/s Arcor Business T-Home/IRT ~ 1.95 Mbit/s ~ 2.94 Mbit/s ~ 10 min. ~ 6.7 min

EBU Networks 2008 Report FINAL Tcm6 62796

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EBU Networks 2008 Report FINAL Tcm6 62796

Uploaded by

Copyright:

Available Formats

1

Network Technology Seminar 2008 "Media Networks in Action"

More than 325!

Opening round table - strategic opportunities and issues

1.1 Concepts and protocols

Increasing Cost and Complexity

Muticast-only Fast Reroute (MoFRR)

1.2 Traffic engineering

1.3 Video over IP - Maintaining QoS

Inside the cloud

1.4 Practical application

Audio Contribution over IP

2.1 The ACIP standard - A tutorial10

MPEG-4 HE-AACv2 Dolby AC-3

2.2 Implementing and testing ACIP using open source software

e.g. - sip:reportername@sr.se or telephone number http://sourceforge.net/index.php http://www.pjsip.org/

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

2.3 Interoperability in action

Figure 4: Audio over IP codecs and SIP

IRT/BBC Reference (Unit in Geneva)

Commander G3 Tieline (Australia) (Unit in Geneva)

Scoopy AETA, (France) (Unit in Geneva)

SIP Proxy and Registrar Server (Unit in UK)

Scoop4+ AETA, (France) (Unit in UK)

Scoop4+ AETA, (France) (Unit in Germany)

PortaNet Prodys (Spain) (Unit in Geneva)

Video contribution over IP

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

EBU TECH 3318 'File Transfer Guidelines'. June 2008 http://www.ebu.ch/CMSimages/en/tec_doc_t3318-2008_tcm6-60595.pdf

Estimated bandwidth requirements incl. possible overhead (draft) FEC

3.2 Real-time transport of television using JPEG2000

3.3 France 3's new contribution network over IP

4.1 HD contribution codecs

4.2 Practical thoughts and wishes or whishful thinking!

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/

4.3 Eurovision experience in HD contribution

Real world applications: the News

5.1 The use of COFDM for ENG applications

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

5.3 How to connect your Video Journalists (VJ)

http://www.thuraya.com/ http://www.streambox.com/ http://www.quicklink.tv/ http://www.vcon.com/ Carbon Coder http://www.rhozet.com

Real world applications - Production and Broadcast

6.1 Architecting a fully-networked production environment

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

No visible impairments using repeaters with 2 SAW filters

Abbreviations and acronyms

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

Network reconverges** / reroutes* on core network failure (link or node).

Requires fast converging network to minimize AL-FEC overhead

Requires fast converging network to minimize block separation period

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

You might also like

generation of wireless communication systems (GPRS, EDGE)