基于UDP协议的网络摄像头的关键问题解决及调试过程

最新推荐文章于 2024-08-23 08:45:43 发布

浩爹

最新推荐文章于 2024-08-23 08:45:43 发布

阅读量2.7k

点赞数

分类专栏：编程语言之C++ RGB格式数据文章标签：摄像头视频图片压缩 c#

编程语言之C++ 同时被 2 个专栏收录

18 篇文章 0 订阅

订阅专栏

RGB格式数据

6 篇文章 0 订阅

订阅专栏

一、摘要

　　该篇博文主要对“基于UDP协议的网络摄像头的设计与实现”调试过程遇到的问题进行说明，并阐述其解决过程。

二、实验平台

硬件平台：DIY_DE2

软件平台：Quartus II 9.0 + Nios II 9.0 + Visual Studio 2008

三、实验内容

　　以VGA显示作为参照，综合调试，使C#端的视频显示正常。C#端的控件显示分辨率为320*240。

1、初始图像

图1 初始图片

上图是初步搭建完成的网络摄像头的显示效果，观察视频图像，其具有以下特点：

（1）有一半的色彩未完全显示；

（2）显示的部分呈斜体状，有锯齿；

（3）显示的部分分辨率降低为160*120，同（1）；

（4）显示的图像的起始位置并非一帧图像的开始，即图像错位。

2、解决图像错位的问题

　　解决过程大致如下：

（1）首先，保证Quartus II端不变的情况下，在NIOS II端不读取缓存在SRAM中的视频数据，而是直接对待传输的数组赋一个定值，则C#端应显示一个单色图像。NIOS II的代码如下，C#端的显示效果如图2所示。

NIOS II端测试代码：

    for(j = 0;j < 76800;j++)

    {

        //a[j] = IORD(SRAM_16BIT_512K_0_BASE,j);

        //b[j] = IORD(SRAM_16BIT_512K_0_BASE,j) >> 8;

        a[j] = 0xff;

        b[j] = 0x03;

     }

图2 C#端显示单色图像1

上述图像能够验证UDP传输正确和C#端的显示程序正确。

（2）其次，保证NIOS II正常传输的基础上，即不做刚才的改动，在Quartus II端压缩子程序press_moudle模块中，直接设定特定数据，观察C#端显示效果，效果如图3所示。

图3 C#端显示单色图像2

这张图像与图1很相似，即有一半的色彩未正确显示（因为是单色图片，其他的特征不容易看出来）。根据图2和图3的对比，可以得知：图像数据在读写SRAM时出了问题。到底是读SRAM还是写SRAM的问题？

（3）再次，在NIOS II端，往SRAM里面写特定数据，之后再读取出来，最后通过网络传输给PC，PC端用C#显示，通过这个测试，可以发现NIOS II端读SRAM没有问题，因此，问题便可以确定为写SRAM。

（4）图像错位的问题可以定位为：开始往SRAM写图像数据时，当前数据并非一帧图像的开始，即写图像数据的条件不正确。为了能够正确的锁存住帧开始信号，采用状态机功能，关键代码如下：

always@(posedge iclk or negedge rst_n)
begin
    if(!rst_n)
        test_out <= 0;
    else
    begin
        if((niosii_cmd) && (oVAL_VS == 2'b01))
        begin
            test_out <= ~test_out;
//            if(test_out)
//                rgb_zuhe <= rgb_zuhe + 1;
        end
//        else
//            test_out <= 0;
    end
end
always@(posedge iclk or negedge rst_n)
begin
    if(!rst_n)
    begin
//        oaddress <= 0;
        rd_en <= 0;
        rgb_zuhe <= 0;
    end
    else
    begin
        case(test_out)
        0:
        begin
            oaddress <= 0;
            rd_en <= 0;
            rgb_zuhe <= 0;
        end
        1:
        begin
            if(VGA_X_count[0] && VGA_Y_count[0] && oVAL_HS)
            begin
//                rgb_zuhe <= (rgb_zuhe + 1)%32;
                rgb_zuhe <= {1'b0,iR[9:5],iG[9:5],iB[9:5]};
                oaddress <= oaddress + 2;
                if(oaddress == 18'h257fe)
                begin
                    rd_en <= 1;
                    oaddress <= 0;
                end
            end
            else
                rd_en <= 0;
        end
        endcase
    end
end

　　因为test_out的反转，这里其实是隔一帧采一帧的结果。

　　采用状态机之后，图像错位的现象便得到解决，显示效果如图4所示。

图4 解决图像错位的显示效果

3、解决显示部分分辨率降低的问题

　　在Quartus II端的压缩子程序press_moudle中，设定图像数据为+1递增的数据，在网络抓包工具wireshark，收到的数据可以看出，数据是呈+2的形式递增的，因此可以断定，存储的时候出现了问题。

刚开始，以为SRAM存储的时候是隔一个地址存储一个数据，后分析一下，实则不然。因为在NIOS II读取缓存在SRAM中的数据的时候，是挨个地址读取的，而读出来的数据确实呈+2的关系，说明：实际写入SRAM的时候还是挨个地址写的，只是写控制器端问题。

后查阅相关资料，16位数据的存储器对应CPU时，地址线应左移一位，在系统的顶层文件中，并没有将地址线左移，因此，造成了分辨率又一次的降低了1/4，解决办法为，往SRAM存储数据时，地址线每次+2即可（在第2步代码中已有所体现）。显示效果如图5所示。

图5 调试完成分辨率降低问题的效果

4、解决图像偏斜的问题

（1）开始一直以为C#端绘图部分的问题，经C#端写buffer数据显示，并认真分析显示效果后，确定绘图没有问题。下面是分析过程。采用单色递增进行分析。

C#端写buffer测试代码：

            for (int m = 0; m < num; m++)

            {

               if (m % 2 == 0)

                    buffer[m] = 0;

                else

                    buffer[m] = (byte)(((m - 1) * 2) % 128);

            }

　　通过C#端调试，可以得知num=1468，即734个像素，按照320*240分辨率来算，一包数据可以绘制2行94个像素点，截取细节图（图5的左上部分），如图6所示。

图6 C#端测试细节图

由图形可以看出，第一包数据刚好绘制了2行94个像素点，且3行的起始部分均正确对应，即均从纯黑色开始，说明造成图像倾斜的不是C#的问题。

（2）NIOS II测试，同样采用单色递增的方式进行验证，同样分析前2行94个像素点及以后的像素点，发现第95和96个像素点为非纯黑色，而第97个像素点才开始为纯黑色。这说明95和96像素点为其他的值，并非预期的像素值。

（3）仔细分析，发现最后2个像素点，即4个字节为一包数据的校验位。NIOS II端发送一包数据的最大值为1510-42-4=1464，前42个字节为包头，后4个字节为校验位。而C#端在绘制图像的时候是按照1468个字节来绘制的，因此，绘制的效果是，每次错位2个像素点。在C#端绘制图像的时候需要将num-4。改正后的显示效果如图7所示。