[go: up one dir, main page]

WO2018121584A1 - 一种数据流传输方法、装置、相关设备及存储介质 - Google Patents

一种数据流传输方法、装置、相关设备及存储介质 Download PDF

Info

Publication number
WO2018121584A1
WO2018121584A1 PCT/CN2017/118912 CN2017118912W WO2018121584A1 WO 2018121584 A1 WO2018121584 A1 WO 2018121584A1 CN 2017118912 W CN2017118912 W CN 2017118912W WO 2018121584 A1 WO2018121584 A1 WO 2018121584A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
data stream
media source
address
udp
Prior art date
Application number
PCT/CN2017/118912
Other languages
English (en)
French (fr)
Inventor
张晓渠
梁建适
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2018121584A1 publication Critical patent/WO2018121584A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]

Definitions

  • the present disclosure relates to a multicast transmission technology in the Internet domain, and in particular, to a data stream transmission method, apparatus, related device, and storage medium.
  • multicast transmission technology is widely used in Internet transmission.
  • IPTV and OTT (Over The Top) technologies multicast transmission technology is often used to implement live broadcast services.
  • a multicast group can only transmit one multicast stream, and one channel will contain multiple streams. Therefore, multiple channels of one channel need multiple multicast groups to transmit.
  • the resources of a multicast group are limited, so how to use a limited multicast group resource to transmit multiple data streams is an urgent problem to be solved.
  • Embodiments of the present disclosure provide a data stream transmission method and apparatus, and related devices and storage media.
  • the embodiment of the present disclosure provides a data stream transmission method, which is applied to a source device, and includes:
  • UDP User Datagram Protocol
  • IP internet protocol
  • the UDP port number is used to identify each data stream, including:
  • the code rate of each data stream of the first media source is different, or the angle of the scene picture corresponding to each data stream of the first media source is different.
  • the embodiment of the present disclosure further provides a data stream transmission method, which is applied to an intermediate device, and includes:
  • Parsing the data stream obtaining the first multicast IP address and at least two port numbers of the UDP;
  • the receiving data stream includes:
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source;
  • the UDP packet header is parsed to obtain a corresponding UDP port number.
  • the method before receiving the data stream, the method further includes:
  • the first multicast IP address corresponding to the first media source is used to join the multicast group corresponding to the multicast channel of the first media source according to an Internet Group Management Protocol (IGMP).
  • IGMP Internet Group Management Protocol
  • the multicast group corresponding to the multicast channel of the first media source based on the IGMP includes:
  • the IGMP message is used to request to join a multicast group corresponding to the multicast channel of the first media source.
  • the port number using UDP identifies each data stream, including:
  • the code rate of each data stream of the first media source is different, or the angle of the scene picture corresponding to each data stream of the first media source is different.
  • the embodiment of the present disclosure further provides a data stream transmission method, which is applied to a terminal, and includes:
  • the receiving data stream includes:
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source;
  • the UDP packet header is parsed to obtain a corresponding UDP port number.
  • the method before receiving the data stream, the method further includes:
  • the multicast group corresponding to the multicast channel of the first media source is added to the first media source by using the multicast IP address corresponding to the first media source.
  • the multicast group corresponding to the multicast channel of the first media source based on the IGMP includes:
  • the IGMP message is used to request to join a multicast group corresponding to the multicast channel of the first media source.
  • the code rate of each data stream of the first media source is different, or the angle of the scene picture corresponding to each data stream of the first media source is different.
  • the embodiment of the present disclosure further provides a data stream transmission apparatus, including:
  • the first identifier module is configured to identify at least two data streams of the first media source, and identify each data stream by using different port numbers of the UDP;
  • the first sending unit sends at least two data streams of the identified first media source based on the IP address of the first media source.
  • the first identifier module is configured to encapsulate a destination port number in a UDP packet header of each data stream, and the destination port numbers of the at least two data streams are different;
  • the first sending unit is configured to add a multicast IP address corresponding to the first media source to a destination address of the IP packet header.
  • the embodiment of the present disclosure further provides a data stream transmission apparatus, including:
  • a first receiving unit configured to receive a data stream
  • the first parsing unit is configured to parse the data stream, and obtain the first multicast IP address and at least two port numbers of the UDP;
  • a first identifying unit configured to determine, by using the first multicast IP address, a received data stream as a data stream of the first media source; and identifying, by using different port numbers of the UDP, each data stream of the first media source;
  • a second identity module configured to identify each data stream by using different port numbers of the UDP for at least two data streams of the received first media source
  • the second sending unit is configured to send at least two data streams of the identified first media source based on the second multicast IP address of the first media source.
  • the device further includes:
  • the first joining unit is configured to use the first multicast IP address corresponding to the first media source to join the multicast group corresponding to the multicast channel of the first media source based on the IGMP.
  • the embodiment of the present disclosure further provides a data transmission stream device, including:
  • a second receiving unit configured to receive a data stream
  • a second parsing unit configured to parse the data stream to obtain a multicast IP address and at least two port numbers of the UDP;
  • the second identifying unit is configured to determine, by using the multicast IP address, the received data stream as a data stream of the first media source; and identify, by using different port numbers of the UDP, each data stream of the first media source.
  • the device further includes:
  • the second joining unit is configured to use the multicast IP address corresponding to the first media source to join the multicast group corresponding to the multicast channel of the first media source based on the IGMP.
  • the embodiment of the present disclosure further provides a source device, including:
  • the first processor is configured to identify each data stream by using different port numbers of the user datagram UDP for at least two data streams of the first media source;
  • the first communication interface is configured to send at least two data streams of the identified first media source based on the multicast IP address of the first media source.
  • the embodiment of the present disclosure further provides an intermediate device, including:
  • a second communication interface configured to receive a data stream
  • a second processor configured to parse the data stream, obtain the first multicast IP address and at least two port numbers of the UDP; and determine, by using the first multicast IP address, that the received data stream is the data stream of the first media source; Identifying each data stream of the first media source by using different port numbers of UDP; and identifying each data stream by using different port numbers of UDP for at least two data streams of the received first media source;
  • the second communication interface is further configured to send at least two data streams of the identified first media source based on the second multicast IP address of the first media source.
  • the embodiment of the present disclosure further provides a terminal, including:
  • a third communication interface configured to receive a data stream
  • a third processor configured to parse the data stream, obtain a multicast IP address and at least two port numbers of the UDP; determine, by using the multicast IP address, the received data stream as a data stream of the first media source; Different port numbers of UDP identify each data stream of the first media source.
  • the embodiment of the present disclosure further provides a storage medium on which a computer program is stored, and when the computer program is executed by the processor, the steps of any method on the source device side are implemented, or the steps of any method on the intermediate device side are implemented. Or implementing the steps of any of the above methods on the terminal side.
  • the data stream transmission method, device, related device and storage medium provided by the embodiment of the present disclosure, for each of the at least two data streams of the first media source, identify each data stream by using different port numbers of UDP; based on the first media source Multicast IP address, sending at least two data streams of the identified first media source; receiving the data stream; parsing the data stream, obtaining the multicast IP address and at least two port numbers of the UDP; using the multicast IP
  • the address determines that the received data stream is the data stream of the first media source; each channel of the first media source is identified by using different port numbers of UDP, that is, when the multi-channel data stream of the media source is transmitted, the multicast IP is used. Different addresses are used to distinguish different media sources.
  • Different UDP port numbers are used to distinguish one media source, that is, different data streams under the same multicast group. This greatly reduces the occupied multicast group resources.
  • the at least two data streams of the identified first media source are sent out, completely comply with IGMP, and have good compatibility with the existing network.
  • FIG. 1 is a schematic flowchart of a method for transmitting a data stream according to an embodiment of the present disclosure
  • FIG. 2 is a schematic flowchart of a second method for transmitting a data stream according to an embodiment of the present disclosure
  • FIG. 3 is a schematic flowchart of a method for transmitting a third data stream according to Embodiment 1 of the present disclosure
  • FIG. 4 is a schematic structural diagram of a data stream transmission apparatus according to Embodiment 2 of the present disclosure.
  • FIG. 5 is a schematic structural diagram of a second data stream transmission apparatus according to Embodiment 2 of the present disclosure.
  • FIG. 6 is a schematic structural diagram of a third data stream transmission apparatus according to Embodiment 2 of the present disclosure.
  • FIG. 7 is a schematic structural diagram of a device for implementing a multicast group to support multiple channels of data streams according to Embodiment 3 of the present disclosure
  • FIG. 8 is a schematic diagram of networking between a multicast channel source device and a multicast channel access server according to Embodiment 3 of the present disclosure
  • FIG. 9 is a schematic diagram of networking between CDN nodes according to Embodiment 3 of the present disclosure.
  • FIG. 10 is a schematic diagram of networking between a CDN node and a terminal according to Embodiment 3 of the present disclosure.
  • FIG. 11 is a schematic diagram of networking corresponding to a VR live broadcast service according to Embodiment 3 of the present disclosure.
  • channel live broadcasts often use multicast transmission.
  • one channel has only one bit rate, so a multicast group (corresponding to a multicast routing entry) is required to transmit a multicast stream.
  • a multicast group (corresponding to a multicast routing entry) is required to transmit a multicast stream.
  • the same name channel such as CCTV1
  • CCTV1 has both standard definition and high definition code rates, it is still processed according to two channels. Therefore, the data streams of the two code rates need to occupy two multicast groups for transmission.
  • one channel has multiple code rates, but the data stream of each bit rate in the data streams of the multiple code rates is still processed according to one channel, and is played by the terminal player. Select the data stream that uses the corresponding bitrate.
  • the usual processing method is to separately form the data stream of each code rate into one multicast group, so that one channel often occupies multiple multicast groups, which occupies multiple multicast routes. entry.
  • panoramic live broadcast scenes with different angles are transmitted using multiple streams, and sometimes, in order to save bandwidth, Different scenes need to use different encoding rates, so there will be a situation where one channel needs to transmit multiple streams. In this case, according to the traditional multicast transmission method, only multiple multicast groups can be used. Transmit multiple streams of one channel.
  • the content delivery network (CDN, server delivery interface) network card For multicast transmission, the content delivery network (CDN, server delivery interface) network card, the multicast routing entry of the protocol stack, and the number of multicast groups on the bearer network router are required.
  • these multicast group resources. that is, the number of multicast routing entries
  • multicast routing entries are scarce resources.
  • IGMP is generally used to control and manage multicast groups, and IGMP is directly contacted with the multicast host based on IGMP.
  • the router running IGMP is responsible for adding, leaving, and maintaining groups of the management group members. Membership.
  • Table 1 shows the format of an IGMP message. As shown in Table 1, in an IGMP message, the main fields contain the version, type, checksum, and multicast address.
  • the version field contains the IGMP version identifier.
  • the type field contains: membership query (0x11) and membership report (0x12).
  • Checksum is used to check IGMP messages.
  • the group address field contains the multicast address.
  • the group address field is 0 and is ignored by the host.
  • Table 2 shows the UDP message format.
  • the UDP packet contains: the source port and the destination port, the field indicating the length of the data packet, the checksum of the UDP data packet, and the UDP data.
  • IGMP is only related to the IP address of the multicast group when it is used to control and manage the multicast group. It has no relationship with the UDP port carried on the IP.
  • the multicast group data packet is carried on the IP and UDP. Therefore, it is feasible to transmit the multi-port data stream on a multicast group, and it does not affect the normal operation of the IGMP protocol family.
  • a multi-channel data stream of a media source when a multi-channel data stream of a media source is transmitted, different media sources are distinguished by using a multicast IP address, and different media ports are used to distinguish one media source, that is, the same multicast group. Different data streams under.
  • the method for transmitting a data stream in the embodiment of the present disclosure is specifically a method for transmitting a majority of a data stream in a multicast group, which is applied to a multicast channel source device in a multicast network, as shown in FIG. 1 , and includes the following steps:
  • Step 101 Identify, for at least two data streams of the first media source, different data ports of each UDP by using different port numbers of UDP;
  • a destination port number is encapsulated in a UDP packet header of each data stream, and destination port numbers of the at least two data streams are different.
  • the code rate of each data stream of the first media source may be different; or, when in a VR live broadcast scenario, the angle of the scene picture corresponding to each data stream of the first media source different.
  • UDP port numbers can be set as needed to identify different data streams of the first media source. For example, suppose the data stream has high-definition, standard-definition, and smooth three-way data streams. You can set three even port numbers, such as 902, 904, and 906, to identify HD, SD, and smooth, respectively. Road data stream.
  • Step 102 Send at least two data streams of the identified first media source according to the multicast IP address of the first media source.
  • the multicast IP address corresponding to the first media source is added to the destination address of the IP packet header, and after the multicast IP address corresponding to the first media source is added to the destination address of the IP packet header, At least two data streams of a media source are presented in the form of IP packets.
  • the first media source is identified by using a multicast IP address, and different media sources use different multicast IP addresses.
  • an embodiment of the present disclosure further provides a method for transmitting a data stream, in particular, a method for transmitting a majority of a data stream of a multicast group, which is applied to a multicast channel intermediate device in a multicast network, such as multicast.
  • the channel access streaming media server such as a CDN central node, etc.
  • its next-level intermediate device a device other than the playback terminal
  • Step 201 Receive a data stream.
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source.
  • the method may further include:
  • the first multicast IP address corresponding to the first media source is used to generate an IGMP message
  • the IGMP message such as an IGMP join or report message, is used to request to join a multicast group corresponding to the multicast channel of the first media source.
  • the first multicast IP address corresponding to the first media source may be used to generate an IGMP message; and the IGMP is sent to the switch.
  • the IGMP message such as an IGMP leave message, is used to request a multicast group corresponding to the multicast channel of the first media source.
  • Step 202 Parsing the data stream, obtaining the first multicast IP address and at least two port numbers of the UDP;
  • the specific implementation of this step includes:
  • the UDP packet header is parsed to obtain a corresponding UDP port number.
  • each message contains only one UDP port number.
  • Step 203 Determine, by using the first multicast IP address, that the received data stream is a data stream of the first media source, and identify, by using different port numbers of the UDP, each data stream of the first media source.
  • the code rate of each data stream of the first media source may be different; or, when in a VR live broadcast scenario, the angle of the scene picture corresponding to each data stream of the first media source different.
  • Step 204 Identify, for at least two data streams of the received first media source, different data ports of each UDP by using different port numbers of UDP;
  • the port number of the UDP is used to identify each data stream, including:
  • a destination port number is encapsulated in the UDP packet header of each data stream, and the destination port numbers of the at least two data streams are different.
  • Step 205 Send at least two data streams of the identified first media source according to the second multicast IP address of the first media source.
  • the second multicast IP address corresponding to the first media source is added to the destination address of the IP packet header.
  • the second multicast IP address corresponding to the first media source is added to the destination address of the IP packet header, at least two data streams of the first media source are presented in an IP packet manner.
  • the multicast group in which the first media source is received is different from the multicast group corresponding to the data stream.
  • the corresponding multicast The group IP address is different. That is to say, the first multicast IP address and the second multicast IP address are generally different.
  • the embodiment of the present disclosure further provides a data stream transmission method, in particular, a multicast group majority channel data stream transmission method, which is applied to a multicast channel play terminal in a multicast network, as shown in the figure.
  • a data stream transmission method in particular, a multicast group majority channel data stream transmission method, which is applied to a multicast channel play terminal in a multicast network, as shown in the figure.
  • the following steps are included:
  • Step 301 Receive a data stream.
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source.
  • the method may further include:
  • the multicast group corresponding to the multicast channel of the first media source is added to the first media source by using the multicast IP address corresponding to the first media source.
  • the IGMP message is generated by using the multicast IP address corresponding to the first media source;
  • the IGMP message is sent to the switch, and the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the IGMP message can be generated by using the multicast IP address corresponding to the first media source; and the IGMP message is sent to the switch.
  • the IGMP message such as the IGMP Leave message, is used to request a multicast group corresponding to the multicast channel of the first media source.
  • Step 302 Parsing the data stream, obtaining a multicast IP address and at least two port numbers of the UDP;
  • the specific implementation of this step includes:
  • the UDP packet header is parsed to obtain a corresponding UDP port number.
  • each message contains only one UDP port number.
  • Step 303 Determine, by using the multicast IP address, the received data stream as a data stream of the first media source; and identify each data stream of the first media source by using different port numbers of the UDP.
  • the code rate of each data stream of the first media source may be different; or, when in a VR live broadcast scenario, the angle of the scene picture corresponding to each data stream of the first media source different.
  • the data stream transmission method identifies each data stream by using different port numbers of UDP for at least two data streams of the first media source; and identifying the data stream based on the multicast IP address of the first media source. Transmitting at least two data streams of the first media source; receiving the data stream; parsing the data stream, obtaining a multicast IP address and at least two port numbers of the UDP; determining, by using the multicast IP address, the received data stream a data stream of a media source; identifying each data stream of the first media source by using different port numbers of UDP, that is, when transmitting the multiple data streams of the media source, using the multicast IP address to distinguish different media sources, Different UDP port numbers are used to distinguish one media source, that is, different data streams under the same multicast group.
  • the occupied multicast group resources are greatly reduced, that is, the multicast resources are saved.
  • the at least two data streams of the identified first media source are sent out, completely comply with IGMP, and have good compatibility with the existing network.
  • the multicast group corresponding to the multicast channel of the first media source based on the IGMP is not required to use the UDP socket port resource of the device.
  • it is not limited to the UDP socket port of the device, and directly uses the multicast IP address to interact with the switch.
  • the occupied multicast group resources are further reduced, and the IGMP can be completely followed, and the existing network can be very Good compatibility.
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source, without obtaining the protocol stack.
  • the embodiment provides a data stream transmission device, which is configured to be a multicast channel source device in a multicast network. As shown in FIG. 4, the device includes:
  • the first identifier module 41 is configured to identify each data stream by using different port numbers of the UDP for at least two data streams of the first media source;
  • the first sending unit 42 sends at least two data streams of the identified first media source based on the IP address of the first media source.
  • the first identifier module 41 is configured to encapsulate a destination port number in a UDP packet header of each data stream, and the destination port numbers of the at least two data streams are different.
  • the code rate of each data stream of the first media source may be different; or, when in a VR live broadcast scenario, the angle of the scene picture corresponding to each data stream of the first media source different.
  • UDP port numbers can be set as needed to identify different data streams of the first media source. For example, suppose the data stream has high-definition, standard-definition, and smooth three-way data streams. You can set three even-numbered port numbers, such as 902, 904, and 906, to identify HD, SD, and smooth, respectively. Road data stream.
  • the first sending unit 42 is specifically configured to add a multicast IP address corresponding to the first media source to a destination address of the IP packet header. After the multicast IP address corresponding to the first media source is added to the destination address of the IP packet header, at least two data streams of the first media source are presented in an IP packet manner.
  • the first identification module 41 may be implemented by a processor in a data stream transmission device; the first transmission unit 42 may be implemented by a transceiver in a data stream transmission device.
  • an embodiment of the present disclosure further provides a source device, including:
  • the first processor is configured to identify each data stream by using different port numbers of the user datagram UDP for at least two data streams of the first media source;
  • the first communication interface is configured to send at least two data streams of the identified first media source based on the multicast IP address of the first media source.
  • an embodiment of the present disclosure further provides a data stream transmission apparatus, which is applied to a multicast channel intermediate device in a multicast network, such as a multicast channel access streaming media server (such as a CDN central node, etc.) or a next level thereof.
  • a multicast channel access streaming media server such as a CDN central node, etc.
  • the intermediate device (the device other than the playback terminal), as shown in FIG. 5, the device includes:
  • the first receiving unit 51 is configured to receive a data stream
  • the first parsing unit 52 is configured to parse the data stream, and obtain the first multicast IP address and at least two port numbers of the UDP;
  • the first identifying unit 53 is configured to determine, by using the first multicast IP address, that the received data stream is a data stream of the first media source, and identify, by using different port numbers of the UDP, each data stream of the first media source;
  • the second identifier module 54 is configured to identify each data stream by using different port numbers of the UDP for at least two data streams of the received first media source;
  • the second sending unit 55 is configured to send at least two data streams of the identified first media source based on the second multicast IP address of the first media source.
  • the first receiving unit 51 is specifically configured to:
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source.
  • the device may further include:
  • the first joining unit is configured to use the first multicast IP address corresponding to the first media source to join the multicast group corresponding to the multicast channel of the first media source based on the IGMP.
  • the first joining unit generates an IGMP message by using the first multicast IP address corresponding to the first media source;
  • the first joining unit sends the IGMP message to the switch; the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the first joining unit may generate an IGMP message by using the first multicast IP address corresponding to the first media source.
  • the IGMP message is sent to the switch, and the IGMP message, such as a IGMP packet, is used to request a multicast group corresponding to the multicast channel of the first media source.
  • the first parsing unit 52 is specifically configured to:
  • the UDP packet header is parsed to obtain a corresponding UDP port number.
  • each message contains only one UDP port number.
  • the code rate of each data stream of the first media source may be different; or, when in a VR live broadcast scenario, the angle of the scene image corresponding to each data stream of the first media source is different.
  • the second identifier module 54 is specifically configured as follows:
  • a destination port number is encapsulated in the UDP packet header of each data stream, and the destination port numbers of the at least two data streams are different.
  • the second sending unit 55 is specifically configured to:
  • the second sending unit After the second sending unit adds the second multicast IP address corresponding to the first media source to the destination address of the IP packet header, at least two data streams of the first media source are presented in an IP packet manner.
  • the multicast group in which the first media source is received is different from the multicast group corresponding to the data stream.
  • the corresponding multicast The group IP address is different. That is to say, the first multicast IP address and the second multicast IP address are generally different.
  • the first receiving unit 51 and the second sending unit 55 may be implemented by a transceiver in the data stream transmission device; the first parsing unit 52, the first identifying unit 53, and the second identifying module 54 may be implemented in the data stream transmitting device.
  • the processor is implemented; the first joining unit can be implemented by a processor in the data stream transmission device in combination with the transceiver.
  • an embodiment of the present disclosure further provides an intermediate device, such as a CDN node, and the like, including:
  • a second communication interface configured to receive a data stream
  • a second processor configured to parse the data stream, obtain the first multicast IP address and at least two port numbers of the UDP; and determine, by using the first multicast IP address, that the received data stream is the data stream of the first media source; Identifying each data stream of the first media source by using different port numbers of UDP; and identifying each data stream by using different port numbers of UDP for at least two data streams of the received first media source;
  • the second communication interface is further configured to send at least two data streams of the identified first media source based on the second multicast IP address of the first media source.
  • the embodiment of the present disclosure further provides a data stream transmission apparatus, which is disposed in a multicast terminal of a multicast channel in a multicast network.
  • the apparatus includes:
  • a second receiving unit 61 configured to receive a data stream
  • the second parsing unit 62 is configured to parse the data stream, and obtain at least two port numbers of the multicast IP address and UDP;
  • the second identifying unit 63 is configured to determine, by using the multicast IP address, the received data stream as a data stream of the first media source; and identify each data stream of the first media source by using different port numbers of the UDP.
  • the second receiving unit 61 is specifically configured to:
  • the hook function is used to receive the complete packet of the multicast data formed by the IP packet header, the UDP packet header, and the at least two data streams of the first media source.
  • the second parsing unit 62 parses the IP packet header to obtain a multicast IP address
  • the second parsing unit 62 parses the UDP packet header to obtain a corresponding UDP port number.
  • each message contains only one UDP port number.
  • the device may further include:
  • the second joining unit is configured to use the multicast IP address corresponding to the first media source to join the multicast group corresponding to the multicast channel of the first media source based on the IGMP.
  • the second joining unit generates an IGMP message by using a multicast IP address corresponding to the first media source
  • the second joining unit sends the IGMP message to the switch; the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the IGMP message (such as an IGMP join or report message) is used to request to join the multicast group corresponding to the multicast channel of the first media source.
  • the second joining unit may generate an IGMP message by using the multicast IP address corresponding to the first media source; And sending the IGMP message, where the IGMP message, such as a IGMP packet, is used to request a multicast group corresponding to the multicast channel of the first media source.
  • the second receiving unit 61 may be implemented by a transceiver in the data stream transmission device; the second parsing unit 62 and the second identifying unit 63 may be implemented by a processor in the data stream transmission device;
  • the joining unit can be implemented by a processor in the data stream transmission device in conjunction with the transceiver.
  • an embodiment of the present disclosure further provides a terminal, including:
  • a third communication interface configured to receive a data stream
  • a third processor configured to parse the data stream, obtain a multicast IP address and at least two port numbers of the UDP; determine, by using the multicast IP address, the received data stream as a data stream of the first media source; Different port numbers of UDP identify each data stream of the first media source.
  • this embodiment describes in detail the transmission process of multiple data streams.
  • a multicast group that is, a multicast IP address corresponding to a multicast routing entry
  • the media source of the related multi-path data stream such as the live channel in the OTT, the VR live channel, etc.
  • the port number of the UDP carried on the IP is used to identify the data stream, that is, different UDP port numbers are used to distinguish one media source.
  • Different data streams are used to identify the data stream.
  • the apparatus shown in FIG. 7 can be used to implement the multicast group to support the transmission of multiple data streams.
  • the apparatus includes: a multicast user information module, a multicast group management module, and a multicast group multiplex data stream receiving/transmitting module.
  • the multicast user information module is used to manage multicast user media sources (such as OTT live channels, VR live channels, etc.).
  • Each media source uses a multicast group, that is, a multicast routing entry is used corresponding to a multicast IP address. address.
  • the multicast IP address and the UDP port information used by the related multi-path data stream are managed; the multicast IP address is used to distinguish different media sources, and the UDP port information is used to distinguish data streams under the same multicast group, such as different codes. Rate of streaming media, etc.
  • the multicast group management module is configured to perform the interaction processing of the multicast IGMP messages between the CDN server node or the terminal and the switch, complete the CDN server node or the terminal joining and leaving the multicast group, and respond to the multicast periodic query message of the switch.
  • the management of the multicast group by the general operating systems such as windows and linux is attached to the UDP socket, and the UDP socket must specify the multicast IP address and port to complete the joining and leaving of the multicast group.
  • receiving the multi-channel multicast code stream through the UDP socket based on the flow of the existing operating system is a relatively large limitation, so the management mode of the multicast group needs to be extended.
  • the multicast group management module sends an IGMP join message to the switch based on the multicast group IP address and requests to join the multicast group to complete the action of the host joining the multicast group.
  • the multicast group management module also receives the IGMP query message of the switch and reports the current multicast group information.
  • the IGMP report message is sent to the switch to notify the switch that a specific multicast group exists.
  • This module mainly implements multiple data streams that send the same multicast group.
  • the multicast group and the UDP packet are configured to transmit the multicast data of the multicast group by using the destination address field of the IP packet header and the destination port field of the UDP packet header.
  • the destination address of the IP packet header is specified as a multicast IP address.
  • different destination ports are encapsulated, and one destination port represents one data stream. For example, in practical applications, different ports represent data streams of different code rates.
  • the multicast group multi-channel data stream receiving module mainly implements receiving multiple data streams included in the same multicast channel (media source). Specifically, the multicast group multiplexed data stream receiving module receives the bare data packet, that is, the packet IP packet header and the UDP packet header, and the complete packet of the multicast data, by using the system hook function. Then, the multicast group multiplexed data stream receiving module first parses the multicast IP address and the port information indicating different data streams according to the multicast packet (the IP packet header and the UDP packet header); and then, according to the multicast user The multicast IP and port information in the information module, that is, the multicast channel information, decomposes different data streams; finally, it can also distribute and process different streams.
  • each multicast group can only support one UDP port, which limits the UDP socket to only receive.
  • a pair of multicast IP and port data packets limit the system's ability to receive multicast multiport data packets using UDP sockets.
  • the bare data packet is directly received by the hook function, which can solve the problem that the common protocol stack cannot support one multicast socket and cannot support multiple UDP ports.
  • FIG. 8 a networking diagram from a multicast channel source device to a multicast channel access server (generally a central node of a CDN) is described.
  • the multicast channel source device sends multiple streams of data to the switch, and the multicast channel access server obtains multiple streams of data from the switch.
  • the process specifically includes:
  • Step 1 The multicast user information module of the multicast channel source device (which may be an encoder or a multicast source channel generation server) establishes a multicast channel, and the multicast group multiplex data stream sending module (equivalent to the first in the second embodiment) The function of the identification module and the first sending unit is to send a multicast multi-channel data stream.
  • the multicast group multi-channel data stream sending module uses a multicast IP address to send the multicast.
  • Step 2 The multicast user information module of the multicast channel access server establishes a corresponding multicast channel, and manages the correspondence between the IP address of the multicast channel and the channel-related multiplexed code stream and the UDP port.
  • Step 3 The multicast group management module of the multicast channel access server sends an IGMP message to the switch to join the multicast group of the channel (equivalent to the function of the first joining unit in the second embodiment), so that the node is ready to receive the multicast. Multiple streams of data from the source.
  • Step 4 The multicast group multiplex data stream receiving module of the multicast channel access server (corresponding to the functions of the first receiving unit, the first analyzing unit, and the first identifying unit in the second embodiment) receives the multicast code sent by the switch flow.
  • the multicast group multiplex data stream receiving module receives all multicast data streams provided by the multicast source.
  • the multicast group multi-channel data stream receiving module of the multicast channel access server uses the UDP port number to distinguish different data streams, and sends the received data stream to the multicast user information module for corresponding service processing, for example, after processing the channel.
  • the multicast stream is sent to the lower node or the terminal.
  • the transmission process of the multiple data streams is: the upper CDN node sends the multiple data streams to the switch, and the lower CDN node obtains the multiple data streams from the switch.
  • the process specifically includes:
  • Step 1 The multicast group multi-channel data stream receiving module of the upper-level CDN node (similar to the above-mentioned multicast channel access server) receives the multi-channel data stream of the multicast source, and the multicast group multi-channel data stream sending module of the upper-level CDN node Send multicast multi-channel data streams.
  • the multicast group multiplex data stream sending module of the upper-level CDN node (corresponding to the functions of the second identifier module and the second sending unit in the second embodiment) uses a multicast IP address to send the multicast channel code stream, and Different UDP ports are used to distinguish between sending different data streams.
  • Step 2 The multicast user information module of the lower-level CDN node establishes a corresponding multicast channel, and manages the correspondence between the IP address of the multicast channel and the channel-related multiplexed code stream and the UDP port.
  • Step 3 The multicast group management module on the lower-level CDN node sends an IGMP message to the switch to join the multicast group of the channel, so that the node is ready to receive the multi-channel data stream of the multicast source.
  • Step 4 The multicast group multi-channel data stream receiving module of the lower-level node receives the multicast code stream sent by the switch.
  • the multicast code stream received by the multicast group multiplex data stream receiving module of the lower-level CDN node is all multicast data streams provided by the upper CDN node.
  • the multi-channel data stream receiving module of the lower-level CDN node uses the UDP port number to distinguish different data streams, and sends the received data stream to the multicast user information module of the lower-level CDN node for corresponding service processing, such as channel processing. After that, the multicast stream is sent to the lower node or the terminal.
  • the multicast data stream of the multicast group is transmitted to the terminal.
  • the transmission process of the multiple data streams between the CDN node and the terminal is: the CDN node sends the multiple data streams to the switch, and the terminal obtains the multiple data streams from the home gateway.
  • the following takes the terminal as an OTT terminal as an example to describe the transmission process in detail.
  • the OTT channel needs to support multiple code rates.
  • the OTT terminal such as an OTT set-top box or an IPAD
  • the CDN node generally have a unicast, and the terminal according to its own device capability or network transmission capability.
  • HTTP Hypertext Transfer Protocol
  • multicast With the large number of applications of OTT channel live broadcast, multicast has the advantage of saving network transmission capability in the live broadcast service. Therefore, the industry is promoting the application of multicast to implement OTT live broadcast. Therefore, the scheme of the present disclosure is used to transmit multiple code rates. The code stream is very efficient.
  • an application (APP) module is generally integrated on the terminal to process multicast, receive the multicast code stream, and the APP module and the terminal.
  • the HTTP playback unicast is still carried out between the playback modules, so it can be understood as an analog unicast live broadcast between the internal modules of the OTT terminal.
  • the device shown in Fig. 7 can be integrated in the APP module of the terminal.
  • the process of multi-channel data transmission between a CDN node and an OTT terminal including:
  • Step 1 The multicast group multiplex data stream receiving module of the edge CDN node receives the channel multicast code stream of the upper CDN node.
  • the edge CDN node has joined the multicast group in the manner described in FIG.
  • the multicast group multiplex data stream receiving module of the edge CDN node distinguishes the data streams of different code rates in the manner described in FIG.
  • Step 2 The multicast group multiplex data stream sending module of the edge CDN node sends the multicast code stream to the OTT terminal.
  • the multicast stream to be sent may have the following two situations:
  • the multicast group multiplex data stream sending module of the edge CDN node can all code rate of one channel.
  • the data stream is sent to the OTT terminal, and the multicast channel code stream is sent by using one multicast IP address, and different UDP ports are used to distinguish the code streams that send different code rates.
  • the second case is: the network transmission bandwidth between the edge CDN node and the OTT terminal is limited, the OTT terminal analyzes its own situation and the network transmission situation, determines the required code rate code stream, and the APP uses the control signaling to notify the edge CDN node. Then, the edge CDN node uses the multicast group to send the required code stream to the OTT terminal. In this case, when the rate switching needs to be performed, the multicast group does not need to be switched, and the APP directly notifies the edge CDN node, and the edge CDN node directly uses the original multicast group to switch and send the code stream corresponding to the code rate.
  • Step 3 The multicast user information module in the OTT terminal APP establishes a corresponding multicast channel, and manages the correspondence between the IP address of the multicast channel and the channel-related multiplexed code stream and the UDP port.
  • Step 4 The multicast group management module in the OTT terminal APP sends an IGMP message to the home gateway to join the multicast group of the channel (equivalent to the function of the second joining unit in the second embodiment), so that the node is ready to receive the multicast source. Multiple streams of data.
  • Step 4 The multicast group multiplex data stream receiving module in the OTT terminal APP (corresponding to the functions of the second receiving unit, the second analyzing unit, and the second identifying unit in the second embodiment) receives the multicast code sent by the home gateway. flow.
  • the multicast code stream received by the multicast group multiplex data stream receiving module in the OTT terminal APP is all multicast data streams provided by the edge CDN node.
  • the multicast group multiplex data stream receiving module in the OTT terminal APP uses the UDP port number to distinguish the code streams of different code rates.
  • Step 5 The multicast group multi-channel data stream receiving module in the OTT terminal APP sends the received code stream to the multicast user information module in the OTT terminal APP, and the multicast user information module in the OTT terminal APP performs the code stream on the code stream.
  • Related business processing such as sending to the relevant decoding module, for decoding and playback processing.
  • the multicast group multiplex data stream receiving module in the OTT terminal APP selects which code rate stream to use by using the multicast user information module in the OTT terminal APP and the decoding module of the terminal, and will correspondingly The code stream is sent to the decoding module.
  • VR panoramic live broadcast is the current hot service.
  • Multicast technology has a natural advantage in live broadcast applications.
  • the live broadcast there are different angles of scene images transmitted by multiple streams. Therefore, VR live broadcast services can also be used.
  • the solution provided by the embodiment of the present disclosure is adopted.
  • the transmission process of the multiple data streams between the VR live broadcast server (which may also be a CDN node) and the VR terminal is: the VR live broadcast server sends the multiple data streams to the switch, and the terminal obtains more from the home gateway.
  • Road data flow the process specifically includes:
  • Step 1 The VR multicast server creates a VR multicast live broadcast source, and the multicast group multi-channel data stream sending module of the VR multicast server sends the VR live multicast code stream.
  • the multicast group multiplex data stream sending module of the VR multicast server uses one multicast IP address to send the VR multicast channel code stream, and uses different UDP ports to distinguish the code streams of the scene pictures that are sent at different angles.
  • Step 2 The multicast user information module of the VR terminal establishes a corresponding multicast channel, and manages the correspondence between the IP address of the multicast channel and the channel-related multiplexed code stream and the UDP port.
  • Step 3 The multicast group management module of the VR terminal sends an IGMP message to the home gateway to join the multicast group of the VR channel, and prepares to receive the multicast code stream of the VR multicast channel.
  • Step 4 The multicast group multiplex data stream receiving module of the VR terminal receives the multicast code stream sent by the home gateway.
  • the multicast group multiplex data stream receiving module receives all multicast data streams of the VR channel provided by the VR multicast server.
  • the multicast group multiplex data stream receiving module of the VR terminal uses the UDP port number to distinguish the code streams of different angle scenes.
  • Step 5 The multicast group multiplex data stream receiving module of the VR terminal sends the received code stream to the multicast user information module of the VR terminal for corresponding service processing, for example, sending it to the relevant decoding module for decoding processing, and implementing VR playback. .
  • the solution of the embodiment of the present disclosure uses a multicast group (that is, a multicast IP address corresponding to a multicast routing entry) to identify the correlation when transmitting the multiple streams of the media source.
  • the media source of the multi-channel data stream such as the live channel in the OTT, the VR live channel, etc., and uses the port number of the UDP carried on the IP to identify the data stream, thereby realizing a multicast group to transmit multiple data streams, thereby saving The number of occupied multicast group entries on the related device.
  • the solution provided by the embodiment of the present disclosure can solve the limitation that multiple multicast data streams occupy different multicast IP addresses and UDP ports in the same multicast service, and reduce the use of the multicast UDP socket of the CDN node, that is, , reducing the occupied multicast IP address and UDP port resources;
  • the multicast source address is used to identify the media source, and the multi-path data stream of the media source is distinguished by the UDP port.
  • the server node or the terminal and the switch can be reduced. IGMP packet exchange.
  • embodiments of the present disclosure can be provided as a method, system, or computer program product. Accordingly, the present disclosure may take the form of a hardware embodiment, a software embodiment, or a combination of software and hardware aspects. Moreover, the present disclosure may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) including computer usable program code.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • an embodiment of the present invention further provides a storage medium, specifically a computer readable storage medium, on which a computer program is stored, and when the computer program is executed by the processor, the steps of the source device side method are implemented, or implemented.
  • a storage medium specifically a computer readable storage medium, on which a computer program is stored, and when the computer program is executed by the processor, the steps of the source device side method are implemented, or implemented.
  • the solution provided by the embodiment of the present disclosure identifies, for at least two data streams of the first media source, each data stream by using different port numbers of the UDP; and based on the multicast IP address of the first media source, the identified Transmitting at least two data streams of a media source; receiving the data stream; parsing the data stream, obtaining a multicast IP address and at least two port numbers of the UDP; and determining, by using the multicast IP address, the received data stream as the first media source
  • the data stream is used to identify each data stream of the first media source by using different port numbers of UDP, that is, when transmitting the multiple data streams of the media source, the multicast IP address is used to distinguish different media sources, and different UDPs are used.
  • the port number distinguishes one media source, that is, different data streams under the same multicast group. This greatly reduces the occupied multicast group resources.
  • the at least two data streams of the identified first media source are sent out, completely comply with IGMP, and have good compatibility with the existing network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本公开公开了一种数据流传输方法，包括：针对第一媒体源的至少两路数据流，利用用户数据报协议（UDP）的不同端口号标识每路数据流；基于所述第一媒体源的组播互联网协议（IP）地址，将标识后的第一媒体源的至少两路数据流发出。本公开同时还公开了一种数据流传输装置、源设备、中间设备、终端及存储介质。

Description

一种数据流传输方法、装置、相关设备及存储介质
相关申请的交叉引用
本申请基于申请号为201611260794.0、申请日为2016年12月30日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本公开涉及互联网领域的组播传输技术，尤其涉及一种数据流传输方法、装置、相关设备及存储介质。
背景技术
随着宽带互联网电视业务的飞速发展，组播传输技术在互联网传输中广泛应用，如在IPTV、OTT(Over The Top)技术中，经常使用组播传输技术来实现直播业务。
在当前的直播业务中，一个组播组只能传输一种组播码流，同时一个频道会包含多路码流，所以一个频道的多路码流就需要多个组播组来传输。但是，组播组的资源是有限的，所以如何利用有限的组播组资源来传输多路数据流是目前亟待解决的问题。
发明内容
本公开实施例提供一种数据流传输方法、装置及相关设备及存储介质。
本公开实施例的技术方案是这样实现的：
本公开实施例提供了一种数据流传输方法，应用于源设备，包括：
针对第一媒体源的至少两路数据流，利用用户数据报协议(UDP，User Datagram Protocol)的不同端口号标识每路数据流；
基于所述第一媒体源的组播互联网协议(IP)地址，将标识后的第一媒体源的至少两路数据流发出。
上述方案中，利用UDP的端口号标识每路数据流，包括：
在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
所述基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出，包括：
在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址。
上述方案中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
本公开实施例还提供了一种数据流传输方法，应用于中间设备，包括：
接收数据流；
解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；
针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
上述方案中，所述接收数据流，包括：
利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文；
相应地，针对每个报文，解析所述IP报文头，获得第一组播IP地址；
解析所述UDP报文头，获得对应的一个UDP的端口号。
上述方案中，接收数据流之前，所述方法还包括：
利用所述第一媒体源对应的第一组播IP地址，基于网际组管理协议(IGMP，Internet Group Management Protocol)加入所述第一媒体源的组播 频道对应的组播组。
上述方案中，基于IGMP加入所述第一媒体源的组播频道对应的组播组，包括：
利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；
向交换机发送所述IGMP报文；所述IGMP报文用于请求加入所述第一媒体源的组播频道对应的组播组。
上述方案中，所述利用UDP的端口号标识每路数据流，包括：
在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
所述基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出，包括：
在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址。
上述方案中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
本公开实施例又提供了一种数据流传输方法，应用于终端，包括：
接收数据流；
解析数据流，获得组播IP地址及UDP的至少两个端口号；
利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流。
上述方案中，所述接收数据流，包括：
利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文；
相应地，针对每个报文，解析所述IP报文头，获得组播IP地址；
解析所述UDP报文头，获得对应的一个UDP的端口号。
上述方案中，接收数据流之前，所述方法还包括：
利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
上述方案中，基于IGMP加入所述第一媒体源的组播频道对应的组播组，包括：
利用所述第一媒体源对应的组播IP地址，生成IGMP报文；
向交换机发送所述IGMP报文；所述IGMP报文用于请求加入所述第一媒体源的组播频道对应的组播组。
上述方案中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
本公开实施例还提供了一种数据流传输装置，包括：
第一标识模块，配置为针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
第一发送单元，基于所述第一媒体源的IP地址，将标识后的第一媒体源的至少两路数据流发出。
上述方案中，所述第一标识模块，配置为在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
所述第一发送单元，配置为在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址。
本公开实施例又提供了一种数据流传输装置，包括：
第一接收单元，配置为接收数据流；
第一解析单元，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
第一识别单元，配置为利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流；
第二标识模块，配置为针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
第二发送单元，配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
上述方案中，所述装置还包括：
第一加入单元，配置为利用所述第一媒体源对应的第一组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
本公开实施例还提供了一种数据传输流装置，包括：
第二接收单元，配置为接收数据流；
第二解析单元，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；
第二识别单元，配置为利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流。
上述方案中，所述装置还包括：
第二加入单元，配置为利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
本公开实施例还提供了一种源设备，包括：
第一处理器，配置为针对第一媒体源的至少两路数据流，利用用户数据报UDP的不同端口号标识每路数据流；
第一通信接口，配置为基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
本公开实施例又提供了一种中间设备，包括：
第二通信接口，配置为接收数据流；
第二处理器，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；以及针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
所述第二通信接口，还配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
本公开实施例还提供了一种终端，包括：
第三通信接口，配置为接收数据流；
第三处理器，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；以及利用所述UDP的不同端口号识别第一媒体源的每路数据流。
本公开实施例还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述源设备侧任一方法的步骤，或者实现上述中间设备侧任一方法的步骤，或者实现上述终端侧任一方法的步骤。
本公开实施例提供的数据流传输方法、装置、相关设备及存储介质，针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出；接收数据流；解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流，也就是说，传输媒体源的多路数据流时，采用组播IP地址区分不同的媒体源，采用不同的UDP端口号来区分一个媒体源即同一组播组下的不同路数据流，如此，大大减少了占用的组播组资源。同时，基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出，完全遵循IGMP，可以和已有的网络具有很好地兼容性。
附图说明
在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。
图1为本公开实施例一一种数据流的传输方法流程示意图；
图2为本公开实施例一第二种数据流的传输方法流程示意图；
图3为本公开实施例一第三种数据流的传输方法流程示意图；
图4为本公开实施例二一种数据流传输装置结构示意图；
图5为本公开实施例二第二种数据流传输装置结构示意图；
图6为本公开实施例二第三种数据流传输装置结构示意图；
图7为本公开实施例三实现组播组支持多路数据流的传输装置结构示意图；
图8为本公开实施例三组播频道源设备到组播频道接入服务器之间的组网示意图；
图9为本公开实施例三CDN节点之间的组网示意图；
图10为本公开实施例三CDN节点至终端之间的组网示意图；
图11为本公开实施例三VR直播业务对应的组网示意图。
具体实施方式
下面结合附图及实施例对本公开再作进一步详细的描述。
在描述本公开实施例之前，先了解一下相关技术。
在传统的IPTV应用中，频道直播往往使用组播传输，一般来说，一路频道只有一种码率，所以需要一个组播组(对应一条组播路由条目)传输一种组播码流。当同一名称频道(比如CCTV1)存在有标清和高清两种码率时，仍然按照两路频道来处理，所以这两种码率的数据流需要占用两个组播组进行传输。
同时，在OTT技术的应用中，一路频道有多种码率，但是这多种码率的数据流中的每种码率的数据流仍然是按照一路频道来处理的，由终端的播放器来选择使用相应码率的数据流。这种情况下，通常处理方法也是将每种码率的数据流单独做成一路组播组，这样一来，一路频道往往就占用了多个组播组，也就占用了多条组播路由条目。
另外，随着虚拟现实(VR，Virtual Reality)技术的快速发展，全景视频的应用也越来越广泛，这种应用给用户带来了真实感很强的视频体验。支持VR的全景直播越来越热门，组播技术在直播应用中有天然的优势，而全景直播中，存在不同角度的场景画面使用多路码流传输的情况，而且，有时候为了节省带宽，不同角度的场景画面需要使用不同的编码速率，那 么就会存在一路直播需要传输多路码流的情况，在这种情况下，按照传统的组播传输方式，只能使用多个组播组来传输一个频道的多路码流。
然而，随着广播电视业务的大力发展，现在直播频道的数量越来越多，目前已经提出了需要支持上千路频道数量的需求，如果按照一路频道有超清、高清和标清三种码率，那么按照传统的组播传输方式，要占用的组播组数量就很大了。
进行组播传输时，需要内容分发网络(CDN，Content Delivery Networks)服务器接口网卡、协议栈的组播路由条目和承载网路由器上组播组的数量这些组播组资源，然而这些组播组资源(即组播路由条目数量)都是有限的，也就是说组播路由条目是紧缺资源。
所以如何在有限的组播组路由条目的基础上实现组播组传输多路数据流是目前需要解决的问题。
同时，一方面，在组播传输技术中，一般都是使用IGMP来控制和管理组播组，基于IGMP直接与组播主机联系，运行IGMP的路由器负责管理组成员的加入、离开，并维护组成员关系。
表1示出了IGMP报文的格式。从表1可以看出，在IGMP报文中，主要字段包含版本、类型、校验和以及组播地址。
Figure PCTCN2017118912-appb-000001
表1
其中，版本字段包含IGMP版本标识，目前有V1、V2和V3三个版本。
类型字段包含：成员关系查询(0x11)以及成员关系报告(0x12)。
校验和，用于对IGMP报文进行校验。
当类型字段表征一个成员关系报告时，组地址字段包含组播地址。当类型字段表征成员关系查询时，组地址字段为0，并被主机忽略。
另一方面，表2示出了UDP报文格式。
Figure PCTCN2017118912-appb-000002
表2
从表2中可以看出，UDP报文包含：源端口和目的端口，表示数据报文长度的字段，UDP数据报文校验和，以及UDP数据。
从IGMP规范和报文格式可以看出，在控制和管理组播组时，IGMP只跟组播组的IP地址有关系，跟IP上承载的UDP的端口没有关系。而组播组数据报文是承载在IP和UDP之上的，因此，在某个组播组上传输多端口的数据流是可行的，也不影响IGMP本身协议族的正常运行。
基于此，在本公开的各种实施例中：传输媒体源的多路数据流时，采用组播IP地址区分不同的媒体源，采用不同的UDP端口号来区分一个媒体源即同一组播组下的不同数据流。
实施例一
本公开实施例数据流的传输方法，具体来说是一种组播组多数路数据流的传输方法，应用于组播网络中组播频道源设备，如图1所示，包括以下步骤：
步骤101：针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
具体地，在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同。
这里，实际应用时，所述第一媒体源的每路数据流的码率可以不同；或者，当在VR直播场景下时，所述第一媒体源的每路数据流对应的场景画面的角度不同。
实际应用时，可以根据需要设置不同的UDP的端口号，以标识第一媒体源的不同的数据流。举个例子来说，假设数据流有高清、标清、以及流畅三路数据流，可以根据业务需要，设置三个偶数的端口号，比如902、904、 906，来分别标识高清、标清以及流畅三路数据流。
步骤102：基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
具体地，在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址，当在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址后，第一媒体源的至少两路数据流以IP报文的方式呈现。
也就是说，所述第一媒体源使用组播IP地址来标识，不同的媒体源使用不同的组播IP地址。
相应地，本公开实施例还提供了一种数据流的传输方法，具体来说是一种组播组多数路数据流的传输方法，应用于组播网络中组播频道中间设备，比如组播频道接入流媒体服务器(比如CDN中心节点等)或者其下一级中间设备(除播放终端外的设备)，如图2所示，包括以下步骤：
步骤201：接收数据流；
具体地，利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文。
这里，实际应用时，在执行本步骤之前，该方法还可以包括：
利用所述第一媒体源对应的第一组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
具体地，利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；
向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的加入(join)或报告(report)报文)用于请求加入所述第一媒体源的组播频道对应的组播组。
当然，当要离开所述第一媒体源的组播频道对应的组播组时，可以利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的离开(leave)报文)用于请求离开所述第一媒体源的组播频道对应的组播组。
步骤202：解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
这里，当利用钩子函数，接收报文的IP报文头及UDP报文头时，本步骤的具体实现包括：
针对每个报文，解析所述IP报文头，获得第一组播IP地址；
解析所述UDP报文头，获得对应的一个UDP的端口号。
也就是说，每个报文只包含一个UDP的端口号。
步骤203：利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；
这里，实际应用时，所述第一媒体源的每路数据流的码率可以不同；或者，当在VR直播场景下时，所述第一媒体源的每路数据流对应的场景画面的角度不同。
步骤204：针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
其中，所述利用UDP的端口号标识每路数据流，包括：
在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同。
步骤205：基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
具体地，在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址。
也就是说，在转发数据流时，使用第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出
在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址后，第一媒体源的至少两路数据流以IP报文的方式呈现。
实际应用时，作为组播网络中组播频道中间设备，一般接收第一媒体源时所在的组播组和其发出数据流时对应的组播组是不相同的，相应地， 对应的组播组IP地址是不同的。也就是说，第一组播IP地址和第二组播IP地址一般情况下是不同的。
相应地，本公开实施例又提供了一种数据流的传输方法，具体来说是一种组播组多数路数据流的传输方法，应用于组播网络中组播频道的播放终端，如图3所示，包括以下步骤：
步骤301：接收数据流；
具体地，利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文。
这里，实际应用时，在执行本步骤之前，该方法还可以包括：
利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
具体地，利用所述第一媒体源对应的组播IP地址，生成IGMP报文；
向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的join或report报文)用于请求加入所述第一媒体源的组播频道对应的组播组。
当然，当要离开所述第一媒体源的组播频道对应的组播组时，可以利用所述第一媒体源对应的组播IP地址，生成IGMP报文；向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的leave报文)用于请求离开所述第一媒体源的组播频道对应的组播组。
步骤302：解析数据流，获得组播IP地址及UDP的至少两个端口号；
这里，当利用钩子函数，接收报文的IP报文头及UDP报文头时，本步骤的具体实现包括：
针对每个报文，解析所述IP报文头，获得组播IP地址；
解析所述UDP报文头，获得对应的一个UDP的端口号。
也就是说，每个报文只包含一个UDP的端口号。
步骤303：利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流。
这里，实际应用时，所述第一媒体源的每路数据流的码率可以不同；或者，当在VR直播场景下时，所述第一媒体源的每路数据流对应的场景画面的角度不同。
本公开实施例提供的数据流传输方法，针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出；接收数据流；解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流，也就是说，传输媒体源的多路数据流时，采用组播IP地址区分不同的媒体源，采用不同的UDP端口号来区分一个媒体源即同一组播组下的不同路数据流，如此，大大减少了占用的组播组资源，即节省了组播资源。同时，基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出，完全遵循IGMP，可以和已有的网络具有很好地兼容性。
另外，利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组，不需要使用设备的UDP套接字(socket)端口资源，也就不受限于设备的UDP socket端口，直接使用组播IP地址来与交换机进行交互，如此，进一步降低了占用的组播组资源，而且能够完全遵循IGMP，可以和已有的网络具有很好地兼容性。
除此以外，利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文，不通过协议栈就能获取到这些信息，解决了普通协议栈不能支持一个组播组的socket端口不能支持多个UDP端口的问题，和已有的网络具有很好地兼容性。
实施例二
为实现本公开实施例的方法，本实施例提供一种数据流传输装置，设置在组播网络中组播频道源设备，如图4所示，该装置包括：
第一标识模块41，配置为针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
第一发送单元42，基于所述第一媒体源的IP地址，将标识后的第一媒体源的至少两路数据流发出。
其中，所述第一标识模块41，具体配置为：在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同。
这里，实际应用时，所述第一媒体源的每路数据流的码率可以不同；或者，当在VR直播场景下时，所述第一媒体源的每路数据流对应的场景画面的角度不同。
实际应用时，可以根据需要设置不同的UDP的端口号，以标识第一媒体源的不同的数据流。举个例子来说，假设数据流有高清、标清、以及流畅三路数据流，可以根据业务需要，设置三个偶数的端口号，比如902、904、906，来分别标识高清、标清以及流畅三路数据流。
所述第一发送单元42，具体配置为在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址。当在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址后，第一媒体源的至少两路数据流以IP报文的方式呈现。
实际应用时，所述第一标识模块41可由数据流传输装置中的处理器实现；所述第一发送单元42可由数据流传输装置中的收发机实现。
基于此，本公开实施例还提供了一种源设备，包括：
第一处理器，配置为针对第一媒体源的至少两路数据流，利用用户数据报UDP的不同端口号标识每路数据流；
第一通信接口，配置为基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
其中，第一处理器及第一通信接口的功能已在上文详述，这里不再赘述。
相应地，本公开实施例还提供了一种数据流传输装置，应用于组播网络中组播频道中间设备，比如组播频道接入流媒体服务器(比如CDN中心节点等)或者其下一级中间设备(除播放终端外的设备)，如图5所示，该 装置包括：
第一接收单元51，配置为接收数据流；
第一解析单元52，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
第一识别单元53，配置为利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流；
第二标识模块54，配置为针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
第二发送单元55，配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
其中，所述第一接收单元51，具体配置为：
利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文。
这里，实际应用时，该装置还可以包括：
第一加入单元，配置为利用所述第一媒体源对应的第一组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
具体地，所述第一加入单元利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；
所述第一加入单元向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的join或report报文)用于请求加入所述第一媒体源的组播频道对应的组播组。
当然，当要离开所述第一媒体源的组播频道对应的组播组时，所述第一加入单元可以利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的leave报文)用于请求离开所述第一媒体源的组播频道对应的组播组。
所述第一解析单元52，具体配置为：
针对每个报文，解析所述IP报文头，获得组播IP地址；
解析所述UDP报文头，获得对应的一个UDP的端口号。
也就是说，每个报文只包含一个UDP的端口号。
实际应用时，所述第一媒体源的每路数据流的码率可以不同；或者，当在VR直播场景下时，所述第一媒体源的每路数据流对应的场景画面的角度不同。
其中，所述第二标识模块54，具体配置为：
在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同。
所述第二发送单元55，具体配置为：
在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址。
所述第二发送单元在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址后，第一媒体源的至少两路数据流以IP报文的方式呈现。
实际应用时，作为组播网络中组播频道中间设备，一般接收第一媒体源时所在的组播组和其发出数据流时对应的组播组是不相同的，相应地，对应的组播组IP地址是不同的。也就是说，第一组播IP地址和第二组播IP地址一般情况下是不同的。
所述第一接收单元51、第二发送单元55可由数据流传输装置中的收发机实现；所述第一解析单元52、第一识别单元53、第二标识模块54可由数据流传输装置中的处理器实现；所述第一加入单元可由数据流传输装置中的处理器结合收发机实现。
基于此，本公开实施例还提供了一种中间设备，比如CDN节点等，包括：
第二通信接口，配置为接收数据流；
第二处理器，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；以及针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数 据流；
所述第二通信接口，还配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
其中，第二处理器及第二通信接口的功能已在上文详述，这里不再赘述。
相应地，本公开实施例又提供了一种数据流传输装置，设置在组播网络中组播频道的播放终端，如图6所示，该装置包括：
第二接收单元61，配置为接收数据流；
第二解析单元62，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；
第二识别单元63，配置为利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流。
其中，所述第二接收单元61，具体配置为：
利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文。
相应地，针对每个报文，所述第二解析单元62解析所述IP报文头，获得组播IP地址；
所述第二解析单元62解析所述UDP报文头，获得对应的一个UDP的端口号。
也就是说，每个报文只包含一个UDP的端口号。
这里，实际应用时，该装置还可以包括：
第二加入单元，配置为利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
具体地，所述第二加入单元利用所述第一媒体源对应的组播IP地址，生成IGMP报文；
所述第二加入单元向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的join或report报文)用于请求加入所述第一媒体源的组播频道对应的组播组。
当然，当要离开所述第一媒体源的组播频道对应的组播组时，所述第二加入单元可以利用所述第一媒体源对应的组播IP地址，生成IGMP报文；向交换机发送所述IGMP报文；所述IGMP报文(比如IGMP的leave报文)用于请求离开所述第一媒体源的组播频道对应的组播组。
实际应用时，所述第二接收单元61可由数据流传输装置中的收发机实现；所述第二解析单元62、第二识别单元63可由数据流传输装置中的处理器实现；所述第二加入单元可由数据流传输装置中的处理器结合收发机实现。
基于此，本公开实施例还提供了一种终端，包括：
第三通信接口，配置为接收数据流；
第三处理器，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；以及利用所述UDP的不同端口号识别第一媒体源的每路数据流。
其中，第三处理器及第三通信接口的功能已在上文详述，这里不再赘述。
实施例三
在实施例一、二的基础上，本实施例详细描述多路数据流的传输过程。
从实施例一、二的描述可以看出，本公开实施例中，传输媒体源的多路数据流时，使用组播组(也就是组播IP地址，对应一个组播路由条目)来标识有相关性的多路数据流的媒体源，比如OTT里的直播频道、VR直播频道等，同时使用IP上承载的UDP的端口号来标识数据流，即采用不同的UDP端口号来区分一个媒体源的不同数据流。
所以，针对上述数据流的传输方法，实际应用时，可以采用图7所示的装置来实现组播组支持多路数据流的传输。
如图7所示，该装置包括：组播用户信息模块、组播组管理模块、组播组多路数据流接收/发送模块。
下面详细描述各模块的功能。
(1)组播用户信息模块
组播用户信息模块用来管理组播用户媒体源(比如OTT直播频道、VR直播频道等)，每个媒体源使用一个组播组，也就是对应使用一条组播路由条目，对应一个组播IP地址。同时，管理组播IP信息和相关的多路数据流使用的UDP端口信息；组播IP地址用于区分不同的媒体源，UDP端口信息用于区分同一组播组下的数据流，比如不同码率的流媒体等。
(2)组播组管理模块
组播组管理模块配置为CDN服务器节点或者终端与交换机之间的组播IGMP报文的交互处理，完成CDN服务器节点或者终端加入和离开组播组，以及响应交换机的组播定期查询报文等功能。
在windows和linux这些通用操作系统的协议栈中，如果主机要加入某个组播组，需要创建UDP socket，然后设置该UDP socket IP层的IP_ADD_MEMBERSHIP属性，这样主机才会向交换机发送基于IGMP的join或report报文，以完成加入组播组的动作；如果主机要退出某个组播组，需要再次设置该UDP socket IP层的IP_DROP_MEMBERSHIP属性，这样主机才会向交换机发送基于IGMP的leave报文，以完成离开组播组的动作。由此可见，windows和linux等通用操作系统对组播组的管理是依附于UDP socket的，而UDP socket必须指定组播IP地址和端口，才能完成组播组的加入和离开。对于本公开实施例来说，基于现有操作系统的流程，通过UDP socket实现接收多路组播码流，这本身就是一个比较大的限制，所以需要扩展组播组的管理方式。
所以组播组管理模基于组播组IP地址向交换机发送IGMP加入报文，请求加入组播组，以完成主机加入组播组的动作。同时，组播组管理模块还会接收交换机的IGMP查询报文，并上报当前组播组信息；定时向交换机发送IGMP报告报文，以通知交换机有具体的组播组存在。
从上面的描述可以看出，组播组的加入和离开，不再受限于UDP socket端口，而是直接使用组播组IP地址来完成与交换机之间的IGMP报文交互。这种方法是对现有驻留操作系统组播组管理应用的扩展。
(3)组播组多路数据流发送模块
该模块主要实现发送同一组播组的多路数据流。综合IP和UDP报文的结构，所述组播组多路数据流发送模块主要利用IP报文头的目的地址字段和UDP报文头的目的端口字段实现组播组多路数据流的发送。在IP报文头的目的地址指定为组播IP地址，在UDP报文头中，封装不同的目的端口，一个目的端口代表一路数据流。例如，在实际应用中，不同的端口表示不同码率的数据流。
(4)组播组多路数据流接收模块
组播组多路数据流接收模块，主要实现接收同一组播频道(媒体源)包含的多路数据流。具体地，组播组多路数据流接收模块通过系统钩子函数，接收裸数据报文，即报文IP报文头和UDP报文头，以及组播数据的完整报文。接着，组播组多路数据流接收模块先根据组播报文(IP报文头及UDP报文头)，解析出组播IP地址和表示不同数据流的端口信息；然后，根据组播用户信息模块中有关的组播IP和端口信息，即组播频道信息，分解出不同的数据流；最后，还可以对不同的流媒体做分发处理。
在windows和linux这些通用操作系统的协议栈中，如果要接收组播码流，创建UDP socket的时候，每个组播组只能支持捆绑一个UDP的端口，限制了一个UDP socket只能接收包含一对组播IP和端口的数据报文，限制了系统利用UDP socket接收组播多端口数据报文的能力。而在本公开实施例中，通过钩子函数直接接收裸数据报文，可以解决普通协议栈不能支持一个组播Socket不能支持多个UDP端口的问题。
基于上述装置，下面详细描述多路数据流的传输过程。
首先，如图8所示，描述从组播频道源设备到组播频道接入服务器(一般是CDN的中心节点)之间的组网示意图。结合图8可以看出，组播频道源设备将多路数据流发送至交换机，而组播频道接入服务器从交换机获得多路数据流。该过程具体包括：
步骤一：组播频道源设备(可以是编码器或者组播源频道生成服务器)的组播用户信息模块建立组播频道，组播组多路数据流发送模块(相当于实施例二中第一标识模块及第一发送单元的功能)发送组播的多路数据流。
这里，如果组播的多路数据流是多种码率，比如分别生成高清、标清和流畅三路码流时，那么组播组多路数据流发送模块使用一个组播IP地址来发送组播频道码流，并使用不同的UDP端口来区分发送不同码率的码流。
步骤二：组播频道接入服务器的组播用户信息模块建立对应的组播频道，管理组播频道的IP地址和频道相关的多路码流和UDP端口的对应关系。
步骤三：组播频道接入服务器的组播组管理模块向交换机发送IGMP报文以加入频道的组播组(相当于实施例二中第一加入单元的功能)，从而使节点准备接收组播源的多路数据流。
步骤四：组播频道接入服务器的组播组多路数据流接收模块(相当于实施例二第一接收单元、第一解析单元及第一识别单元的功能)接收交换机发来的组播码流。
具体地，组播组多路数据流接收模块接收组播源提供的所有组播数据流。
组播频道接入服务器的组播组多路数据流接收模块使用UDP端口号来区别不同的数据流，将接收的数据流送给组播用户信息模块做相应的业务处理，比如对频道处理后，向下级节点或者终端发送组播码流。
如图9所示，当组播频道接入服务器至终端之间还存在下级CDN节点，或者说，从组播频道源设备到终端之间存在至少两个CDN节点时，两个CDN节点之间的多路数据流的传输过程是：上级CDN节点将多路数据流发送至交换机，而下级CDN节点从交换机获得多路数据流。该过程具体包括：
步骤一：上级CDN节点(类似上述的组播频道接入服务器)的组播组多路数据流接收模块接收组播源的多路数据流，上级CDN节点的组播组多路数据流发送模块发送组播的多路数据流。
具体地，上级CDN节点的组播组多路数据流发送模块(相当于实施例 二中第二标识模块及第二发送单元的功能)使用一个组播IP地址来发送组播频道码流，并使用不同的UDP端口来区分发送不同的数据流。
步骤二：下级CDN节点的组播用户信息模块建立对应的组播频道，管理组播频道的IP地址和频道相关的多路码流和UDP端口的对应关系。
步骤三：下级CDN节点上的组播组管理模块向交换机发送IGMP报文以加入频道的组播组，从而使节点准备接收组播源的多路数据流。
步骤四：下级节点的组播组多路数据流接收模块接收交换机发来的组播码流。
具体地，下级CDN节点的组播组多路数据流接收模块接收的组播码流是上级CDN节点提供的所有组播数据流。
下级CDN节点的组播组多路数据流接收模块使用UDP端口号来区别不同的数据流，将接收的数据流送给下级CDN节点的组播用户信息模块做相应的业务处理，比如对频道处理后，向下级节点或者终端发送组播码流。
如图10所示，到达CDN节点后，组播组的多路数据流会传输给终端。CDN节点和终端之间的多路数据流的传输过程是：CDN节点将多路数据流发送至交换机，而终端从家庭网关获得多路数据流。下面以终端为OTT终端为例，来详细说明该传输过程。
在OTT业务里，OTT频道需要支持多码率，传统处理机制里，OTT终端(比如OTT机顶盒或者IPAD等)跟CDN节点之间一般都是走的单播，终端根据自身设备能力或者网络传输能力来决定获取哪种码率，使用超文本传输协议(HTTP)来获取单播码流。
而随着OTT频道直播的大量应用，组播在直播业务里存在着节省网络传输能力的优势，所以业界都在推广应用组播来实现OTT直播，因此采用本公开实施例的方案传输多码率的码流是非常有效的。
在OTT组播直播业务中，为了兼容终端(一般都是走HTTP单播的方式)，一般在终端上集成一个应用(APP)模块来处理组播，接收组播码流，而APP模块跟终端的播放模块之间仍然走HTTP模拟单播，所以可以理解为OTT终端内部模块间模拟单播直播。
这样的话，可以在终端的APP模块里集成图7所示的装置。
CDN节点至OTT终端之间多路数据流传输的过程，包括：
步骤一：边缘CDN节点的组播组多路数据流接收模块接收上级CDN节点的频道组播码流。
这里，在执行步骤一之前，边缘CDN节点已经按照图9所描述的方式加入组播组。
且边缘CDN节点的组播组多路数据流接收模块按照图9所描述的方式来区分不同码率的数据流。
步骤二：边缘CDN节点的组播组多路数据流发送模块向OTT终端发送组播码流。
这里，发送的组播码流可能有以下两种情况：
第一种情况是：边缘CDN节点跟OTT终端之间有足够的网络传输带宽，在这种情况下，边缘CDN节点的组播组多路数据流发送模块就可以将一个频道的所有码率的数据流都发送给OTT终端，使用一路组播IP地址来发送组播频道码流，使用不同的UDP端口来区分发送不同码率的码流。
第二种情况是：边缘CDN节点跟OTT终端之间的网络传输带宽有限，OTT终端分析自身情况和网络传输情况，确定需要的码率码流，并由APP使用控制信令来通知边缘CDN节点，那么边缘CDN节点就使用组播组将需要的码流发给OTT终端。在这种情况下，当需要进行码率切换时，不需要切换组播组，APP直接通知边缘CDN节点，边缘CDN节点直接使用原来的组播组，切换发送对应码率的码流即可。
下面描述第一种情况的处理过程。
步骤三：OTT终端APP里的组播用户信息模块建立对应的组播频道，管理组播频道的IP地址和频道相关的多路码流和UDP端口的对应关系。
步骤四：OTT终端APP里的组播组管理模块向家庭网关发送IGMP报文以加入频道的组播组(相当于实施例二中第二加入单元的功能)，从而使节点准备接收组播源的多路数据流。
步骤四：OTT终端APP里的组播组多路数据流接收模块(相当于实施 例二中第二接收单元、第二解析单元及第二识别单元的功能)接收家庭网关发来的组播码流。
具体地，OTT终端APP里的组播组多路数据流接收模块接收的组播码流是边缘CDN节点提供的所有组播数据流。
OTT终端APP里的组播组多路数据流接收模块使用UDP端口号来区别不同码率的码流。
步骤五：OTT终端APP里的组播组多路数据流接收模块将接收的码流发送给OTT终端APP里的组播用户信息模块，由OTT终端APP里的组播用户信息模块对码流作相关的业务处理，比如发送给相关的解码模块，进行解码播放处理。
也就是说，OTT终端APP里的组播组多路数据流接收模块通过OTT终端APP里的组播用户信息模块与终端的解码模块选择确定使用哪种码率的码流，并将把对应的码流发给解码模块。
另外，VR全景直播是目前的热门业务，组播技术在直播应用中有天然的优势，而全景直播中，存在不同角度的场景画面使用多路码流传输的情况，因此VR直播业务中也可以采用本公开实施例提供的方案。如图11所示，VR直播服务器(也可以是CDN节点)与VR终端之间的多路数据流的传输过程是：VR直播服务器将多路数据流发送至交换机，而终端从家庭网关获得多路数据流，该过程具体包括：
步骤一：VR组播服务器制作VR组播直播源，由VR组播服务器的组播组多路数据流发送模块发送VR直播组播码流。
这里，VR组播服务器的组播组多路数据流发送模块使用一路组播IP地址来发送VR组播频道码流，使用不同的UDP端口来区分发送不同角度的场景画面的码流。
步骤二：VR终端的组播用户信息模块建立对应的组播频道，管理组播频道的IP地址和频道相关的多路码流和UDP端口的对应关系。
步骤三：VR终端的组播组管理模块向家庭网关发送IGMP报文以加入VR频道的组播组，准备接收VR组播频道的组播码流。
步骤四：VR终端的组播组多路数据流接收模块接收家庭网关发来的组播码流。
具体地，组播组多路数据流接收模块接收VR组播服务器提供的VR频道的所有组播数据流。
VR终端的组播组多路数据流接收模块使用UDP端口号来区别不同角度场景的码流。
步骤五：VR终端的组播组多路数据流接收模块将接收的码流送给VR终端的组播用户信息模块做相应的业务处理，比如送给相关的解码模块做解码处理，实施VR播放。
从上面的描述中可以看出，本公开实施例的方案，传输媒体源的多路数据流时，使用组播组(也就是组播IP地址，对应一个组播路由条目)来标识有相关性的多路数据流的媒体源，比如OTT里的直播频道、VR直播频道等，同时使用IP上承载的UDP的端口号来标识数据流，实现了一个组播组传输多路数据流，从而节省了相关设备上组播组条目的占用数量。
具体来说，表现在以下几个方面：
1、采用本公开实施例提供的方案，能够解决同一路组播业务下多路组播数据流占用不同组播IP地址和UDP端口的限制，减少CDN节点组播UDP socket的使用，也就是说，减少了占用的组播IP地址和UDP端口的资源；
2、直接使用组播IP地址来完成与交换机之间的IGMP报文交互，不依赖主机的操作系统，不再受限于UDP socket端口，所以是对TCP/IP协议栈的一个很好的扩展，而且完全遵循IGMP。
3、接收多路数据流的具体实现是对协议栈一个很好的补充，支持了一路组播组可以接收多路组播流的问题。
4、由于采用组播IP地址来标识媒体源，而媒体源的多路数据流是用UDP的端口来区分的，这样，在传输多路数据流时可以减少服务器节点或者终端与交换机之间的IGMP报文交互。
本领域内的技术人员应明白，本公开的实施例可提供为方法、系统、 或计算机程序产品。因此，本公开可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
基于此，本发明实施例还提供了一种存储介质，具体为计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述源设备侧方法的步骤，或者实现上述中间设备侧方法的步骤，或者实现上述终端侧方法的步骤。
以上所述，仅为本公开的较佳实施例而已，并非用于限定本公开的保护范围。
工业实用性
本公开实施例提供的方案，针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出；接收数据流；解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流，也就是说，传输媒体源的多路数据流时，采用组播IP地址区分不同的媒体源，采用不同的UDP端口号来区分一个媒体源即同一组播组下的不同路数据流，如此，大大减少了占用的组播组资源。同时，基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出，完全遵循IGMP，可以和已有的网络具有很好地兼容性。

Claims (24)

  1. 一种数据流传输方法，包括：
    针对第一媒体源的至少两路数据流，利用用户数据报协议UDP的不同端口号标识每路数据流；
    基于所述第一媒体源的组播互联网协议IP地址，将标识后的第一媒体源的至少两路数据流发出。
  2. 根据权利要求1所述的方法，其中，利用UDP的端口号标识每路数据流，包括：
    在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
    所述基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出，包括：
    在IP报文头的目的地址添加所述第一媒体源对应的组播IP地址。
  3. 根据权利要求1所述的方法，其中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
  4. 一种数据流传输方法，包括：
    接收数据流；
    解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
    利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；
    针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
    基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
  5. 根据权利要求4所述的方法，其中，所述接收数据流，包括：
    利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文；
    相应地，针对每个报文，解析所述IP报文头，获得第一组播IP地址；
    解析所述UDP报文头，获得对应的一个UDP的端口号。
  6. 根据权利要求4所述的方法，其中，接收数据流之前，所述方法还包括：
    利用所述第一媒体源对应的第一组播IP地址，基于网际组管理协议IGMP加入所述第一媒体源的组播频道对应的组播组。
  7. 根据权利要求6所述的方法，其中，基于IGMP加入所述第一媒体源的组播频道对应的组播组，包括：
    利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；
    向交换机发送所述IGMP报文；所述IGMP报文用于请求加入所述第一媒体源的组播频道对应的组播组。
  8. 根据权利要求4所述的方法，其中，所述利用UDP的端口号标识每路数据流，包括：
    在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
    所述基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出，包括：
    在IP报文头的目的地址添加所述第一媒体源对应的第二组播IP地址。
  9. 根据权利要求4所述的方法，其中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
  10. 一种数据流传输方法，包括：
    接收数据流；
    解析数据流，获得组播IP地址及UDP的至少两个端口号；
    利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用 所述UDP的不同端口号识别第一媒体源的每路数据流。
  11. 根据权利要求10所述的方法，其中，所述接收数据流，包括：
    利用钩子函数，接收报文的IP报文头及UDP报文头、第一媒体源的至少两路数据流所形成的组播数据的完整报文；
    相应地，针对每个报文，解析所述IP报文头，获得组播IP地址；
    解析所述UDP报文头，获得对应的一个UDP的端口号。
  12. 根据权利要求10所述的方法，其中，接收数据流之前，所述方法还包括：
    利用所述第一媒体源对应的第一组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
  13. 根据权利要求12所述的方法，其中，基于IGMP加入所述第一媒体源的组播频道对应的组播组，包括：
    利用所述第一媒体源对应的第一组播IP地址，生成IGMP报文；
    向交换机发送所述IGMP报文；所述IGMP报文用于请求加入所述第一媒体源的组播频道对应的组播组。
  14. 根据权利要求10所述的方法，其中，所述第一媒体源的每路数据流的码率不同，或者，所述第一媒体源的每路数据流对应的场景画面的角度不同。
  15. 一种数据流传输装置，包括：
    第一标识模块，配置为针对第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
    第一发送单元，基于所述第一媒体源的IP地址，将标识后的第一媒体源的至少两路数据流发出。
  16. 根据权利要求15所述的装置，其中，所述第一标识模块，配置为在每路数据流的UDP报文头，封装一个目的端口号，所述至少两路数据流的目的端口号不同；
    所述第一发送单元，配置为在IP报文头的目的地址添加所述第一媒体 源对应的组播IP地址。
  17. 一种数据流传输装置，包括：
    第一接收单元，配置为接收数据流；
    第一解析单元，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；
    第一识别单元，配置为利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流；
    第二标识模块，配置为针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
    第二发送单元，配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
  18. 根据权利要求17所述的装置，其中，所述装置还包括：
    第一加入单元，配置为利用所述第一媒体源对应的第一组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
  19. 一种数据传输流装置，包括：
    第二接收单元，配置为接收数据流；
    第二解析单元，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；
    第二识别单元，配置为利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；利用所述UDP的不同端口号识别第一媒体源的每路数据流。
  20. 根据权利要求19所述的装置，其中，所述装置还包括：
    第二加入单元，配置为利用所述第一媒体源对应的组播IP地址，基于IGMP加入所述第一媒体源的组播频道对应的组播组。
  21. 一种源设备，包括：
    第一处理器，配置为针对第一媒体源的至少两路数据流，利用用户数 据报UDP的不同端口号标识每路数据流；
    第一通信接口，配置为基于所述第一媒体源的组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
  22. 一种中间设备，包括：
    第二通信接口，配置为接收数据流；
    第二处理器，配置为解析数据流，获得第一组播IP地址及UDP的至少两个端口号；利用所述第一组播IP地址确定接收的数据流为第一媒体源的数据流；利用UDP的不同端口号识别第一媒体源的每路数据流；以及针对接收的第一媒体源的至少两路数据流，利用UDP的不同端口号标识每路数据流；
    所述第二通信接口，还配置为基于所述第一媒体源的第二组播IP地址，将标识后的第一媒体源的至少两路数据流发出。
  23. 一种终端，包括：
    第三通信接口，配置为接收数据流；
    第三处理器，配置为解析数据流，获得组播IP地址及UDP的至少两个端口号；利用所述组播IP地址确定接收的数据流为第一媒体源的数据流；以及利用所述UDP的不同端口号识别第一媒体源的每路数据流。
  24. 一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至3任一项所述方法的步骤，或者实现权利要求4至9任一项所述方法的步骤，或者实现权利要求10至14任一项所述方法的步骤。
PCT/CN2017/118912 2016-12-30 2017-12-27 一种数据流传输方法、装置、相关设备及存储介质 WO2018121584A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611260794.0A CN108270731A (zh) 2016-12-30 2016-12-30 一种数据流传输方法、装置及相关设备
CN201611260794.0 2016-12-30

Publications (1)

Publication Number Publication Date
WO2018121584A1 true WO2018121584A1 (zh) 2018-07-05

Family

ID=62710273

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/118912 WO2018121584A1 (zh) 2016-12-30 2017-12-27 一种数据流传输方法、装置、相关设备及存储介质

Country Status (2)

Country Link
CN (1) CN108270731A (zh)
WO (1) WO2018121584A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113490162A (zh) * 2021-07-04 2021-10-08 芯河半导体科技(无锡)有限公司 一种组播数据流转发的优化方法
CN116033365A (zh) * 2023-03-22 2023-04-28 新华三技术有限公司 一种通信方法、装置、电子设备及存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110876070A (zh) * 2018-08-29 2020-03-10 中国电信股份有限公司 内容分发系统、处理方法以及存储介质
CN112491909B (zh) * 2020-12-01 2023-09-01 三六零数字安全科技集团有限公司 基于doh协议的流量标识方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1825944A (zh) * 2005-02-25 2006-08-30 华为技术有限公司 一种移动视频广播系统及移动视频广播方法
WO2008005815A2 (en) * 2006-06-30 2008-01-10 Scientific-Atlanta, Inc. Systems and methods of assembling an elementary stream from an encapsulated multimedia transport stream
CN101494763A (zh) * 2008-01-24 2009-07-29 华为技术有限公司 一种频道切换的方法、系统和设备
CN102265553A (zh) * 2008-12-22 2011-11-30 汤姆森特许公司 用于可靠组播数据流的方法和设备
WO2016180029A1 (zh) * 2015-05-12 2016-11-17 华为技术有限公司 直播媒体数据的方法、设备和系统

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101110814A (zh) * 2006-07-17 2008-01-23 中兴通讯股份有限公司 一种实现用户组播权限控制的方法
EP2028836A3 (en) * 2007-07-30 2010-07-14 LG Electronics Inc. A host device, a point of deployment (POD), and a method of identifying an operation mode
US20100165859A1 (en) * 2008-12-31 2010-07-01 Herve Marc Carruzzo Sorting flow records into analysis buckets
CN104346135B (zh) * 2013-08-08 2018-06-15 腾讯科技（深圳）有限公司 数据流并行处理的方法、设备及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1825944A (zh) * 2005-02-25 2006-08-30 华为技术有限公司 一种移动视频广播系统及移动视频广播方法
WO2008005815A2 (en) * 2006-06-30 2008-01-10 Scientific-Atlanta, Inc. Systems and methods of assembling an elementary stream from an encapsulated multimedia transport stream
CN101494763A (zh) * 2008-01-24 2009-07-29 华为技术有限公司 一种频道切换的方法、系统和设备
CN102265553A (zh) * 2008-12-22 2011-11-30 汤姆森特许公司 用于可靠组播数据流的方法和设备
WO2016180029A1 (zh) * 2015-05-12 2016-11-17 华为技术有限公司 直播媒体数据的方法、设备和系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113490162A (zh) * 2021-07-04 2021-10-08 芯河半导体科技(无锡)有限公司 一种组播数据流转发的优化方法
CN113490162B (zh) * 2021-07-04 2022-05-17 芯河半导体科技(无锡)有限公司 一种组播数据流转发的优化方法
CN116033365A (zh) * 2023-03-22 2023-04-28 新华三技术有限公司 一种通信方法、装置、电子设备及存储介质
CN116033365B (zh) * 2023-03-22 2023-06-20 新华三技术有限公司 一种通信方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN108270731A (zh) 2018-07-10

Similar Documents

Publication Publication Date Title
CN108737768B (zh) 一种基于监控系统的监控方法和监控装置
CN110049271B (zh) 一种视联网会议信息展示方法及装置
CN109168064B (zh) 一种电子数据的同步显示方法和系统
CN109474715B (zh) 一种基于视联网的资源配置方法和装置
CN109120879B (zh) 一种视频会议的处理方法和系统
CN109391551B (zh) 一种多端口组播方法、设备及计算机可读存储介质
CN109547731B (zh) 一种视频会议的展示方法和系统
WO2018121584A1 (zh) 一种数据流传输方法、装置、相关设备及存储介质
CN110650171B (zh) 一种视联网业务调度系统及方法
CN110266577B (zh) 一种隧道建立方法和视联网系统
CN110049268B (zh) 一种可视电话连接方法及装置
CN110149305B (zh) 一种基于视联网的多方播放音视频的方法和中转服务器
CN109768964B (zh) 音视频显示方法和装置
CN109451001B (zh) 一种通讯方法和系统
CN109005378B (zh) 一种视频会议的处理方法和系统
CN110022286B (zh) 点播多媒体节目的方法和装置
CN111787261B (zh) 一种音视频数据发送方法、装置、电子设备及存储介质
CN111245592B (zh) 信令传输方法、装置及计算机可读存储介质
CN110289974B (zh) 一种数据流的处理方法、系统及装置和存储介质
CN110740087B (zh) 报文传输方法、终端、网关设备、电子设备及存储介质
CN110062259B (zh) 视频获取方法、系统、设备和计算机可读存储介质
CN110446058B (zh) 视频获取方法、系统、设备和计算机可读存储介质
CN110149306B (zh) 一种媒体数据的处理方法及装置
CN110401807B (zh) 一种可视电话系统的通信方法及装置
CN110113563B (zh) 一种基于视联网的数据处理方法和视联网服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17886572

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17886572

Country of ref document: EP

Kind code of ref document: A1