医学英文论文的翻译方法

来源：医学论文发表——辑文编译

辑文编译小编告诉大家英文医学文献翻译除应透彻理解原文以外，还要考虑到医学本身的特点，即翻译时要正确选择词语，更要注意对一些常用句型如被动语态、各种从句以及长句和图像资料的处理。完全拘泥于原文的对号人座式的翻译是译不出高质量的译文的。那样译出的文章必然刻板、生硬，甚至文不从，意不顺。英文论文翻译要避免这些问题的出现，就要注意中文和英文之间的某些细微而又非常重要的差别，并掌握一些基本的翻译方法和技巧。

(一)透彻理解原文

这是翻译原文的前提。对原文理解得透彻与否，对表达原文的意思至关重要。翻译时，要把原文先看二三遍，做到:1.弄清原文的主题思想，明确原作者的写作目的。主题、目的明确了，才能从总体上把握译文，不会出现大的偏差，也才能使译文连贯通顺。2.弄清原文的文体风格。文体风格明确了，才能使译文的文体接近原文的文体，将原作者的风格再现。3.弄清原文的整体结构，由哪几部分组成，每部分主要表达什么意思以及各部分之间的关系如何。弄清了以上几点，再着手翻译，这样头脑里有了文章的全局和整体概念，以此来指导具体翻译，才有可能译出高质量的译文。

(二)正确选择词语

英译中词语的正确选择取决于对原文词义的确切理解，而对原文词义的确切理解又取决于对原文上下文的反复推敲。有些词看起来很简单，其实除了用在普通英语外，还有专业意义，如the first attack不是“首次攻击”，而是“初次发病”，又如a change of air不是“空气变化”，而是“转地治疗”。Influenza is an acute self-limited infection and is characterized by constitutional symptoms, although the infection is restricted to the respiratory tract普通词self-limited“自身限制的”，在这里要加以引伸，译为“定期自愈的”，此句可译为:流感是一种定期自愈的急性传染病，虽然传染只限于呼吸道，但其特征却是全身性症状。以上实例说明，只有正确选择词语，才能正确表达原文的内容。

(三)被动语态的翻译

英文医学文献常出现被动语态的句子，而中文较少采用被动语态，故多将被动语态译为主动语态，但在有些情况下，也可把英文的被动语态译为中文的被动语态。具体翻译时，可采用以下几种方法。

1.译为中文主动句

如果英文被动句的主语(即受动者)为无生命的东西，而施动者又不十分具体时，就宜直接译为中文主

动句，即把原文被动句中的主语保留下来，作为中文主动句中的主语，后面直接跟上谓语。

The incidence has been reduced to 0. 5 percent as compared with before.

和以前比较，发病率已降到千分之五。

2.译为中文被动句

如果动词表示的动作不利于受动者的场合，就可译为“被”字，以及“由、让、爱、给、遭、加以、为?所”等结构。

Fever may be brought on by infection.

发烧可由感染引起。

3.以形式主语为前导结构的译法

It has been shown that some bacteria under the right conditions may grow to full size and reproduce two new bacteria every twenty minutes, capable of destroying tissues or producing toxin. 已经证明某些细菌在适宜的条件下可以长得很大，而且每二十分钟能再繁殖为两个新菌体，能破坏组织或产生毒素。

(四)定语从句的翻译

英语定语从句分为限制性定语从句和非限制性定语从句两大类。一般都置于被修饰的名词或代词之后，但在翻译时，具体处理的方法并不完全相同。

1.限制性定语从句对所修饰的名词或代词起限制作用和明确作用，一般译为定语结构，置于被修饰词之前

All the poisons that are absorbed in any part of the body are sooner or later brought to the liver.

机体各部分所吸收的全部毒物迟早都会被带到肝脏。

2.非限制性定语从句对被修饰词起描述作用和补充作用，一般译为并列分句。

In any case, its activity is profoundly modified by various factors, which may be of either nervous or chemical origin.

无论如何，它的活动受到各种因素的强烈影响，这可能是神经因素，也可能是化学因素。

形式上的限制性定语从句，一般也译为并列分句。

Suppression of a portion of the microflora inevitably results in proliferation of other

organisms of which some may have pathogenic potentiality.

一部分细菌受到抑制势必导致其他细菌的增殖，其中有些可能具有致病的潜在能力。

(五)长句的处理

医学文献，出于叙事说理的需要，其中的长句很多，并且长句大多为并列句或复合句或并列复合句。在理解全句的前提下，经过化整为零步骤时，据此组成的各个主句、分句和从句大多可化为简单句。

Among all these, with the exception of water, sugar, fat and protein account for the greater part in quantity, and therefore, they are also called the three major nutritious substances. 这个长句是由第二个and连接2个并列分句，所以应该先译第一分句，而在第一个分句里有1个介词短语with the exception of water，主语是sugar, fat and protein，谓语则是account for,整个长句可译为;在这些营养物中，除水外，糖、脂肪及蛋白质所占份额较大，所以把它们叫做三大营养素。

(六)图像资料的处理

在翻译过程中，还要对原文中的图像资料进行适当的处理。原则是能删节的就把它去掉;确有较大参考价值的就将其“转化”为文字形式，或者编译成一个小的自然段，或者穿插到适当的字里行间中去。 除了上述介绍的一些翻译方法和技巧，当然还有许多办法都能处理好英文医学文献的翻译问题。但总的来说，由于中外文化的明显差异，英文医学文献的翻译是一个较为复杂的问题，需要我们通过学习建立起对汉英两种语言的转换意识，避免汉化英语和英化汉语，努力从实践中探寻出规律性的东西，从而全面提高翻译水平和译文质量。

第二篇：英文论文&翻译

LAN real-time video communication

【Abstract】：In this paper, to different local area network, a common real-time video transmission solutions is proposed.on base of Divx codec in use, Made from compressed, Framing, sent to the receiver, the idea of extracting the entire process Concrete implementation of programs and VC + + to achieve the core source code as well as the transmission control strategy. effectively ensure the high quality real-time video transmission.

【keywords】: Guest; Server ;Real-time video transmission; Divx

Introduction:

In-house real-time transmission of video local area network has been widely used. Now for the video transmission is the most wired LAN LAN, wired LAN because the technology is mature, fast speed, good stability. However, a large quantity of video data, cable networks will also be job insecurity, caused by blockage of data, over time will cause serious delay; if the working environment is not fixed, request mobility, then they would have used a wireless network, wireless network card is now work with the changes in the environment becomes unstable, so that video transmission will lead to a significant decline in the quality, easily lead to re-screen video, jitter, and so on.

In this paper, a different local area network, a common real-time video transmission solutions, the use of VC + + since the package of Windows VFW SDK software development kit for the secondary development, through the Divx codec, the transmission in accordance with the development of strategies to effectively solution as a result of network instability caused by the partial video image ghosting, jitter, etc. problems.

LAN real-time video transmission problems：

LAN in order to effective, high-quality transmission of video streams need to support a variety of technologies, including video compression, encoding technology, application-layer quality control techniques and so on.

Network bandwidth is limited, so it is necessary to transmit video image compression, MPEG-4 has been widely used in network environments in real-time video transmission, because the MPEG-4 with: You can achieve very high compression ratio; with flexible encoding and decoding complexity; Object-based encoding, allowing video, audio, interactive objects; has strong advantages such as fault tolerance. In this paper, Divx codec for video encoding, compression, in fact, Divx = (video) MPEG-4 + (audio) MP3.

Application-layer quality control techniques are now used by RTP / RTCP protocol to ensure that the video stream in the network with low latency, high-quality transmission. RTP data transfer protocol is responsible for streaming audio and video data and load, RTCP is responsible for the RTP data packet transmission control. This agreement was adopted by the client (receiver) feedback network status, server-side (sender) to adjust the information collection, transmission speed and compression

ratio. However, for a fixed rate of image acquisition, the need for software compression, decompression, adjust the speed of acquisition lead time compression of data collected directly discarded,

Encoder to adjust the compression ratio needs to set the encoder parameters and restart the encoder, the corresponding decoder to be adjusted, the process will take a long time, not real-time requirements. Therefore, this article did not use RTP / RTCP protocol, but starting from the sending end, real-time network conditions to determine, using "stop-and-wait" strategy in real-time transmission.

There are two types of network communications protocol TCP and UDP, UDP is more suitable for network video transmission environment, but it does not provide error detection and error correction features, as soon as network congestion, the large amount of data packet will be lost. The Divx codec technology, is a frame for the codec unit, divided into key frames and non-key frame. During transmission, due to relatively high compression ratio, as long as a bit of a wrong place, will have an impact on hundreds of even thousands of other bits, and a direct result of the fuzzy image, and so on. Only until the next key frame can be the restoration of the arrival of a clear image. In order to ensure the accuracy of transmission,

They need to develop an agreement in the application layer. In this way, UDP advantages no longer exist. Therefore, this article choose to use TCP for network communications. VFW integrated use of technology, streaming media technology, support to "stop, such as" control strategy, the better solution for real-time video transmission LAN easily lead to the ghosting, jitter problem.

To achieve real-time video transmission：

In order to achieve real-time video transmission, with a total of at least the idea is to send redundant information, the maximum extent possible to send the latest video. . LAN real-time video transmission using the server / client model, using VC + + to achieve. Its work processes as shown in Figure 1.

Figure 1 Real-time video transmission workflow

AVICap from the use of video capture video capture card to capture video images, the bitmap pattern of the video frame, and then use Divx encoder for compression, to achieve through the Winsock compressed video data in real-time network transmission, the receiving end of the data delivery Divx decoder to extract the final realization of video display.

In VC + +, using VFW technology, the client through capSetCallbackOnFrame () register a callback function, when the collection to an image acquisition card, the system will automatically call the callback function, and then use the callback function ICSeqCompressFrame () compression function. And then through the Winsock compressed data will be sent to the server-side. Server-side after receiving an End to the ICDecompress () extract, and finally with SetDIBitsToDevice () the image displayed.

1. video frame of the formation:

Video capture data is a bitmap type of video frame, Divx encoder after compression to form a frame for the stream Mpeg4 format. Divx codec format also extract frames. Therefore, to frame as a unit to send video data stream. The receiving end in order to be easily extracted from a proposed format as shown in Figure 2 to form the frame.

Figure 2 video frame format

Complete a field by five of the meaning of each field is as follows: frame the beginning of signs, marks the beginning of one to take up 4 bytes of space. May be set to 0xffffffff. Frame size that the size of the entire frame, including the size of five fields, occupied by four bytes of space. Frame number of sequentially numbered frames that take up 4 bytes of space. Frame type, mark whether or not this frame is the key frame, occupied by a byte of space. Frame data, stored in a compressed data integrity.

2.video frames sent:

Real-time video transmission in order to real-time, will be compressed to keep good data sent to the receiving end. Therefore, in the sending end to create a thread, designed to send data. At the same time keep the main thread is still collecting data and compression. Send-threaded workflow shown in figure 3.。

No

Figure 3 workflows to send thread

May wish to create a thread called the assumption sendThread, the core code is as follows:

while(1)

{

isOK=true; //ready

SuspendThread(sendThread); // Hang thread

isOK=false; // Thread is sending data

int length=frameLength; // Data set length

if(length<50000) {// Data to determine whether the normal

int n=0;

int sendCount=0;

while(length>0) {

n=send(sock,(char*)imageBuf+sendCount,length,0); //send message //imageBuf is Guidelines，Ready to frame

if(n==SOCKET_ERROR) // Network abnormal, then withdraw from the thread

break;

length-=n;

sendCount+=n;

}

}

}

Thread to send the data frame is based on a method in the formation of a good data frame. This approach can guarantee the current frame is being sent to reach the receiver intact.

Attention to the beginning of this thread, or when to send a finished, the thread to hang on, and wait for the outside world to wake up. This task is completed by the

callback function in the callback function to determine if the thread is ready to send (in a hung state), were carried out in image compression, and then wake up the thread after sending compressed data, or directly out of, wait for the next call the callback function, this strategy called "stop-and-wait" strategy is detailed in the back.

3.video frames to receive

The receiving end the most important thing is to accept the data stream from the extracted one complete. Methods of thought is: First of all, from the data stream to start looking for signs frame, and then next to the back of the data from the extracted frame size, and then read from the receive buffer to the remainder of the frame data. The next frame and then start looking for signs, and so back and forth.

The same receiver to create a thread dedicated to the implementation of data reception. May wish to assume that the thread called recThread, the core code is as follows: while(temp!=SOCKET_ERROR)

{

if(!isStart) {//if Frame data will start，true shows start

if(endNum>3) //Outstanding record of the current receive data

endNum=0;

temp=recv(clisock,(char*)(recBuf+endNum),1000,0);//Read data from the buffer zone

startPos=serchStr(temp+endNum); // Find a frame marked the beginning if(startPos!=-1) {

isStart=true;

endNum=temp+endNum-startPos-4;

memcpy(imageBuf,recBuf+startPos+4,endNum); // Preservation of data frame }

else{

memcpy(recBuf,recBuf+temp+endNum-3,3);// Save the last three bytes of data

endNum=3;

}

}

else{

if(endNum<4) {// Closely follow the signs to determine the beginning of the data, if that can not be less than 4 frame size

temp=recv(clisock,(char*)(recBuf),1000,0); // Read data

memcpy(imageBuf+endNum,recBuf,temp);//save data

endNum+=temp;

if(endNum<4)

continue;

frameSize= *((int*)imageBuf);// get the size of Frame

if(frameSize<500 || frameSize>50000) {// Exception Handling (frame size of the illicit)

isStart = false; // Discard the data frame to find the beginning of re-signs endNum = 0;

continue;

}

frameSize-=endNum+4;

}

else{

while(frameSize>0&&temp!=SOCKET_ERROR) {// Complete the remaining data frames

temp=recv(clisock,(char*)(imageBuf+endNum),frameSize,0);

endNum+=temp;

frameSize-=temp;

}

if(frameSize<=0) {// Purchase the end frame, and extract

isStart=false;

endNum=0;

deCompress();//To determine the validity of data, to extract the call ICDecompress

}

}

}

}

The results of the implementation of the above procedure is to complete one (other than the frame marks the beginning of) the preservation of the imageBuf.

4. "stop, such as" Control Strategy:

If a high rate of local area network communications, and job security, according to the method above, said real-time video transmission, without any control strategy, we can achieve very good results. However, in many cases, the network will be abnormal, so that data transfer rate will lead to significantly decreased, resulting in the sending end of data backlog, waiting to send the data can not be normal at this time will be made to take a certain degree of strategy to control the sending end, so as to achieve real-time requirements.

Send the above process, the variable is used to send isOK side made the current frame have finished, if made after the home for true, at the same time that the transmitter is ready to continue to send data, otherwise false. Then can be used to inform isOK video capture and compression thread, if isOK to true, you can capture video and compress, and then wake up to send the thread to continue to send new data frame, or else have been waiting until the network can continue to send data (isOK to true). Of course, the video capture has been kept, then when network congestion occurs when data,

Not as long as the encoder to compress can be resolved; when the network returned to normal when compression transmission continue, in other words, when

network congestion occurs, the direct discard the frame waiting to be sent to ensure that once the network restored, send the latest compressed frame . Of course, to ensure that once the beginning of a send, it is necessary to be fully issued.

In accordance with such a "stop-and-wait" strategy in real-time video transmission, will only lead to one question: When the poor quality of the network, the receiving end of a moving target screen will appear the phenomenon of instant mobile. However, this strategy will ensure that there will not ghosting, jitter, and so on.

Conclusion

In this paper, the real-time video transmission scheme in 100M LAN, 10M and 11M LAN Wireless LAN in the test. When testing a target in front of the cameras (the sending end) to move the receiver to observe the display of video. Local Area Network in different in a number of tests, each test time from 10 minutes to 30 minutes, and the movement to change the target rate of the experiment. Finally, data collection, statistical results obtained. Test results as shown in table 1.

Table 1 under different LAN test results

Note: 11M wireless card through the USB1.0 interface and PC-connected, if the effect will be better USB2.0 interface.

From the actual test results, the effect is good, apart from the emergence of mobile instant, the image will remain clear, the elimination of poor quality due to the network caused by ghosting, jitter and other phenomena, for different local area network to meet the requirements of real-time transmission .

局域网即时视频通讯

[摘要]本文针对不同的局域网，提出一种通用的实时视频传输的解决方案。在使用Divx编解码的基础上，提出了从压缩、组帧、发送到接收、解压整个流程的思想，具体实施方案和VC++实现核心源代码以及传输控制策略，有效地保证了高质量的实时视频传输。

[关键词] 客户/服务器；实时视频传输；Divx

引言

在局域网内部实时传输视频已经得到广泛应用。现在用以传输视频的局域网大多数是有线局域网，因为有线局域网技术成熟，传输速度快，稳定性好。但是视频数据量大，有线网络也会出现工作不稳定，引起数据堵塞，时间久了会导致严重的延迟现象；如果工作的环境不固定，要求移动性，那么就要采用无线网络，如今无线网卡的工作随环境的变化而变得不稳定，这样会导致视频传输的质量大幅度下降，容易引起画面的重影、抖动、花屏等现象。本文针对不同的局域网，提出一种通用的实时视频传输的解决方案，使用VC++自封装的Windows VFW SDK软件开发包进行二次开发，通过Divx编解码，按照制定的传输策略，能够有效地解决由于网络的局部不稳定导致的视频图像重影、抖动、花屏等的问题。

局域网中实时视频传输存在的问题

为了在局域网上有效的、高质量的传输视频流，需要多种技术的支持，包括视频的压缩、编码技术，应用层质量控制技术等等。

网络的带宽是有限的，所以需要压缩传输视频图像，MPEG-4被广泛的应用于网络环

境下的实时视频传输，因为MPEG-4具有：可以达到很高的压缩比；具有灵活的编码和解码复杂性；基于对象的编码方式，允许视频、音频对象的交互；具有很强的容错能力等优点。本文采用Divx编解码器对视频进行编码、压缩，实际上Divx=（视频）MPEG-4+（音频）MP3。

应用层质量控制技术现在采用的是RTP/RTCP协议，以确保视频流在网络中低时延、高质量地传输。RTP数据传输协议负责音视频数据的流化和负载，RTCP负责RTP数据报文的传输控制。此协议是通过客户端（接收方）反馈网络的状况，服务器端（发送方）来调整信息采集、发送的速度和压缩率。但是，对于图像采集速度固定，需要软件进行压缩、解压，调整采集的速度会引起采集的数据来不及压缩而直接丢弃，调整编码器的压缩率需要重新设置编码器的参数，重启编码器，相应的解码器也要调整，这个过程中需要很长的时间，达不到实时的要求。所以本文没有采用RTP/RTCP协议，而是从发送端出发，实时判断网络状况，采用“停等”策略进行实时传输。

网络通信有两种协议TCP和UDP，UDP更适合于网络环境下的视频传输，但是它不提供检错和纠错功能，一旦网络出现堵塞时，大量的数据报文会丢失。对于Divx编解码技术，是以帧为单位进行编解码的，分为关键帧和非关键帧。在传输过程中，由于压缩率比较高，只要一帧中错一比特位，将影响其它几百甚至几千的比特位，直接造成图像的模糊、花屏等现象。只有等到下一次关键帧的到来才有可能恢复图像的清晰。为了保证传输的正确性，自己需要在应用层制定协议。如此一来，UDP的优势荡然无存。所以本文选择使用TCP来进行网络通信。综合使用VFW技术、流媒体技术，辅助以“停等”控制策略，较好的解决局域网中实时视频传输容易引起的重影、抖动、花屏的问题。

实时视频传输实现

为了达到视频传输的实时性，总的思想是最少的发送冗余信息，最大程度上发送最新的视频。

局域网实时视频传输采用服务器/客户机模式，利用VC++实现。其工作流程如图1所示。

图1 实时视频传输工作流程

视频采集采用AVICap从视频采集卡捕获视频图像，得到的是位图型式的视频帧，然后用Divx编码器进行压缩，通过Winsock实现压缩后的视频数据在局域网中的实时传输，接收完的数据交给Divx解码器解压，最后实现视频显示。

在VC++中，采用VFW技术，客户端通过capSetCallbackOnFrame()注册回调函数，当采集卡采集到一幅图像后，系统就会自动调用回调函数，然后再回调函数中使用ICSeqCompressFrame()函数进行压缩。然后再通过Winsock将压缩后的数据发送到服务器端。服务器端接收完一帧以后，交给ICDecompress()解压，最后用SetDIBitsToDevice()

将图像显示出来。

1、视频帧的组建

视频采集的数据是位图型式的视频帧，Divx编码器压缩以后形成以帧为格式的Mpeg4流。Divx解码器也是以帧的格式解压。所以提出以帧为单位发送视频数据流。为了在接收端能够方便地提取出一帧，提出如图2所示的格式组建帧。

图2 视频帧格式

完整的一帧由5个字段组成，各个字段的意义如下：帧开始标志，标志着一帧地开始，占用4个字节的空间。不妨设为0xffffffff。帧大小，表示整个帧的大小，包括5个字段的大小，占用4个字节的空间。帧编号，表示帧的顺序编号，占用4个字节的空间。帧类型，标志此帧是否是关键帧，占用1个字节的空间。帧数据，存放压缩后一帧的完整数据。

2、视频帧的发送

实时视频传输为了实时，要不断地将压缩好的数据发送到接受端。所以在发送端创建一个线程，专门用来发送数据。同时主线程仍然不停的采集数据并进行压缩。发送线程的工作流程如图3所示。

图3 发送线程工作流程

可假设创建的线程名为sendThread，核心代码实现如下：

while(1)

{

isOK=true; //准备就绪

SuspendThread(sendThread); //挂起线程

isOK=false; //线程正在发送数据

int length=frameLength; //待发数据长度

if(length<50000) {//判断数据是否正常

int n=0;

int sendCount=0;

while(length>0) {

n=send(sock,(char*)imageBuf+sendCount,length,0); //发送数据， //imageBuf是指针，指向待发数据帧

if(n==SOCKET_ERROR) //网络出现异常，则退出线程

break;

length-=n;

sendCount+=n;

}

}

}

线程中发送的数据帧是按照上一节中的方法组建好的数据帧。这种方法能够保证正在发送的当前帧能够完整地到达接收端。

注意此线程中刚开始或者每当发送完一帧以后，线程就转到挂起状态，等待外界唤醒。这个任务由回调函数完成，在回调函数中，判定如果发送线程准备就绪（处于挂起状态），则进行图像压缩，然后唤醒线程发送压缩完的数据，否则直接跳出，等待下一次调用回调函数，这种策略称之为“停等”策略，在后面有详细介绍。

3、视频帧的接收

接收端最重要的是从接受的数据流中提取出完整的一帧。方法的思想是：首先从数据流中寻找帧开始标志，再从紧挨后面的数据中提取出帧的大小，然后再从接收缓冲区中读入该帧剩余的数据。再寻找下一帧的开始标志，如此往复。图4是接收端的工作流程。

同样接收端创建一个线程专门用来执行数据接收。不妨假设线程名为recThread，核心代码实现如下：

while(temp!=SOCKET_ERROR)

{

if(!isStart) {//帧数据是否开始，true表示开始

if(endNum>3) //endNum纪录当前接收未处理的数据

endNum=0;

temp=recv(clisock,(char*)(recBuf+endNum),1000,0);//从缓冲区读取数据

startPos=serchStr(temp+endNum); //查找帧开始标志

if(startPos!=-1) {

isStart=true;

endNum=temp+endNum-startPos-4;

memcpy(imageBuf,recBuf+startPos+4,endNum); //保存帧数据 }

else{

memcpy(recBuf,recBuf+temp+endNum-3,3);//保存最后三个字节的数据 endNum=3;

}

}

else{

if(endNum<4) {//判定紧跟开始标志的数据，如果小于4表示不能获得帧大小

temp=recv(clisock,(char*)(recBuf),1000,0); //读入数据 memcpy(imageBuf+endNum,recBuf,temp);//保存数据

endNum+=temp;

if(endNum<4)

continue;

frameSize= *((int*)imageBuf);//获得帧大小

if(frameSize<500 || frameSize>50000) {//异常处理（帧大小非法） isStart = false; //丢弃数据重新查找帧开始标志

endNum = 0;

continue;

}

frameSize-=endNum+4;

}

else{

while(frameSize>0&&temp!=SOCKET_ERROR) {//获得完整帧的剩余数据 temp=recv(clisock,(char*)(imageBuf+endNum),frameSize,0); endNum+=temp;

frameSize-=temp;

}

if(frameSize<=0) {//帧结束置位，解压

isStart=false;

endNum=0;

deCompress();//判断数据的有效性，调用ICDecompress进行解压 }

}

}

}

以上程序执行的结果是将完整的一帧（除帧开始标志）保存在imageBuf中。

4、“停等”控制策略

如果局域网通信速率很高，而且工作稳定，则按照以上说的方法进行实时视频传输，不需要任何控制策略，就可以达到非常好的效果。但是在很多情况下，网络会出现异常，这样会导致数据传输率明显下降，造成发送端数据积压，等待发送的数据不能正常发出去。此时就要采取一定的策略来控制发送端，以达到实时性的要求。

上文发送程序中，变量isOK是用来表示发送端当前帧有没有发完，如果发完则置为true，同时也表示发送端准备就绪，可以继续发送数据，否则为false。那么可以用isOK来通知视频采集和压缩线程，如果isOK为true，则可以采集视频并且压缩，然后唤醒发送线程继续发送新来的帧数据，否则一直等待，直到网络可以继续发送数据（isOK为true）。当然，视频采集一直不停的进行，那么当网络发生数据堵塞时，只要不让编码器进行压缩则可解决；当网络恢复正常时，继续进行压缩传输，换句话说，当网络发生堵塞时，直接抛弃等待发送的帧，保证一旦网络恢复时，发送最新的压缩帧。当然要保证一旦有一帧开始发送，就要将其完全发出。

按照这样的“停等”策略进行实时视频传输，只会带来一个问题：当网络质量差时，接收端画面中的移动目标会出现瞬间移动的现象。但是这种策略会保证不会出现重影，抖动，花屏等现象。

结论

本文提出的实时视频传输方案在100M的局域网、10M局域网和11M无线局域网中进行了测试。测试时让一个目标在镜头前（发送端）移动，观察接收端视频的显示。在不同的局域网中进行了多次测试，每次测试时间从10分钟到30分钟不等，并且改变目标的运动速度进行实验。最后将数据汇总，得出统计结果。测试结果如表1所示。

表1 不同局域网下的测试结果

注：11M无线网卡是通过USB1.0接口和PC机连接的，如果采用USB2.0接口效果会更好。

从实际测试的结果看，效果是良好的，除了出现瞬间移动外，图像能够保持清晰，消除了由于网络质量差而导致的重影、抖动等现象，对于不同的局域网都能满足实时传输的要求。