日记存档 (2005.4.10~2005.4.29)

来源:互联网 发布:淘宝店铺标志可以换吗 编辑:程序博客网 时间:2024/05/17 08:16

朔雪飘飘开雁门,
平沙历乱卷蓬根。
功名耻计擒生数,
直斩楼兰报国恩。
——张仲素

一剑横空星斗寒,甫随平北复征蛮。
他年觅得封侯印,愿学幽人住此山。
——戚继光


不多说什么了,抵制日货。

2005.4.10

看了RFC2435 --
RTP Payload Format for JPEG-compressed Video

要实现RTP/RTCP协议栈是不太现实的.
打算就借用它的打包格式,加些修改和简化.
直接用UDP进行传输.

为了实现对RFC2435里描述的"abbreviated format"格式
的编码解码,还修改了原来写的JPEG/JFIF编解码器.
添加了一组函数.

感觉程序一大,管理起来实在复杂.
修改也尤其困难,都不知道会在原来
正确的地方引起什么错误.


现在的难题是接收端缓冲区的管理.

2005.4.12

今天到图书馆查资料.
关于缓冲管理,时间戳法.
有一些理论.
没什么具体的算法.
自己想吧.

2005.4.13

发现clock()只能精确到10ms,
只好找更精确的方法.至少要到1ms.
这样才可以用来打时间戳,终于找到了.呵呵~~~~

用sleep可以延迟,精度能到1ms.

2005.4.14

好爽!!!
缓冲区管理终于有些端倪了.
呵呵呵呵~~~~

可以发送和接收数据了.
也加上了编码解码.
只是没有加显示,和捕获模块.

但问题还是有的.
速度一快就当掉了,不知为什么,慢慢查吧.

VC调试爽,就是字体不好看...

2005.4.16

累啊.
总算把T.81标准里第四部分
——概述翻译完了.
10页啊~~~~~手都抽筋了.

形式主义,没办法...

2005.4.19

客户端基本完成.
本机测试有丢帧,因为用两张图片交替发送测试,
且发送和接受都在本机,看不出效果到底如何.
可能丢帧比较厉害.
还是加上状态栏比较好,
否则连我自己都不知道缓冲区和解码器的工作状况.

最为郁闷的是有时候会有异常.
程序崩掉.哭~~~~~~~~~~~
都不知道为什么...

2005.4.21

上午给Client加了状态栏.
刷新好麻烦,不太懂.

下午交了开题报告.

晚上还在试Video Streaming Client.
就是试,调也没法调.

开始以为是HBITMAP一边在写入,一边读出来显示.
造成了问题,但是把WriteDDB()屏蔽掉以后,
程序还是会崩掉,而且我已经用了临界区.
看来不是这个问题.

又试了把解码器DecodeVideoFrame()屏蔽掉.
现在已经发送了101553多帧了,还没有发生异常.
看来是发生错误的原因是解码器.
但不是解码器本身的问题.
应该是数据在传输中损坏或丢失.
导致huffman解码出错,造成段违例.

不过也说不准.
如果真是这样,倒让我松了一口气,
说明:缓冲区控制,接收线程和播放线程都没有问题.
谢天谢地了.

看来无论如何都要在Network模块里
加上CRC试一下了.
这样一来恐怕又要慢一些了.

2005.4.22

基本搞定~~~~~~~~~~~~

加了CRC32,还是会崩掉。
(其实,LAN环境怎么可能有数据错误?!上次也不知道自己怎么想的..)

写了一个CONSOLE程序,便于调试.
查看异常发生时的CALL STACK.
发现错误发生在malloc或memcpy函数内部.

怀疑C标准库函数是否线程安全.
查了MSDN:

To build a multithread application that uses the C run-time libraries, you must tell the compiler to use a special version of the libraries (LIBCMT.LIB). To select these libraries, first open the Project Settings dialog box (Build menu) and click the C/C++ tab. Select Code Generation from the Category drop-down list box. From the Use Run-Time Library drop-down box, select Multithreaded. Click OK to return to editing.

这才想起来连接时还有多线程库和单线程库这个问题.
狂FT.

改了以后,一切OK!

2005.4.25

实时视频监视系统.
SERVER & CLIENT
功能基本完成.

SO WONDERFUL!!!

320 x 240
motion-JPEG video
25 fps
multicast/UDP packet
delay < 0.5s

呵呵~~~~~

还有一些工作要做:

添加注释
代码结构优化
改进缓冲区管理
帧率控制
测试

LHH在写AVI读写模块.
可能还要做transcoding.

2005.4.27

工作基本告一段落...

五一回家去了.呵呵~~~~~~~


  Video Monitor System (DEMO)
(Video Streaming Server/Client)


开发环境: VC++ 6.0
日期:     2005.4.28
作者:     kingwei @ ECUST


E-mail: jx_kingwei@sina.com
QQ:    77191167
BLOG:    http://blog.csdn.net/jx_kingwei


1> 目录组织结构

Video Monitor
   System


┣━━ source code             源代码
┃         ┃
┃         ┣━━ codec        JPEG/Motion-JPEG编解码器模块
┃         ┃
┃         ┣━━ interface    界面及显示模块
┃         ┃
┃         ┣━━ network      网络传输模块
┃         ┃
┃         ┗━━ thread       线程相关操作


┗━━ release exe             可执行程序


2> 实现特性

1 320 x 240 图像分辨率
2 Motion-JPEG 视频编解码
3 组播(multicast)/UDP协议


3> 存在问题

1 视频捕获的帧率调整似乎不起作用.
2 服务器端的显示在切换时有抖动现象.
3 状态拦刷新有小问题
4 缓冲区管理不理想
5 需要添加出错控制机制



还有一个线程访问控制问题.
我用的是临界区,实际上一般用互斥比较多.
但觉得效果是一样的.一个是从代码(访问操作)的角度,
一个是从数据结构(访问对象)的角度来看的.

2005.4.29

原创粉丝点击