Re: Vivantel's 'AMP' data compression website suddenly disappeared?

Sportman wrote:
Mistake domain admin or something else?

http://www.ereleases.com/pr/20060308015.html

Cached pages in Google:
http://www.google.com/search?hl=en&q=site%3Avivantel.com

Cached pages in MSN:
http://search.msn.com/results.aspx?q=site%3Avivantel.com

Their website http://www.vivantel.com is still down.
Looks like somebody bought their technology and wipe all tracks.

Here some copies:

VivantelTM AMPTM is a unique, enabling technology that allows for
ground breaking, crystal clear video and audio over low bandwidth
connections.

Come see AMP and other Vivantel proucts at the Digital Enterprise
Pavilion, at the Intel Developer's Forum, March 7-9, 2006, in San
Francisco's Moscone Center.

- Standard Definition at 512k!
- Extended Definition at 1000k!
- Full 1080i High Definition at 2500k!

-------------------------------------------------------

Services

Vivantel's data compression features a 10:1 ratio for 1080i HDTV over
Consumer Broadband!

Vivantel has developed its own proprietary, patent-pending data
transfer protocol; AMP (Advanced Media Protocol). AMP is a flexible,
cost-efficient way for content providers and communication service
providers to provide high-quality streaming video and a full range of
IP telephony services over the current broadband networks.

Current bandwidth limitations of commonly available consumer broadband
networks have handicapped vendors' ability to deliver high-quality
multimedia content. The Vivantel solution provides a proprietary
technology enabling the delivery of 1080i High-Definition video,
high-quality mobile video, and high-quality two-way video telephony.

Vivantel AMP enables you to place real full-screen streaming DVD
quality video phone calls!

Vivantel's AMP technology enhances existing media delivery systems by
encapsulating the video stream, providing additional compression of
10:1 or more. With this technology, 1080i High-Definition streaming
video can be delivered, via widely available consumer broadband
connections, and displayed in it's full wide-screen format.

AMP provides this superior quality, on an operating system platform
running on Intel processors, without the need for additional software
or a proprietary viewer (i.e.: Real Networks Real Player is still used
to play the Real Networks media format, and no additional software is
required by the client). Video streams are full-featured and include
advanced options such as closed captioning, subtitles, multiple
language tracks and full support for 5.1 digital surround sound.

Vivantel's AMP allows you to stream HDTV 1080i video over a 2.5 mb
connection without the need for additional client side software or
proprietary viewers!

Vivantel, a Web Delivered Solutions, Inc. company, is a media-driven
technology developer and network operator with innovative products and
services that will rapidly change the foundation of personal and
enterprise communications.

----------------------------------------

Delivery Model:


Source material is encoded for target client platform (Windows Media
Player or Real Player) using Vivantel AMP technology.

Full support for digital rights management.

End user accesses content via URL or application.
- Live broadcast video
- Video conferencing
- Video on-demand

Content is delivered via Vivantel's unique, patent pending high-speed
delivery system, with a net reduction in bandwidth requirements of up
to 90%.


-----------------------------------------

Vivantel provides revolutionary data compression rates,

enabling IPTV, Internet TV, VoIP or any data transfer

over a fraction of the otherwise required bandwidth!


Full-Motion Video (30fps)

Full-Screen Video

Projection System and Big-Screen Ready

2 Channel Stereo with SAP Program

5.1 Dolby Digital Ready

6.1 THX Ready

Full Screen 720i @ 512k

1080i @ 2.5mb

HDTV

-------------------------------

About

Web Delivered Solutions, Inc., Vivantel's parent company, offers the
highest quality of Video and VoIP telephone products on the market
today. Since 2001, we have provided superior service to our customers
and have assisted them in achieving their goals.

-------------------------------

Contact Us

Headquarters
200 Ridge Street, Suite 210
Reno NV, 89501
(800) 971-2435
(360) 816-2960

-------------------------------

After some research I found out an other video compression company was
located at that same address one and half year ago.

Web Delivered Solutions, Inc.

Also their website http://www.webdelivered.com is down.
Also their press messages where away here a copy:

Cybermedia _ presents:

RENO, Nev., Nov. 16, 2004 -- Web Delivered Solutions, Inc.
(WDS) is proud to announce its new product featuring better
than DVD quality video over the Internet. The World Wide Web
features high-speed access to a vast quantity of information
in text and photograph formats. Until now, good quality
video has only been realized to those with very high speed
(and very costly) connections with 4 MB of bandwidth or
more. With WDS's new system, users of even low-end DSL and
cable connections can see full screen, high quality video.
Video streams are full-featured and include advanced options
such as closed captioning, subtitles, multiple language
tracks and full support for 5.1 digital surround sound.
Video can be delivered via satellite downlink, server based
content and live broadcasts.

Take this exciting new technology for a test drive today!
Provide us with your own DVD or video clip, and then watch
your own video clip on our website. Call 775-786-7350 to
arrange for your own private demo, then visit
http://www.webdelivered.com.

Web Delivered Solutions is a Nevada-based corporation
focused in leading edge web technologies. The full product
offering includes innovative technologies that increase
productivity in the video, database, software, medical and
transfer arenas.

Abstract of software:

This solution offers an innovative way to send video over
the Internet. While it is currently possible to send video
with legacy solutions, the quality of this video is fuzzy
and can pause during playback, especially if viewed full
screen. The reason for this is two-fold. First, unlike a
television, video over the Internet must be capable of
digitally imaging a screen 30 times per second. With current
technology and compression, this transmission requirement is
impossible to meet. To combat this requirement, the quality
of the video image is reduced, and appears fuzzy because
there is not enough video information. Second, a computers
screen has a much (3:1) higher resolution than a television
screen. In comparison, if you were to take your 40"
television and make it three times bigger the low-definition
image would appear fuzzy - this is the case on the computer.
To make an image sharp, it must be sent over the Internet in
high-definition, which, by the first case above, can not be
accomplished with legacy solutions.

For additional information, visit our website or contact:
John Sikkens
Web Delivered Solutions, Inc.
1-775-786-7350
sikkensj@xxxxxxxxxxxxxxxx
http://www.webdelivered.com

------------------------------------------------------

Here a copy or their Web Delivered Solutions Technology White Paper:
________________________________________
Page 1
Web Delivered Solutions, Inc. High Speed Delivery White Paper
Streaming Video
High quality, low bandwidth.
Web Delivered Solutions Technology White Paper
Streaming Video Protocol Overlay
Rev 12/10/04 D
Web Delivered Solutions, Inc.
200 Ridge Street, Suite 210
Reno, NV 89503
sikkensj@xxxxxxxxxxxxxxxx
www.webdelivered.com
(775) 786-7350
________________________________________
Page 2
Web Delivered Solutions, Inc. High Speed Delivery White Paper
Table of Content
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-1-
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-1-
Video Stream System and Architecture . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . -3-
Video Streaming Model and Architecture . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . -3-
The Internet Challenge to Video Streaming . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . -4-
Video Streaming System Characteristics and Constraints . . . . . . . .
.. . . . . . . . . . . . . . . -6-
Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -6-
Client-Server Model . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . -6-
Server Load Restrictions. . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . -7-
The Best-Effort Service Model . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . -7-
Packetization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . -8-
Back-channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . -8-
The Approach: Technology Overlay . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . -9-
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-10-
________________________________________
Page 3
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-1-
Streaming Video: Overview
Abstract
For about 10 years, several commercial producers have created and
refined proprietary
formats for streaming media. While each format has it's advantages,
it also has drawbacks. The
primary problem faced by vendors is bandwidth constraints. Good quality
low definition small
screen video requires about five hundred and twelve (512k) for full
speed (30 frames per second)
and full screen low definition requires around two megabyte (2MB). For
high definition (1900 x
1780) up to ten megabyte or more is required.
This white paper discusses a solution designed to cure this issue while
not requiring new
deployment of technology.
Introduction
Video streaming is one of the most exciting applications on the
Internet. It already
created a new business known as Internet broadcast, or
Intercast/Webcast. Although Internet
broadcast is still in its infancy, we get a glimpse of the future of
broadcasting where people can
enjoy not only scheduled live or pre-recorded broadcast but also
on-demand and personalized
programs. Stirring more excitement is the idea that anyone will be able
to set up an Internet TV
station and broadcast his or her video programs on the Internet just
like we publish our
"homepage" on the Web today. While video streaming as a core
technology behind a new
business is a success story, it remains very much limited by the fact
that the bandwidth need for
good quality video is much higher than most end-users have, or will
have in the next five years.
Even the definition of streaming is sketchy; it is often described as a
process. Generally
speaking, streaming involves sending media (e.g., audio and video) from
a server to a client over
a packet-based network such as the Internet. The server breaks the
media into packets that are
routed and delivered over the network. At the receiving end, the
packets are reassembled by the
client and the media is played as it comes in. A series of time-stamped
packets is called a stream.
From a user's perspective, streaming differs from simple file
transfer in that the client plays the
media as it comes in over the network, rather than waiting for the
entire media to be downloaded
before it can be played. In fact, a client may never actually download
a streaming video; it may
simply reassemble the video's packets and play the video as the
packets come in, and then
discard them. To a user the essence of streaming video may lie in an
expectation that the video
stream the user has requested should come in continuously without
interruption. This is indeed
one of the most important goals for which a video streaming system is
designed.
Over the last decade, IP multicast and particularly the MBone have
received considerable
attention from the research community. IP multicast provides a simple
and elegant architecture
and service model that are particularly suitable for realtime
multimedia communications. The
________________________________________
Page 4
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-2-
emergence of the MBone, an experimental virtual multicast backbone, has
offered a testbed for
researchers around the world to develop and test a suite of
applications known as MBone tools
for real-time multimedia communications and collaborations. See, for
example, a recent article
by McCanne1 for the evolution of the MBone and its applications. Many
of these applications
have been designed for audio and video conferencing and broadcasting
using IP multicast. On
November 18, 1994, the MBone reached a festive milestone amid great
fanfare when Rolling
Stones broadcast the first major rock band concert on the Mbone.
Despite the promise demonstrated by the MBone and a logical reasoning
that IP multicast
would serve as a foundation for video streaming on the Internet,
commercial deployment of
multicast applications and services on the public Internet has been
painfully slow by the Internet
standard. The bulk of the streaming media traffic generated by three
major commercial
streaming systems (i.e., QuickTime, RealSystem, and Windows Media) on
today's Internet
consists of largely unicast streams. It is out of this papers scope to
define or discuss the issues
that remain unresolved in each vendors application. However, we want to
note that even when
multicast is fully deployed, a very large volume of streaming media
traffic will remain to be
unicast streams. This is because a large portion of the streaming media
content is archived and
played on demand
by users on the Internet. Multicast is of little help to on-demand
streaming unless a large number
of users from the same neighborhood of the Internet would request the
same content
simultaneously.
The purpose of this paper is to review new technology that operates
with legacy formats
(currently supported is the Real Media Format) and enhances the quality
of the video along with
adding home theater applications such as surround sound and interactive
controls. For the
reasons we have just mentioned above, our review will focus on unicast
streaming while
considering multicast as a possible extension. Drawing from the
author's experience in
developing one of the major solutions to this problem to work with
existing systems, we attempt
to identify the most challenging problems in video streaming and
evaluate how this new
technology can create viable solutions for these problems. We will then
cover the feasability
with a cost analysis and statement.
To make the review useful to corporate users, researchers and
application developers, we
would like to clearly identify among the proposed solutions: what works
in real world, what
doesn't, and why? We want to note that although to a Web surfer
streaming video commonly
implies synchronized audio as well, video and audio are actually
delivered in independent
streams in a streaming session.
Video Stream System and Architecture
Video Streaming Model and Architecture
________________________________________
Page 5
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-3-
Figure 1 Flow Diagram of Streaming Media
A schematic system diagram of Internet video streaming is shown in
Figure 1 for both
unicast and multicast scenarios. Figure 1(a) represents the unicast
model for two types of video
streaming services, on-demand or live. In on-demand streaming,
pre-compressed, streamable
video content is archived on a storage system such as a hard disk drive
or satellite downlink and
served to a client on demand by the streaming server. In live
streaming, a video stream coming
out of a live source such as a video camera is compressed in real-time
by the encoder. The
compressed bitstream is packetized by the packetizer, and sent over the
Internet by the streaming
server. On the client side, the video bitstream is reassembled from the
received packets by the
reassembler, then decoded by the decoder, and finally rendered on a
display. Noting that each
________________________________________
Page 6
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-4-
client connecting to the server receives an individual stream, the
disadvantages of the unicast
streaming model can be explained. Clearly, the server load will
increase proportionally to the
number of clients connected to and served by the server. When a large
number of clients try to
connect to a server at the same time, the server gets overloaded,
creating a "hot spot" on the
Internet. Additionally, sending copies of the same data in individual
streams to a large number of
clients is obviously inefficient; it causes congestion on the network
and deteriorates quality of
services.
The multicast model of Figure 1(b) has many advantages over unicast in
live video
streaming (broadcasting) where a large audience could tune in for the
broadcast at the same time.
Instead of sending a stream to each client individually, the server
sends out only one stream that
is routed to one or more "group addresses". A client tunes in to a
multicast group in its
neighborhood to receive the stream. Since the server is decoupled from
connecting to each client
directly, server load does not increase with the number of receiving
clients. In the case of
delivering a stream to multiple groups, the stream on its route gets
replicated and branched only
at the fan-out points within the network. Despite the clear advantages
of multicast-based video
streaming, it is employed in only a small fraction of today's
Internet, primarily in Intranets
within an institution or corporation. There are complex reasons for the
slow deployment of
multicastbased services in general. Beyond deployment hurdles we note
that a large volume of
streaming video content is archived and streamed to users on demand.
Multicast does not help
very much in on-demand streaming where the service requests from users
are random and highly
desynchronized in terms of requested content and timing of these
requests. Interestingly, recent
development in the so-called "content delivery network" appears to
have achieved some
improvements in unicast based on-demand streaming that are reminiscent
of those we have seen
with multicast-based live streaming. A content delivery network such as
the one developed by
Akamai Technologies is essentially a load-balanced network of servers.
The servers are
deployed on the "edge" of the Internet, making them close to the
end users. These "edge servers"
communicate with a "source server" to update their content. A
client requesting a streaming
video is redirected dynamically to the closest edge server that is not
overloaded. Like multicast-
based video streaming, this decentralized service model can reduce
"hot spots". In principle, a
content delivery network can also help unicast-based live streaming
with a possibly increased
latency.
The Internet Challenge to Video Streaming
The Internet provides a great challenge to video streaming. From a
communication point
of view the Internet is a shared channel with a massive number of
heterogeneous components.
This channel is extremely volatile over space and time in terms of
communication capacity and
quality. To see what it means to video streaming let us look at some
data that we have collected
from a real-life video streaming session.
Figure 2 shows a 10-minute data log by a streaming client in Sunnyvale,
California,
during a session watching the BBC World channel on QuickTimeTV on
December 23, 1999.
The data shows the variations in bitrate and percentage of packet loss
of the incoming RTP
(Real-time Transport Protocol)4 video stream. The client has signaled
to the server that it had a
dual ISDN connection with up to 112kbps in bandwidth. Knowing that the
client's bandwidth
________________________________________
Page 7
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-5-
Figure 2
..
RTP video bitrate (top) and packet loss rate (bottom). The data was
recorded at
10:08-10:18am on December 23, 1999, while watching BBC World live
broadcast on
QuickTimeTV from Sunnyvale, CA.
was also shared by streaming audio, we observed that the bitrate of the
incoming video
fluctuated between 60 and 80kbps in general and the packet loss ranged
from 0 to 10%. There
are, however, a few exceptional instances where the bitrate dropped to
as low as 2kbps and
packet loss rate shot up as high as 85%. It is also interesting to
observe from Figure 2 that there
is a strong correlation between a sudden drop in bitrate and a burst of
packet loss. This appears
to agree with a common-sense logic about the relationship between
congestion and packet loss.
Figure 2 shows us all but a typical video streaming session when
everything runs normally.
There are also extreme cases. Many of us may have experience of
watching streaming video that
stalled completely for several times during a streaming session. In
such cases, the bitrate of the
incoming video is nil and the packet loss rate is 100%, making it
totally worthless to watch.
Generally speaking, the experience of streaming video isn't always as
bad (or good) as that in
our memory or in Figure 2. A person who was watching the same streaming
video from another
________________________________________
Page 8
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-6-
location might have had a totally different experience. The point is
that the Internet channel
variations are so volatile and space- and time-dependent that the
observation can be different by
every client on the network at every second. The data shown in Figure 2
and our experience
about video streaming challenge us with two fundamental signal
processing problems whose
solutions can improve the performance of Internet video streaming
dramatically. The first
problem is concerned with how to adapt to the constantly changing
bandwidth and congestion
condition on the Internet. The second calls for solutions to coping
with packet loss due to the
best-effort service model of the current Internet. We will, for short,
refer to these two problems
as "rate adaptation", and "error control and recovery",
respectively. Before we attempt to address
these problems and evaluate a number of proposed solutions, we need to
examine the constraints
that have been imposed on any prospective solutions. We go back to the
video streaming model
and architecture of Section 2.1 and make a few important observations.
Video Streaming System Characteristics and Constraints
Many signal processing researchers are familiar with the video
conferencing model thanks to the
popularity of ITU H.261 and H.263 standards. In the following we review
the characteristics of a
video streaming system and point out its difference from video
conferencing. For the comparison
purpose we provide in Figure 3 a functional diagram of an IP-based
peer-to peer video
conferencing system. As we have mentioned, we will focus on analyzing
the unicast video
streaming system.
(a) Latency. One difference between streaming and conferencing is that
the
former does not require two-way user interaction. As such the
requirement on
latency is more relaxed in streaming than in conferencing. Latency
requirement
commonly translates into a decoder/client buffer of certain size; which
is often
simulated by the encoder/server for rate control. When a video
streaming session
is initiated, the client waits for a few seconds for its buffer to be
filled by the
server. This process is called pre-roll. After the pre-roll the client
starts playing
the video. Obviously, the client's buffer has to be kept from
underflow in order
for the video to continue to play without interruption. Generally
speaking,
streaming can afford to use a much larger buffer than that can be
considered in
conferencing to absorb network jitters. However, latency and smooth
playback
must be balanced to create a good user experience, which becomes more
important in streaming live video. It is common in commercial video
streaming
systems to pre-roll a few seconds of data into the decoder/client
buffer.
(b) Client-Server Model. This makes a major distinction between the
video
streaming system of Figure 1(a) and the peer-to peer conferencing
system of
Figure 3. In the video conferencing system of Figure 3, there is no
server
involved. Additionally, most components including encoder, decoder,
packetizer,
and reassembler at either end often reside on one piece of hardware,
which is a
desktop computer in the so-called desktop conferencing environment. The
video
streaming system in Figure 1(a), however, operates in a client-server
environment. As such, a streaming server may be required to serve
thousands of
clients simultaneously. It is therefore necessary for the encoder to be
separate
________________________________________
Page 9
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-7-
Figure 3 An IP-based peer-to-peer video conferencing system.
from the server hardware so that the server hardware can be dedicated
to serving
the clients. For archived, on-demand video streaming, encoder and
server are
separate by default. In live streaming, encoder/server separation
enables a more
efficient "encode once, serve multiple times" service model. This
model is almost
always adopted in practice. A common implementation for live video
streaming is
to combine the encoder and packetizer to reside on one piece of
hardware that
broadcasts a stream to the server. The server simply "reflects" the
stream to its
clients. The client-server model and the nature of encoder/server
separation make
it unsuitable for many signal processing techniques that have been
developed for
video conferencing to be used in video streaming. We will come back to
this
observation later.
(c) Server Load Restrictions. As we have pointed out that a streaming
video
server may be required to serve thousands of clients simultaneously.
When the
number of clients connected to a server increases, the server
experiences an
elevated load due to increased processing and I/O demands. Eventually
the server
can get overloaded and the quality of service drops. While it is
relatively well
understood that a good signal processing solution should not require
the server to
do much processing, the requirement for I/O is often overlooked. In
archived, on-
demand video streaming, when the number of clients increases, heavy I/O
activity, particularly disk access, often becomes the bottleneck in the
streaming
system. This ought to be kept in mind in designing a signal processing
solution
for video streaming.
(d) The Best-Effort Service Model. The Internet is a best-effort
service network.
As such, each request to send a packet is honored by the Internet at
best it can.
Congestion on the Internet causes packet delay and loss. Normally, a
packet is
routed through multiple hops on its way to the destination. At each
switching
point linking the hops, if there are other packets that have arrived
earlier, the
incoming packet is queued before it can be processed by the router,
resulting a
queuing delay. If the router's queue is full, the incoming packet
will be dropped,
resulting a packet loss. Statistics have shown that packet delay and
loss often
________________________________________
Page 10
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-8-
occur in bursts because an overloaded router and the affected route are
likely to
stay congested for some time. In video streaming, each packet is
scheduled to be
played at certain time; a packet that has arrived later than the
scheduled time is
useless and will be discarded. For this reason, we don't distinguish
packets that
are dropped by a router due to congestion or by the streaming client
because they
come too late to be used. More generally, taking a signal processing
approach, we
can view the Internet as a "black box". A streaming client from
outside the black
box can observe an effective bandwidth and packet loss rate without
having to
know what is going on inside the black box.
(e) Packetization. A packetizer takes an encoded video bitstream and
packetizes it
for transmission over a transport protocol such as RTP. One of the most
important
aspects in designing a packetizer is to determine how to fragment the
video
bitstream. A well-designed fragmentation scheme with associated header
information can help contain error in case of a packet loss. To date
many video
payload formats have been specified or proposed for RTP including those
for the
popular H.261, H.263 and the MPEG family. These payload formats offer
fragmentation schemes of different granularities, such as
Group-Of-Block(GOB)
based or Macro-Block (MB) based. Besides fragmentation scheme it is
also
important to choose the size of a packet. On the one hand, small
packets could
control the adverse effect of a packet loss; on the other hand, it is
desirable to
send large packet to reduce packet header overhead. When streaming
video over
RTP, it is common to packetize the data for the maximum transmission
unit
(MTU) of a local area network (LAN). For the Ethernet, the MTU is about
1500
bytes, or 12000 bits. However, other restrictions may apply. For
example, a RTP
video packet is required to contain at most a single video frame. In
other words, a
new frame cannot start in the middle of a packet, though a frame can be
split into
multiple packets.
(f) Back-channel. A back-channel in a video streaming system is a
communication channel established for a streaming client to report its
state to
and/or request services from the server. In RTP streaming,
implementation of
back-channels is facilitated by the Real-time Transport Control
Protocol (RTCP)
that is part of the RTP specifications. The RTCP defines a type of
packet for
receiver report (RR). A RR packet includes such information as fraction
of
packets lost since the previous RR packet, cumulative number of packets
lost, and
interarrival jitter. It also supports profile- or application-specific
extensions for
including more information from the receiver. In addition to using the
RR
packets, it is also possible to define customized RTCP packet to carry
feedback
information from a streaming client. While the information about
effective
bandwidth and the state of packet loss can be fed back and useful to
the streaming
server, it is a common mistake to assume that the video encoder can
always take
advantage of the back- channel.
The Approach: Technology Overlay
________________________________________
Page 11
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-9-
This system uses a different approach than signal dependant
transmission methodology.
Providing an overlay at the point of packet transmission using a
proprietary mathematical key,
the packet size is reduced by a ratio of about 800% (uncompressed
material) 200 % (compressed
material such as MPEG) optimal ratio or about 50% less sustained.
Video transmission occurs as outlined in part one of this document.
Using the Linux
platform and a compression daemon, the video packet is modified at the
time of placement on
layer one of ODI. Because it is a sequence modification, and not actual
compression, all of the
original data is included. This removes the requirement of having a
decompressor running on
the client side, and will allow the algorithm to work without the need
for the client to install
additional software or use a proprietary viewer outside of the viewer
required for the format
offered. (i.e.: Real Networks Real Player is still used to play the
Real Networks media format,
and no additional software is required by the client).
In addition, this approach provides a cost feasible solution to the
content provider.
Services are primary offered using an ASP (application service
provider) model. This means
that the content providers media, while stored on their own equipment
or ours, is transmitted
from our data center. The encoding is performed at this point in the
process. Compare the
following two cost assessments. This assumes a content provider using
our system to host and
transmit their videos. This also assumes the use of the Real Networks
format with the unlimited
server. Comparison made with the Real Networks website
(www.realnetworks.com) in April of
2004.
Not illustrated below is the redundant network provided by WDS. All
data is replicated
not just between multiple servers but between multiple server
co-location facilities. This
guarantees that, even in the event of a catastrophic system failure,
content will still be available.
The WDS pricing model is based on the 30 MB server package, which
includes up to 30
gigabyte of video content space and a maximum of 30 MB of transmission
bandwidth at any one
time.
* Setup fee assumes flat rate setup of server and installation and
configuration of Linux at
$995.00
** Maintenance of equipment assumes 5 hour per month support contract
at $125.00. Actual
cost of maintenance could be much higher.
The first table is one time fees for setup and required purchases. The
second is monthly costs.
________________________________________
Page 12
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-10-
Setup Costs
Legacy Solution
WDS Solution
Streaming Software
$32,000.00
Not Required
Encoding Software
$195.00
$195.00
Setup Fee
$995.00 *
$495.00
File Server
$12,500.00
Not Required
Total Setup Fees
$45,690
$690
Monthly Costs
Legacy Solution
WDS Solution
Bandwidth Per Month
$11,500.00
$9,995
Maintenance for Equipment
Per Month **
$625.00
Included
Backups Per Month
$525.00
Included
Total Monthly Costs
$12,650
$9,995
Conclusion
There are many approaches to video technology with three being deemed
industry
standards. These standards include the Real Networks Real Media format,
the Apple Quicktime
format, and the Microsoft Windows Media Player format. All of the
approaches used attempt to
send high quality video and audio in a stream over the Internet and do
a good job at high
connection speeds.
The industry challenge is in providing this same video quality over the
average connection
speed obtained by end users using DSL or Cable Modem technologies, with
an average speed of
512k.
Creating a new format to do this would be cost prohibitive due to the
requirement of
educating end users to download and install new video software, as well
as the issue of convening
content providers to re-encode all their media. The best approach is to
create a way that the
existing media format can be used to delivery higher quality content.
Web Delivered Solutions has created a technology that "overlays"
the existing media
stream and recreates the data packets at the point of transmission.
This proprietary technology
allows all of the original data to be included without the need of the
installation of end user
software in addition to the player. A reconfiguration is required at
the point of the server, or, the
________________________________________
Page 13
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-11-
video delivery may be used in an ASP environment requiring no server
end equipment be
purchased or configured by the content provider.
________________________________________
Page 14
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-12-
References
1.
1. S. McCanne, "Scalable multimedia communication using IP multicast
and
lightweight sessions," IEEE Internet Computing, Vol. 2, No.2, pp.
33-45, Mar.
1999.
2.
Stardust.com, Inc, "The evolution of multicast," IP Multicast
Initiatives White
Paper, December 1999. http://www.ipmi.org/
3.
Akamai Technologies, Inc. http://www.akamai.com/
4.
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport
protocol for real-time applications," RFC 1889, Internet Engineering
Task Force
(IETF), Jan. 1996.
5.
J.-C. Bolot, T. Turletti, and I. Wakeman, "Scalable feedback control
for multicast
video distribution in the internet," in SIGCOMM Symposium on
Communications
Architectures and Protocols, (London, England), pp. 58-67, Aug. 1994.
6.
I. Busse, B. Deffner, and H. Schulzrinne, "Dynamic QoS control of
multimedia
applications based on RTP," Computer Communications, Jan. 1996.
7.
J-C. Bolot, T. Turletti, "Experience with rate control mechanisms for
packet video
in the Internet," Computer Communication Review, Vol. 28, No. 1, Jan.
1998.
8.
Y.J. Chung, J.W. Kim, and C.-C.J. Kuo, "Network friendly video
streaming via
adaptive LMS bandwidth control," in Applications of Digital Image
Processing
XXI, Proc. SPIE, vol. 3460, pp. 448-456, July 1998.
9.
Y.J. Chung, J. Kim, and C.-C.J. Kuo, "Real-time streaming video with
adaptive
bandwidth control and DCT-based error concealment," IEEE Trans. CAS
II:
Analog and Digital Signal Processing, Vol. 46, No. 7, pp. 951-956, July
1999.
10.
F. Le Léannec, F. Toutain, C. Guillemot, "Packet loss resilient
MPEG-4 compliant
video coding for the Internet," Signal Processing: Image
Communications, Vol.
15, pp. 35-56, Sept. 1999.
11.
E. Steinbach, N. Färber, and B. Girod, "Standard compatible
extension to H.263
for robust video transmission in mobile environments," IEEE Trans.
CAS for
Video Technol., Vol. 7, No. 6, pp. 872-881, Dec. 1997.
12.
S. Fukunaga, Y. Matsumura, and T. Nakai, "Error resilient video
coding controlled
by backward channel signaling," Signal Processing: Image
Communications, Vol.
14, pp. 531-540, May 1999.
13.
S. Wenger, G. Knorr, J. Ott, and F. Kossentini, "Error resilience
support in
H.263+," IEEE Trans. Circuits and Sys. for Video Tech., Vol. 8, No.
7, pp. 867-
877, Nov. 1998.
14.
U. Horn, K. Stuhlmüller, M. Link, and B. Girod, "Robust Internet
video
transmission based on scalable coding and unequal error protection,"
Signal
Processing: Image Communications, Vol. 15, pp. 77-94, Sept., 1999.
15.
H. Sun, W. Kowk, and J.W. Zdepski, "Architectures for MPEG compressed
bitstream scaling," IEEE Trans. CAS for Video Technol., Vol. 6, No.
2, pp. 191-
199, April 1996.
16.
G. Keesman, R. Hellinghuizen, F. Hoeksema, and G. Heideman,
"Transcoding of
MPEG bitstreams," Signal Processing: Image Commun., Vol. 8, pp.
481-500,
________________________________________
Page 15
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-13-
Sept. 1996.
17.
P.A.A. Assuncao and M. Ghanbari, "A frequency-domain video transcoder
for
dynamic bit-rate reduction of MPEG-2 bit streams," IEEE Trans. CAS
for Video
Technol., Vol. 8, No. 8, pp. 953-967, Dec. 1998.
18.
S., Jacobs and A. Eleftheriadis, "Streaming video on the Web using
dynamic rate
shaping," J. Visual Commun. Image Representation, Vol. 9, No. 3, pp.
211-222,
Sept. 1998.
19.
W. Zeng and B. Liu, "Rate shaping by block dropping for transmission
of MPEG-
precoded video over channels of dynamic bandwidth," in Proc. ACM
Multimedia'96, pp. 385-393, Nov. 1996.
20.
Y. Nakajima, H. Hori, and T. Kanoh, "Rate conversion of MPEG coded
video by
re-quantization process," in Proceedings of IEEE Intl. Conf. Image
Proc.,
Washington, DC, Oct. 1995, pp. 408-411.
21.
Darwin Streaming Server Project,
http://www.publicsource.apple.com/projects/streaming/
22.
A. Lippman, "Video coding for multiple target audiences," in Visual
Communications and Image Processing'99, Proc. SPIE, Vol. 3653, pp.
780-782,
Jan. 1999.
23.
"SureStream?-Delivering superior quality and reliability,"
RealNetworks White
Papers,
http://www.realnetworks.com/devzone/library/whitepapers/surestrm.html
24.
B. Girod, N. Färber, and K. Stuhlmüller, "Internet video
streaming," in: F. De
Natale and S. Pupolin (eds.), Multimedia Communications, Springer,
1999, pp.
547-556.
25.
K.M. Uz, M. Vetterli, and D. LeGall, "Interpolative multiresolution
coding of
advanced television with compatible subchannels," IEEE Trans. CAS for
Video
Technol., Vol. 1, pp. 86-99, Mar. 1991.
26. S. McCanne, V. Jacobson, and M. Vetterli, "Receiver-driven
layered multicast,"
ACM SIGCOMM'96, Stanford, CA, Aug. 1996.
27.
S. McCanne, M. Vetterli, and V. Jacobson, "Low complexity video
coding for
receiver driven layered multicast," IEEE J. Selected Areas in
Communications,
Vol. 15, No. 6, pp. 983-1001, Aug. 1997.
28.
D. Taubman and A. Zakhor, "Multi-rate 3-dimensional subband coding of
video,"
IEEE Trans. Image Proc., Vol. 3, pp. 572-588, Sept. 1994.
29.
J.Y. Tham, S. Ranganath, and A.A. Kassim, "Highly scalable
wavelet-based video
codec for very low bit-rate environment," IEEE J. Selected Areas in
Communications, vol. 16, No. 1, pp. 12-27, Jan. 1998.
30.
K. Chen and E.J. Delp, "Wavelet based rate scalable video
compression," IEEE
Trans. CAS for Video Technol., Vol. 9, No. 1, pp. 109-22, Feb. 1999.
31.
K. Sripanidkulchai and T. Chen, "Network-adaptive video coding and
transmission," in Visual Communications and Image Processing'99,
Proc. SPIE,
Vol. 3653, pp. 854-861, Jan. 1999.
32.
L. Yang, F.C.M. Marins, and T.R. Gardos, "Improving H.263+
scalability
performance for very low bit rate applications," in Visual
Communications and
Image Processing'99, Proc. SPIE, Vol. 3653, pp. 768-779, Jan. 1999.
________________________________________
Page 16
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-14-
33.
J.M. Shapiro, "Embedded image coding using zerotrees of wavelet
coefficients,"
IEEE Trans. Signal Processing, Vol. 41, No. 12, pp. 3445-3462, Dec.
1993.
34.
A. Said and W.A. Pearlman, "A new, fast and efficient image codec
based on set
partitioning in hierarchical trees," IEEE Trans. CAS for Video
Technol., Vol. 6, pp.
243-250, June 1996.
35.
W.-T. Tan and A. Zakhor, "Real-time Internet video using error
resilient scalable
compression and TCP-friendly transport protocol," IEEE Trans.
Multimedia, Vol.
1, No. 2, pp. 172-186, June 1999.
36.
B.-J. Kim, Z. Xiong, W.A. Pearlman, and Y.S. Kim, "Progressive video
coding for
noisy channels," Journal of Visual Communication and Image
Representation,
Vol.10, No. 2, pp.173-185, June 1999.
37.
W. Li, "Bit-plane coding of DCT coefficients for fine granularity
scalability,"
MPEG contributions, m3989, Atlantic City, NJ, Oct. 1998.
38.
H. Radha, Y. Chen, K. Parthasarathy, and R. Cohen, "Scalable Internet
video using
MPEG-4," Signal Processing: Image Communications, Vol. 15, No. 1-2,
pp. 95-
126, Sept. 1999.
39.
Y. Chen, C. Dufour, J.-F. Vial, A. Zakhor, W. Li, J. Liang, and B.
Schuster,
"Description of mini-experiment of fine granular video
scalability," MPEG
contributions, m3881, Atlantic City, NJ, Oct. 1998.
40.
ISO/IEC JTC1/SC29/WG11, "Text of ISO/IEC 14496-2 FGS Amendment
Working Draft 3.0," MPEG Document N3095, Maui, USA, Dec. 1999.
41.
W. Li, F. Ling, and X. Chen, "Fine granularity scalability in MPEG-4
for
streaming video," to appear in Proceedings of IEEE International
Symposium on
Circuits and Systems (ISCAS'2000), Geneva, Switzerland, May 28-31,
2000.
42.
W. Li, et al, "Streaming video profile," MPEG Contributions, m4990,
Melbourne,
Australia, Oct. 1999.
43.
W. Li, el al, "Streaming video profiles based on
fine-granularity-scalability,"
MPEG Contributions, m5582, Maui, USA, Dec. 1999.
44.
Y. Wang, and Q. Zhu, "Error control and concealment for video
communications:
a review," Proc. IEEE, Vol. 86, No. 5, pp. 974-997, May 1998.
45.
J. Villasenor, Y.-Q. Zhang, and J. When, "Robust video coding
algorithms and
systems," Proc. IEEE, Vol. 87, No. 10, pp. 1724-1733, Oct. 1999.
46.
B. Girod and N. Färber, "Feedback-Based Error Control for Mobile
Video
Transmission", Proc. IEEE, Vol. 87, No. 10, pp. 1707-1723, Oct. 1999.
47.
R. Talluri, "Error resilient video coding in the MPEG-4 standard,"
IEEE Commun.
Mag., Vol. 36, pp. 112-119, June 1998.
48.
R. Talluri, I. Moccagatta, Y. Nag, and G. Cheung, "Error concealment
by data
partitioning," Signal Processing: Image Communication, vol.14,
No.6-8, pp. 505-
518, May 1999.
49. L. Ducla-Soares, and F. Pereira, "Error resilience and
concealment performance
for MPEG-4 frame-based video coding," Signal Processing: Image
Communication, vol.14, No.6-8, pp. 447-472, May 1999.
50.
Y. Wang, M.T. Orchard, and A.R. Reibman, "Multiple description image
coding
for noisy channels by pairing transform coefficients," in Proc. First
IEEE
________________________________________
Page 17
Web Delivered Solutions, Inc. High Speed Delivery White Paper
-15-
Workshop on Multimedia Signal Processing, New York, NY, June 1997. Pp.
419-
424.
51.
D.M. Chung and Y. Wang, "Multiple description image coding using
signal
decomposition and reconstruction based on lapped orthogonal
transforms," IEEE
Trans. CAS for Video Technol., vol. 9, No. 6, pp. 895-908, Sept. 1999.
52. S.D. Servetto, K. Ramchandran, V.A. Vaishampayan, and K. Nahrstedt,
"Multiple
description wavelet based image coding," submitted to IEEE Trans.
Image Proc.,
Nov. 1998.
53.
V.K. Goyal, J. Kovacevic, R. Arean, and M. Vetterli, "Multiple,
description
transform coding of images," in Proceedings of IEEE Conference on
Image
Processing, Chicago, IL, Oct. 1998, pp. 674-678.
54.
X. Yang and K. Ramchandran, "Optimal multiple description subband
coding," in
Proceedings of IEEE Conference on Image Processing, Chicago, IL, Oct.
1998,
pp. 654-658.
55.
R. Chellappa, and M. Srinivasan, "Multiple description subband
coding," in
Proceedings of IEEE Conference on Image Processing, Chicago, IL, Oct.
1998,
pp. 684-688.
56.
A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, "Priority
encoding
transmission, " IEEE Trans. Inform. Theory, Vol. 42, No. 6, pp.
1737-1747, Nov.
1996.
57.
A.E. Mohr, E.A. Riskin, and R.E. Ladner, "Graceful degradation over
packet
erasure channels through forward error correction," in Proc. Data
Compression
Conference, Snowbird, UT, Mar. 1999, pp. 92-101.
58.
Workshop Report: 1999 NSF Sponsored Workshop on Joint Source-Channel
Research, Oct. 1999.
59. Overlay Solution Whitepapers, WDT, Feb. 2004, pp 4-8
60.
Based primary on Signal Processing for Internet Video Streaming: A
Review, Jian
Lu, Apple Computer, Inc.

.