Xi'an University of Posts and Telecommunications
Software development papers
RealSystem-based remote teaching system
Remote Teaching System Based on realsystem
Basic knowledge and protocol part
Department: Computer
Professional: Computer Electronic Information Science and Technology
Class: Electricity 0101
Developer Name: Xu Zhaoyuan
mentor:
Start time: October 2003 to XX Month
table of Contents
I. Basic knowledge of streaming media
1.1 What is a stream
1.2 stream transmission foundation
2. Analysis of the PNA protocol
2. Real Time Flow Protocol RTSP
2.2 Real Time Transport Protocol RTP
2.3 Real Time Transmission Control Protocol RTCP Protocol
2.4 Resource Reserved Agreement RSVP
Three. Smil language
3.1.smil language profile
3.2 Details
3.3 SMIL foreground prospects
One. Stream media knowledge
1.1 What is a streaming
With the development of modern network technology, the network as the fourth media begins to bring more form of information mode. From the Internet, the first picture appeared on the network, and now various forms of online video, three-dimensional animation, people's audio-visual sensation officials have been greatly satisfied on the network. At the same time, it is facing another inevitable embarrassment: It is because of the continuous improvement of people's needs, the increasing number of Internet users, plus the limitations of network hardware devices, making the size of the file become a non-negligible parameter of the network. On the one hand, people want to see vivid and clear media demonstrations on the Internet, and in the other hand, people have to face a lot of time required for file transmission under this slow network speed. In order to solve this contradiction, a new media technology came into being, this is "streaming media technology".
I don't know if you start to know such technologies. In my impression, Flash technology is the first to bring me the concept of "stream". Includes subsequent Shockwave for Authorware, Shockwave for Director, etc. The latest network 3D image standard, the same is the flow-type propagation technology, and examples are very hot recently, and the effect is really good for ViewPoiInt (Metastream) and Cult3D technology. Of course, I also use the concept of streaming in QTVR. We are not mentioned here.
The above may only be aligheated out, we mainly introduce the system of streaming media for network video transmission applications, mainly REAL SYSTEM and MedIA Service, of course there is QuickTime. As for a Cisco IP / TV, a class system, due to a small range of use, the time and occasion of the time and occasion, do not do detailed research.
No matter which system, their basic principles are the same: first, by using an efficient compression algorithm, the original massive multimedia data is suitable for streaming of streaming while reducing the loss of the file size while reducing the size of the file. Then, the MIME ID is then modified by the frame. Transport stream data through various real-time protocols.
Real-time flow transfer agreements include:
Real-time transmission protocol RTP: RTP (Real-Time Transport Protocol)
Real-time transmission control protocol RTCP: RTCP (Real-Time Transport Control Protocol)
Real Time Flow Protocol RTSP: RTSP (Real-Time Streaming Protocol)
RSVP protocol: RSVP (Resource Reserve Protocol)
MMS protocol: MMS protocol (Microsoft Media Server Protocol)
Streaming Media is an important basic technology for modern network transmission, which is critical to online broadcast of remote teaching systems. The streaming media actually refers to a new media transfer method, not a new media. 1.2 streaming transmission foundation
Multimedia information such as transport / video on the network is currently mainly downloaded and streaming two programs. The A / V file is generally large, so the storage capacity required is also large; the download is often a few minutes from the network bandwidth, and this processing method is also very delayed. When streaming, the sound, video or animation, etc., by the audio and video server, the user's computer continuous, real-time transmission, the user does not have to wait until all the files are all downloaded, but only a few seconds or more seconds start launch delay Watch can be viewed. When the audio of the base is played on the client, the remainder of the file will continue to download from the server in the background. Flow not only makes startup delays ten times, not shortened, and does not require too much cache capacity. Flow transmission avoids the shortcomings that users must wait for the entire file to download from the Internet to watch.
Streaming refers to the continuous time base media for streaming technology in Internet / intranet, such as audio, video or multimedia files. Flow media does not download the entire file before playback, only put the beginning of the content into memory, flow media's data flow versatile with time, but there are some delays at the beginning. The key technologies achieved by streaming are streaming.
Stream transmission definitions are wide, and now mainly refers to the technology generalization of the media (such as video, audio) through network. Its specific meaning is transmitted to the PC through the Internet. There are two ways to achieve streaming: realTime streaming and sequential streaming. Generally speaking, such as video is real-time broadcast, or using streaming media servers, or applies a real-time protocol such as RTSP, that is, real-time streaming. If the HTTP server is used, the file is sent in sequence. Using that transmission method relies on your needs. Of course, the flow file also supports completely downloaded to the hard drive before playing.
1.2.1 Sequential streaming (Progressive Streaming)
Sequential streaming is the order of downloading, and the user can watch the back-line media while downloading the file. At a given moment, the user can only watch the part of the downloaded part, and cannot jump to the front part of the yet to download, sequentially streaming Unlike real-time streaming during transmission, adjustments according to the speed of the user connection. Since the standard HTTP server can send this form of file, it does not require other special protocols, which are often referred to as HTTP streaming. Sequential streaming is more suitable for high quality short fragments, such as tabs, tails and advertisements, because the file is not desirably downloaded, this method guarantees the final quality of movie playback. This means that users must experience delay before watching, especially for slower connectivity.
The sequential streaming is very practical for the release of a short segment through a modem, which allows for creating a video clip with a higher data rate than the modem. Despite latency, you will have a higher quality video clip after all.
Sequential flow files are placed on standard HTTP or FTP servers, easy to manage, basically independent of firewall. Sequential streaming is not suitable for long fragments and videos with random access requirements, such as lectures, speeches and demos. It also does not support live broadcasts, strictly saying, it is a broadcas technology.
1.2.2 Real Time Stream Transmission (RealTime Streaming)
Real-time streaming refers to ensuring that the media signal bandwidth is matched to network connection, so that the media can be seen in real time. Real-time flow is different from HTTP streaming, and he needs a dedicated streaming server and transport protocol.
Real-time streaming is always real-time transmission, especially suitable for on-site events, but also supports random access, users can quickly forward or retreat to watch the front or later. In theory, the real-time stream can not stop, but in fact, cycle suspension may occur. Real-time streaming must match the connection bandwidth, which means that the image quality is poor when the modem speed is connected. Moreover, the quality of the video is poor when the information that is lost, the network is crowded or problematic. If you want to guarantee the quality of the video, sequential flow transmission may be better. Real-time streaming requires specific servers such as QuickTime Streaming Server, RealServer with Windows Media Server. These servers allow you to send more levels of control over the media, so system settings, management is more complicated than standard HTTP servers. Real-time streaming requires special network protocols, such as: RTSP (Realtime Streaming Protocol) or MMS (Microsoft Media Server). These protocols sometimes have problems when there is a firewall, causing users to see the real-time content of some locations.
1.3 streaming media playback
u unicast
Unicast is a point-to-point connection between the client and the server. "Point-to-point" means that each client receives a remote stream from the server. The unicast stream is sent only when the client issues a request. A separate data channel needs to be created between the client and the media server, and each packet sent from one server can only be transmitted to a client. Each user must send a separate query on the media server, while the media server must send each user to a copy of the data package. This huge redundancy first causes the server heavy burden, and the response takes a long time, even stops playback; the management also is forced to purchase hardware and bandwidth to ensure a certain quality of service.
u multicast
Multicast is through the content stream passed by enabling multicast networks; all clients in the network share the same first class. IP Multicast Technologies build a network with multicast capabilities, allowing routers to copy packets to multiple channels at a time. With multicast mode, a single server can simultaneously send continuous data streams simultaneously with tens of thousands of clients. The media server only needs to send a packet instead of multiple; all the requested client sharing the same packet. Information can be sent to the client of any address, reducing the total amount of packets transmitted on the network. Network utilization efficiency is greatly improved, and the cost is greatly reduced.
u on demand
On-demand connection is a proactive connection between the client and the server. In the on-demand connection, the user initializes the client connection by selecting a content item. Users can start, stop, back, fast forward, or pause flow. On-demand connections provide maximum control of convection, but this way is quickly used throughout the network bandwidth due to each client connected to the server.
U broadcast / multicast
The broadcast is the user passive reception stream. During the broadcast, the client receives stream, but cannot control the stream. For example, the user cannot pause, fast forward, or back to the stream. A single copy of the data packet in the broadcast mode will be sent to all users on the network. When using unicast transmission, you need to copy multiple copies, send them to those users who need it in multiple point-to-point, while using broadcast mode, a single copy of the packet will be sent to all users on the network. No matter whether the user needs, the above two transmission methods will have a waste of network bandwidth. The multicast absorbs the length of the above two transmission methods, overcomes the weaknesses of the above two transmission methods, and sends a single copy of the packet to those customers required. Multicast does not copy multiple copies of the packet to the network, nor does it send the packet to those customers who don't need it, ensuring the smallest bandwidth of multimedia applications on the network.
two. Protocol analysis
2. Real Time Flow Protocol RTSP
Real-time flow protocols RTSP (RealTimeStreamingProtocol) is made by RealNetworks and Netscape, which defines how a multimedia data is transmitted efficiently through IP networks. RTSP is located on the RTP and RTCP on the architecture, which uses TCP or RTP to complete data transmission. HTTP transmits HTML compared to RTSP, while RTP is transmitted is multimedia data. The HTTP request is issued by the client, and the server responds; when using RTSP, both the client and the server can issue a request, that is, the RTSP can be two-way. Real Time Flow Protocol (RTSP) is the application level protocol to control the transmission of real-time data. RTSP provides an extensible framework that makes real-time data, controlled by audio and video, on-demand. The data source includes field data and data stored in the clip. The protocol is an object of controlling multiple data transmission connections, providing a transmission channel, such as UDP, multicast UDP, providing a way, and provides a method based on RTP-based transmission mechanism.
2.1.1 Introduction
2.1.1.1 Purpose
Real Time Flow Protocol (RTSP) establishes and controls one or several time synchronized continuous streaming media. Although continuous media streams and control flow intersect, usually it does not send continuous streams. In other words, RTSP acts as a network remote control of a multimedia server. The RTSP connection is not bound to the transport layer connection, such as TCP. During the RTSP connection, the RTSP user can turn off or off multiple reliable transfer connections to the server to issue RTSP requests. In addition, you can use no connection transport protocol, such as UDP. The RTSP stream control flows may be used to RTP, but the RTSP operation does not depend on the transmission mechanism for carrying continuous media. The real-time flow protocol is similar to HTTP / 1.1 in syntax and operation, so the HTTP expansion mechanism can be added to RTSP. The operations of the protocol support are as follows:
Retrieve media from the media server:
Users can submit a presentation description via HTTP or other methods. If the demo is multicast, the demo includes multicast addresses and ports for continuous media. If the presentation is sent to the user only by unicast, the user should provide the destination address for security.
Media server invitation to meet the meeting:
The media server can be invited to participate in the positive meeting, or play back the media, or record some of them, or all. This model is useful in distributed education applications, and several conferences can be turned by remote control buttons.
Add the media to the ready-made lecture:
If the server tells the user to get additional media content, it is especially useful for the on-site lectures. Similar to HTTP / 1.1, the RTSP request can be processed by proxy, channels and cache.
2.1.1.2 Characteristics of protocol
The RTSP features are as follows:
Scalability:
The new methods and parameters are easy to join RTSP.
Easy to analyze:
RTSP can be parsed by standard HTTP or MIME desirators.
Safety:
RTSP uses a web security mechanism.
Independent transmission:
RTSP You can use a reliable stream protocol using Un Reliat Data Rights Protocol (UDP), Reliable Data Rights Protocol (RDP), if you want to be reliable, you can use Reliable Stream Protocol.
Multiple server support:
Each stream can be placed on different servers, and the client automatically establishes several concurrent control connections with different servers, and the media is synchronized in the transport layer.
Record device control:
The protocol can control recording and playback devices.
Flow control and conference start separation:
Only the meeting initialization protocol is required, or can be used to create a unique conference identification number. Special circumstances, SIP or H.323
Can be used to invite the server into the meeting.
Suitable for professional applications:
With the SMPTE time, RTSP supports frame level accuracy, allowing remote digital editing
Demo Description Neutral:
The agreement does not have a special demo or metafile, which can transmit the format type used; however, the presentation describes at least one RTSP URI. Agent and firewall friendly:
The protocol can be processed by the application and transport layer firewall. The firewall needs to understand the setup method to open a "gap" for the UDP media stream.
HTTP friendly:
Here, RTSP is wise to adopt HTTP concepts, making it reuse now. The structure includes an Internet Content Select Platform (PICS). The RTSP is not only to the HTTP to add a method not only to the HTTP in most cases.
Appropriate server control:
If the user starts a stream, he must also stop a stream.
Transmission coordination;
The user can coordinate the transmission method before actually handling the continuous media stream.
Performance coordination:
If the basic feature is invalid, there must be some cleaning mechanism to make the user decide that the method did not take effect. This allows users to propose suitable user interfaces.
2.1.1.3 Expanding RTSP
Since not all media servers have the same function, the media server is necessary to support different request sets. RTSP can be extended in three ways, here to change the size:
Extension with new parameters. If the user needs to refuse notice, the method extension does not support, and the corresponding tag is added to the requirements.
Join new methods. If the information recipient does not understand the request, return 501 error code (not implemented), the sender should not try this method again. Users can use the Options method to query the method of server support. The server uses a public response header to list the method of support.
Define a new version protocol to allow all parts to be changed. (In addition to the protocol version number location)
2.1.1.4 Operation mode
Each presentation and media stream can be identified by RTSP URL. The entire presentation with the media attribute is defined by the presentation description file. Use HTTP or otherwise users to get this file, it is not necessary to save on the media server.
For explanation, it is assumed that the presentation describes a plurality of demonstrations, each of which maintains a common time axis. To simplify the description, and if you do not lose general, assume that the presentation describes the presentation. The presentation can contain multiple media streams. In addition to media parameters, network destination addresses and ports need to be decided. The following is different from several modes of operation:
Unicast:
The media is sent to the RTSP request source with the port number selected by the user.
Multicast, server selection address:
The media server selects multicast addresses and ports, which is the way live broadcast or varies.
Multicast, user selection address:
If the server adds the ongoing multicast conference, multicast addresses, ports, and programs are given by the conference description.
2.1.1.5 RTSP status
The RTSP control is independent of the stream transmitted by a separate protocol. For example, RTSP control can be connected via TCP, and the data stream is adopted by UDP. Therefore, the data will continue to send even if the media server does not receive requests. In the connection life, a single media stream can be controlled by different TCP connection sequences. Therefore, the server needs to maintain the connection status of the connection stream with the RTSP request. Many methods are independent of the state in RTSP, but the following methods are important to define the allocation and application of server flow resources:
Setup:
Let the server give the stream allocation resource and start the RTSP connection.
Play with Record:
Start the data transfer of the SETUP allocation stream.
PAUSE:
Temporary stop stream without releasing server resources.
TEARDOWN:
Release the resources, the RTSP connection is stopped.
The RTSP method of the identification state uses the connection header to identify the RTSP connection, to respond to the setup request, the server
Convergence the connection logo.
2.1.1.6 Relationship with other protocols
RTSP overlaps with HTTP, and the HTTP interaction is reflected in the initial contact of the stream content through the web page. The current protocol specification is to allow different transfer points between web servers and implementation RTSP media servers. For example, the demo description can be retrieved by HTTP and RTSP, which reduces the round trip delivery of the browser, and allows the independent RTSP server and the user to rely on HTTP. However, the essential difference between RTSP and HTTP is that the data is transmitted in different protocols. HTTP is an asymmetric agreement, the user issues a request, and the server responds. In RTSP, media users and servers can issue requests, and their requests are stateless; they can set parameters for a long time after the request is confirmed, and the media stream can be controlled. The HTTP function is reused, at least two aspects, the security and proxy. It is very close to the HTTP function in cache, proxy, and authorization.
When most real-time media use RTP as a transfer protocol, the RTSP is not bound to the RTP. RTSP assumes that there is a demo description format indicates a static and temporary property that contains several media streams.
2.1.2 Protocol parameters
2.1.3 RTSP information
RTSP is based on text-based protocol, using the ISO 10646 character set, using the UTF-8 coding scheme. The row is interrupted in CRLF, but the recipient itself can explain CR and LF to a row terminator. The text-based protocol is made easier to increase optional parameters in the self-description. Due to the number of parameters and the frequency of commands, the processing efficiency is not paying attention. If you carefully study, the text agreement is easy to implement research prototypes in scripting languages (such as: TCL, Visual Basic and Perl).
10646 Character Set Avoid sensitive character set switching, but it is invisible to applications. RTCP also uses this coding scheme. ISO 8859-1 characters with important sense bits indicate such as 10001x 10xxxxxx.. RTSP information can be carried by any low-level transport protocol.
The request includes a method, method acting on the objects thereon and the parameters of the further description. The method can also be designed to require only small or no status maintenance on the server side. When the information is included in the information, the information body length is determined by the following factors:
Regardless of whether the entity head segment occurs in the information, the response information does not include the information of the information, always ends the first and space lines after the head segment.
If the content length header appears, its value is based on byte, indicates the length of the information body. If the header is not appeared, its value is zero.
The server is turned off.
Note: RTSP currently does not support HTTP / 1.1 "block" transmission coding, requiring content length head. If you return an appropriate demo description length, even if it is dynamically generated, the block transmission coding is not necessary, the server should also determine its length. If there is an entity, even if there must be content length, and the length is not explicitly given, the rules ensure reasonable behavior.
The request information from the user to the server includes the method, source ID, and the protocol version used in the first line. RTSP defines additional status code without defining any HTTP code.
2.1.4 entity
If the request and response information can be transmitted, the request and response information can be transmitted, and the entity consists of the physical header file and the test, and some responses include the entity head. Here, depending on who sends an entity, who receives the entity, senders and recipients can refer to users and servers, respectively.
The physical head defines the substantial optional elevational information, such as the resource that does not have a solid body, refers to the request identified. The extended head mechanism allows the additional entity header to be defined without changing the protocol, but these segments cannot assume that the recipient can identify. The unrecognizable head should be ignored by the recipient, and let the agent forward.
2.1.5 connection
RTSP requests can be transmitted in several different ways:
1, persistent transmission connection, used in multiple request / response transmission.
2, each request / response transmission one connection.
3, no connection mode.
The transmission connection type is defined by the RTSP URI. For the "RTSP" scenario, you need to continuous connection; and the "RTSPU" scheme calls the RTSP request to send without establishing a connection. Unlike HTTP, RTSP allows media servers to send requests to media users. However, this is only supported when persistent connections, otherwise the media server does not have a reliable way to reach the user, which is also the only way to pass the firewall from the media server to the user.
2.1.6 method definition
Methodology indicates the method of the resource execution, which is case sensitive. The new method can be defined in the future, but cannot start with $.
Some firewall design may require the server to insert the RTSP method and stream data. Since the insert will make the client and server operation complex, and add additional overhead, this should be avoided unless it is necessary. Insert binary data is only available when RTSP is transmitted through TCP. Flow data (such as RTP packet) is encapsulated with an ASCII Meet, followed by a one-byte channel identifier, and then the length of the package binary data, two bytes intensity. The flow data is followed by it, without CRLF, but includes a high-level protocol header. Each $ block contains a high-level protocol data unit.
When the transmission is selected as RTP, the RTCP information is also inserted by the server via TCP connection. By default, the RTCP package is transmitted on the first available channel than the RTP channel. The client may explicitly request the RTCP package in another channel, which can be done by specifying the two channels in the transmissive insertion parameters. When two or more streams intersect, in order to get synchronization, RTCP is required. Moreover, this is a convenient way to provide a convenient way to the network settings through the TCP control connection through the RTP / RTCP, which may be transmitted on the UDP.
2.1.7 Intoctional line operation
A client that supports persistent or unconnected may be queued. The server must be responded in the same order in which the request is received. If the request is not sent to the multicast group, the recipient confirms the request. If there is no confirmation information, the sender can reach the same information after more than one recovery (RTT).
RTT is estimated in TCP and the initial value is 500 ms. Applying the cache finally measured RTT as the initial value of the future connection. If you use a reliable transfer protocol to transfer RTSP, requests are not allowed to resend, and the RTSP application is relying on low-layer transmission to provide reliability. If two low-level reliable transmission (such as TCP and RTSP) application retransmission requests, it is possible that each package loss causes two retransmission. Since the transmission stack does not send the application layer retransmission before the first attempt to receive the receiver, the recipient does not fully utilize the application layer retransmission. If the package loss is caused by blocking, the retransmission of different layers will cause the blocked clogging to deteriorate. Time headers are used to avoid retransmission of fuzzy issues to avoid dependence on the conical algorithm. Each request carries a series number in the CSEQ header, and it will be added every time you send a different request. If the request must be carried if it is not confirmed, the request must be carried with the initial series number.
The system that implements RTSP must support RTSP via TCP and support UDP. For UDP and TCP, the default port of the RTSP server is 554. Many of the glimpse of the RTSP package are packaged into a single low-level PDU or TCP stream. The RTSP data can be cross with RTP and RTCP packages. Unlike HTTP, RTSP information must contain a content length head, regardless of when the information contains the load. Otherwise, the RTSP package ends with the empty line, followed by the last information head.
2.2 Real Time Transport Protocol RTP
2.1.1 Real Time Transport Protocol RTP
2.1.1.1RTP protocol:
The RTP (Real-Time Transport Protocol) protocol was originally used in the 1970s to deliver the sound file, divide the package into several parts to transfer voice, time flags, and queue numbers. After a series of developments, RTP was released in August 1991 by a laboratory in the United States. By the 1996, a standard version was formed in 1996. Many famous companies, such as Netscape, claim "Netscape LiveMedia" is based on the RTP protocol. Microsoft also claims that their "netmeeting" also supports the RTP protocol. RTP is defined as a transport protocol that transmits real-time data such as audio, video, simulation data. The initial design is for multicast of data transmission, but it is also used for unicast. Compared to the traditional highly reliable transportation layer protocol, it focuses more focuses on the real-time data transmission. The services provided by this protocol include time load identification, data sequence, timestamp, transmission control, and the like. The RTP is part of the relevant control information for data transfer with the auxiliary control protocol RTCP.
2.1.1.2 How does the RTP protocol work:
In the previous description, a sharp problem threatened multimedia data transmission is that it is unpredictable data arrival time. However, the transmission of streaming is the timely arrival of data to play and play back. The RTP protocol is to provide time labels, serial numbers, and other structures for controlling the delivery of timely data.
"Time Label" is the most important information in the concept of stream. The sender is set up in the data packet in the data package in accordance with the instant sample. After receiving the packet after the receiving end, the time tag is restored to the original time-time data according to the correct rate. Different media format Tune attributes are different. However, the RTP itself is not responsible for synchronization, and RTP is only a transport layer protocol, in order to simplify transportation layer processing, improve the efficiency of the layer. Move some transport layer protocol function (such as flow control) to the application layer. Synchronization is done by the application layer protocol. It does not have the full function of the transportation layer protocol, does not provide any mechanism to ensure that the data is transmitted, and the resource reservation is not supported, and the quality of service is not guaranteed. RTP packets do not even include descriptions of length and packet boundaries. At the same time, the data packets of the RTP protocol and the use of the use of adjacent ports, which greatly improves the flexibility and processing of the protocol.
The RTP protocol and the UDP completed the transportation layer protocol function. The UDP protocol is just transmitting the packet, which is regardless of the time order of the packet transmission. The RTP protocol data unit is carried by UDP grouping. When carrying the RTP packet, sometimes one frame data is split into several packages having the same time tag, then the time tag is not necessary. UDP multiplexing allows RTP protocols to support explicit multi-point delivery, which can meet the needs of multimedia sessions.
Although the RTP protocol is a transport layer protocol but it is not implemented as a separate layer in the OSI architecture. The RTP protocol typically provides services based on a specific application, and RTP only provides protocol frameworks, and developers can fully expand protocols based on the specific requirements of the application. At present, RTP design and research is mainly used to meet multimedia conferences of multi-user, and it also applies to storage, interactive distribution simulation and some control, measurement applications. RTP-based experiments and commercial products are also endless.
2.3 Real Time Transmission Control Protocol RTCP Protocol
2.3.1. RTCP protocol:
RTCP (Real-Time Transpond, Control Protocol) is a service control protocol for traffic control and congestion control together with RTP.
2.3.2. How to work in the RTCP protocol:
Two ports will be used when the application starts an RTP session: one to the RTP, one to the RTCP. The RTP itself does not provide a reliable transmission mechanism to deliver a packet in order, nor does traffic control or congestion control, which rely on RTCP. Some RTCP packages on the cycle of RTP's session are sent to configure functions such as listening to service quality and exchange session user information. The RTCP package contains statistics such as the number of packets that have been sent, the number of lost packets, and other statistics. Therefore, the server can utilize this information to dynamically change the transmission rate, and even change the payload type. RTP and RTCP use, which can optimize the transmission efficiency with effective feedback and minimal overhead, thus particularly suitable for real-time data on the network. Depending on the data transmission feedback information between the user, the policy of flow control, and the interaction of the session user information, the policy of session control can be established. The RTCP protocol processor defines five types of packets as needed -
RR: Receiver Report
SR: Sender Report
Sord Description Items.
INDICATES End of participation.
App: Application Specific Functions
They complete the function of receiving, analyzing, generating and transmitting control packets.
2.4 Resource Reserved Agreement RSVP
Since the audio and video data flow are more sensitive to the network's delay, high quality audio, video information, in addition to bandwidth requirements in the network, and other more conditions are required. RSVP (ResourceRereveProtocol) is a resource booking protocol on the Internet, using RSVP to reserve a part of the network resources (ie, bandwidth), to provide QoS for streaming. RSVP is integrated in some experimental systems such as the network video conferencing tool Vic.
2.4.1 Background Resource Reservation Protocol (RSVP) is a network control protocol that allows the Internet to transmit data streams (Qoss), and RSVP is a non-routing protocol; it works with the routing protocol to calculate Routing equivalent dynamic access list, RSVP is the transport layer in the OSI Seventh Tile Stack, which is beginning to construct the researchers, and IETF is working in the standardization direction, and Figure 3.4 illustrates the RSVP operating environment.
Figure 3.4 Host information in RSVP Sends to the recipient through the data stream. 2.4.2 RSVP data stream In RSVP, the data stream is a series of information, with the same source, the purpose (multiple) and service quality, QoS requirements pass The network communicates in the form of flow. The flow description is the data structure used by the interconnection network to request a special service to ensure that the interconnect processing host transmission. RSVP supports three transmission types: Best-Effort, rate-sensitive and delay-sensitive. Data stream service used to support these transport types relies on QoS implementation, the following sections state the transmission type and related services. Preferably, performance is transmitted for traditional IP transmission. Applications include file transfer (such as mail transmission), disk image, interactive login, and transaction transmission. Services that support the best performance transfer are called the best performance service. Rate sensitive transmission gives up timely sex, and ensures rate. For example: rate sensitive transmission request 100 kbps bandwidth, such as 200 Kbps actually transmits 200 Kbps during the extended period, and the router may delay the transmission. Rate sensitive transmission purposes are not transmitted through circuit switched networks, but it is usually associated with the circuit switched network (ISDN) application, and is now running on the Data News Network (IP). Such applications such as H.323 video conferencing, design running on ISDN (H.320) or ATM (H.310), but found on the Internet. H.323 encoding is a constant rate or a regular number of times, which requires a constant transmission rate. RSVP service supports rate sensitive transmission, called bit rate guarantee services. Delay-sensitive transmission requires timely transmission, and thus changes its rate. For example, the MPEG-II video varies according to an image to 3 to 7 Mbps, 3 Mbps may correspond to a wall, while 7 Mbps may be the waves of the ocean. MPEG-II video source sends critical and incremental frames. Typical, one or two keyframes per second, describe the entire image, and describe changes between key frames per second 13 or 28 frames, and incremental frames are typically smaller than critical frames. Therefore, the rate at the frame and the frame change is large. However, since a single frame requires that the decoder speed is not allowed, the decoder speed must be coordinated. RSVP services support delay sensitive transmission, which is considered to control delay service (non-real-time service) and forecast service (real-time service). 2.4.3 RSVP data stream processing RSVP data stream Basic features are connected, and the packet is circulated. The connection is the data stream having the same unicast or multicast destination, and the RSVP handles each connection, respectively. RSVP supports unicast and multicast connections (here the connection is some sessions of the sender and other recipients), while the flow is always starting from the sender. A specific connection packet is directed to the same IP destination address or the disclosed destination port. The IP destination address may be a group address sent by the multicast, or may be a unicast address of a single recipient. The public destination port can be defined by the UDP / TCP destination port segment, and the other transfer protocol is or some application specific information definitions. The RSVP data release is implemented by multicast or unicast. Multicast Transport forwards each packet copy of a sender to multiple purposes. Unicast transmission features are only one recipient. Even if the destination address is unicast, there may be multiple recipients to distinguish between public ports. Multiple senders may also have unicast addresses, in which case RSVP can establish multi-to-one resource subscription. Each RSVP sender and the recipient correspond to a unique Internet host. However, a single host can include a plurality of senders and recipients to distinguish between public ports.
RSVP Service Quality (QoS): In RSVP, service quality (QoS) is the attribute specified by the stream specification, and the stream specification is used to determine how to participate in the entity (router, recipient, and sender). The host and router use RSVP to specify QoS; where the host represents the application data stream Using RSVP from the network application QoS level, the router uses RSVP to send QoS request to other routers for data flow paths. In doing so, RSVP can maintain the router and host status to provide the requested service. RSVP connection start: In order to initialize the RSVP multicast connection, the recipient first uses the Internet Group Member Protocol (IGMP) to add the multicast group specified by the IP destination address. For unicast connections, unicast routing is similar to the IGMP combined protocol independent multicast (PIM) in multicast. After the recipient adds to the group, the potential sender begins to send the RSVP path information to the IP destination address. The recipient application receives the path information and starts to send the corresponding resource subscription request information, and use RSVP to specify the stream description of the on-demand. When the sender application receives the resource subscription request information, the sender starts sending a packet. 2.4.4 RSVP Resource Booking Type Resource Booking Type Note A set of control options for specifying the supported parameters. RSVP supports two major resources reservations: exclusive resource reservations and shared resources reservations. Exclusive resource reservations are installed for each relevant sender in each connection; and the shared resource subscription is used by the sender who is not related to each other. Table 3.10 illustrates the application range of these two resource reservation protocols and the combination of supported ranges and types. 2.4.5 RSVP Soft Status Implementation to RSVP, soft status refers to the status of routers and terminal nodes that can be updated by certain RSVP information. Soft status feature allows RSVP networks to support dynamic group members change and adapt to route changes. Generally, the soft state is maintained based on RSVP network, so that the network can change the status without querying the terminal node. The comparison circuit switched structure, the terminal node performs calls, such as failure, and performs a new call. The RSVP protocol provides a general feature for creating and maintaining multicast and unicast mixing path of distributed resource subscription status. To maintain the resource reservation state, the RSVP tracks the soft status of the router and host node. The path is created and periodically updated the RSVP soft status with the resource subscription request information. If the corresponding update information is not received before the clearing time interval is expired, the state is deleted, and the explicit TEARDOWN information can also be deleted. The Soft status of the RSVP cycle scans established, and forwards the path to the next hop with the subscription request update information. When the route changes, the next path information initializes the path status of the new route, and the resource subscription request information is created in the resource subscription state. The number of network segments that are not used now are marked as timeout. (RSVP specification requires new resource reservation through the network two seconds after the topology change). When a state change occurs, the RSVP has no delay to pass the change from one terminal of the RSVP network to another. If the received state is different from the storage state, the storage state is updated. If the result changes the update information you want, the update information is generated and forwarded. 2.4.6 RSVP Operation Model Under RSVP, resources are made up in simple data streams (one-way data stream). Each sender logically is different from the recipient, but any applications can act as the sender and the recipient, and the recipient is responsible for requesting the resource reservation. Figure 3.5 illustrates its basic operating environment, and the next portion will provide a framework for a particular event sequence. Figure 3.5 RSVP operating environment: ordering resources for one-way data flow
2.4.6.1 Basic RSVP Protocol Operation RSVP Resource Reservation Process Initialization begins in the RSVP background service query local routing protocol to get routing. The host sends an IGMP message to add a multicast group, and send the RSVP message booking along the resource along the group path. Each router that can add a resource subscription will pass the received packet to the package classifier and then queue them in the package scheduler. The RSVP package classifier determines the route and QoS classes of each package; the RSVP scheduler transmits allocated resources on the special data link layer medium used by each interface. If the data link layer has its own QoS management capabilities, the package scheduler is responsible for coordinating the data link layer to obtain the QoS requested by RSVP. The scheduler itself allocates passive QoS medium-package transfer capabilities, such as double-hinges; other system resources, such as CPU time and cache. QoS requests generally originate from the recipient host application, and is passed to the local RSVP application, such as the RSVP background service. The RSVP protocol then passes the request of all nodes (roadmaker and host) to the data source. At each node, the RSVP program applies a local decision program called access to allowed control to determine whether to provide the requested QoS. If you enter the allowable control, the RSVP program sets the parameters of the package classification and scheduler to obtain the QoS applied. If you enter the allowable control failure at a sode, the RSVP program returns an error indication to the application that produces this request. 2.4.6.2 RSVP Tunnel Configuring RSVP on the entire Internet or any other protocol is impossible. In fact, RSVP will never be configured every place. Therefore, RSVP must provide the correct protocol operation, even if only two routers that support RSVP are connected to a router that does not support RSVP. A medium-sized network that does not support RSVP cannot perform resource reservations, so the service guarantee cannot be implemented. However, if the network has sufficient extra capacity, it can also provide acceptable real-time services. To support RSVP network connections, RSVP supports tunnel technology by non-supporting RSVP. Tunnel technology requires RSVP and non-RSVP routers to forward path information of the destination address with local routing tables. When the path information passes the non-RSVP network, the path information is copied with the last IP address of the last support RSVP. The subscription request information Forward to the next upstream support RSVP router 2.4.7 Weighted average queuing scheme technology to strengthen effective resource reservations in the bottleneck (such as Cisco's weighted average queuing scheme) has a positive impact. Tunnel technology is only risky only in non-RSVP domains and inevitable in the bottleneck. Figure 3.6 Indicates the RSVP environment based on tunnel technology between RSVP networks
Figure 3.6: RSVP Environment for Applying Tunnel Technology 2.4.8 RSVP Message RSVP supports four basic message types: Resource subscription request messages, path messages, errors, and confirmation messages and disconnect messages. 2.4.9 RSVP Packet Format Table 3.11 illustrates the RSVP package format, listed in the format head and object segment as follows. Table 3.11 RSVP package format RSVP message head segment (length unit: Bit) 4 4 8 16 8 8 32 15 1 16 Version flag Type Check and length booking Send TTL message ID Booking MF offset RSVP object segment (length unit: Bit) 16 8 8 Variable Length Classification number C Type Object Content RSVP Message Heap RSVP Message Headers Composition: Version Number - 4 Bit, Represents Protocol Version Number (The current version 1). Flag - 4 digits, currently did not define flags. Type --- 8, there are several possible values, as shown in Table 3.12. Table 3.12: RSVP Message Type Segment Value Value Message Type 1 Path 2 Resource Release Request 3 Route Error 4 Resource Reservation Request Errors 5 Pread Disconnect 6 Resource Booking Dive 7 Resource Booking Request Confirmation Checksum --- 16, Express Standard TCP / UDP checksum based on the content of the RSVP message. Length - 16-bit, representation of the byte length of the RSVP package, including common heads and subsequent variable length objects. If the MF flag is set, or the fragment is offset to a non-zero value, this is the length of the larger message. Send TTL --- 8 bits, indicating the IP survival period sent by the message. Message ID --- 32 bits, provide all fragments shared tags in the next RSVP jump / front RSVP hop message. More fragment (MF) logo --- One byte minimum, other 7-bit subscriptions, MF will be set outside the last segment of the message. Fragment offset --- 24 bits, indicating the byte offset of the clip in the message. The RSVP object segment RSVP object segment is composed of: length --- 16-bit, containing the length of the total object, by byte count (must be a multiple of 4, at least 4). Category --- Represents an object type, each object type has a name. The RSVP program must identify classification, and the type is listed in Table 3.13. If there is no identification of the object classification number, the classification number is determined to determine what action uses. C-type --- C type, unique in the sort number. The maximum length is 65528 bytes. Classification numbers and C-type segments (together with the flag) can be used as 16-digits that define a unique bit of each object. Object content --- Length, class model, and Class C specify the form of object content. 2.4.10 RSVP small junction RSVP runs in the transport layer, on the upper layer of IP. Compared to ICMP and IGMP, it is a control protocol. The component of RSVP has a sender, a recipient, and a host or a router. The sender is responsible for letting the recipient know the data will be sent, and what kind of QoS is needed; the recipient is responsible for sending a notification to the host or router so that they can prepare the upcoming data; host or router is responsible for leaving all suitable resources . The two important concepts of the RSVP protocol are streaming and reservation. The stream is the connection feature from the sender to one or more recipients, and is authenticated through the "flow tag" in the IP package. Before sending a flow, the sender transmits a path information to the destination receiver, including the source IP address, destination IP address, and a stream specification. This stream specification is composed of flow rates and delays, which is required for the QoS of the stream. The recipient can achieve a distributed solution after the recipient is scheduled. The development of the RSVP field is very rapid, but there is currently no confirmation in any network, and its application is only limited to the small Intranet network tested.
Because RSVP's reservation must be based on full flow mode, its scalability issues are concerned. RSVP has problems such as how the network should notify the user and how the user responds to such a notification when a service request is applied for control. SMIL language
3.1.smil language profile
3.1.1 Overview
Since SMIL is developed, you have been a praise in the industry. But for this technology born to support Web multimedia technology, how much vitality is there after the support of the client browser, it is really a question mark.
SMIL is W3C. The W3C also hopes that a series of specifications it develop can be complied with. Microsoft and Netscape also swear each time they will be a good child and will follow W3C. They swear to have a web platform that adopts general standards, and browsers will comply with these standards.
But in fact, it is not only a unified standard, but the construction of the Web has become more complicated. The new version of the browser continues to introduce some special technologies, and these technologies seem to be used to split the market. Web creators are now spending about 25% of the time to handle browser compatibility issues, and with the 5.0 browser's launch, this 100 points will rise.
Feeling terror is that Web creators are struggling with Web Standards Project and other advocacy organizations, but victory is still very embarrassing. All Microsoft and Netscape have a full reason to continue to differentiate their browsers, but there are very few interest to care about the voices of poor web creators.
The two browser makers have never expressed support for SMIL (SYNCHRONIZED MULTIMEDIA Integration Language). Microsoft goes farther, proposes HTML Time (Timed Interactive MultiMedia Extensions for HTML) and denied that it will compete with the SMIL that has been approved. The intention is obvious.
SMIL's most powerful support comes from RealNetworks. It believes that SMIL has fundamentally enhances the Web architecture, which is a product that is widely supported and collaboration in the industry, and SMIL can be used with existing technologies (including DHTML). RealNetworks believes that Microsoft will eventually adopt time synchronization features in SMIL.
Currently, RealNetworks accounts for about 85% of the market share of the web streaming media page and has 24 million registered users. Its G2 system Beta released on July 13 is completely SMIL, which is the first commercial streaming media player that supports SMIL.
Now, have such an idea full of your mind? A normative work draft, all mainstream browsers do not support. Yes, in fact, this is the case.
Whether the final standard will be widely used, or even if it can develop into a specification that can be published, it is a guess. And SMIL draft directly competing technology, such as ShockWave, RealFlash and Active Movie Control's market may be larger than smil media objects.
Netscape and Microsoft seem to maintain SMIL a wait-and-see attitude, and each party is waiting for the other party before the announcement. But there is a little hope that W3C is widely respected in the Internet society. It supports multimedia norms hopes to make netizens and Microsoft make some stunned and unhappy and unhamined attempts.
This opening is just wanting to learn SMIL's friends not too nervous, because SMIL is really not as important as you think. The future problem is still unclear.
3.1.2 SMIL history
I have always hoped that WWW in multimedia applications can only be tired in the face of HTML, and the bandwidth limit and synchronization problems they have always hoped to make a Web structure standard can solve these problems. For clarity, in the order of time, I lists a SMIL major evolution.
1. The 1998 World Wide Web Alliance (W3C) officially recommended Synchronized multimedia integration language .2. On August 3, 1999, W3C launched a Smilboston version on the basis of the first draft. Smilboston has a SMILBoston version. Many important extensions, including reusable modules, universal animation design, improved interaction function, and TV integrated features.
3. 2000 On August 9th, US Local Time, W3C Recommendation (W3C Synchronized MultiMedia (SYM) ", published XML-based Internet multimedia Demo Language" SYNCHRONIZED MULTIMEDIA Integration Language " 2.0 ". SMIL is a description language that enables multimedia information such as audio, video, and text. It is also the latest version today.
Members participating in SYMM include Glocomm, US IBM, USA Intel, USA Macromedia, Microsoft, Netscape / United States Online, Finland Nokia, Oratrix, Matsushita Electric Industry, Dutch Philips, USA RealNetworks, WGBH and other companies; also includes CWI (CentreforMathematicsandComputerScience / Netherlands), INRIA (InstitutNationalDeRecherceenInformatiqueetenAutomatique / France), NIST (NationalInstituteofStandardsandTechnology / USA) and other research and government agencies.
3.2 Details
3.2.1 Multimedia Mark
Although playing video products online is possible, it is not feasible. Uncompressed video needs to play almost 4 megabits per second. This transmission rate is difficult to achieve on the local area network. People are trying to achieve effective video compression in future chips, but when it is implemented, the video is just a very waste of media. Whether using fast montage or other methods, the transferred file is still quite large.
In order to make the video be feasible online, we need to achieve smart content. Video editors such as EDL (Edit Decision List) and SMPTE (Society of Motion Picture and Television Engineers believe that the time coding standard for granted is difficult to switch to the web. SMPTE Time Coding is the standard of video time slice, divides the video signal into hours, points, seconds and disinson (30 in the video, 24 in the movie).
Once SMPTE becomes a standard, it is possible to describe a video based on the time slice. For example, the first editing occurs at 20 seconds and 22 persons for 2 seconds and 4, then switching to 1 second and 15 persons, and so on. Soon, many editors provide EDL that can remember a given tablet, you can store EDL as a computer file having only a few KB. In this way, if the main volume is lost or destroyed, or adding a new film, it can be quickly rebuilt with EDL.
This is the basic principle of SMIL.
Until now, the clear definition of the temporary data on the Internet is now not really appeared.
Equisition, there is indeed some technical technology. Most of these, such as Macromedia's ShockWave or RealNetwork's RealMedai, you need plugins, ActiveX controls, even separate applications first downloaded, then use 100% ownership file format. Moreover, the documents generated by these technologies have no meaning to search engines. Web-based multimedia lack standard part is due to today's confusion, but it is also forgiven. The bandwidth is still a problem. It is assumed that most people use 28.8 kbps rates to internet, 1M information takes a few minutes to download. For audio and video, 1M information is nothing. So unless you know that your most viewers have a quick connection, it is meaningless to use web-based multimedia.
It seems that we can see some bandwidth dramatic growth within 18 months, or developing technologies such as XDSL and cable Modem exceeding the test phase. The most important fact is that the general conservative W3C has released a draft working on tag language that tries to handle multimedia: SMIL.
3.2.2 Enter SMIL
SMIL, synchronous multimedia Integration Language, the first letters of Synchronized MultiMedia Integration Language, align it to the audio and video world. If the draft of the current work can become a final standard guide, then we may have to do a lot of SMIL work.
The first thing to know is that SMIL is a subset of XML. XML is essentially about Meta-Data, allowing the new HTML mode tag to describe the web content.
The most obvious (and most common) XML example is
or
The creation of the marker.
Many web pages have clear author and byline, but now they are expressed by no difference HTML. The obvious marker for this type of information is valuable to the search engine, so you can distinguish between the author of the article. XML Use Document Type Definition (DTD) to describe how XML's specific subset is organized. In XML, it is generally extended by adding new entity definitions (however, in SMIL, this is not recommended). Because SMIL is one of the first drafts based on XML, it is best to wait XML to become a reality.
3.2.3 Basic knowledge
The advantage of SMIL is that its structure is very like HTML, so it is not difficult to master its basics. In fact, the most basic SMIL document looks substantially the same as the basic HTML document:
use
The tag is replaced by replacement, you get a SMIL document. Another benefit of SMIL is that its core function is based on both markers:
with
. If you know the two markers, you can write the SMIL expression. When you know
Is the abbreviation of "parallel",
When it is the abbreviation of "sequence", their functions are obvious. So you can
Place where you want to start playing media,
Place a place where a sequence entry is played. These two markers can be nested, so several parallel other media objects can be started in the subsequence, or several objects can be played in parallel in a sequence. The SMIL media type representation is slightly different from HTML. The image representation is almost the same, but because all XML tags do not require a second end tag, it is necessary to set a backslash in the end. therefore:
become
Note that we did not explicitly specify that we were calling a GIF image. SMIL has handled this situation independently, extracts information from the server, operating system, or "Type" attribute in SMIL. This is not as complex when starting: SMIL knows that we handle images in the tag, so it is not necessary to directly indicate that the GIF image. Of course, since it is a multimedia tag language, it contains a media type of not only images. Effective media types include audio, animation, A (Anchor tag), REF (common media type indication, when you cannot determine the media type), IMG, text, text, video, of course, there is a PAR and SEQ tag . 3.2.4 Structure
Many people in you may have bulld the teeth and hoped to stop using the table and control spacing a day - use the style sheet to control the layout and performance of the elements on the page.
SMIL's good news is to allow you to accurately control the elements immediately. The bad news is that it does not only make things easy and use the style sheet as its default layout protocol. It does not adopt package
Marker
with
Mark. However, basic SMIL layout elements are very similar to CSS, and CSS itself also supports, so determine that "Text / CSS" will allow the page to lay out with a style sheet. These two ways can be effectively locate elements on the page:
with
#smile {TOP: 200; Left: 100; Z-Index: 5; Width: 100; Height: 220}
I don't know why W3C does not choose CSS directly, but I am sure they have their own reasons.
3.2.5 Conditional content without script
In the past, the conditionalized content established in the HTML file generally involves a certain server-side solution, such as XSSI or ASP, or some useful a wide range of client scripts. SMIL use
The marker implements such a function.
It is a good feature in the SMIL specification because it can provide multiple repetitions of repetition or customer / end users with a full-order page that is more special than the SMIL specification itself.
Can be simply
The tag is surrounded around a bunch of content, then SMIL checks the properties of each media object, see which one is most consistent with the customer's setting, then select the most suitable. In fact, it chooses the first one to work, so the order of the media object is important.
As an example, assume that you have established a video performance and you have a different version of the performance of various connection velocities. use
You can guarantee the user to get the right file:
#smile {TOP: 200; Left: 100; Z-Index: 5; Width: 100; Height: 220}
Video_high "system-bitrate =" 33000 "/>
Video_good "system-bitrate =" 22000 "/>
Video_slow "system-bitrate =" 12000 "/>
Video_crap "system-bitrate =" 8000 "/>
3.2.6 Property
Now, suppose you have basic knowledge of SMIL, but build a real powerful SMIL document that requires all available SMIL tags. Unfortunately, this article cannot involve too much. I have said before, SMIL is now just a draft of work, but it is not worth speaking to learn all SMIL properties.
Then let's take a look at some of the most common SMIL properties:
Abstract - Provides additional information, or an overview of the content.
Author - Content of the contents of the content.
Begin - Decides that the media object appears in its parent package container.
Copyright - copyright information.
DUR - Duration of Media Objects.
End - The end of the media object.
ID - The name of the object.
Repeat - The number of media objects is repeated.
System-bitrate - connection speed. System - CAPTIONS - Whether to use the text-based equivalent of the track.
System-language - the language of the performance.
System-overdub-or-caption - Using subtitles or duplicates.
System-Required - the name of the extension.
System-screen-size - Specific screen size.
System-Screen-Depth - The depth of the pixel performance.
3.3 SMIL foreground prospects
Now, I will give such an idea full of your mind: a normative work draft, all mainstream browsers do not support.
SMIL is an attempt to implement multimedia content online, but whether the final specification will be widely used, or even if it can develop into a specification that can be published, it is a speculation. And SMIL draft direct competition technology, such as ShockWave, RealFlash, and Active Movie Control's market may be larger than the SMIL media object type.
In fact, the true threat to SMIL comes from dynamic HTML. Browser manufacturers have tried to enable dynamic HTML to accommodate multimedia content, they may regard SMIL as unnecessary and confusing options. On the other hand, W3C has been widely respected in the Internet society. She supports multimedia norms to make netizens and Microsoft make some stunned and unhappy attempts - handling multimedia for common goals. Time.
Netscape and Microsoft seem to maintain SMIL a wait-and-see attitude, and each party is waiting for the other party before the announcement. At least one year, SMIL can be considered to be integrated into the browser, depending on whether the W3C is formally blessing to this draft (also cheap, high-speed connection can become a reality). In short, SMIL is still nice. It is not strong enough, but it is hoped. I would rather CSS becomes a smil default layout protocol unless its manuscript uses a better reason to use SMIL layout. I also expect to see different playback speeds and the ability to set the start and end points in a given media object. With my understanding, drafts do not support such functions. Therefore, we now have to wait and expect this unsupported specification that can realize our favorite version.
