MXPA04006449A

MXPA04006449A - Rtp payload format.

Info

Publication number: MXPA04006449A
Application number: MXPA04006449A
Authority: MX
Inventors: E Klements Anders
Original assignee: Microsoft Corp
Priority date: 2003-07-03
Filing date: 2004-06-30
Publication date: 2005-03-31
Also published as: US7483532B2; TW200503485A; US20050002525A1; KR101022894B1; AU2004202538A1; CO5600215A1; TWI347106B; MY146788A; KR20050004128A; NZ543135A; IL162304A; CN1578311A; CA2469830C; SG129298A1; EP1494425A1; MY144841A; BRPI0402436A; CA2786809C; IL199658A; ZA200404701B

Abstract

A data stream is encrypted to form encryption units that are packetized into RTP packets. Each RTP packet includes an RTP packet header, one or more payloads of a common data stream, and a RTP payload format header for each payload and including, for the corresponding encryption units, a boundary for the payload. The payload can be one or more of the encryption units or a fragment of one of the encryption units. The encryption units are reassembled the using the payloads in the RTP packets and the respective boundary in the respective RTP payload format header. The reassembled of encryption units are decrypted for rendering. Each RTP payload format header can have attributes for the corresponding payload that can be used to render the payload. The RTP packets can be sent server-to-client or peer-to-peer.

Description

LOAD FORMAT OF TRANSPORT PROTOCOL IN REAL TIME (RTP) Field of the Invention The present invention relates to Real Time Transport Protocol (RTP) and more particularly to an RTP cable format for transmitting media (eg, audio-video) in a network, such as the Internet. Background of the Invention The following discussion assumes that the elector is familiar with the 1889 IETF RFC-RTP standard: A transport protocol for real-time applications and with the 1890 IETF RFC standard - RTP Profile for audio and video conferencing with a control minimum. The real-time transport protocol (RTP), as defined in the 1889 RFC standard, provides end-to-end network transport functions suitable for applications that transmit data in real time, such as audio, video or simulation data. multicast or unicast network services. These transport functions provide end-to-end delivery services for data with real-time features, such as interactive audio and video. Such services include identification of the type of cargo, sequence numbering, printing of the date and time and monitoring of the delivery. RTP supports data transfer to multiple destinations with the use of multicast distribution if provided by the underlying network.

Rule 1889 RFC does not provide any mechanism to ensure timely delivery or provide other guarantees of quality of service, but depends on lower layer services to do so. It does not guarantee delivery or prevent delivery in clutter, nor does it assume that the underlying network is reliable and deliver packets in sequence. The sequence numbers included in RTP allow the receiver to rebuild the transmitter's packet sequence, but sequence numbers could also be used to determine the appropriate location of a packet, for example, in video decoding, without necessarily decoding packets in sequence. A typical RTP application involves transmitting data, where audiovisual data (AV) packets in Advanced Systems Format (ASF) are sent in RTP packets over a network from a server to a client or as peers. ASF audio and video data can be stored together in an ASF package. As such, an RTP packet can contain both audio data and video data. RTP, as defined in the 1889 RFC standard, lacks the flexibility to group multiple loads together into a single RTP packet and divide a load into multiple RTP packets. Nor does the 1889 RFC standard define a format in which metadata can be delivered with each load in an RTP packet. Another shortcoming of the 1889 RFC standard is the lack of a mechanism to transmit encrypted blocks of data over an entire network while maintaining a block limit of each encrypted block so that the receiver can decipher the encrypted blocks of data. It would be an advance in the art to provide such flexibility as an improvement to the RTP transmission. Accordingly, there is a need for improved methods, computer readable media, data structures, apparatus and computing devices that can provide such flexibility. Summary of the Invention In an implementation, audiovisual data (AV) packages in Advanced Systems Format (ASF) are placed back into Real-Time Transport Protocol (RTP) packets and sent over a network from one server to the client or by peer-to-peer network communications in response to a request to transmit the AV data. The AV data is encrypted to form encryption units. The repositioning process includes packetting the encryption units in the RTP packets, each of which includes an RTP packet header, one or more loads of a common data stream, and a load format header (PF) RTP for each load. The PF RTP header includes, for the corresponding encryption units, a limit for the load. The load in the RTP packet can be one or more encryption units or a fragment of an encryption unit. After the RTP packets are sent over a network, the encryption units contained in the received RTP packets are reassembled.

The reassembly process uses the loads in the RTP packets and the respective limit in the respective PTP RTP header. Reassembled encryption units can be decrypted for presentation. Each PF RTP header can have attributes for its corresponding load that can be used to present the load. In a variation of the previous implementation, data in a different ASF format is used to form the RTP packets. In another variation of the previous implementation, the RTP packets are formed to contain loads that are not encrypted. In another implementation, a cable format is provided to transmit encrypted blocks of protected data with Windows® Digital Rights Management (WM DRM) across a network in RTP packets (for example, to transmit content protected with WM DRM). Each RTP packet contains header data to maintain cipher block boundaries so that each cipher unit can be deciphered by the cipher receiver. When deciphering using the WM DRM protocol, the data per flow can be presented by the receiver. Brief Description of the Drawings Figure 1 is an illustration of an exemplary process, according to one embodiment of the invention, for the transformation of two (2) audiovisual data packets (AV) into Advanced Systems Format (ASF) into four (4) RTP packets, where audio data and video data are placed in separate packets in the resulting RTP packets and where block boundaries for each load are maintained in such a way that original AV samples that were encrypted and placed in the two ASF packets can be reconstructed by means of a deciphering mechanism. Figure 2 is an illustration of alternative exemplary processes, according to different embodiments of the invention, for the transformation of two (2) ASF video data packets into one (1) RTP packet, where an alternative process moves the loads of the ASF packets in separate loads in the RTP packet, where the other alternative process combines the loads of the ASF packets in a combined load in the RTP packet and where block boundaries for each load are maintained in such a way that an original video sample that was encrypted and placed in the two ASF packets can be reconstructed by means of a decryption mechanism. Figures 3a-3b are diagrams of respective data structures, according to one embodiment of the present invention, for an RTP header and a corresponding loading header. Figure 4 is a block diagram, according to an embodiment of the present invention, of a network client / server system in which the transmission can be performed via server to client or peer to peer. Figure 5 is a block diagram, according to an embodiment of the present invention, which illustrates communications between a server (or client) and a client, where the server (or client) serves the client a stream of audiovisual data requested that the client can present. Figure 6 is a block diagram, according to one embodiment of the present invention, of a networked computer that can be used to implement either a server or a client. Detailed Description of the Invention The implementations described herein define cable formats for delivery of simple and mixed data streams, such as Windows® media data via Real-Time Transport Protocol (RTP). The delivery can be between server and client, as well as in a peer-to-peer context (for example, an environment of Windows® Messenger ™ audiovisual conferencing software). A cable format, in various implementations, improves the 1889 IETF RFC standard to provide greater flexibility for RTP delivery. The implementations provide a mechanism for transmitting audio data in RTP packets that are separated from video data in RTP packets. In addition, implementations provide a cable format in which metadata can be delivered with each load in an RTP package, where the. metadata provide abundant information describing the load. Other implementations provide a mechanism for transmitting encrypted blocks of data over an entire network while maintaining a block limit of each encrypted block so that the receiver thereof can decrypt the encrypted blocks of data. In another implementation, a cable format provides data delivery that is protected with Digital Rights Management of Windows® Media (WM DRM) in such a way that the delivery of the same can be decrypted for presentation. Various implementations described herein repackage data into a series of media packets that are included in a stream of system layer bits. This data is placed in RTP packets that match the 1889 RFC standard, but they improve it, so that the system layer bitstream is correlated with RTP. In this correlation, each media pack contains one or more uploads. In some system layer bitstreams, there may be mixed media packets having data such as audio data, video data, program data, JPEG data, HTML data, MIDI data, etc. A mixed media package is a package of media where two or more of its charges belong to different media streams. Various implementations apply to system layer bit streams where each media pack is a single media packet. In a single media packet, all the loads in the media packet belong to the same media stream. Other implementations apply to system layer bit streams where each media pack always contains only one (1) load. In other implementations, the size of the "load header" in the media pack is zero - which is likely if each media pack contains only a single load, but it could also happen when there are multiple loads where the media packet header It contains information about the size of each load. Figures 1-2 illustrate exemplary implementations in which system layer bitstreams include a series of Advanced Systems Format (ASF) packets, where each has data therein. These data are placed in RTP packets that match the 1889 RFC standard, but they improve it. As such, the system layer bitstreams include a series of media packets that are ASF packets and the load on each ASF packet is an ASF load. Although ASF packages are used for illustration, the creation of RTP packets, in other implementations described herein, is not limited to the use of ASF format data, but may use other formats in which the data that is going to transmit are stored. These other formats, as well as the ASF format, are generally described herein as streams of system layer bits that include a plurality of media packets where each has data therein, where this data is correlated with RTP in several implementations In Figure 1, audiovisual data (AV) is illustrated by ASF 100 stream. AV data by ASF 100 stream, including audio data 102 and video data 104, has been placed in an ASF A 106 package and an ASF B package. 108. The ASF pack A 106 includes a first ASF header, an ASF upload header, audio data 102, a second ASF header and a video data A video data fragment 104. The ASF B 108 package includes a header ASF, an ASF upload header and a video data fragment B of video data 104. The AV data per ASF 100 stream as expressed in the ASF A 106 package and ASF B 108 package, in one implementation, can be place in a plurality of RTP packets. As shown in Figure 1, these include RTP pack A 110, packet RTP 112 (1) to packet RTP 112 (N) and packet RTP D 116. Each packet RTP, according to rule 1889 RFC, has a header of RTP package, a load and a load format header (PF) RTP. As used herein, the PF RTP header in is a load header in the RTP packet. Only one (1) type of media is in the RTP package. In other words, the RTP package does not contain mixed media loads. In the implementation illustrated in Figure 1, the video data A of the ASF A 106 package is too large to fit into a single RTP packet. As such, the video data A of the ASF A 106 packet is divided between the RTP pack 112 (1) to the RTP pack 112 (N). The RTP packet size can be a function of a physical characteristic of an underlying network over which the RTP packets are to be transmitted, or an administrative policy with respect to the packet size can be created by the administrator of the underlying network, or an evaluation of the transmission bandwidth of the underlying network. After placement in RTP packets illustrated in FIG. 1, audio data 102 is included in packet RTP A 110 and video data B of packet ASF B 108 is included in packet RTP D 116. Each header The PTP RTP of each RTP packet may contain information regarding the separation of the audio and video data into respectively separate RTP packets. Accordingly, the sample data per A / V stream 124 can be reconstructed from the audio data in the RTP pack A 110, fragment 1 of video data A to the N fragment of video data A in respective RTP packets 112 (1) to 112 (N) and video data B in RTP packet D 116. Once the reconstruction of sample data per A / V stream 124 is complete, the audio sample data 120 and the sample data of video A + B 122 in them can be presented in a context by flow. Given the above, Figure 1 illustrates a cable format in which smaller RTP packets are created from larger ASF packets, where packet placement places a load of different data streams in separate packets, each with its own own PF RTP header. Also, Figure 1 illustrates an implementation of a cable format in which block boundaries for each load are maintained in such a way that original audio and video samples that were encrypted and placed in ASF packets can be reconstructed by means of a mechanism of decryption that takes place in the RTP packets. Figure 2 shows AV data per ASF 200 stream. AV data per ASF 200 stream, which includes video data 202, has been placed in an ASF A 208 package and an ASF B 210 package. The ASF A package 208 includes an ASF header, an ASF upload header and A 204 video data. The ASF B 210 package includes an ASF header, an ASF upload header and B 206 video data. Figure 2 shows two (2) alternatives for put AV data per ASF 200 flow in RTP packets that match the 1889 RFC standard, but improve it. In the first alternative, following the arrow 250, the video data A 204 and the video data B 206 are placed in packets in a single packet alternative A RTP 212 having an RTP header. Each of the video data A 204 and the video data B 206 is preceded by a PF RTP header. The RTP 212 packet alternative A, in accordance with the 1889 RFC standard, has an RTP header, multiple loads and respective PTP RTP headers. In the second alternative, also following the arrow 250, the video data A 204 and the video data B 206, of respective ASF packets, are placed in packets in an alternative B of packet RTP 214 having an RTP header. The video data A 204 and the video data B 206 are assembled contiguously as the load in alternative B of packet RTP 214. The load is preceded by a PF RTP header. Alternative B of RTP 214 package, according to the 1889 RFC standard, has an RTP header, a load and a PF RTP header. After placement in RTP packages illustrated in figure 2, the video data A and B (204, 206) are included in either alternative A of packet RTP 212 or alternative B of packet RTP 214. Each PF RTP header may contain information regarding the corresponding load. Each of the alternative RTP packets 212, 214 contains sufficient data to reconstruct the ASF pack A 208 and the ASF pack B 210 to obtain video data A and B (204, 206) therein. Once the reconstruction is complete, the video sample data 222 can be presented in one context per stream. Given the above, Figure 2 illustrates an RTP cable format in which larger RTP packets are created from small ASF packets and where block boundaries for each load are maintained in such a way that original video samples that were encrypted and placed in the two ASF packets can be reconstructed by means of a decryption mechanism that is carried out in the RTP packets. Figure 3a illustrates a data structure diagram for fields in an RTP header. The RTP header is described in more detail in the 1889 RFC standard. The date clock field in the RTP header must match the display time of the sample contained in the RTP packet. In one implementation, the clock frequency is 1 kHz unless it is specified that it is different through independent means of RTP. The eighth bit from the beginning of the RTP header is interpreted as a marker bit field (M). The M bit is set to zero, but it will be set to one ("1") as long as the corresponding RTP packet has a load that is not a fragment of a sample, it contains the final fragment of a sample, that is, one of a plurality of complete samples in the RTP package. The M-bit can be used by a receiver to detect the reception of a complete sample for decoding and presentation. Therefore, the bit in the RTP header can be used to mark significant events in a packet stream (for example, video sample frame limits). Figure 3b illustrates an implementation of a load format (PF) RTP header or load header. The PF RTP header has a fixed length portion of sixteen (16) bits followed by a variable length portion. The fields of the PF RTP header illustrated in Figure 3b include a series of 8 bits indicated by the character fields "SGLRTDXZ", a length / offset field, a relative date dial field, a decompression time field, a field of duration and a length field of Load Extension (PE) and a PE data field corresponding, each of which is explained below. Field S has a length of one (1) bit and is set to one ("1") if the corresponding load (eg, sample, fragment of a sample, or combination of samples) is a key sample, ie, intra-coded sample or I-frame. Otherwise it adjusts to zero. The S bit in all PF RTP headers that precede fragments of the same sample must be set to the same value. Field G has a length of one (1) bit and is used to group subsamples into a corresponding load that form a single sample. The Digital Rights Management of Windows® Media (WM DRM) encrypts content based on the "ASF Load" limits. In order to allow this content to be deciphered correctly, the limits of the subsamples in the load can be communicated to the client that is going to receive the load. For example, an encryption unit may be packaged such that it is divided into a plurality of transmission units (eg, placed within separate packages) to be transmitted. Before the split plurality of transmission units can be decrypted in a receiving client, they have to be reassembled in the original encrypted form. As in other decryption methodologies and mechanisms, the client can use the limits to appropriately reconstruct encrypted encryption units in preparation for deciphering the encrypted content. As such, each "ASF Load" must be preceded by this PF RTP header. Field bit G must be set to zero ("0") to indicate that an encrypted "unit" has been fragmented. If ASF is being used, the cipher unit will be an ASF load and the bit is set to zero ("0") on all fragmented ASF loads, except the last ASF load. In this case it does not matter if a sample has been fragmented or not. If ASF is not being used, the encryption unit is a sample of media, in which case the G bit is set to zero ("0") on all samples of fragmented media except the last sample. Regarding the latter case, the problem about whether an ASF load has been fragmented or not is not applicable, since ASF is not used. Field L has a length of one (1) bit and is set to one ("1") if the length / offset field contains a length. Otherwise it is set to zero ("0") and the length / displacement field4 contains a displacement. The L bit must be set to one ("1") in all the PTP RTP headers that precede a complete (non-fragmented) sample in the corresponding load and must be set to zero in all the PTP RTP headers that precede a load of a fragmented sample. Field R has a length of one (1) bit and is set to one ("1") if the PF RTP header contains a relative clock. Otherwise it adjusts to zero. The R bit in all headers that precede fragments of the same sample must be set to the same value. The field T has a length of one (1) bit and fits one ("1") if the PF RTP header contains a decompression time. Otherwise it adjusts to zero. The T-bit in all PF RTP headers that precede a load that contains a fragment of the same sample must be set to the same value. Field D has a length of one (1) bit and fits one ("1") if the PF RTP header contains a sample duration. Otherwise it adjusts to zero. The D bit in all the PF RTP headers that precede a load containing fragments of the same sample must be set to the same value. Field X has a length of one (1) bit and is for optional or unspecified use. A transmitter of an RTP packet must set this bit to zero and a receiver thereof can ignore this bit. The Z field has a length of one (1) bit and is set to one ("1") if the PF RTP header contains Load Extension data (P.E.), which may be metadata referring to the corresponding load. Otherwise, the Z field is set to zero. The field bit Z could be zero for all PF RTP headers whose M bit is zero, but must be set for all PF RTP headers in which M bit is set to one ("1") if the corresponding load has data of PE associated with it. The length / displacement field has a length of twenty-four (24) bits and quantifies the length or displacement of a single sample that has been fragmented over multiple RTP packets. The L bit is set to zero and the length / offset field contains the byte offset of the first byte of this fragment from the beginning of the corresponding load (eg sample or fragment thereof). If one or more complete samples are contained in the RTP packet, the L bit is set to one ("1") in each PF RTP header and the sample length / offset field contains the length of the sample (including the PF header) RTP). The relative datum clock field has a length of thirty-two (32) bits and is present only if the R bit is set to one ("1"). It contains the relative date clock for the corresponding sample with respect to the time stamp in the corresponding RTP header. The time scale used is the same as that used for the time stamp in the RTP header. The relative time stamp field is specified as a signed 32-bit number to consider negative offsets of the RTP header's time stamp. When the relative date dial field is absent, a relative zero-zero date dial can be used. The decompression time has a length of thirty-two (32) bits and is present only if the T-bit is set to one ("1"). It contains the decompression time in relation to the time stamp in the RTP header. The time scale used is the same as that used for the time stamp in the RTP header. This field is specified as a signed 32-bit number to consider negative shifts of the time stamp in the RTP header. The duration field has a length of thirty-two (32) bits and is present only if bit D is set to one ("1"). It contains the duration of the corresponding sample. The time scale used is the same as that used for the time stamp in the RTP header. The duration field, in all PF RTP headers that precede fragments of the same sample, must be set to the same value. When this field is absent, the default duration is obtained implicitly or explicitly from the sample data. If this is not feasible, the omission is the difference between the time stamp of this sample and the time stamp of the next sample. The Load Extension data length field (P.E.) has a length of sixteen (16) bits and is present only if the Z bit is set to one ("1"). Contains the number of data bytes of P.E. contained after the fixed part of the PF RTP header. The data of P.E. they are variables in length and contain one or more attributes that describe the corresponding load that precedes. The data length field of P.E. immediately follows the fixed part of the loading header and will be a number of bytes containing the data of P.E. real. The structure of the data of P.E. is communicated between the client and the server (or as peer), such as via an SDP description. In an implementation for content protected with WM DRM, there may be at least 4 bytes of DUE data representing the load identification WM DRM associated with each sample. Although Figures 3a-3b show various fields in various orders for an RTP header and RTP PF header, not all fields are required and the order thereof can be re-arranged. Therefore, in some implementations, the required fields and order can match, and even extend, the flexibility of the 1889 RFC standard. Therefore, although ASF packets are used for illustration of Figure 3a-3b, the creation of RTP packets, PTP RTP headers and uploads, in other implementations described herein, is not limited to the use of ASF format data, but rather You can use other formats in which the data to be transmitted is stored. General Network Structure Figure 4 shows a client / server network system 400 and environment according to the invention. In general, system 400 includes one or more network media servers (m) 402 and one or more network clients (k) 404. Computers communicate with each other over a data communications network, which in figure 4 includes a wired / wireless network 406. The data communications network 406 could also include the Internet or local area networks and private wide area networks. The servers 402 and clients 404 communicate with each other via any of a wide variety of known protocols, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). Multimedia servers / clients 402/404 have access to media content per stream in the form of different media streams. These media streams can be streams of individual media (eg, audio, video, graphics, simulation, etc.), or alternatively mixed media streams that include multiple of said individual streams. Some media streams could be stored as files 408 in a database (eg, ASF files) or another file storage system, while other media streams 410 could be provided to the 402 server or multimedia client 404 in a form "activates" other data source components through dedicated communication channels or through the Internet itself. The media streams received from the servers 402 or from the clients 404 are presented to the client 404 as a multimedia presentation, which may include media streams from one or more of the servers / clients 402/404. These different media streams can include one or more of the same different types or types of media streams. For example, a multimedia presentation may include two video streams, an audio stream and a stream of graphic images. A user interface (Ul) in the client 404 may allow users various controls, such as allowing a user to already increase or decrease the speed at which the presentation of media is carried out. Exemplary Computer Environment In the discussion that follows, the invention will be described in the general context of computer executable instructions, such as program modules, which are executed by one or more conventional personal computers. In general, the program modules include routines, programs, objects, components, data structures, etc. to perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will understand that the invention can be implemented with other computer system configurations, including portable devices, multiprocessor systems, microprocessor-based or programmable electronic products, network PCs, minicomputers. , main computers and similar. In an environment of distributed computers, program modules can be located in both local and remote memory storage devices. Alternatively, the invention could be implemented in hardware or a combination of permanent hardware, software and / or accessories (firmware). For example, one or more application-specific integrated circuits (ASICs) could be programmed to carry out the invention. As shown in Figure 4, a network system according to the invention includes server (s) and network client 402, 404 from which a plurality of media streams are available. In some cases, the media streams are actually stored by the server (s) and / or client 402, 404. In other cases, the server (s) and / or client (s) 402, 404 can obtain the streams of media from other sources or network devices. In general, network clients 404 respond to user input to request media streams corresponding to selected media content. In response to a request for a media stream corresponding to multimedia content, the server (s) and / or clients 402, 404 transmit the requested media streams to the 404 network client requesting them according to an RTP cable format . The client 404 decrypts the loads in the respective RTP packets and presents the resulting decrypted data streams to produce the requested multimedia content. Figure 5 illustrates the data entry and storage by A / V stream in a server 402 or a client 404 (for example, a similar one). Also, Figure 5 illustrates communications between server and client (402-404) or peer-to-peer (404-404) according to various implementations. By way of overview, the server or client 402, 404 receives data input per A / V stream from an input device 530. The server or client 402, 404 encodes the input by using a codec encoder. The coding can, but does not need, to be carried out in ASF format data. If ASF format data is used, the coding is carried out in ASF packets that each include an ASF header and ASF load header and an AV load (audio and / or video). The encoding may include encryption, such as where WM DRM is used. The ASF packets are stored by the server / client 402, 404 to serve future requests thereof. Subsequently, the client requests the corresponding AV data stream from the server / client. The server / client retrieves and transmits to the client the corresponding AV stream that the server / client had previously stored. Upon receipt, the client decodes the AV data stream and reconstructs and decrypts encrypted divided AV data stream samples with the use of communicated boundaries in the corresponding PTP RTP headers. The client can then perform the presentation of the transmitted AV data. The data flow is seen in Figure 5 between and in between blocks 504-530. In block 504, an input device 502 provides the server / client 402, 404 input that includes data per A / V stream. By way of example, the data per A / V flow could be provided to the server / client 402/404 in an "active" manner by means of the input device 502 through dedicated communication channels or through the Internet. The data per A / V flow is provided to an encoder in block 504 to place the data in ASF packets. In block 506, optional WM DRM encryption is employed and the ASF packets are stored in the server / client 402/404. One result of WM DRM encryption and packet placement may be that an encryption unit is divided into a plurality of separate packets. Before the split plurality of transmission units can be decrypted in a receiving client, they have to be reassembled in the client in the original encryption units. As such, the limits of the split drive units are stored in the ASF load headers in block 506. In block 508, the client 404 makes a request for the A / V data stream that is transmitted to the server / client 402/404 as seen on the date 510 in figure 5. In block 512, the server / client 402/404 receives application. The corresponding ASF packets containing the requested A / V data stream are recovered. In block 514, the audio and video loads in the ASF packets are logically separated so that they can be placed separately in RTP packets. The limits are identified for each logically separated audio and video load. A bandwidth of the network on which the RTP packets are to be transmitted is determined. This determination is used to derive a predetermined RTP packet size. Where the ASF packet size is smaller than the default RTP packet size, similar type loads can be combined into a single RTP packet. Where the ASF packet size is larger than the default RTP packet size, ASF loads can be fragmented to be placed as a load on a single RTP packet. Limits are determined for each RTP load with the use of the logically separate audio and video loads of the ASF packets. In step 516, the RTP header, PF RTP header and respective load are assembled for each RTP packet. As such, a plurality of RTP packets representing a plurality of ASF packets have been formed, where the ASF packets contain the A / V data stream that was requested by the client 404. The RTP packets are transmitted to present the client 404 of the server / client 402/404 via a transmission function in block 518. An arrow 520 in figure 5 shows the transmission of the RTP packets from server / client 402/404 to client 404. In block 522, client 404 receives the RTP packages. In block 524, an RTP decoder in client 404 decodes each received RTP packet, including the RTP header and PTP RTP header. In block 526, a process performs the defragmentation and reconstruction of the ASF packets containing the solved A / V data stream. Defragmentation and reconstruction use the limits stated in the PF RTP header for each corresponding load that contains, for example, a sample or fragment thereof. In lock 528, reconstructed ASF packets are decrypted to present in block 530. The PTP RTP header in an RTP packet may contain Load Extension data (P E.) Describing the corresponding load. As a result, the data of P. E. they can provide metadata that can be used during a presentation of the load in the corresponding RTP packet in block 530. Blocks 522-530 are repeated for each RTP packet that is received in client 404, thus logging the transmission of data. the A / V data of the server / client 402/404 for presentation. Figure 6 shows a general example of a computer 642 that can be used according to the invention. The computer 642 is shown as an example of a computer that can perform the functions of any of the clients 402 or servers 404 of Figures 4-5. The computer 642 includes one or more processors or processing units 644, a system memory 646, and a system bus 648 that couples various system components among which system memory 646 is included to 644 processors. Bus 648 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a local bus or processor using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 650 and random access memory (RAM) 652. A 675 cache has L1, L2 and L3 levels and may be included in RAM 652. A basic input / output system (BIOS) 654, which contains the basic routines that help transfer information between elements within the computer 652, such as during boot, is stored in the ROM 650. The computer 642 further includes a hard disk drive 656 for reading from and writing to a hard disk (not shown), a magnetic disk unit 658 for reading from and writing to a removable magnetic disk 660 and an optical disk unit 662 for reading from and writing to a removable optical disk 664 such as a CD ROM or other optical media. t Any of the hard disk (not shown), magnetic disk unit 658, optical disk unit 662 or removable optical disk 664 can be an information medium having recorded information therein. The information medium has a data area for recording flow data using flow packets, each of which includes a packet area containing one or more data packets. By way of example, each data packet is encoded and decoded by a code of application programs 672 running in the processing unit 644. As such, the encoder distributes the flow data to the data packet areas in the flow packets so that the distributed flow data is recorded in the data packet areas using a coding algorithm. Alternatively, the coding and decoding of data packets can be performed as a function of operating system 670 running in the processing unit 644. The hard disk drive 656, magnetic disk drive 658 and optical disk drive 662 they are connected to the 648 system bus through a SCSI 666 interface or some other appropriate interface. The units and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the 642 computer. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 660 and a removable optical disk 664, those skilled in the art should understand that other types of computer-readable media that can store data that are accessible by a computer, such as magnetic cassettes, non-volatile flash memory cards (memory) 'flash'), digital video discs, random access memories (RAMs), read only memories (ROM) and the like, can also be used in the exemplary operating environment. A number of program modules may be stored on the hard disk, magnetic disk 660, optical disk 664, ROM 650 or RAM 652, including an operating system 670, one or more application programs 672 (which may include the code), other program modules 674 and program data 676. A user may enter commands and information into computer 642 through input devices such as a keypad 678 and signaling device 680. Other input devices (not shown) may include a microphone, joystick, game controls, satellite dish, scanner or similar. These and other input devices are connected to the processing unit 644 through an interface 682 that is coupled to the system bus. A monitor 684 or other type of display device is also connected to the system bus 648 via an interface, such as a video adapter 686. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) as speakers and printers. The computer 642 operates in a networked environment that uses logical connections to one or more remote computers, such as a remote computer 688. The remote computer 688 may be another personal computer, a server, a router, a network PC, a device similar or other common network node and typically includes many or all of the elements described above in relation to computer 642, although only one memory storage device 690 has been illustrated in figure 6. The logical connections illustrated in figure 6 they include a local area network (LAN) 692 and a wide area network (WAN) 694. Such networking environments are common in offices, computer networks throughout the company, intranets and the Internet. In the described embodiment of the invention, the remote computer 688 executes a browser program of pages of the global network ('web') of the Internet such as the navigator of pages of the Internet network Internet Explorer® manufactured and distributed by Microsoft Corporation of Redmond, Washington. When used in a LAN networking environment, computer 642 is connected to local network 692 through a network interface or adapter 696. When used in a WAN network connection environment, computer 642 typically includes a modem 698 or other means for establishing communications over the wide area network 694, such as the Internet. The modem 698, which may be internal or external, is connected to the system bus 648 via a serial port interface 688. In a networked environment, the program modules illustrated in relation to the personal computer 642, or portions of the they can be stored in the remote memory storage device. It will be understood that the network connections shown are exemplary and other means may be used to establish a communication link between the computers. In general, the data processors of the 642 computer are programmed by means of instructions stored at different times in the various computer readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD ROMs. From there, they are installed or loaded into the secondary memory of a computer. In the execution, they are at least partially loaded into the primary electronic memory of the computer. The invention described herein includes these and various other types of computer readable storage media when such means contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. Likewise, the invention includes the computer itself when it is programmed according to the methods and techniques described below. In addition, certain subcomponents of the computer can be programmed to perform the functions and steps described below. The invention includes said subcomponents when they are programmed as described. In addition, the invention described herein includes data structures, which are described below, as modalized in numerous types of memory media. For purposes of illustration, programs and other components of executable programs such as the operating system are illustrated here as discrete blocks, although it is recognized that said programs and components reside in multiple times in different storage components of the computer and are executed by the computer's data processor (s). Conclusion The implementations described herein define a cable format that can be used in the delivery of multimedia data between server and client and peer-to-peer via RTP. The cable format considers greater flexibility than the 1889 IETF RFC standards currently adopted for RTP delivery. The implementations of the cable format provide encrypted data transmission, provide a mechanism to deliver by metadata sample via RTP and provide data transmission that are protected with WM DRM. Although the invention has been described in language specific to structural features and / or methodological actions, it should be understood that the invention defined in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are described as exemplary ways of implementing the claimed invention.

Claims

CLAIMS 1. An apparatus comprising: means for encrypting a data stream with an arbitrary block size to form a plurality of encryption units; and means for placing the plurality of encryption units in a plurality of RTP packets, each including: an RTP packet header; one or more loads of a common data stream and selected from the group consisting of: one or more of the encryption units; a fragment of one of the encryption units; and an RTP load format header for each of the loads and including, for the corresponding encryption units, a limit for the arbitrary block size. The apparatus as described in claim 1, characterized in that it comprises: means for reassembling the plurality of encryption units using: the loads in the plurality of RTP packets; and the respective limit for the arbitrary block size in the respective RTP load format header; means for deciphering the plurality of encryption units to form the data stream. 3. The apparatus as described in claim 2, characterized in that: each of the RTP load format headers further comprises one or more attributes of the corresponding load; and the apparatus further comprises means for displaying the data stream formed using the attributes of the corresponding load. The apparatus as described in claim 2, characterized in that the attributes in each of the RTP load format headers are selected from the group consisting of: synchronization information; and video compression chart information. The apparatus as described in claim 2, characterized in that it further comprises means for transmitting the plurality of RTP packets over a network. 6. An apparatus comprising: means for logically separating types of media data in a data stream including a plurality of media data types; and means for forming a plurality of RTP packets from the data stream, each of the RTP packets includes: only one of the media data types; an RTP packet header; one or more variable length RTP load format headers where each has one or more attributes; and an RTP load corresponding to each of the RTP load format headers and which is described by the attribute (s) therein. The apparatus as described in claim 6, characterized in that it further comprises: means for extracting the charges from the plurality of RTP packets; and means for presenting each load in the plurality of RTP packets using the attribute (s) in the corresponding RTP load format header. The apparatus as described in claim 7, characterized in that: each load comprises video data; and the attributes in each RTP load format header are selected from the group consisting of: synchronization information; and video compression chart information. The apparatus as described in claim 7, characterized in that the means for extracting further comprise, for each RTP load: means, wherein the RTP load includes a plurality of portions of one of the media data types, for assembling the plurality of portions of one of the media data types into a contiguous load; means, wherein the RTP load includes a portion of one of the media data types, to assemble the portion of one of the media data types into a contiguous load; and means, wherein the RTP load includes a fragment or a portion of one of the media data types, to assemble all the fragments of the portion of one of the media data types into a contiguous load. The apparatus as described in claim 9, characterized in that it further comprises: means for assembling, in chronological order corresponding to the plurality of media data types of the media file, the adjacent charges; and means for simultaneously displaying the contiguous logs ordered chronologically from the plurality of media data types of the media file. 11. A data structure having a cable format for transmission over a network, the data structure comprises a plurality of simple media packets formed from a plurality of mixed media packets, characterized in that: each mixed media packet includes: a load for each of a plurality of data streams, wherein the load is encrypted and has an arbitrary block size; and a load header for each load and including a limit for the arbitrary block size; each simple media pack includes a stream of data, corresponds to one of the mixed media packets, and includes: a load corresponding to one of the loads in a mixed media packet; a header of the load profile format that corresponds to: the load; and one or more load headers of the mixed media packet, wherein the load profile format header has a limit corresponding to: the respective limits of the load headers or headers of the mixed media packet; and the load. The data structure as described in claim 11, characterized in that each simple media packet further comprises: a packet header corresponding to one or more packet headers of the plurality of mixed media packets; a composition selected from the group consisting of: a plurality of the loads of the mixed media packets, which is of a similar data stream, each having a corresponding charge profile format header; and a load and header of corresponding load profile format. The data structure as described in claim 11, characterized in that each single media packet is smaller than a predetermined size which is a function selected from the group consisting of: a physical characteristic of an underlying network; an administrative policy regarding package size; and an evaluation of the transmission bandwidth of the underlying network. The data structure as described in claim 11, characterized in that the load limit in the simple media pack identifies the chronological order of the corresponding load in the mixed media packet. 15. The data structure as described in claim 11, characterized in that the data stream is selected from the group consisting of audio data, video data, program data, JPEG data, HTML data and MIDI data. 16. The data structure as described in claim 11, characterized in that: the load profile format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding load. The data structure as described in claim 11, characterized in that: each mixed media packet includes a portion of an ASF data stream, an ASF packet header and at least one ASF load header; and each simple media pack includes, an RTP packet header and an RTP load format header; a portion of an RTP data stream. 18. A method comprising: encrypting a data stream with an arbitrary block size to form a plurality of encryption units; and placing the plurality of encryption units in a plurality of RTP packets in, each includes: an RTP packet header; one or more loads of a common data stream and selected from the group consisting of: one or more of the encryption units; and a fragment of an encryption unit; an RTP load format header for each load and including, for the corresponding encryption units, a limit for the arbitrary block size. 19. The method as described in claim 18 further comprising: reassembling the plurality of encryption units using: the loads in the plurality of RTP packets; and the respective limit for the arbitrary block size in the respective RTP load format header; deciphering the plurality of encryption units to form the data stream. The method as described in claim 19, characterized in that: each RTP load format header further comprises one or more attributes of the corresponding load; and the method further comprises presenting the data stream formed using the attributes of the corresponding load. The method as described in claim 19, characterized in that the attributes in each RTP load format header are selected from the group consisting of: synchronization information; and video compression chart information. The method as described in claim 19, further comprising, before reassembling, the plurality of RTP packets over a network to a client in which the reassembly is carried out. 23. A computer readable medium comprising machine readable instructions which, when executed, carries out the method as described in claim 18. 24. A method comprising forming a plurality of RTP packets from a data stream including a plurality of media data types, each RTP pack includes: only one of the media data types; an RTP packet header; one or more variable length RTP load format headers, each having one or more attributes; and an RTP load that corresponds to each RTP load format header and that is written by the attribute or attributes in it. 25. The method as described in the claim 24, further comprising: extracting the charges from the plurality of RTP packets; and presenting each load in the plurality of RTP packets using the attribute (s) in the corresponding RTP load format header. 26. The method as described in the claim 25, characterized in that the attributes in each RTP load format header are selected from the group consisting of: synchronization information; and video compression chart information. The method as described in claim 25, characterized in that the extraction of the loads from the plurality of RTP packets further comprises, for each RTP load: which includes a plurality of portions of one of the media data types. , assembling the plurality of portions of one of the media data types in an adjoining load; which includes a portion of one of the media data types, assembling the portion of one of the media data types in a contiguous load; and which includes a fragment of a portion of one of the media data types, assembling all the fragments of a portion of one of the media data types in a contiguous load. 28. The method as described in the claim 27, further comprising: assembling, in chronological order corresponding to the plurality of media data types of the media file, contiguous charges; and simultaneously displaying the contiguous logs ordered chronologically from the plurality of media data types of the media file. 29. A computer readable medium comprising machine-readable instructions which, when executed, performs the method as described in claim 25. 30. A method comprising changing a plurality of mixed media packets into one. plurality of simple media packets, characterized in that: each mixed media packet includes: a load for each of a plurality of data streams, wherein the load is encrypted and has an arbitrary block size; a load header for each load and including a limit for the arbitrary block size; each simple media pack includes a stream of data, corresponds to one of the mixed media packets, and includes: a load corresponding to one of the loads in the mixed media packet; a load profile format header that corresponds to: the load; and one or more load headers of the mixed media packet, wherein the header of the load profile format has a limit corresponding to: the respective limits of the load header (s) of a mixed media packet; and the load. The method as described in claim 30, characterized in that each simple media packet further comprises: a packet header corresponding to one or more packet headers of the plurality of mixed media packets; a composition selected from the group consisting of: a plurality of the loads of the mixed media packets, which is of a similar data stream, each having a corresponding charge profile format header; and a load and header of corresponding load profile format. 32. The method as described in claim 30, characterized in that each single media packet is smaller than a predetermined size which is a function selected from the group consisting of: a physical characteristic of an underlying network; an administrative policy regarding package size; and an evaluation of the transmission bandwidth of a network. 33. The method as described in the claim 30, characterized in that the load limit in the simple media pack identifies the chronological order of the corresponding load in the mixed media packet. 34. The method as described in claim 30, characterized in that the data stream is selected from the group consisting of audio data, video data, program data, JPEG data, HTML data and MIDI data. 35. The method as described in claim 30, characterized in that: the load profile format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding load. 36. The method as described in claim 30, characterized in that: each mixed media packet includes a portion of an ASF data stream, an ASF packet header and at least one ASF load header; and each simple media pack includes, an RTP packet header and an RTP load format header; a portion of an RTP data stream. 37. A computer readable medium comprising machine-readable instructions which, when executed, performs the method as described in claim 30. 38. A method comprising changing a plurality of mixed media packets into one. plurality of simple media packets, characterized in that: each mixed media packet includes: a load for each of a plurality of data streams, wherein the load is encrypted and has an arbitrary block size; a packet header; and a loading header for each load and including a limit for the arbitrary block size; each simple media pack corresponds to one of the mixed media packets, and includes: a load corresponding to one of the loads in the mixed media packet; a packet header that corresponds to one of the package headers of the mixed media package; a header of the load profile format that corresponds to: the load; and one or more load cables of the mixed media packet; wherein the header of the load profile format has a load limit corresponding to: the respective ca gage levels of the load header (s) of the mixed media packet; and the load. 39. The method as described in claim 38, characterized in that: each mixed media packet includes a portion of an ASF datastream, an ASF packet packet and at least one ASF load header; and each simple media pack includes, an RTP packet header and an RTP load format header; a portion of an RTP data stream. 40. The method as described in claim 38, characterized in that: the load profile format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding load. 41. A computer readable medium comprising machine readable instructions which, when executed, performs the method as described in claim 38. 42. A method comprising changing a plurality of single media packets into a mixed package, characterized in that: each simple media pack includes: a load of a data stream, wherein the load is encrypted and has an arbitrary block size; a loading header for the load and including a limit for the arbitrary block size; the mixed packet corresponds to the plurality of single media packets and includes: one or more loads of a similar data stream and corresponding to the respective loads of the plurality of single media packets; and a load profile format header for each load in the mixed packet and corresponding to the load headers of the plurality of single media packets, wherein the load profile format header has a load limit for a respective load in the mixed packet identifying an order thereof in the plurality of single media packets. 43. The method as described in claim 42, characterized in that the mixed packet further comprises: a packet header corresponding to packet headers for each of the plurality of single media packets; a composition selected from the group consisting of: a plurality of the charges, each having a corresponding charge profile format header; and a load and header of corresponding load profile format. 44. The method as described in claim 42, characterized in that each single media packet is smaller than a predetermined size which is a function selected from the group consisting of: a physical characteristic of an underlying network; an administrative policy regarding package size; and an evaluation of the transmission bandwidth of the underlying network. 45. The method as described in claim 42, characterized in that the data stream is selected from the group consisting of audio data, video data, program data, JPEG data, HTML data and MIDI data. 46. The method as described in claim 42, characterized in that: each mixed media packet includes a portion of an ASF data stream, an ASF packet header and at least one ASF load header; and each simple media pack includes, an RTP packet header and an RTP load format header; a portion of an RTP data stream. 47. The method as described in claim 42, characterized in that: the load profile format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding load. 48. A computer readable medium comprising machine-readable instructions that, when executed, performs the method as described in claim 42. 49. A client computing device comprising a processor for executing configured logic for: sending a request for a media file that includes a plurality of media data types; receiving media per stream in a plurality of RTP packets corresponding to the media file and including: only one of the media data types; an RTP packet header; one or more RTP load format headers, each one includes an RTP load limit; and an RTP load for and corresponding to each RTP load format header, where the RTP load is encrypted and has an arbitrary block size corresponding to the load limit RTP, each RTP load is selected from the group consisting of: a plurality of portions of one of the media data types; a portion of one of the media data types; and a fragment of a portion of one of the media data types; for each RTP load in the received RTP packets: including a plurality of portions of one of the media data types, assembling the plurality of portions of one of the media data types in an adjoining load using the load limit RTP of the corresponding RTP load format header; which includes a portion of one of the media data types, assembling the portion of one of the media data types into a contiguous load using the load limit RTP of the corresponding RTP load format header; and which includes a fragment of a portion of one of the media data types, assembling all fragments of the portion of one of the media data types into a contiguous load using each RTP load limit of the format headers of corresponding RTP charge; assemble, in chronological order corresponding to the plurality of media data types of the media file, the contiguous loads; and simultaneously presenting the contiguous loads ordered chronologically from the plurality of media data types of the media file. 50. The client computation device as described in claim 49, characterized in that the plurality of RTP packets are of variable size and smaller than a predetermined size which is a selected function of the group consisting of : an evaluation of the transmission bandwidth of an underlying network from which the plurality of RTP packets was received; a physical characteristic of the underlying network; and an administrative policy regarding package size. 51 The client computing device as described in claim 49, characterized in that each load limit RTP identifies the chronological order of the corresponding RTP load in the media data type of the media file. 52. The client computing device as described in claim 49, characterized in that each type of average data is selected from the group consisting of audio data, video data, program data, data JPEG, HTML data and MIDI data. 53. The client computing device as described in claim 49, characterized in that: each RTP load format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding RTP load. 54. A client computing device comprising a processor for executing logic configured to: send a request for a media file that includes audio and video data; receiving a plurality of RTP packets corresponding to a plurality of ASF packets for the media file, characterized in that: each ASF packet includes: an ASF packet header; and one or more ASF load headers, each including an ASF load limit for a corresponding ASF load, wherein the ASF load is encrypted with an arbitrary block size corresponding to the ASF load limit; the ASF load for and corresponding to each ASF load header is selected from the group consisting of: some of the audio data including an audio sample or fragment thereof; and some of the video data including a video sample or fragment thereof; each RTP package includes: either some of the audio data or some of the video data; an RTP packet header that corresponds to at least one of the ASF packet headers; one or more RTP load format headers corresponding to at least one of the ASF load headers, wherein each RTP load format header includes an RTP load limit corresponding to at least one of the load limits ASF; and an RTP load for and corresponding to each RTP load format header, each RTP load is selected from the group consisting of: a plurality of the ASF loads; one of the ASF loads; and a fragment of one of the ASF loads; for each RTP load in the received RTP packets: including a plurality of the ASF loads, assemble the plurality of the ASF loads in a contiguous load using the load limit RTP of the corresponding RTP load format header; which includes one of the ASF loads, assemble the ASF load in a contiguous load using the RTP load limit of the corresponding RTP load format header; and including a fragment of one of the ASF loads, assembling all the fragments of one of the ASF loads in a contiguous load using each RTP load limit of the corresponding RTP load format headers; assemble, in chronological order corresponding to the audio and video data of the media file, the adjacent loads; and simultaneously presenting the contiguous loads ordered chronologically from both the audio data of the media file and the video data from the media file. 55. The client computing device as described in claim 54, characterized in that the RTP packets are of variable size and smaller than a predetermined size which is a function selected from the group consisting of: an evaluation of the transmission bandwidth of an underlying network from which the plurality of RTP packets was received; a physical characteristic of the underlying network; and an administrative policy regarding package size; the size of the ASF packets corresponding to the plurality of received RTP packets; and a combination of the above. 56. The client computation device as described in claim 54, characterized in that each ASF load limit identifies the respective chronological order of the corresponding ASF load in one of: the audio data in the media file; and the video data in the media file. 57. The client com- puter device as described in claim 54, characterized in that each RTP load limit identifies the respective chronological order of the corresponding RTP load in u of: the audio data in the file media; and the video data in the media file. 58. The client computing device as described in claim 54, characterized in that each load limit RTP identifies the respective chronological order of the corresponding RTP load in one of: a plurality of the ASF loads; and a fragment of one of the ASF loads. 59. The client computing device as described in claim 54, characterized in that: each RTP load format header includes a fixed length portion and a variable length portion; and the variable length portion includes attributes of the corresponding RTP load.