multimedia internet broadcasting and distributed conferencing lecture 2
Post on 19-Dec-2015
213 Views
Preview:
TRANSCRIPT
MultimediaInternet 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 users need special attention
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 inter-server 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
Server
User
User
User
User
User
ISP netcasting
Server
Users
Users
Users Users
User
Server Server
Server
Event
ISP domain
Linked individual sites
Server
Users
Users Users
User
Server Server
Server
Event
Domain A
Domain B Domain C
Co-operation agreements
Server
Server Server
ServerDomain A
Domain B
Domain C
Permanent links
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 many-
to-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
top related