BRKSPV 3112

Development trends in delivery of Live and
VOD based services

BRKSPV-3112
Thomas Kernen
Consulting Systems Engineer
2013 Cisco and/or its affiliates. All rights reserved. BRKSPV-3122 Cisco Public
Agenda
Video codec evolution
What next for 3DTV delivery?
Audio loudness normalisation
Beyond HD: Ultra High Definition
Next generation time and sync for broadcast infrastructure
3
Video codec evolution
Codec Evolution
Codec timeline: Standard ratification
5
MPEG-2 / H.262 1994
MPEG-4 Part 2 /
H.263
1999
MPEG-4 Part 10 /
AVC / H.264
2003
HEVC / H.265 /
MPEG-H Part 2
2013
Codec Evolution
ITU H.265 = MPEG HEVC (High Efficiency Video Coding)
Developed by experts of the Joint Collaborative Team on Video Coding (JCT-
VC) between ITU SG-16 VCEG and ISO MPEG WG11
Feb 2012 : Committee Draft: but only one profile (Main Profile)
Jul 2012 : Draft International Standard (DIS) (Main, Main 10, Main Static)
Jan 2013 : Final Draft International Standard (FDIS)
March 2013 : Final FDIS editorial changes (to become ISO/IEC 23008-2)
June 2013: ITU-T H.265 published
http://www.itu.int/rec/T-REC-H.265-201304-I
HEVC Specification status
6
Note: Parts of the specification will continue to evolve
Codec Evolution
Bandwidth savings at all bitrates (Target is 2:1 over H.264/AVC)
Ex: Enables expanding IPTV service delivery footprint for DSL based infrastructure
Support for higher resolutions (8K by 4K and 4K by 2K) and frame rates
Improve performance on mobile devices with HD display capabilities
More integrated decode functions = less power/battery usage
Launch of 1080p50/60 services to compete against package media (BluRay)
Current services generally in 720p or 1080i
Support for full resolution plano-stereoscopic 3DTV*
Current services are frame compatible (2 frames packed in single frame)
Expected <10x more computational complexity (encode) and 2x-3x (decode)
720p30 software decode on iPad3 available today (with reference SW decoders)
HEVC Main drivers
7
Codec Evolution
Anticipated Adoption Requirements
8
Mobile markets
12 to 24 month refresh cycle on endpoints vs. 5 years for displays
Initially can be software decode only until silicon is available and shipping
Expected to launch in 2013
IPTV
Enable VOD and pre-packaged services ahead of live broadcast
Rely on existing CDNs for content distribution
Expected to launch in 2014/2015
Satellite, Cable & Terrestrial
Timeline linked to introduction of DVB-T2 in national markets
Linked to DVB-Sx extensions for satellite for efficient spectrum usage
Expected to launch in 2015

Codec Evolution
Class Resolution F. rate Rate 1 Rate 2 Rate 3 Rate 4 Rate 5
A 2560 x 1600 30 2.5 Mb/s 3.5 Mb/s 5 Mb/s 8 Mb/s 14 Mb/s
B1 1920 x 1080 24 1 Mb/s 1.6 Mb/s 2.5 Mb/s 4 Mb/s 6 Mb/s
B2 1920 x 1080 50 60 2 Mb/s 3 Mb/s 4.5 Mb/s 7 Mb/s 10 Mb/s
C 832 x 480 30 60 384 Kb/s 512 Kb/s 768 Kb/s 1.2 Mb/s 2 Mb/s
D 416 x 240 30 60 256 Kb/s 384 Kb/s 512 Kb/s 850 Kb/s 1.5 Mb/s
E 1280 x 720 60 256 Kb/s 384 Kb/s 512 Kb/s 850 Kb/s 1.5 Mb/s
Classes of resolutions and bit rate points in Call for Proposal
9
Where HEVC bandwidth savings stands
Resolution
Random
Access
Low Delay All Intra
Class A 2560 x 1600 @30 36.9% 23.3%
Class B 1920 x 1080 @24 39.5% 41.2% 22.6%
Class C 832 x 480 @30/60 30.7% 32.7% 20.0%
Class D 416 x 240 @30/60 28.7% 30.2% 16.7%
Class E 1280 x 720 @60 43.2% 28.6%
Average 34.3% 36.7% 21.9%
HEVC Working Draft HM 8 Main Profile vs. JM 18.4 AVC High Profile (Oct 2012)
10
Source: JCTVC-K0279 contribution (October 2012)

Codec Evolution
HM 5.0 Objective Testing
11
Source: Comparison of the Coding Efficiency of Video Coding Standards, IEEE Trans. Cir. Sys. Video Tech., Vol. 22, No. 12, Dec 2012
Codec Evolution
HM 5.0 Objective Testing
12
Codec Evolution
HM 5.0 (HEVC) Subjective Testing vs. JM 18.2 (H.264/AVC)
13
High Level information
3 Profiles: Main: (8-bit), Main10: (10-bit), Main Still Picture: (8-bit)
Chroma Sub-Sampling: 4:2:0 (4:2:2, beyond 10-bit in Range Extension CfP)
Levels: 1 (176144@15.0) - 6.2 (3,8402,160@300.0 / 7,6804,320@128.0)
Tiers: Main, High
SEI message for Stereo (3D)
Support for Temporal scalability
No specific coding tools for interlaced sources
14
Quadtree-Based Block Partitioning
CU (white) and nested TU (red) from quad-tree partitioning

15
Source: HEVC Complexity and Implementation Analysis, IEEE Trans. Cir. Sys. Video Tech., Vol. 22, No. 12, Dec 2012
H.264/AVC used fixed size
16x16 Macroblocks
HEVC introduces flexible
Coding Tree Units (CTUs):
16x16, 32x32, 64x64
Coding Units within the
CTU:16x16, 32x32, 64x64
Intra and Inter prediction can
be used inside the CU
Z-Scan Order
Prediction Units
Partition spans Coding Units
Intra PUs:
Always square: 64x64 to 4x4

Inter PUs:
Rectangle or square
16
2NxN Nx2N
2NxnD nLx2N nRx2N
2NxnU
CU
PU
NxN
2Nx2N
High-level parallelism
Slices, Tiles & Wavefront Parallel Processing (WPP)

17
Subdivision into Slices
Raster scan in a picture
One Independent Slice Segment
Optional Dependent Slice Segments

Subdivision into Tiles
Raster scan in a tile

Wavefront parallel processing
Processing rows of Coding Tree Blocks
When ref block is processed next line
can start
Summary of AVC vs. HEVC
High Level View
18
AVC HEVC
Coding Unit size
64x64 to 8x8
Hierarchical quad-tree
partitioning down to 8x8
Up to 35 Intra modes
32x32, 16x16, 8x8 and
4x4 transform sizes
16 x 16 Macroblock size
Various Inter partitions
down to 4x4
9 Intra modes
8x8 and 4x4
transform sizes
What next for 3DTV delivery?
3D Distribution Technologies
Dual Stream Encoding
22
Provides
full resolution quality but
requires
increased channel
bandwidth and storage!
Left Eye
Right Eye
Need to synch both views
Time
3D Frame
Sequential
RE
LE
RE
LE
RE
LE
RE
LE
RE
LE
Frame Compatible Plano-Stereoscopic 3DTV
23
Side-by-
Side
Checkerboard
Line
Interleave
Column
Interleave
Provides
legacy channel
compatibility but
reduced
picture resolution!
Top &
Bottom
Left Eye
Right Eye
Left Eye
Right Eye
Existing standards
Frame Compatible Plano-Stereoscopic 3DTV
24
MPEG-2
Video
H.264/AVC Top and Bottom
720p and 1080p
Side by Side
1080i
Side by Side
720p, 1080i and
1080p
CableLabs OpenCable
Content Encoding Profiles
3.0 Specification
X X X X
DVB TS 101 547 v1.1.1
X X X
ATSC 3DTV Terrestrial
Broadcasting, Part 3
(Candidate Standard)

X X X X
Service Compatible Plano-Stereoscopic 3DTV
25
Can provide
2D playback
compatibility
in legacy devices!
Left Eye
Right Eye
2D
2D
Time
2D
2D
2D
2D
2D + Enhancement
H.264/AVC Multi-view Coding (MVC)
Left Eye
Right Eye
Next phase in 3DTV
DVB Steering Board Approved October 2011
DVB-3DTV Phase 2a
Allow 2D and 3D versions of a program in a single video signal
2D derived from left or right image of stereo pair
Required work in DVB and MPEG
Technical work completed in June 2012
Published as DVB TS 101 547-3 v1.1.1 in November 2012
Source coding information in TS 101 154 v1.11.1
Services to be launched by broadcasters
Service Compatible Plano-Stereoscopic 3DTV
26
Frame Compatible Compatible
Frame Compatible packs 2 pictures into one frame
Loss of 50% resolution per image
Code 2
nd
view into primary image
Target approx. 25% extra bandwidth
New generation receivers could decode the 2
nd
view.
Legacy receivers would ignore the additional content
Roadmap:
MPEG Call for Proposals in July 2012
ITU/MPEG group set up: JCT-3V
H.264/AVC and HEVC models under study
Working Draft for Multi Resolution Frame Compatible (MFC) planned for
completion by end of 2013
Is this the next phase of 3DTV?
27
Next stage in 3DTV
Dual stream full L+R view mostly used in contribution and primary distribution
Frame compatible is the de facto broadcasting standard today
Service compatible specification published late 2012 by DVB
With extra MPEG-2 TS syntax elements in MPEG
MPEG MFC work started late 2012
Requests to support Frame Compatible with HEVC
The real question: Is there still interest in 3DTV broadcast services to the
home?
Summary
28
Current state of audio across multiple services
30
Target state of audio across multiple services
31
Enforces commercials to be same overall level as surround programming
FCC adopted December 13
th
2011
Went into effect on December 13
th
2012
Requires application of ATSC A/85 Recommended Practice
Set of method to measure and control audio loudness in digital programs
Specifics in Annex J (AC-3 codec) and K (non AC-3 codec)
Updated revision in March 2013
User complaints will initiate FCC action against network operator

US: Commercial Advertisement Loudness Mitigation Act
32
ATSC A/85 uses ITU BS.1770-3 (2013 update)
Focuses on anchor elements ie: dialog
Relies on dialnorm field in metadata
No specific measurement methodology
Target level is -24 LKFS
US: Commercial Advertisement Loudness Mitigation Act
33
EBU uses ITU BS.1770-2
Includes additional gating: ignores silence
Loudness Range (LRA) detailed in EBU Tech 3342
Target level is -23 LUFS
Measurements performed in 1 hour blocks over 24 periods
European Broadcasting Union (EBU) Recommendation 128 + Tech Docs
34
All sources to be treated according to EBU Tech 3344
35
EBU Measurements according to ITU-R BS.1770-2
36
EBU Measurements: target level -23 LUFS
37
EBU Level adjustments
38
The real world goal
43
CALM Act - US Congress Bill H.R. 1084 (111
th
)
ATSC A/85:2013
ITU BS.1770-2 (BS.1770-3 published, not currently used in R128)
EBU R128 Loudness Recommendation
EBU Tech 3341 Metering specification
EBU Tech 3342 Loudness Range descriptor
EBU Tech 3343 Production Guidelines
EBU Tech 3344 Distribution Guidelines
References
44
Beyond HD: Ultra High Definition
Why Ultra High Definition?
Early work to improve SD systems:
Baird 600 line colour system in 1940
French 819 lines (1949 - 1983)
Initial HD systems:
NHK Color in 1972 (1125 lines)
MUSE (1125 lines) in Japan with commercial broadcasting from 1994
HD-MAC trials from 1990 to 1993 (1152 lines)
Current HD systems:
ATSC approved in December 1996, official public HD service launch in 1998
Commercial DVB broadcasts started on January 1
st
2004 (Euro1080 channel)
History of High Definition
46
Basics of Ultra High Definition
Higher spatial resolution
Better immersion with larger field of view
Shorter ideal viewing distance than HD
Higher frame rates for better motion portrayal
Benefit for larger displays (50 and above)
Comparable to high end cinema experience
Next sales cycles for displays manufactures
To be introduced with new services
47
Source: ITU
Ultra High Definition systems
Ultra HD-1: 3840x2160 24, 50, 60, 120Hz
Near term evolution: 4 times the resolution of current High Definition
Ultra HD-2: 7680x4320 24, 50, 60, 120Hz
Long term evolution with ongoing trials, 16 times the resolution of current HD
Improved colorimetry for more realistic representation
99% of Pointers colours seen in nature
10 and 12-bit depth
Progressive scanning mode only
No support for interlaced legacy (for now)
2 levels defined
48
Higher frame rates
Content genre dependent
Provides an impression of higher
resolution
Most beneficial to higher resolutions
In broadcast world, higher than 50/60Hz
New issues with conversions between
rates?
Further research being conducted in
this space

49
Source: BBC
High Dynamic Range
Brightness levels on modern displays much higher than when CRT based
specifications where designed
Camera vendors providing digital sensors with higher dynamic capabilities
Extended the delta between light and darkness
50
Provide detail in low contrast situations:
Details in high brightness or dark areas
Improve light reflection (specular) on
materials and light sources
Realism and aesthetics
Where to get 4K content?
Theatrical productions:
35 or 70mm cinema print (scanned and converted to 4K format)
4K Digital Cinema production, editing and play out in cinemas
Note: 4K Digital Cinema is 4096x2160
Broadcast productions:
Trials for shooting live content
Rolland Garros, Wimbledon, Confederations Cup, FIFA World Cup
Requires new production trucks and photography style
Distribution:
Rely on new HEVC encoding standard. Trials with H.264/AVC also exist
HDMI currently only supports up to 4K@30fps. HDMI 2.0 in the works to address this
51
4K and 8K Production
2160p50/60 (10-bit 4:2:0 & 4:2:2) 12 Gbit/s
2160p50/60 (12-bit 4:2:0, 4:2:2, 4:4:4) 24 Gbit/s
4320p50/60 (10-bit 4:2:0 & 4:2:2) 48 Gbit/s
4320p50/60 (12-bit 4:2:0, 4:2:2, 4:4:4) 96 Gbit/s

ITU BT.2020 (production standard) additionally supports 120Hz
Even higher rates may be required
Uncompressed delivery
52
Complex ecosystem
Integration with many efforts
worldwide
Production
Interfaces and content exchange
Contribution
DVB standards and EBU
recommendations
Distribution
DVB standards and industry forums
CE vendors
Interfaces and marketing labels
53
Source: EBU
Ultra High Definition
Higher spatial resolution, frame rates and wider field of view
More realistic and immersive experience
More accurate colour representation, higher dynamic range
Production and distribution chains need to be upgraded
New video codec to distribute content due to high bandwidth requirements
New displays and an update to HDMI specification to deliver to end point
Distribution standards (DVB) need to update specifications
Permanent 24/7 demo channel on air in Europe
Expect to see more news in the near future
Summary
54
Next generation time and sync for broadcast
infrastructure
Broadcast production 101
Content is either live (news, sports) or recorded
Outdoor broadcast (OB) trucks/vans - to capture events in locations without
pre-installed equipment, or connecting to 3
rd
party equipment
Small(ish) stationary studios or TV stations - to connect to stationary equipment
or OB truck
TV plant/station - Shot live in studio (news cast, morning show), play out to air
live or pre-recorded content
Live content shot is typically carried uncompressed over SDI (Serial Digital
Interface)
56
Classic view how production elements connect
57
*Excerpt from
RFT_270208
VTR Video Tape
Recorder. Original
equipment which gets
replaced by digital servers
but the name stays for
now.
Synchronisation in studio
Studios are very tightly synchronised
For analogue composite signal the alignment is 0.5ns
For digital signal the alignment is +/-1us
All studios use frame synchronisers to align cameras
Frame synchronisers compensate cable length differences between cameras
Adapt input rate from cameras to the common facility output rate by manipulating some
frames if input rate is faster or slower
Synchronisation within studio must happen within seconds
Devices are plugged and unplugged on a regular basis within the studio
Important to provide means for eliminating packet delay variation (PDV) and
asymmetry effects within studio network
58
Some benefits of precise synchronisation
Common sync distribution for the whole production plant reduces
dependencies on individual sync generators.
Having all cameras running at the same frequency and common time would
provide means to reduce frame drops/replays
Having common time at all cameras would allow simple time stamping without
a mandatory link to the number of frames, if required.
Common time may simplify conversion between different video systems (ex.
50/60 Hz).
Common time would allow simple storage and replay of the video content
59
So why the need for change?
Cost, complexity of infrastructure
Multiple distributions required
Inflexibility have to pull cables everywhere
Many single points of failure
Analogue susceptibilities (legacy)
Shift in technology

61
Transitioning to a new network infrastructure
Cameras, video tape recorders (VTR) / digital servers and phase synchronizers
are starting to become Ethernet ready
Each camera and microphone have individual connections to the mixer
Massive amount of cabling is done in each studio
Each camera control unit (CCU) has video cable, synchronisation cable and
sometimes separate Continuous Time code. May also include return video signal.
The audio is digitized in the audio mixer. The mixer receives Digital Audio Reference
Signal (DARS) via separate cables
IP based connections for all cables could be replaced by a single one
Distribute data and timing synchronisation over the same connection
Still many audio and video mixers are not (yet) network ready
62
IEEE 1588-2008
Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems
Precision Time Protocol (PTP) is, like NTP, a Two Way Time Transfer protocol
(TWTT).
PTP has been designed to obtain accuracies down to the nanoseconds if
every elements are correctly implemented.
IEEE 1588 has been originally specified for plug-and-play time synchronization
solution.
Original interest for telecom because dedicated standard and precision
marketing.
63
IEEE 1588-2008 Clocks
OC has unique PTP port, either slave or master (defines clock state).
As network intermediate nodes, BC and TC aim correcting delay variations, in
both directions (asymmetry).
64
Reference
Clock

Recovered
Clock
Ordinary
Slave
Ordinary
Master
TC
Transparent
Clock
Boundary
Clock
BC
PTP PTP
PT
P
TWTT Protocol Basics
Basic PTP Message Exchange
65
Timestamps
known by
slave
t
1
, t
2
, t
3
, t
4
Delay

Delay

Offset = TS - TM
t
1
, t
2
, t
3

t
1
, t
2

Delay - Offset = B = t
4
t
3
t
2
= t
1
+ Offset + Delay
Offset + Delay = A = t2 t1
t
4
= t
3
- Offset + Delay
Master time = TM Slave time = TS = TM + offset
Offset = ((t
2

t
1
)(t
4

t
3
))/2 Delay = ((t
2
t
1
)+(t
4

t
3
))/2
MASTER SLAVE
Delay_Resp
t
1
t
3
t
4
t
2
SYNC
Delay_Req
Follow in the footsteps of others
IEEE 1588-2008
2nd revision to the 1588 standard
Different industries define their own profile based on requirement specifics:
Telecom standardised in ITU-T G.8265.1
Power industry relies on IEEE C37.238 (SmartGrid)
Industrial Ethernet
High Frequency Trading in the financial sector
Each profile defers from the others. For example:
Use of Layer 2 (Ethernet) vs. Layer 3 (IP) for message propagation
Default values for message rates
SMPTE TC-33TS20 Work Group creating a 1588 SMPTE Broadcast profile
IEEE 1588
66
High level example of a production environment
Based on IEEE 1588 PTP
68
2-3
Switches
Video mixer
with delay
adjustment
Servers
Nearline
Server
5-10 Switches
Special
effects, CC,
commercial
Audio
mixer/
digitizer
microphones
Content to/from other studio
PTP BC or
TC with slave
PTP BC or TC with
slave
monitors
Live transmission
PTP slave
Ethernet connection
Physical clock connection
Analog audio connection
PTP BC or TC
PTP BC or TC with
slave
PTP BC or
TC
Playout
Server
PTP BC or TC with
slave
Encoder
One studio potentially may
be master to another
PTP slave
PTP BC or
TC
Due to potentially high number of switches the on-path support such as BC or TC in the switches would be required
GNSS
PTP GM
BC boundary clock
TC transparent clock
GM grandmaster
GNSS Global Navigation Satellite
System, ex. GPS/GLONASS/Galileo
CCU Camera Control Unit
PTP GM can be collocated with
some of central piece of equipment
such as servers, video mixers, etc
PTP
slave
CCU
Compressed
stream/
end customer.
No timing
distribution is
required
Example of a pre-standard implementation
69
Breakout Summary
H.265/HEVC/MPEG-H part 2 is the next step in the video codec evolution
MPEG Frame Compatible is the next stage in 3DTV delivery
Audio loudness normalisation to be enforced across Europe
Ultra High Definition will enable a more immersive experience
Broadcast production industry working on next generation time and sync
70
Maximize your Cisco Live experience with your
free Cisco Live 365 account. Download session
PDFs, view sessions on-demand and participate in
live activities throughout the year. Click the Enter
Cisco Live 365 button in your Cisco Live portal to
log in.
Complete Your Online Session Evaluation
Give us your feedback and
you could win fabulous prizes.
Winners announced daily.
Receive 20 Cisco Daily Challenge
points for each session evaluation
you complete.
Complete your session evaluation
online now through either the mobile
app or internet kiosk stations.
71

BRKSPV 3112

Uploaded by

Document Information

Original Title

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

BRKSPV 3112

Uploaded by

Copyright:

Available Formats

Development trends in delivery of Live and

VOD based services

You might also like