CN102625079B - Video implementation method for trilateral video conference - Google Patents
Video implementation method for trilateral video conference Download PDFInfo
- Publication number
- CN102625079B CN102625079B CN201210075934.2A CN201210075934A CN102625079B CN 102625079 B CN102625079 B CN 102625079B CN 201210075934 A CN201210075934 A CN 201210075934A CN 102625079 B CN102625079 B CN 102625079B
- Authority
- CN
- China
- Prior art keywords
- video
- data
- hosting
- rtp
- screen
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
Links
Landscapes
- Telephonic Communication Services (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
The invention discloses a video implementation method for a trilateral video conference. A conducting party captures and codes a trilateral video combined on a screen of the conducting party by utilizing display resources of the screen, and transmits the coded trilateral video to conference participants, and screen capture data transmitted by the conducting party is displayed on screens of the conference participants respectively. Therefore, resource occupation for the mixing of video data is avoided, video resource consumption can be controlled, and three parties of the conference can be audible and visible for one another in a low-cost hardware running environment.
Description
Technical field
The present invention relates to a kind of video implementation method of 3 side video conference.
Background technology
Support that the equipment of tripartite talks function is more at present on the market, but great majority are voice conference device, and video conference device often price is higher, mainly due to major part, to realize 3 side video conference function algorithm higher to hardware requirement for this, thus holistic cost is promoted.
Tradition tripartite talks equipment is substantially all pass to other two sides after adopting hosting side to receive all the other two side data mixing RTP data to realize, and wherein the implementation method of audio & video is each different, realizes type analysis below for these two kinds:
1, the implementation method of conventional audio meeting:
As shown in Figure 1, A and C side reality does not directly transmit data, but by hosting side B as terminal, second party is passed to after third-party data being mixed with the data of B side self, therefore, the process of the side of hosting B is particularly important, but due to the process of voice data comparatively simple, therefore, only need many establishments two threads to carry out mixing to data in principle can meet the demands.Tripartite's audio conferencing calling steps for hosting side B is:
(1) side of hosting B creates for A, C two Socket of RTP receiving port of side, and carries out monitorings wait;
(2) sound that hosting side B sends self is sampled;
(3) side of hosting B receives the RTP voice data that A side transmits, and releases after decoding in loud speaker, and after being mixed with B side's own voice by decoded voice data, is packaged as RTP Packet Generation to the RTP receiving port of C side during negotiation network parameter;
(4) side of the hosting B that (walks abreast with step (3)) receives the RTP voice data that C side transmits, release in loud speaker after decoding, and by after the mixing of decoded voice data and hosting side B self, be packaged as RTP Packet Generation to the RTP receiving port of A side when consulting network parameter;
(5) like this, the sound that A side hears is just the sound of B/C two side mixing, and the sound that B side hears is then the sound of A/C both sides' mixing, and the sound that C side hears is the sound of A/B both sides' mixing, thus forms tripartite's audio conferencing.
2, the implementation method of conventional video meeting:
In video conference situation, if do not consider hardware cost, adopt the scheme of as above audio conferencing also can realize, and the effect that participant sees another participant and hosting side can be reached, but owing to using the program higher to hardware requirement, and current most video telephone does not all reach this requirement, therefore, phone on the market substantially all moves back and asks its it, as long as tripartite can both hear the sound of all the other two sides, as long as and participant can see the video of hosting side, as long as wherein either party video also can be checked by hosting side simultaneously.
Taking resource in 3 side video conference at most also complicated is blended data, therefore, as shown in Figure 2, the side of hosting B eliminates the process of mixed video data, and be distinguishing for the process of A/C two number formulary certificate, mainly due to for video calling, the CPU received shared by data is less relative to decoded data, therefore, saving resource the most effectively reduces decoding, so eliminate the decoding of C number formulary certificate that non-present activates, only retain key frame with facilitate follow-up again check time decoding normal.Therefore, cpu resource now takies as CPU summation shared by tripartite's audio conferencing+single channel pure video calling+single channel RTP data receiver, the basic resource loss just taking audio mix compared with single channel voice and video telephone more.
3 side video conference calling steps for hosting side B following (audio-frequency unit process is see the implementation method of audio conferencing above):
(1) side of hosting B creates for A, C two Socket of side RTP receiving port, and carries out monitorings wait;
(2) video image of hosting side B self is sampled, and be packaged as RTP packet, to send to when consulting network parameter A, C two RTP receiving port of side respectively;
(3) suppose that hosting side B arranges the main video that A side's video is current display, then the side of hosting B receives the RTP data that A side transmits, and shows user can be viewed after decoding on the FrameBuffer of display screen;
(4) (parallel with step (3)) B side receives the RTP data that C side transmits, but do not decode, just store key frame I frame data, to carry out switching main video be carry out decoding compensation behind C side for follow-up, occurs mosaic phenomenon when avoiding just showing;
(5) if it is C side that the side of hosting B now arranges main video, then the side of hosting B utilizes communication control processor (SIP or custom protocol) to ask C side to retransmit I frame, thus upgrades up-to-date video image, and by A, C two side's data processing method exchange.
Though scheme above solves the problem of inadequate resource, but still there is following problem:
A, side's participant cannot view the video information of another participant, lose the most important principle of tripartite talks: tripartite can listen mutually visible;
B, hosting side can only view a certain participant video simultaneously, and if desired check that the video of another participant will switch, user operation comparatively bothers.
Summary of the invention
The object of the present invention is to provide one can control video resource loss, under the hardware running environment of low cost, meeting three can listen mutually the video implementation method of visible 3 side video conference simultaneously.
The video implementation method of a kind of video tripartite talks of the present invention, specifically comprises the steps:
Step 1, the side of hosting B create the Socket for the RTP receiving port of Liang Ge conferenced party A, C, and carry out monitoring wait;
The video image of self is sampled by step 2, the side of hosting B, and the video of display B side, the viewing area of corresponding B side on the screen of hosting side B;
Step 3, the side of hosting B receive the RTP data that conferenced party A transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party A shows the video of A side;
Step 4, (walking abreast with the step 3) side of hosting B receive the RTP data that conferenced party C transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party C shows the video of C side;
Step 5, the side of hosting B intercept the associating viewing area that self screen is made up of the viewing area of A, B, C tripartite, are packaged as RTP packet, and it are sent to respectively the RTP receiving port consulting network parameter Shi Liangge conferenced party A, C;
Step 6, this two conferenced party A, C show from after the screenshotss RTP data decode of hosting side B on respective screen.
Transmitting-receiving bag is separated with the treatment step of encoding and decoding by the present invention further:
After the side of hosting B has created Socket in above-mentioned steps 1, create separate threads T1 for receiving the RTP packet from A or C side, and it is left in respectively in two different public queues, and the data of public queue are added access lock before reception, by the release of access lock after finishing receiving, this access lock is used for conducting interviews synchronous with decoding thread below;
Another independent decoding thread T2 is by the data in above-mentioned two public queues of timing acquisition, after all data in two public queues are taken out, the multiple packets relating to whole two field picture are decoded simultaneously, like this before fetching data at every turn by judging the quantity of packet overstock in now public queue, as exceeded threshold value, the non-key frame of centre is removed and is directly decoded I frame by the thread T2 that then decodes after this situation occurs, also need before taking out decoding the data of public queue to be added access lock, by the release of access lock after having decoded;
Decode thread T2 before fetching data by judging the quantity of the packet overstock in now public queue at every turn in decode procedure, if exceed threshold value, then this decoding thread T2 directly sends RTP packet rate control command by RTCP signaling to data receiver, and request slows down the transmission rate of RTP packet;
Cataloged procedure is also with above-mentioned step process.
The present invention utilizes the display resource of screen, conferenced party is sent to by carrying out coding after the tripartite's video intercepting combined on hosting side's screen, the respective screen of conferenced party shows screenshotss data respectively that send this hosting side, eliminates the resource occupation of mixed video data like this.
Accompanying drawing explanation
Fig. 1 is the principle schematic of conventional audio meeting implementation;
Fig. 2 is the principle schematic of conventional video meeting implementation;
Fig. 3 is schematic flow sheet of the present invention;
Fig. 4 is the principle schematic that the present invention improves further;
Fig. 5 is the principle schematic of video conference implementation of the present invention;
Below in conjunction with the drawings and specific embodiments, the present invention is further described.
Embodiment
As shown in Fig. 3,5, the video implementation method of a kind of video tripartite talks of the present invention, specifically comprises the steps:
Step 1, the side of hosting B create the Socket for the RTP receiving port of Liang Ge conferenced party A, C, and carry out monitoring wait;
The video image of self is sampled by step 2, the side of hosting B, and the video of display B side, the viewing area of corresponding B side on the screen of hosting side B;
Step 3, the side of hosting B receive the RTP data that conferenced party A transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party A shows the video of A side;
Step 4, (walking abreast with the step 3) side of hosting B receive the RTP data that conferenced party C transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party C shows the video of C side;
Step 5, the side of hosting B intercept the associating viewing area (can be rectangle as shown in Figure 3) that self screen is made up of the viewing area of A, B, C tripartite, and be packaged as RTP packet, send to the RTP receiving port consulting network parameter Shi Liangge conferenced party A, C respectively;
Step 6, this two conferenced party A, C show from after the screenshotss RTP data decode of hosting side B on respective screen.
The implementation method of a kind of video tripartite talks of the present invention, hosting side utilizes screen display resource, conferenced party is sent to after being encoded by the tripartite's video intercepting combined, remove the resource occupation of mixed video data like this from, as shown in Figure 3, taking as can be seen from this cpu resource calculates above, although the present invention meets the requirement that tripartite can check mutually the other side's video, but resource occupation now still has more a road video calling decoding than other phones, and for video calling, the decoding of video is also higher to resource requirement, especially under H264-Codec, and H264 has become the first-selected Codec of video calling at present substantially, therefore, require further improvement, resources occupation rate is declined again.
As shown in Figure 3, B cpu resource now in the side of hosting takies: tripartite's audio conferencing+two-way pure video calling decoding+screenshotss+single channel Video coding+basic network receives and dispatches bag summation.Take upper from cpu resource of the present invention, because screenshotss own resources take lower, when realizing, usage data cache way reaches optimal case substantially simultaneously, therefore emphasis is still in the utilization of decode resources, and solve the most direct method of this problem yes and improve decoding algorithm, but due to the algorithm that currently used decoding algorithm has been comparatively ripe, if amendment algorithm simultaneously, then may bring more compatibility issue, therefore, consider from another point of view, break-through point is placed on resource occupation when reducing decoding, and encode and Internet Transmission because the operation now carried out for a long time only has, and the amendment of coding and codec class are seemingly, so consider from the resource occupation of Internet Transmission.
Secondly first, can not network transmission speed be reduced, also can not remove the transmission of network packet, but consideration can be taken from what avoid Internet Transmission peak value.Because network transmission is before bound with encoding and decoding with reception, namely in same thread process, therefore, the speed of decoding is caused can be subject to receiving and dispatching the impact of bag.
As shown in Figure 4, transmitting-receiving bag is separated with the treatment step of encoding and decoding by the present invention further:
After the side of hosting B has created Socket in described step 1, create separate threads T1 for receiving the RTP packet from A or C side, and it is left in respectively in two different public queues, and the data of public queue are added access lock before reception, by the release of access lock after finishing receiving, this access lock is used for conducting interviews synchronous with decoding thread below;
Another independent decoding thread T2 is by the data in above-mentioned two public queues of timing acquisition, after all data in two public queues are taken out, multiple packet (i.e. whole two field picture, about being generally 6 packets) decode simultaneously, like this before fetching data at every turn by judge in now public queue overstock data volume, as more than 20 packets, the non-key frame (i.e. non-I frame) of centre is removed and is directly decoded I frame by thread of then decoding after this situation occurs, avoid because packet too much causes this locality frequently to unpack, thus CPU takies too high phenomenon, also need before taking out decoding the data of public queue to be added access lock, by the release of access lock after having decoded.
Decode thread T2 before fetching data by judging the data volume overstock in now public queue at every turn in decode procedure, as more than 30 packets, then this thread directly sends RTP packet rate control command by RTCP signaling to data receiver, request slows down the transmission rate of RTP packet, avoids out of buffers.
Cataloged procedure is similar process also.
Like this, the mode jointly can decoded by multiple data is avoided originally being received and decoded serial by same thread, data are caused to overstock, thus frequently get bag wait, take the problem that cpu resource is higher, also can be carried out the speed of request msg transmit leg RTP Packet Generation by decoding thread according to the amount of current overstocked data, thus overall transfer bandwidth can be controlled.
The above, it is only present pre-ferred embodiments, not technical scope of the present invention is imposed any restrictions, thus every above embodiment is done according to technical spirit of the present invention any trickle amendment, equivalent variations and modification, all still belong in the scope of technical solution of the present invention.
Claims (2)
1. a video implementation method for video tripartite talks, is characterized in that comprising the steps:
Step 1, the side of hosting B create the Socket socket for the RTP receiving port of Liang Ge conferenced party A, C, and carry out monitoring wait;
The video image of self is sampled by step 2, the side of hosting B, and the video of display B side, the viewing area of corresponding B side on the screen of hosting side B;
Step 3, the side of hosting B receive the RTP data that conferenced party A transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party A shows the video of A side;
Step 4, the side of hosting B receive the RTP data that conferenced party C transmits, and after decoding, on the screen of hosting side B, the viewing area of corresponding conferenced party C shows the video of C side, and this step walks abreast with step 3;
Step 5, the side of hosting B intercept the associating viewing area that self screen is made up of the viewing area of A, B, C tripartite, are packaged as RTP packet, and it are sent to respectively the RTP receiving port consulting network parameter Shi Liangge conferenced party A, C;
Step 6, this two conferenced party A, C show from after the screenshotss RTP data decode of hosting side B on respective screen.
2. the video implementation method of a kind of video tripartite talks according to claim 1, is characterized in that being separated with the treatment step of encoding and decoding by transmitting-receiving bag further:
After the side of hosting B has created Socket socket in above-mentioned steps 1, create separate threads T1 for receiving the RTP packet from A or C side, and the RTP packet received is left in respectively in two different public queues, and the data of public queue are added access lock before reception, by the release of access lock after finishing receiving, this access lock is used for carrying out synchronous with separate threads T2 to the data access of public queue;
Another separate threads T2 is by the data in above-mentioned two public queues of timing acquisition, after all data in two public queues are taken out, the multiple packets relating to whole two field picture are decoded simultaneously, like this before fetching data at every turn by judging the quantity of packet overstock in now public queue, as exceeded threshold value, then the non-key frame of centre is removed and is directly decoded I frame by separate threads T2, also need before taking out data decode the data of public queue to be added access lock, by the release of access lock after having decoded;
In decode procedure separate threads T2 before fetching data at every turn by judging the quantity of packet overstock in now public queue, if exceed threshold value, then this separate threads T2 directly sends RTP data package transmission velocity control command by RTCP signaling to data receiver, and request slows down the transmission rate of RTP packet.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210075934.2A CN102625079B (en) | 2012-03-21 | 2012-03-21 | Video implementation method for trilateral video conference |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210075934.2A CN102625079B (en) | 2012-03-21 | 2012-03-21 | Video implementation method for trilateral video conference |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN102625079A CN102625079A (en) | 2012-08-01 |
| CN102625079B true CN102625079B (en) | 2015-01-14 |
Family
ID=46564742
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210075934.2A Active CN102625079B (en) | 2012-03-21 | 2012-03-21 | Video implementation method for trilateral video conference |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN102625079B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104349120A (en) * | 2013-07-26 | 2015-02-11 | 北京计算机技术及应用研究所 | Audio and video decoding system and decoding method thereof |
| CN105095123A (en) * | 2014-05-19 | 2015-11-25 | 联想(北京)有限公司 | Data processing method and electronic device |
| CN108234432B (en) * | 2016-12-22 | 2021-02-26 | 展讯通信（上海）有限公司 | Media implementation method and device for multi-channel terminal, multi-channel terminal and media server |
| CN108965932B (en) * | 2017-05-17 | 2021-05-28 | 武汉斗鱼网络科技有限公司 | Continuous wheat window display method and device |
| CN108419125A (en) * | 2018-03-08 | 2018-08-17 | 弘成科技发展有限公司 | The long-range control method of multimedia classroom mobile terminal |
| CN108804067A (en) * | 2018-06-14 | 2018-11-13 | 上海掌门科技有限公司 | Method for information display, equipment and computer-readable medium |
| CN108924471A (en) * | 2018-09-13 | 2018-11-30 | 福建星网智慧科技股份有限公司 | A kind of conference system based on QSV fast video encoding and decoding |
| CN109474661B (en) * | 2018-09-25 | 2021-05-14 | 视联动力信息技术股份有限公司 | Method and system for processing network request event |
| CN109698929A (en) * | 2018-11-30 | 2019-04-30 | 视联动力信息技术股份有限公司 | A kind of screenshot method and device of view networking meeting |
| CN109669658A (en) * | 2018-12-29 | 2019-04-23 | 联想(北京)有限公司 | A kind of display methods, device and display system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101018316A (en) * | 2007-02-27 | 2007-08-15 | 深圳创维－Rgb电子有限公司 | Video conference system based on IPTV and its implementation method |
| CN101031065A (en) * | 2007-04-27 | 2007-09-05 | 华为技术有限公司 | Method, apparatus and system for switching pictures in video service |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101309390B (en) * | 2007-05-17 | 2012-05-23 | 华为技术有限公司 | Visual communication system, apparatus and subtitle displaying method |
-
2012
- 2012-03-21 CN CN201210075934.2A patent/CN102625079B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101018316A (en) * | 2007-02-27 | 2007-08-15 | 深圳创维－Rgb电子有限公司 | Video conference system based on IPTV and its implementation method |
| CN101031065A (en) * | 2007-04-27 | 2007-09-05 | 华为技术有限公司 | Method, apparatus and system for switching pictures in video service |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102625079A (en) | 2012-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102625079B (en) | Video implementation method for trilateral video conference | |
| CN101778181B (en) | Method and system for mobile terminal to achieve three-part call of videophone | |
| ES2719529T3 (en) | Processing procedure and control device, automatic call distribution device and agent terminal | |
| CN112422879B (en) | Method and device for dynamically adjusting media capability | |
| CN202918417U (en) | Video conversation system based on Android set top box | |
| CN104980683A (en) | Implement method and device for video telephone conference | |
| WO2013113281A1 (en) | Multimedia data transmission method, device and system | |
| CN107592429B (en) | Multi-seat multimedia scheduling system | |
| CN201127081Y (en) | System for implementing multimedia contents share | |
| CN103856809A (en) | Method, system and terminal equipment for multipoint at the same screen | |
| CN102710778A (en) | Collaboration wireless display system and working method thereof | |
| CN103139202A (en) | Thin client, communication method and device thereof | |
| CN100454821C (en) | Method for resource sharing among MCUs in videoconference system | |
| CN201813477U (en) | Handheld terminal capable of realizing three dimensional (3D) video call by using two cameras | |
| WO2014204180A1 (en) | Method and apparatus for rate adaptation in motion picture experts group media transport | |
| CN103957391A (en) | Method and system for displaying videos of all parties at same time during multi-party call in video intercom | |
| US8649487B2 (en) | Video implementation method for three-party video conference | |
| CN101150464A (en) | Method and system for sharing multimedia content | |
| CN108366044A (en) | A kind of VoIP remote audio-videos sharing method | |
| CN110460801A (en) | The method and device of data forwarding between a kind of media server | |
| CN102438119B (en) | Audio/video communication system of digital television | |
| CN104349108B (en) | Communication means, system and radio phone terminal based on radio phone terminal | |
| CN101815073A (en) | Embedded Bluetooth-Ethernet server | |
| CN101610380A (en) | Dialing and answering method and device of video telephone, video telephone | |
| US20110228038A1 (en) | Method and apparatus for realizing a video phone |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C53 | Correction of patent for invention or patent application | ||
| CB02 | Change of applicant information |
Address after: 361009, Xiamen Software Park, Fujian, two, expecting channel 63, unit 402-502 Applicant after: Xiamen Yealink Network Technology Co., Ltd. Address before: 361009, Xiamen Software Park, Fujian, two, expecting channel 63, unit 402 Applicant before: Xiamen Yilian Network Technology Co., Ltd. |
|
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |