Download Evaluation of Digital Video Transmission via DVTS Software over

Evaluation of Digital Video Transmission via DVTS Software
over NYU-NET between NYU Washington Square and
NYU Medical Center Campuses
Jimmy Kyriannis
Senior Technology Architect
NYU Information Technology Services, C&CS
Fall, 2005
Introduction
A technology trial of a high-quality, high-bandwidth digital video transmission over the NYU
campus network (NYU-NET) was conducted for the first time. The goal of this trial was to
determine the feasibility of using Digital Video Over IP (DVIP) between the NYU School of
Medicine (the NYU SoM) and its collaborators, both at the Washington Square (NYU) campus
and elsewhere at Internet- and Internet2- connected institutions. One possible application of
DVIP at the NYU SoM is instructional in nature, where three audio/video sources are streamed to
an audience, while one stream is transmitted back to provide audience feedback to the instructor.
Though successful, a few difficulties were faced during the tests, which served to distinguish
high-bandwidth DVIP technology as one which requires greater attention to its use than do more
common client-server network applications.
Technology Overview
DVIP is a technology by which coordinated audio and video are encoded into a digital format by
a dedicated system or a computer with video capabilities, and then delivered to one or more
receivers via IP communications over a conventional data network. The amount of network
bandwidth used for the transmission is typically a function of the quality of the conveyed content
and the characteristics of the codec(s) used to present it. Very low data rate audio/video (A/V)
transmissions used by conferencing software characteristically delivers low to average quality
images, albeit in small size formats to reduce the amount of data transmitted and conserve
bandwidth on slow network links. On the opposite end of the spectrum, high-quality video –
especially high definition - can easily consume tens or hundreds of megabits per second of
bandwidth. A substantial amount of network infrastructure is required to support such
transmissions, which can be quite costly to implement, especially if outside the confines of a local
area network (LAN).
DVTS (Digital Video Transport System, http://www.sfc.wide.ad.jp/DVTS) is an application
which accepts DV25-encoded (typical digital camcorder output) video, and transmits it over an IP
network at roughly 30Mbps per stream. The DVTS software is freely available for use on
Windows, MacOS X and various UNIX platforms; it only accepts video input for encoding via a
digital FireWire interface connection, and can output received IP video either directly to a
FireWire video output device or (with lesser quality) into a display window on the computer’s
desktop. DVTS can transmit and receive IP video via IPv4 unicast or multicast, as well as IPv6
unicast or multicast. Since a significant amount of computing power is required to process digital
video at 30Mbps, it is noteworthy that a computer with a clock rate of less than 1 GHz is likely
too slow for practical use with DVTS. Nonetheless, DVTS was chosen for a DVIP trial at the
NYU SoM since its excellent video output successfully conveys fine detail, a requisite for
usefully transmitting video material of surgical procedures.
DVTS Test Process
Testing of the DVTS application took place during the summer and early fall of 2005, and were
divided into four phases; 1) tests of DVTS software use and its viability on the local networks of
both the NYU SoM and NYU campuses; 2) live transmission tests between the NYU SoM and
NYU; 3) live transmission test between NYU in New York, NY and UC Berkeley (UCB) campus
in Berkeley, CA; and 4) a final live transmission test between the NYU SoM (New York, NY)
and UC Berkeley. These tests were conducted with IPv4 unicast, over UDP ports 8000 and 8001
(default settings).
The fairly straightforward first phase of the DVTS testing was done largely to overcome any
configuration difficulties with the software, to confirm the viability of DVTS, and confirm that
the local networks could support the demand of such high bandwidth applications. Once
completed, as a prelude to the second phase of testing, a fairly rigorous set of network benchmark
and stress tests were conducted between the NYU SoM and Warren Weaver Hall at the NYU
campus.
This set of preliminary tests was designed to determine the amount of usable bandwidth between
the two campuses, and help identify any bottlenecks imposed by network infrastructure such as
routers or firewalls. Iperf (http://dast.nlanr.net/Projects/Iperf/), a common network benchmarking
tool, was used to conduct performance tests between the two campus networks during off-hours.
Initial tests demonstrated about 220Mbps of usable bandwidth between them, however, it was
later determined that a firewall security setting was in place to impede high bandwidth activity.
When that setting was adjusted to support the DVTS test, the amount of bandwidth available for
an individual data stream jumped to 559 Mbps for a sustained 1-minute TCP transmission, and
613 Mbps for a 1-minute UDP transmission. The lesser performance of TCP was attributed to the
processing overhead associated with it at high data rates. With DVTS requiring 30Mbps of
bandwidth per video transmission, the performance numbers confirmed that the network could
safely support the application, even during business hours.
The live DVTS transmission tests between the NYU SoM and NYU, though successful, revealed
a number of points regarding its use:
-
-
-
A fair amount of coordination is required with firewall admin staff, as any static NAT
translations for inbound transmissions must be set beforehand and coordinated, and
support for inbound transmissions on UDP ports 8000 and 8001 must be similarly
configured in access rules.
Any rate limiters the data path must be adjusted to accommodate DVTS on the network.
During initial tests, at least, network staff should be available to monitor and characterize
network usage and performance. To the DVTS user, it’s entirely unclear whether
software difficulties are rooted in a network problem or an issue with DVTS itself.
Ample computers for testing purposes should be available on either side of the test, with
reasonable processing power and ample free memory.
Ultimately, four DVTS streams were transmitted simultaneously, for a total of 120Mbps of DVIP
data being sent in the form of two bidirectional streams.
Prior to the third phase of testing to an Internet2-connected site, iperf and DVTS trials were
conducted with our Internet2 service provider, NYSERNet. Though receipt of network data from
NYSERNet was reliable, receipt of NYU data by NYSERNet was poor and lossy. DVTS video
received by NYSERNet, in particular, was non-functional. By virtue of these tests, a single
strand of NYU fiber optic cable on the path to Internet2 was found to exhibit a very low level of
errors. Since DVTS uses UDP for transmission of its video stream, it is not readily able to
recover from errors and as a result is very sensitive to packet loss even at such low levels. The
majority of campus applications which use Internet2 resources are TCP-based, and use lower
amounts of bandwidth. Since TCP can recover from errors, routine applications were not visibly
affected by the fiber problem. Once the fiber issue was resolved, however, DVTS transmissions
to and from NYSERNet functioned well, in fact, over the four major IP protocols: IPv4 unicast,
IPv4 multicast, IPv6 unicast and IPv6 multicast
The third phase of testing, a DVTS transmission in each direction between NYU and UCB, was
successful and ran without difficulty, though a bit of burstiness was experienced in receipt of the
NYU video. That issue was later identified as a behavior unique to DVTS under the FreeBSD
platform in use.
In the final set of tests, a complete simulation of the distance learning experience was established,
where three 30Mbps DVTS streams were sent to UCB, while one return stream was sent back to
the NYU SoM. Prior to the onset of the tests, the external IP address of the one statically-mapped
NAT’ed receiver at the NYU SoM was provided to UCB staff, and the IP address of that UCB
source streaming into the NYU SoM was configured into NYU firewalls. A credit to the amount
of testing and preparatory work done ahead of time by staff at both NYU and UCB, the four
simultaneous DVTS streams came up immediately with no difficulties. The quality of each
stream was excellent, especially when FireWire cameras were used as sources, despite the fact
that the test constituted a 6,000 mile round-trip from sourced instructional video to receipt of the
audience feedback return stream. For a brief period of time during the tests, some packet loss
was experienced on the stream to New York, however, UCB networking staff were able to
identify a congestion point in Internet2 infrastructure at Indianapolis, which resolved itself within
a few minutes. Given the distributed nature of Internet2, brief periods of heavy use of the
Abilene Network can occur from time to time, which may cause difficulties for applications such
as DVTS which are intolerant of jitter or loss.
The four streams in the final test consumed an aggregate amount of 120Mbps of bandwidth over
Internet2: 90Mbps from NYU SoM to UC Berkeley, 30Mbps from UCB to NYU SoM. The
network utilization graph in Figure A documents receive and transmit levels at the time of the test,
which began at 5pm EDT.
Figure A: Network utilization levels during the final test (1700 hours EDT; X-axis depicts time)
`Daily' Graph (5 Minute Average)
Max In: 109.9 Mb/s (11.0%) Average In: 16.5 Mb/s (1.7%) Current In: 13.8 Mb/s (1.4%)
Max Out: 46.6 Mb/s (4.7%) Average Out: 15.5 Mb/s (1.5%) Current Out: 9420.3 kb/s (0.9%)
Trial Results
Though the DVIP tests successfully demonstrated the use of DVTS over the NYU campus
network and on Internet2, it was not accomplished without significant effort from technical staff
expert in both networking and digital video at both NYU and UC Berkeley. Technology
components of the trial, including firewall configuration, network monitoring and troubleshooting,
A/V hardware configuration and support, and DVTS host computer performance tuning, were
stressed far beyond what is experienced with routine on-campus and Internet client-server
applications. The intellectual capital expended for this trial was considerable.
Though DVTS offers high quality video at no software cost, it does not, in fact, come without a
price. At least two DVTS-capable systems are necessary at each end of a two-way conversation,
as a system cannot reasonably transmit and receive DVTS video simultaneously. Low-cost video
cameras are not compatible with DVTS; FireWire video sources are required for transmitting
video, although received video can be output either directly on a receiver’s monitor or on a
FireWire video output device. At 30Mbps per stream, switched fast ethernet is the minimum
network capable of supporting a bidirectional DVTS session, and routers with hardwareaccelerated packet switching are best capable of supporting the conveyed network traffic. Given
the high bandwidth and low tolerance for loss and jitter, DVTS proved to be excellent at
identifying networks not operating reliably and entirely error-free.
The DVTS software itself is rather stable on the Windows XP platform, while the GUI-based
MacOS X implementation isn’t as reliable. Still, both versions are fairly processor-intensive,
performing best on systems with clock rates greater than 1 GHz. The windows XP
implementation, in particular, appeared to have difficulty recovering from severe processor loads,
network jitter or data loss. In many cases, a restart of the receiver application was the only way
to recover lossless video stream receipt in a reasonable amount of time. Also noteworthy was a
perceptible sub-second latency associated with a one-way video stream, as compared with
simultaneous and parallel phone conversations. A two-way interactive stream would obviously
suffer from this behavior. The inherent latency of the DV25 encoding process itself has been
quantified at approximately 140ms, and factors such as computer processor load, network
performance characteristics and FireWire input/ouput hardware latencies contribute to a DVTS
unidirectional latency of roughly between 200ms and 400ms. (Some DVTS latency numbers are
documented in a discussion thread on the the Internet2 bigvideo mailing list, which is archived at:
http://mail.internet2.edu/wws/arc/bigvideo/2005-11/msg00014.html)
Summary
DVTS’ support needs are not necessarily representative of all DVIP applications, however, its
free-source nature and support for high-quality DV25 video make it attractive for a distance
learning application which requires conveyance of fine video detail over IP. Though the initial
tests required significant attention from a number of technical staff, as the testing continued, use
of the software became more routine. Nonetheless, given the high-bandwidth characteristics of
DVTS, its use on a campus requires very clean networks and coordination with network and
firewall support staff, at least during an initial period of use. Similarly, use of DVTS for a
production-level event across Internet2 is best served by coordination with Internet2/Abilene
network operations staff in advance, to reduce the chance of conflict with other Internet2
activities.
Despite the free nature of the DVTS software, it does require multiple well-powered computers
with FireWire interfaces and FireWire video devices for practical use. As the latter are not
necessarily off-the-shelf components in every environment, DVTS tends to be somewhat less of
an install-and-go application, often requiring a bit of assistance from a computer hardware expert.
The Windows and Macintosh GUI interfaces to DVTS are still in the early stages of software
release, and as a result, significant testing is required before confidence is at a level where it
could be considered for live event use (it is the author’s understanding that the UNIX commandline version of DVTS is somewhat more reliable, though more unwieldy to use.) As a result,
DVTS is best handled by computer and A/V experts, and less advanced computer users may
experience difficulty with its use. For that reason, a DVTS-based service may be difficult to
operationalize, and an instructor or lecturer is advised to have one or more support technicians
on-hand during a streamed presentation.
Overall, the quality of the DV25 video streamed by DVTS is excellent, and its ability to receive
input from a FireWire digital camera and output to a FireWire device lends DVTS readily to a bidirectional presentation environment. Latencies experienced with the receipt of DVTS audio and
video, even if not exacerbated by network congestion, can be slightly disorienting, and should be
understood before attempting a live interactive streaming event. Certainly, institutions may differ
on the degree to which the support issues are sufficiently significant that they become
burdensome. Therefore, ample testing as described above should help organizations determine
whether DVTS is supportable for production use.
Acknowledgements
Jon Weider initiated and coordinated this project at the NYU SoM. Joe Frey was responsible for
supporting A/V technologies, the DVTS application, and coordinated the testing at the NYU SoM.
Eric Ruiz and Yiwen Tan provided network support, and Joshua Hart provided network
benchmark assistance at the NYU SoM. The author was responsible for supporting DVTS and
the network at NYU. Bill Owens from NYSERNet graciously offered considerable assistance in
testing and troubleshooting both DVTS and network communications. Michael Sinatra and Ken
Lindahl generously offered their time and assistance in support of the DVTS application and
networking at UC Berkeley, and the author would like to thank them for their assistance and time.