experiences with high-definition video conferencing
DESCRIPTION
TRANSCRIPT
Experiences with High-DefinitionVideo Conferencing
Colin Perkins, Alvaro SaurinUniversity of Glasgow, Department of Computing Science
Ladan Gharai, Tom LehmanUniversity of Southern California, Information Sciences Institute
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Talk Outline
• Scaling multimedia conferencing• The UltraGrid system
– Hardware requirements– Software architecture
• Experimental performance• Challenges in congestion control• Conclusions
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Scaling Multimedia Conferencing
• Given advances in system power, network bandwidth and videocameras, why are video conferencing environments so limited?
Why are we stuck with low qualityimages…?
352
288
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Why do conferencing systems look like this?
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
…and not like this?
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Research Objectives
• To explore the problems inherent in delivering high definitioninteractive multimedia over IP:– Related to the protocols– Related to the network– Related to the end-system
• To push the limits of:– Image resolution, frame rate and quality– Network and end system capacity
• To demonstrate the ability of best effort IP networks to supporthigh quality, high rate, media with effective congestion control
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
RFC 4175Demo at iGrid’05, San Diego
Sep. 2005
HDTV work at ISI starts1999
Demo at SC’02, Baltimore(24 bit colour, 60fps ⇒ 1.0 Gbps)
Nov. 2002
Demo at SC’05, SeattleNov. 2005
Full uncompressed HDTV(30 bit colour, 60fps ⇒ 1.2 Gbps)
Apr. 2005
Public code release(BSD-style open source license)
Jan. 2002
Demo at SC’01, Denver(24 bit colour, 45 fps ⇒ 650Mbps
Nov. 2001
UltraGrid: High Definition Conferencing
Build an HDTV conferencing demonstrator:• Standard protocols
– RTP over UDP/IP– HDTV payload formats & TFRC profile– Best effort congestion controlled delivery
no additional QoS• Commodity networks
– High performance IP networks• OC-48 or higher• Competing with other IP traffic
– Local area up to 10 gigabit Ethernet• Commodity end systems
– PC or similar workstation– HDTV capture and display
UltraGrid: The first HDTV conferencing system using commodity hardware
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Media Formats and Equipment
• Capture and transmit a range of video formats:– Standard definition video:
• IEEE 1394 + DV camera– High definition video:
• DVS HDstation or Centaurus capture card– 100MHz PCI-X– 720p/1080i HDTV capture from SMPTE-292M– Approx. $6,000
• Video data rates up to 1.2Gbps
• Chelsio T110 10-gigabit Ethernet• Dual processor Linux 2.6 system
288
352
CIF/288 lines
1280
720
HDTV/720p
576
720
PAL/576 lines
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Media Formats and Equipment
• A variety of HDTV cameras are now available:– Broadcast quality cameras:
• Generally expensive ~$20,000– Panasonic AJ-HDC27F– Thomson LDK 6000
• SMPTE-292M output ⇒ directly connect to UltraGrid, low latency– Consumer grade cameras:
• Price is in the $3,000–5,000 range– Sony HVR-Z1E, HDR-FX1– JVC GY-HD-100U HDV Pro
• No SMPTE-292M output ⇒ converter needed (E.g. AJA HD10A), higherlatency
• Displays must accommodate:– 16:9 aspect ratio– 1280×720 progressive or 1920×1080 interlaced
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Software Architecture
• Classical media tool architecture– Video capture and display– Video codecs
• DV and M-JPEG only at present,others can be added
– RTP– Adaptive video playout buffer
• Two interesting additions:– Congestion control over RTP– Sophisticated video sending buffer
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Experimental Performance
UG sender
UGreceiver
UG sender
UGreceiver
Los Angeles
10 Gbs Ethernet
Seattle, WASC 2005
Chicago
Houston
Arlington, VAISI-East
OC-192 SONET/SDH
LDK 6000
AJ-HDC27F
• Wide area HDTV testson the Internet2 backbone– ISI-East ⇔ ISI-West– ISI-East ⇔ Denver (SC’01)– ISI-East ⇔ Seattle (SC’05)
• Demonstrated interactive low-latency uncompressed HDTV conferencingbetween ISI-East and Seattle at SC’05– Gigabit rate bi-directional video flows (tested using both HOPI and Abilene)
• Ongoing low-rate tests between ISI-East and Glasgow using 25 Mbps DVformat video
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Inter-packet interval (measured at receiver)
Experimental Performance
• Environment:– Seattle ⇔ ISI-East over Abilene; 14-18 November 2005– Best effort IP service, non-QoS enabled, shared with production traffic– 8,800 byte packets; 10 gigabit Ethernet w/jumbo frames; OC-192 WAN
• Packet loss:– Overwhelming majority of RTCP reports showed no packet loss– Occasional transient loss (≤0.04%) observed due to cross traffic
• Inter-packet interval:– Inter-packet interval (jitter) shows
expected sharp peak with long tail– Network disrupts packet timing:
not significant for the application• Playout jitter buffer compensates
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Deployment Issues
• Good performance on Internet2 – usable today– Observe occasional loss due to transient congestion
• HDTV flows not TCP-Friendly, cause transient disruption during loss periods– Cannot support large numbers of uncompressed HDTV flows
• But active user community exists in well provisioned regions of the network(UltraGrid nodes in US, Canada, Korea, Spain, Czech Republic...)
• Two approaches to wider deployment– Optical network provisioning and/or quality of service
• E.g. Internet2 hybrid optical packet network (HOPI) also used for some tests• Possible, solves problem, but expensive and hard to deploy widely• Necessary for guaranteed-use deployments
– Congestion control• Adaptive video transmission rate to match network capacity• Preferred end-to-end approach for incremental, on demand, deployment• Necessary for safety, even if QoS provisioned network available
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Congestion Control for Interactive Video
• TCP not suitable for interactive video– Abrupt variations in sending rate– Couples congestion control and reliability– Too slow
• Obvious alternative: TCP-Friendly rate control (TFRC)– Well specified, widely studied rate-based congestion control– Aims to provide relatively smooth variations in sending rate– Doesn’t couple congestion response and reliability
– Two implementation choices:• Use DCCP with CCID 3• Use RTP profile for TFRC
• DCCP implementations not mature• Deployment challenges due to firewalls• Not feasible to use at this time
• Can be deployed in end systems only (running over UDP)• Easy to develop, deploy, debug and experiment with code
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
TFRC Implementation
• Rate based algorithm,clocking packets fromsending buffer
• Sending buffer size chosen to respect 150ms oneway latency constraint (⇒ a couple of frames)
• Rate based control driving queuing system:– Widely spaced (16ms) bursts of data from codec– Fast, smoothly paced, transmission (~70µs spacing)
• Mismatched adaptation rates– TFRC ⇒ O(round-trip time)– Codec ⇒ O(inter-frame time)– Relies on buffering to align rates, varies codec rate ⇒ problematic for stability
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
TFRC Performance
Throughput with varying RTT
Transport protocol stable on large RTTpaths, less stable for shorter paths
100ms RTT, 800kbps bottleneck, 10 fps M-JPEGTesting in dummynet
Desired vs. actual sending rate
Video rate can follow congestion controlrate, provided frame rate and RTT similar
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
Implications and Conclusions
• Well engineered IP networks can support very high performanceinteractive multimedia applications– The current Internet2 best effort IP service provides real-time performance
suitable for gigabit rate interactive video when shared with other traffic– Transient congestion causes occasional transient packet loss, but recall that
we added a gigabit rate real-time video flow to an existing network withoutre-engineering that network to support it
• Initial congestion control experiments raise more questions thanthey answer– Possible to implement, but more sophisticated codecs needed– Difficult to match codec and network rates, causes bursty behaviour
• Impact on perceptual quality due to implied quality variation unclear• Likely easier as video quality, frame-rate, and network bandwidth increase
Cop
yrig
ht ©
200
6 U
nive
rsity
of G
lasg
owA
ll rig
hts r
eser
ved.
UltraGridA High Definition Collaboratory
http://ultragrid.dcs.gla.ac.uk/