CN112073822B

CN112073822B - Media change method and system in broadband trunking communication

Info

Publication number: CN112073822B
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: 2022-10-18
Anticipated expiration: 2039-06-10
Also published as: CN112073822A

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 global public safety, government affairs, transportation, energy and other industries, the demand of industry users on broadband wireless data service and multimedia cluster scheduling is rapidly increased on the basis of traditional voice clusters, and the demand is extremely urgent. 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 a 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 such as 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) 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) media quantity change: such as a change from a voice call to a voice and video call. (3) media format change: such as changing the video format from h.264 to h.265. (4) 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 in the prior art. Sending end UE1 triggers media change and sends out change request; receiving end UE2 receives the change request, modifies the media stream receiving mode and modifies the decoder configuration; the transmitting end UE1 transmits 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, the 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 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.

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 attributes include 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: resolve 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

To make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further 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 only a framework is presented, in order to avoid unnecessarily obscuring aspects of the invention. Hereinafter, "comprising" means "including but not limited to", "according to '8230;' 8230;" means "according to at least '8230;' 8230;, but not limited to only according to '8230;' 8230;". 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 media change, 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, and the scope of the change includes: (1) changing a media transmission mode; (2) changing the number of media; (3) media format change; and (4) 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, 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.

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

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 header of the RTP stream to indicate that the media is changed.

The RTP protocol is used for real-time transmission of data. RTP the 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 formats (to specify 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 the media attribute of the RTP stream is changed, 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 coded pixel data of one frame and one frame of an original video. 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: profile _ idc: and identifying the profile of the current H.264 code stream. Three commonly used 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. 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. 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. Log2_ max _ frame _ num _ minus4: 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 _ minus4: 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: and the identification bit indicates whether discontinuous values are allowed in the frame _ num. (9) pic _ width _ in _ mbs _ minus1: for calculating the width of the image. (10) pic _ height _ in _ map _ units _ minus1: the height of a frame of picture in the video is measured using PicHeightInMapUnits. 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. 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 macroblock-level frame field adaptive coding is adopted or not. 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. 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. 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 stored separately in one NAL Unit in the bare stream of h.264, similar to SPS. 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 elements of PPS have the following meanings: (1) pic _ parameter _ set _ id: represents 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. 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 _ minus1: 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 way macroblocks in a frame are combined. (6) Num _ ref _ idx _ l0_ default _ active _ minus1 and num _ ref _ idx _ l0_ default _ active _ minus1: indicating that when num _ ref _ idx _ active _ override _ flag in Slice Header is 0, default values for syntax elements num _ ref _ idx _ l0_ active _ minus1 and num _ ref _ idx _ l1_ active _ minus1 of P/SP/B Slice. Weighted _ pred _ flag: and the identification bit indicates whether the weighted prediction is started in the P/SP slice. Weighted _ bipred _ idc: the method of weighted prediction in B Slice is shown. (9) pic _ init _ qp _ minus26 and pic _ init _ qs _ minus26: representing the initial quantization parameter. (10) chroma _ qp _ index _ offset: for calculating the quantization parameter for the chrominance components. Deblocking _ filter _ control _ present _ flag: and the identification bit is used for indicating whether the information used for controlling the deblocking filter exists in the Slice header. 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 bit is 0, it indicates that the I macroblock can use the 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.

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

In fig. 3, UE1 serves as a transmitting end; UE2 acts as the receiving end. Between UE1 and UE2, an RTP (Over RTP) based video stream 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: 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 YYY to indicate that the media has changed. The SPS included in the RTP video stream after the change carries the newly modified resolution.

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

Step 303: 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: and the UE2 re-resolves the PPS and the SPS in the RTP video stream until the PPS and the SPS are successfully resolved. Because the PPS and SPS are transmitted 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 resolution from the PPS and the SPS.

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

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

In fig. 4, UE1 serves as a transmitting end; UE2 acts as the receiving end. Between UE1 and UE2, an RTP (Over RTP) based video stream 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: 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 modified RTP video stream is sent from UE1 to UE2 via the core network, wherein the SSRC in the RTP packet header is modified to YYY.

Step 403: UE2 detects the change in SSRC and no longer the original XXX, and therefore assumes the media change and suspends the video decoding operation for the RTP video stream.

Step 404: UE2 re-parses PPS and SPS in the RTP video stream until PPS and SPS are successfully parsed. Since the PPS and SPS are transmitted 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 video frame rate after the change.

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

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

In fig. 5, UE1 acts as the transmitting end; UE2 acts as the receiving end. Between UE1 and UE2, an RTP (Over RTP) based video stream 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: UE1 triggers the modification of the video bitrate of the RTP video stream and modifies the SSRC of the RTP packet header from XXX to YYY 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 used by the video file in unit time, also called bitrate rate. 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 modified RTP video stream is sent from UE1 to UE2 via the core network, where the SSRC in the RTP packet header is modified to YYY.

Step 503: 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: and the UE2 re-resolves the PPS and the SPS in the RTP video stream until the PPS and the SPS are successfully resolved. Because the PPS and SPS are transmitted 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: UE2 configures the decoder based on the re-parsed PPS and SPS (including the changed video rate).

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

Based on the above description, the embodiment of the present invention further 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 attributes include 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 successfully again, and resume decoding for the RTP stream.

In one embodiment, the media attributes include 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.

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 implemented by 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 comprise 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.

Embodiments of the storage medium for supplying the program code include a floppy disk, a hard disk, a magneto-optical disk, an optical disk (e.g., CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD + RW), a magnetic tape, a nonvolatile memory card, and a ROM. 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:

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 packet header to indicate that the media is changed; wherein the receiving end successfully resolves the media parameters in the RTP stream in the transmission process;

when the receiving end detects that the SSRC of the RTP stream changes, the media is determined to be changed, the decoding aiming at the RTP stream is suspended, and after the media parameters in the RTP stream are analyzed again successfully, a decoder is configured based on the media parameters analyzed again successfully, and the decoding aiming at the RTP stream is recovered;

the RTP stream is a video media stream; the media parameters successfully parsed into the RTP stream again include: re-successfully parsing to the sequence parameter set SPS and the picture parameter set PPS in the RTP stream.

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

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.

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

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

4. The method of claim 1, wherein the media change in broadband group communication is performed by a user,

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.

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

a sending end, configured to change a media attribute of an RTP stream during a transmission process of the RTP stream, and modify a synchronization source identifier SSRC of an RTP packet header to indicate that a media is changed; wherein the receiving end successfully resolves the media parameters in the RTP stream in the transmission process;

a receiving end, configured to determine that a media is changed when the SSRC of the RTP stream is detected to be changed, suspend decoding for the RTP stream, and configure a decoder based on a media parameter that is successfully parsed again after the media parameter in the RTP stream is successfully parsed again, and resume decoding for the RTP stream; the RTP stream is a video media stream; the media parameters successfully parsed into the RTP stream again include: re-successfully parsing to the sequence parameter set SPS and the picture parameter set PPS in the RTP stream.

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

the media attribute comprises a video resolution;

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

the media attribute comprises a video frame rate;

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

the media attribute comprises a video bitrate;