CN112073822A

CN112073822A - Media change method and system in broadband trunking communication

Info

Publication number: CN112073822A
Application number: CN201910496443.7A
Authority: CN
Inventors: 汪远
Original assignee: Chengdu TD Tech Ltd
Current assignee: Chengdu TD Tech Ltd
Priority date: 2019-06-10
Filing date: 2019-06-10
Publication date: 2020-12-11
Anticipated expiration: 2039-06-10
Also published as: CN112073822B

Abstract

The embodiment of the invention provides a media change method and a media change system in broadband trunking communication. The method comprises the following steps: a sending end changes the media attribute of a real-time transport protocol (RTP) stream in the transmission process of the RTP stream and modifies a synchronous source identifier (SSRC) of an RTP header to indicate that the media is changed; when the receiving end detects that the SSRC changes, the decoding of the RTP stream is suspended, and after the media parameters in the RTP stream are re-analyzed, a decoder is configured based on the media parameters, and the decoding of the RTP stream is resumed. The embodiment of the invention can also ensure the reliability on the basis of improving the change efficiency.

Description

Media change method and system in broadband trunking communication

Technical Field

The present invention belongs to the technical field of Broadband Trunking Communication (B-TrunC), and in particular, to a media changing method and system in Broadband Trunking Communication.

Background

With the rise of intelligent terminals and mobile internet, wireless data services are growing explosively. With the rapid development of the industries such as global public safety, government affairs, traffic, energy and the like, the requirements of industry users on broadband wireless data service and multimedia cluster scheduling are rapidly increased and urgent on the basis of the traditional voice cluster. The LTE technology is used as a global 4G standard, has the advantages of high speed, high spectrum efficiency, low time delay and the like, is powerful in industrial strength, and becomes a common choice of a global wireless private network broadband technology. The evolution of broadband trunking technology based on LTE technology is also becoming a consensus for the development of wireless private networks worldwide. The standardization work of the B-Trunc system based on the LTE technology is firstly developed in China, and at present, broadband cluster products are widely deployed and applied in the industries of government affairs, public security, emergency, traffic, energy and the like.

The B-TrunC standard supports changing media during a call, the range of changes including: (1) and media transmission mode change: for example, the transmission mode of the voice media stream is changed from AMR over PDCP to AMR over RTP. (2) And changing the number of media: such as changing a voice call to a voice and video call. (3) And media format change: such as changing the video format from h.264 to h.265. (4) And media attribute change: such as the resolution of the video has changed. After the sending end changes the media, the receiving end needs to modify the way of receiving the media or modify the configuration of the media decoder.

Fig. 1 is a flow chart of a process of media change in broadband trunking communication according to the prior art. Wherein, the sending end UE1 triggers media change and sends out a change request; receiving end UE2 receives the change request, modifies the media stream receiving mode, and modifies the decoder configuration; the sender UE1 sends the changed media stream. The process shown in fig. 1 is a typical negotiation change process.

However, the process shown in fig. 1 is a general negotiation change process, but not all changes need to be performed. In fact, for some light weight changes, this process is heavy, resulting in inefficiency.

Disclosure of Invention

The embodiment of the invention provides a media change method and a media change system in broadband trunking communication.

The technical scheme of the embodiment of the invention is as follows:

a method of media change in broadband group communication, the method comprising:

a sending end changes the media attribute of a real-time transport protocol (RTP) stream in the transmission process of the RTP stream and modifies a synchronous source identifier (SSRC) of an RTP header to indicate that the media is changed;

when the receiving end detects that the SSRC changes, the decoding of the RTP stream is suspended, and after the media parameters in the RTP stream are re-analyzed, a decoder is configured based on the media parameters, and the decoding of the RTP stream is resumed.

In one embodiment, the parsing of the media parameters into the RTP stream includes: parsing into Sequence Parameter Set (SPS) and Picture Parameter Set (PPS).

In one embodiment, the media attributes include video resolution; the media parameters successfully parsed into the RTP stream again include: successfully resolving back to the video resolution contained in the SPS.

In one embodiment, the media attributes include a video frame rate; the media parameters successfully parsed into the RTP stream again include: successfully resolving to the video frame rate contained in the SPS again.

In one embodiment, the media attribute comprises a video bitrate; the media parameters successfully parsed into the RTP stream again include: successfully resolving to the video bitrate contained in the SPS again.

A system for media change in broadband group communication, comprising:

the sending end is used for changing the media attribute of the RTP stream in the transmission process of the RTP stream and modifying the SSRC of the RTP packet header to indicate that the media is changed;

and the receiving end is used for pausing the decoding of the RTP stream when the SSRC is detected to be changed, configuring a decoder based on the media parameters after the media parameters in the RTP stream are analyzed, and recovering the decoding of the RTP stream.

In one embodiment, the parsing of the media parameters into the RTP stream includes: resolving to SPS and PPS.

In one embodiment, the media attributes include video resolution;

and the receiving end is used for configuring a decoder based on the video resolution after the video resolution contained in the SPS is successfully analyzed again, and recovering decoding aiming at the RTP stream.

In one embodiment, the media attributes include a video frame rate;

and the receiving end is used for configuring a decoder based on the video frame rate and recovering decoding aiming at the RTP stream after the video frame rate contained in the SPS is successfully analyzed again.

In one embodiment, the media attribute comprises a video bitrate;

and the receiving end is used for configuring a decoder based on the video code rate after the video code rate contained in the SPS is successfully analyzed again, and recovering decoding aiming at the RTP stream.

As can be seen from the above technical solutions, in an embodiment of the present invention, a method includes: the sending end changes the media attribute of the RTP stream in the transmission process of the RTP stream and modifies the SSRC of the RTP packet header to indicate that the media is changed; when the receiving end detects that the SSRC changes, the decoding of the RTP stream is suspended, and after the media parameters in the RTP stream are re-analyzed, a decoder is configured based on the media parameters, and the decoding of the RTP stream is resumed. Therefore, the embodiment of the invention removes the negotiation process aiming at the media attribute changing scene, realizes self-adaptive change at the receiving end, and can ensure the reliability on the basis of improving the changing efficiency.

Drawings

Fig. 1 is a flow chart of a process of media change in broadband trunking communication according to the prior art.

Fig. 2 is a flow chart of a method for media change in broadband group communication according to the present invention.

Fig. 3 is a flowchart of a method for media change in broadband group communication according to a first embodiment of the present invention.

Fig. 4 is a flowchart of a method for media change in broadband group communication according to a second embodiment of the present invention.

Fig. 5 is a flowchart of a method for media change in broadband group communication according to a third embodiment of the present invention.

Fig. 6 is a system structure diagram of media change in broadband trunking communication according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail with reference to the accompanying drawings.

For simplicity and clarity of description, the invention will be described below by describing several representative embodiments. Numerous details of the embodiments are set forth to provide an understanding of the principles of the invention. It will be apparent, however, that the invention may be practiced without these specific details. Some embodiments are not described in detail, but rather are merely provided as frameworks, in order to avoid unnecessarily obscuring aspects of the invention. Hereinafter, "including" means "including but not limited to", "according to … …" means "at least according to … …, but not limited to … … only". In view of the language convention of chinese, the following description, when it does not specifically state the number of a component, means that the component may be one or more, or may be understood as at least one.

The applicant found that: in a scenario of lightweight change of media, the standard flow shown in fig. 1 may not be performed, and thus media change efficiency is improved.

As described above, the B-TrunC standard supports changing media during a call, the range of changes including: (1) changing a media transmission mode; (2) changing the number of media; (3) a media format change; (4) and changing the media attribute. After the sending end changes the media, the receiving end needs to modify the way of receiving the media or modify the configuration of the media decoder.

The applicant found that: for lightweight media attribute change, if the negotiation process can be removed and adaptive change is realized at the receiving end, the efficiency can be obviously improved.

To achieve this object, the applicant has also found that: besides video frame data, the RTP stream also includes a Sequence Parameter Set (SPS) and a Picture Parameter Set (PPS) that periodically describe attributes of the video frame data (where the attributes include information such as resolution), and a decoder can correctly decode the video data according to the attributes carried by the SPS and PPS. Therefore, under the condition that no packet is lost during transmission, no special processing is needed in the process for lightweight media attribute change, such as video resolution change, and the receiving end can realize self-adaptive decoding. However, in the case of packet loss, if SPS and PPS information is lost, the decoder at the receiving end decodes the video data with an incorrect configuration, which may cause errors.

Based on the analysis, the embodiment of the invention can ensure the reliability on the basis of improving the efficiency.

As shown in fig. 2, the method includes:

step 201: the sending end changes the media attribute of the RTP stream during the transmission process of the RTP stream, and modifies a Synchronization source identifier (SSRC) of the RTP packet header to indicate that the media is changed.

The RTP protocol is used for real-time transmission of data. The RTP protocol provides information including: the information provided by the timestamp (for synchronization), sequence number (for packet loss and reordering detection), and payload format (for encoding format to account for data) protocols includes: time stamps (for synchronization), sequence numbers (for packet loss and reordering detection), and payload format (for specifying the coding format of the data). The SSRC is the source stream of RTP packets, represented in the RTP header by a 32-bit long synchronization source identifier, independent of the network address. This field is used to identify the synchronization source of the signal, and its value should be chosen randomly to ensure that the SSRC identifications of any two synchronization sources in the RTP session are not the same.

In the RTP stream transmission process before changing the media attribute of the RTP stream, the receiving end has successfully analyzed the media parameter in the RTP stream, and has obtained the original SSRC of the video stream.

When the sending end changes the media property of the RTP stream in the transmission process of the RTP stream, the media parameter in the RTP stream is correspondingly changed. Also, the SSRC of the RTP packet header is further modified at the transmitting end to indicate that the media is changed.

Preferably, the changing the media attribute of the RTP stream includes: changing the resolution of the video; changing the video frame rate; changing the video code rate; and so on.

Step 202: when the receiving end detects that the SSRC changes, the decoding of the RTP stream is suspended, and after the media parameters in the RTP stream are re-analyzed, a decoder is configured based on the media parameters, and the decoding of the RTP stream is resumed.

When the receiving end detects that the SSRC of the RTP stream is different from the original SSRC, that is, the SSRC is detected to be changed, the media is determined to be changed, the video decoding for the RTP stream is suspended (that is, the video data is not analyzed), until the media parameters are successfully re-analyzed (for the video, until the PPS and SPS are successfully analyzed), the decoder is configured based on the media parameters, and the video decoding for the RTP stream is resumed (that is, the video data is decoded).

Since the PPS and SPS are transmitted periodically, even if the first PPS and SPS after the change are lost, the PPS and SPS can always be resolved. Before the successful PPS and SPS are analyzed, the receiving end does not decode the video data, so that errors can be avoided.

In one embodiment, the RTP stream is a video media stream; parsing the media parameters into the RTP stream includes: resolving to SPS and PPS.

Specifically, a set of global parameters of a Coded video sequence (Coded video sequence) is stored in the SPS. The coded video sequence is a sequence formed by a structure of one frame of original video after pixel data of one frame is coded. The parameters on which the encoded data for each frame depends are stored in an image parameter set. The nalunitt of the SPS is usually located at the start of the whole codestream. In order for the parameters contained in the SPS to be available for subsequent decoding processes, the data therein needs to be parsed.

The syntax element meaning of the part of the SPS is as follows: (1) profile _ idc: and identifying the profile of the current H.264 code stream. Three commonly used profile profiles are defined in h.264: reference grade: baseline profile; the main grade is as follows: main profile; expanding the grade: extended profile; in the SPS of h.264, the first byte represents profile _ idc, and which level the code stream conforms to can be determined according to the value of profile _ idc. (2) Level _ idc: and identifying the Level of the current code stream. The coded Level defines parameters such as the maximum video resolution, the maximum video frame rate and the like under certain conditions, and the Level followed by the code stream is specified by Level _ idc. (3) Seq _ parameter _ set _ id: id representing the current sequence parameter set. With this id value, the picture parameter set pps may refer to the parameters in the SPS that it represents. (4) Log2_ max _ frame _ num _ minus 4: for calculating the value of MaxFrameNum. MaxFrameNum is an upper limit value of frame _ num, which is a representation of picture sequence number, and is commonly used as a reference frame marker in inter-frame coding. (5) Pic _ order _ cnt _ type: indicating a method of decoding POC. POC is another way of measuring picture order number, and there is a different calculation method from frame _ num. (6) Log2_ max _ pic _ order _ cnt _ lsb _ minus 4: the value used to calculate MaxPicOrderCntLsb, which represents the upper limit of POC. (7) Max _ num _ ref _ frames: for indicating the maximum number of reference frames. (8) Gaps _ in _ frame _ num _ value _ allowed _ flag: a flag indicating whether or not discontinuous values are allowed in frame _ num. (9) Pic _ width _ in _ mbs _ minus 1: for calculating the width of the image. (10) Pic _ height _ in _ map _ units _ minus 1: PicHeightInMapUnits are used to measure the height of a frame of image in a video. PicHeightInMapUnits is not an explicit height of a picture in pixels or macroblocks, but rather takes into account whether the macroblock is frame-coded or field-coded. (11) Frame _ mbs _ only _ flag: and the identification bit is used for explaining the coding mode of the macro block. When the flag is 0, the macroblock may be frame-coded or field-coded; when the flag is 1, all macroblocks are coded by frames. The PicHeightInMapUnits have different meanings according to different values of the identification bits. (12) Mb _ adaptive _ frame _ field _ flag: and the identification bit is used for indicating whether the macroblock-level frame field adaptive coding is adopted. When the flag bit is 0, there is no switching between frame coding and field coding; when the flag is 1, the macroblock may select between frame coding and field coding modes. (13) Direct — 8x8_ inference _ flag: and the identification bit is used for the derivation calculation of the motion vector in the B _ Skip and B _ Direct modes. (14) Frame _ cropping _ flag: and the identification bit is used for indicating whether the output image frame needs to be cut or not. (15) Vui _ parameters _ present _ flag: and the identification bit indicates whether the VUI information exists in the SPS.

In addition to SPS, another important parameter set in h.264 is PPS. In general, PPS is similar to SPS and is stored separately in a NAL Unit in the h.264 bare stream. The NAL _ Unit _ type value of the PPS NAL Unit is 8. In the encapsulated format, the PPS is typically saved in the header of the video file along with the SPS. The PPS corresponds to a certain picture or several pictures in a sequence, and parameters such as identifier pic _ parameter _ set _ id, optional seq _ parameter _ set _ id, entropy coding mode selection flag, slice group number, initial quantization parameter, deblocking filter coefficient adjustment flag, and the like.

The partial syntax element meaning of PPS is as follows: (1) pic _ parameter _ set _ id: denotes the id of the current PPS. A certain PPS is referred by a corresponding Slice in the code stream, and the way that the Slice refers to the PPS is to store the id value of the PPS in a Slice header. (2) Seq _ parameter _ set _ id: denotes the id of the activated SPS referenced by the current PPS. (3) Entropy _ coding _ mode _ flag: and the entropy coding mode identification indicates the algorithm selected by entropy coding/decoding in the code stream. (4) Bottom _ field _ pic _ order _ in _ frame _ present _ flag: a flag bit indicating the presence or absence of two syntax elements delta _ pic _ order _ cnt _ bottom and delta _ pic _ order _ cn in the additional slice header. (5) Num _ slice _ groups _ minus 1: indicating the number of slice groups in a frame. When the value is 0, all slices in a frame belong to a slice group. slice group is the combination of macroblocks in a frame. (6) Num _ ref _ idx _ l0_ default _ active _ minus1 and num _ ref _ idx _ l0_ default _ active _ minus 1: denotes default values of syntax elements num _ ref _ idx _ l0_ active _ minus1 and num _ ref _ idx _ l1_ active _ minus1 of the P/SP/B Slice when num _ ref _ idx _ active _ override _ flag in Slice Header is 0. (7) Weighted _ pred _ flag: and the identification bit indicates whether the weighted prediction is started in the P/SP slice. (8) Weighted _ bipred _ idc: a method of weighted prediction in B Slice is shown. (9) Pic _ init _ qp _ minus26 and pic _ init _ qs _ minus 26: representing the initial quantization parameter. (10) Chroma _ qp _ index _ offset: for calculating the quantization parameter for the chrominance component. (11) Deblocking _ filter _ control _ present _ flag: and an identification bit for indicating whether information for controlling the deblocking filter exists in the Slice header. (12) Constrained _ intra _ pred _ flag: if the identifier is 1, the II macro block can only use the information from the II and SISI macro blocks when the intra-frame prediction is carried out; if the flag is 0, it indicates that the I macroblock can use information from the Inter type macroblock. (13) Redundant _ pic _ cnt _ present _ flag: and the identification bit is used for indicating whether a redundant _ pic _ cnt syntax element exists in the Slice header.

In one embodiment, the media attributes include video resolution; the media parameters that are successfully parsed back into the RTP stream include: the resolution to the video resolution contained in the SPS is re-successfully resolved.

In one embodiment, the media attributes include a video frame rate; the media parameters that are successfully parsed back into the RTP stream include: the resolution to the video frame rate contained in the SPS is resumed successfully.

In one embodiment, the media attributes include video bitrate; the media parameters that are successfully parsed back into the RTP stream include: and successfully resolving the video code rate contained in the SPS again.

In fig. 3, UE1 acts as the sender; the UE2 acts as the receiving end. Between UE1 and UE2, a video stream based on rtp (over rtp) is established via the core network. During the RTP video stream transmission process, the receiving end has successfully parsed the media parameters in the RTP video stream and has obtained the original SSRC of the video stream, which is assumed to be XXX. Thereafter, the following steps are performed to implement the media change.

Step 301: the UE1 triggers a modification of the media resolution of the RTP video stream and modifies the SSRC of the RTP packet header from XXX to yyyy to indicate that the media has changed. The SPS included in the modified RTP video stream carries the newly modified resolution.

Step 302: the altered RTP video stream is sent from UE1 to UE2 via the core network, where the SSRC of the RTP packet header is modified to YYY.

Step 303: the UE2 detects that the SSRC has changed and is no longer the original XXX, and therefore assumes that the media has changed, pausing the video decoding operation for the RTP video stream.

Step 304: the UE2 re-parses the PPS and SPS in the RTP video stream until the PPS and SPS are successfully parsed. Because the PPS and SPS are sent periodically, even if the first PPS and SPS after the change is lost, the UE2 can always resolve the PPS and SPS successfully. Thus, the UE2 may obtain the changed video resolution from the PPS and SPS.

Step 305: the UE2 configures the decoder based on the re-parsed PPS and SPS (including the altered video resolution).

Step 306: the UE2 resumes the video decoding operation for the RTP video stream.

In fig. 4, UE1 acts as the sender; the UE2 acts as the receiving end. Between UE1 and UE2, a video stream based on rtp (over rtp) is established via the core network. During the RTP video stream transmission process, the receiving end has successfully parsed the media parameters in the RTP video stream and has obtained the original SSRC of the video stream, which is assumed to be XXX. Thereafter, the following steps are performed to implement the media change.

Step 401: the UE1 triggers a modification of the video frame rate of the RTP video stream and modifies the SSRC of the RTP packet header from XXX to yyyy to indicate that the media has changed. The SPS included in the RTP video stream after the change carries the newly modified video frame rate.

Step 402: the altered RTP video stream is sent from UE1 to UE2 via the core network, where the SSRC of the RTP packet header is modified to YYY.

Step 403: the UE2 detects that the SSRC has changed and is no longer the original XXX, and therefore assumes that the media has changed, pausing the video decoding operation for the RTP video stream.

Step 404: the UE2 re-parses the PPS and SPS in the RTP video stream until the PPS and SPS are successfully parsed. Because the PPS and SPS are sent periodically, even if the first PPS and SPS after the change is lost, the UE2 can always resolve the PPS and SPS successfully. Therefore, the UE2 can acquire the changed video frame rate.

Step 405: the UE2 configures the decoder based on the re-parsed PPS and SPS (including the changed video frame rate).

Step 406: the UE2 resumes the video decoding operation for the RTP video stream.

In fig. 5, UE1 acts as the sender; the UE2 acts as the receiving end. Between UE1 and UE2, a video stream based on rtp (over rtp) is established via the core network. During the RTP video stream transmission process, the receiving end has successfully parsed the media parameters in the RTP video stream and has obtained the original SSRC of the video stream, which is assumed to be XXX. Thereafter, the following steps are performed to implement the media change.

Step 501: the UE1 triggers a modification of the video rate of the RTP video stream and modifies the SSRC of the RTP packet header from XXX to yyyy to indicate that the media has changed. The SPS included in the RTP video stream after the change carries the newly modified video bitrate. The video bitrate refers to the data traffic, also called bitrate, used by the video file in a unit time. The larger the code rate is, the larger the sampling rate in unit time is, the higher the data stream precision is, thus the effect is shown as follows: the video picture is clearer and the image quality is higher.

Step 502: the altered RTP video stream is sent from UE1 to UE2 via the core network, where the SSRC of the RTP packet header is modified to YYY.

Step 503: the UE2 detects that the SSRC has changed and is no longer the original XXX, and therefore assumes that the media has changed, pausing the video decoding operation for the RTP video stream.

Step 504: the UE2 re-parses the PPS and SPS in the RTP video stream until the PPS and SPS are successfully parsed. Because the PPS and SPS are sent periodically, even if the first PPS and SPS after the change is lost, the UE2 can always resolve the PPS and SPS successfully. Therefore, the UE2 can acquire the changed video bitrate.

Step 505: the UE2 configures the decoder based on the re-parsed PPS and SPS (including the changed video rate).

Step 506: the UE2 resumes the video decoding operation for the RTP video stream.

Based on the above description, the embodiment of the present invention also provides a system for media change in broadband trunking communication.

As shown in fig. 6, the system includes a transmitting end 601 and a receiving end 602, and a core network has been arranged between the transmitting end 601 and the receiving end 602. Wherein:

a sending end 601, configured to change a media attribute of an RTP stream during a transmission process of the RTP stream, and modify an SSRC of an RTP packet header to indicate that a media is changed;

a receiving end 602, configured to, when detecting that the SSRC changes, suspend decoding for the RTP stream, and after parsing the media parameters in the RTP stream, configure a decoder based on the media parameters, and resume decoding for the RTP stream.

In one embodiment, the media attributes include video resolution;

and a receiving end 602, configured to configure a decoder based on the video resolution and resume decoding for the RTP stream after successfully parsing to the video resolution included in the SPS again.

In one embodiment, the media attribute comprises a video bitrate;

and a receiving end 602, configured to configure a decoder based on the video bitrate after the video bitrate included in the SPS is resolved again successfully, and resume decoding of the RTP stream.

In one embodiment, the media attributes include video bitrate;

The invention also provides a video group calling device in the broadband trunking communication with the processor-memory architecture. The video group calling device in the broadband trunking communication comprises a processor and a memory; the memory has stored therein an application executable by the processor for causing the processor to perform the method of media alteration in broadband group communication as described above.

The memory may be embodied as various storage media such as an Electrically Erasable Programmable Read Only Memory (EEPROM), a Flash memory (Flash memory), and a Programmable Read Only Memory (PROM). The processor may be implemented to include one or more central processors or one or more field programmable gate arrays, wherein the field programmable gate arrays integrate one or more central processor cores. In particular, the central processor or central processor core may be implemented as a CPU or MCU.

In summary, in the embodiment of the present invention, the method includes: the sending end changes the media attribute of the RTP stream in the transmission process of the RTP stream and modifies the SSRC of the RTP packet header to indicate that the media is changed; when the receiving end detects that the SSRC changes, the decoding of the RTP stream is suspended, and after the media parameters in the RTP stream are re-analyzed, a decoder is configured based on the media parameters, and the decoding of the RTP stream is resumed. The embodiment of the invention can also ensure the reliability on the basis of improving the change efficiency.

It should be noted that not all steps and modules in the above flows and structures are necessary, and some steps or modules may be omitted according to actual needs. The execution order of the steps is not fixed and can be adjusted as required. The division of each module is only for convenience of describing adopted functional division, and in actual implementation, one module may be divided into multiple modules, and the functions of multiple modules may also be implemented by the same module, and these modules may be located in the same device or in different devices.

The hardware modules in the various embodiments may be implemented mechanically or electronically. For example, a hardware module may include a specially designed permanent circuit or logic device (e.g., a special purpose processor such as an FPGA or ASIC) for performing specific operations. A hardware module may also include programmable logic devices or circuits (e.g., including a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The implementation of the hardware module in a mechanical manner, or in a dedicated permanent circuit, or in a temporarily configured circuit (e.g., configured by software), may be determined based on cost and time considerations.

The present invention also provides a machine-readable storage medium storing instructions for causing a machine to perform a method as described herein. Specifically, a system or an apparatus equipped with a storage medium on which a software program code that realizes the functions of any of the embodiments described above is stored may be provided, and a computer (or a CPU or MPU) of the system or the apparatus is caused to read out and execute the program code stored in the storage medium. Further, part or all of the actual operations may be performed by an operating system or the like operating on the computer by instructions based on the program code. The functions of any of the above-described embodiments may also be implemented by writing the program code read out from the storage medium to a memory provided in an expansion board inserted into the computer or to a memory provided in an expansion unit connected to the computer, and then causing a CPU or the like mounted on the expansion board or the expansion unit to perform part or all of the actual operations based on the instructions of the program code.

Examples of the storage medium for supplying the program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g., CD-ROMs, CD-R, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs, DVD + RWs), magnetic tapes, nonvolatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer via a communications network.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method for media change in broadband group communication, the method comprising:

the method comprises the steps that a sending end changes the media attribute of an RTP stream in the transmission process of the RTP stream, and modifies a synchronous source identifier (SSRC) of an RTP header to indicate that media is changed;

2. The method of claim 1, wherein the RTP stream is a video media stream; the parsing of the media parameters into the RTP stream includes: to the sequence parameter set SPS and the picture parameter set PPS.

3. The method of media change in broadband group communication according to claim 2,

the media attribute comprises a video resolution; the media parameters successfully parsed into the RTP stream again include: successfully resolving back to the video resolution contained in the SPS.

4. The method of media change in broadband group communication according to claim 2,

the media attribute comprises a video frame rate; the media parameters successfully parsed into the RTP stream again include: successfully resolving to the video frame rate contained in the SPS again.

5. The method of media change in broadband group communication according to claim 2,

the media attribute comprises a video bitrate; the media parameters successfully parsed into the RTP stream again include: successfully resolving to the video bitrate contained in the SPS again.

6. A system for media change in broadband group communication, comprising:

the sending end is used for changing the media attribute of the RTP stream in the transmission process of the RTP stream and modifying a synchronous source identifier SSRC of the RTP packet header to indicate that the media is changed;

7. Media change system in broadband group communication according to claim 6,

the RTP stream is a video media stream; the parsing of the media parameters into the RTP stream includes: to the sequence parameter set SPS and the picture parameter set PPS.

8. Media change system in broadband group communication according to claim 6,

the media attribute comprises a video resolution;

9. Media change system in broadband group communication according to claim 6,

the media attribute comprises a video frame rate;

10. Media change system in broadband group communication according to claim 6,

the media attribute comprises a video bitrate;