Multimedia Internet Broadcasting and Distributed Conferencing
Download
Report
Transcript Multimedia Internet Broadcasting and Distributed Conferencing
Multimedia
Internet Broadcasting and
Distributed Conferencing
Lecture 2
Internet broadcasting and TV
Terrestrial
and satellite TV
– broadcasts to large audiences
– has “economy of scale”
– provides popular programmes and events
Internet
broadcasting (IB)
– allows small events to be broadcast
– can reach small but global audience
– provides low-cost, user-level broadcasting
What is out there?
Internet
broadcasts (Audio and
Audio/Video) are now common practice
Some are
– well-designed
– easily accessible
– widely available
Others
are difficult to access and
view/hear
Access to IB
In
general all users can access IB
shared links cause capacity shortfall
variable capacity broadcast
lowest quality at 28.8 kbps
– small picture
– low frame rate
– low bandwidth audio
Home-based
attention
users need special
The home-based user
low
bandwidth connection
shared links between Internet service
providers (ISPs) limit bandwidth
IB allows home user to be active in
“production” - not solely consume!
Quality of Service (QoS) is dependent
on the provider - there are few user
options
Software
Many
now available
– CuSeeMe/WhitePine Video conferencing
– Real Networks – RealPlayer G2
– Microsoft Media Player
– Quicktime
Either
– two way communication (conferencing)
– one-way communication (broadcasting)
Real Systems
rtsp
–
–
–
–
or http
rtsp - real time streaming protocol (RFC 2326)
works over TCP or UDP (and could use RTP)
uses URL rtsp://host.domain/dir/file as in http
rtsp and request channel separate
– (out-of band control)
– port 554 is standard
– Uses Real’s Surestream encoding
Surestream (RealPlayer G2)
Embeds
a number of bit-rate versions in
an encoding
Rates from 28.8 kbps up to corporate
LAN capacities
Switches rate based on network
congestion/capability
– i.e. Adaptive/dynamic streaming of data
Servers
Broadcasting
is generally done with
servers
Servers (Reflectors in CUSeeMe) allow
– a number of users to connect to a single
source
– links to other servers to reach
larger
audience
geographically-dispersed audience
Infrastructure issues
Configuration
of servers and interserver links determines network QoS for
individuals
Home-based users can choose server
but a (network) local server usually
performs best
For broadcasting to be an important tool
the delivery infrastructure needs careful
design.
Example events
Concert
broadcast
– Wolverhampton and Aberystwyth
Universities joint venture (concert in
Machynlleth, Wales)
– used CUSeeMe with reflectors in
– UK (3), France, US(2), and Australia
OECD
Seminar - Turku, Finland
– broadcast by EUNet
– linked servers in various EU countries
Infrastructure models
Various
models
Each has its own application area
Choice depends upon
– QoS required
– Audience
– Network operator participation
– other factors
Single server
User
User
Server
User
User
User
ISP netcasting
Event
User
ISP domain
Server
Server
Server
Server
Users
Users
Users
Users
Linked individual sites
Event
User
Domain A
Server
Server
Domain B
Server
Server
Domain C
Users
Users
Users
Co-operation agreements
Domain A
Server
Permanent links
Server
Server
Domain B
Server
Domain C
Working practices
Event-dependent
– Video/Audio need to be useable
– and should account for
small
picture size
limited bandwidth
typical user terminal
New
technical solutions may be needed
Higher bandwidth networks will help
Protocols
Current
protocols are mainly not
optimised for use in broadcast
environments
Use of multicasting can help
Reservation protocols will improve QoS
Home-based users (in particular) are
reliant on many outside factors to
provide good QoS.
Multicasting
Depends
on multicast routers (see
RFC 1112)
Routers maintain multicast groups and
deliver messages to individual hosts
Cuts down on duplication of messages
except for low-use wide-spread
connections
Multicasting is useful if audience is
grouped
Reservation protocol - RSVP
RSVP (RFC 2205)
Uses control messages to reserve capacity along a TCP
connection
Works with TCP/IP - IPv4 and v6
RSVP provides transparent operation through routers that do
not support it.
RSVP makes resource reservations for both unicast and manyto-many multicast applications,
– adapting dynamically to changing group membership as well
as to changing routes
RSVP is receiver-oriented,
– i.e., the receiver of a data flow initiates and maintains the
resource reservation used for that flow.
RSVP characteristics summary
RSVP is simplex, i.e., it makes reservations for
unidirectional data flows.
RSVP maintains "soft" state in routers and hosts,
providing graceful support for dynamic membership
changes and automatic adaptation to routing
changes.
RSVP is not a routing protocol but depends upon
present and future routing protocols.
RSVP transports and maintains traffic control and
policy control parameters that are opaque to RSVP.
RSVP provides several reservation models or "styles"
to fit a variety of applications.
Future use
Higher
bandwidth will help but
– it will be more expensive
– not available to all
– inter-ISP links are also factors in QoS
– infrastructure and configuration is still
relevant
Wider
use will use available bandwidth
– so broadcasts need planning
Other areas
Computer
supported co-operative work
(CSCW)
Teleteaching
Video conferencing
Conferencing
Conferencing
or two-way video/audio
introduces new problems.
Many possible solutions
ISABEL architecture allows
– Distributed conferences
– Multi-point access for send and receive
ISABEL
A management
platform
– Scalable architecture covering large
geographical areas and many sites
– global event management from a single
point
– services can be defined and tuned
– heterogeneous networks
Isabel service model
Type of service,
site, role etc
Network
configuration etc
ISABEL sites
1.
Interactive site
– send and receive, audio, video and data
2. Main Interactive site
– An IS but with special privilege e.g bigger screen.
(It may have a local audience)
3. Control site
– the most important site which controls the event
4.
Watch point
– receive-only site
ISABEL layered architecture
Typical configuration
Summary
Different models of broadcast infrastructure
have been proposed with different application
areas
Home-based users rely on ISPs to provide
QoS
New developments may not be the solution
Providers should develop infrastructures to
support broadcasts to (and from) homes
Conferencing is a much more complex
activity
References
Broadcasting
– RSVP - RFC2205
(ietf web site)
– Multicasting - RFC 1112 (ietf web site)
– Sloane A (2000), “ Infrastructure issues for Internet broadcasting to
home-based users”, in Beardon, Munari and Rasmussen (Eds.),
“Computers and Networks in the Age of Globalisation”, Kluwer,
Boston, ISBN0-7923-7253-0, pp187-196
Conferencing
– Robles et al “Distributed Global Conferences over heterogeneous
networks” in Sloane A and Lawrence D (2001), Multimedia Internet
Broadcasting, Springer, London Chapter 4