|
多媒体流的 internet 传输演示程序 老赫 manufactured for zxx公司面试 前言：本次面试因为招聘方有不看应聘者demo程序的优良传统习惯， 而且是只做在unix下的程序的 而且在本地研发也不做net conf system，而是玩database的.(我讨厌databse，整天要和数据报表，键约束，工作流程打交道，和用opengl做demo相比起来，database简直无聊之极...) (哇，老赫，i服了u,去面试连对方的工作平台和工作内容都没搞清楚...) 最后结果是它不理会我，我不理会它(继续蛰伏在机关吧...zzzzzzzz) 事实上这些东西的实质(无论是socket,rtp协议,线程同步设计，压缩传输设计)都是没有平台特性的 还是把这些天的学习心得写出来，给需要者参考 (比如做电子教室的,net conference的,相关内容毕业设计的小伙子) （但是可能有bug哦,matt pietrek,jeffery richter的书也有bug,何况我老赫,请行家商榷指正，不要拍板砖） 如果对你的学习，工作有所帮助，那么最好不过了，我老赫是最没有小农的保守思想的。:) (引用要写明出处哦，还可以提高imagicstudio的counter值,不要学csdn)
开发目标 : 在低带宽条件下实现实时音视频传输。 rtp 协议的软件实现。 几个考虑的实现方法： 一，直接使用 netmeeting sdk ，做出与 netmeeting 完全类似的东西 二，基于某个已实现 ip 层以上的多媒体通讯协议栈 ( 如 open source h.323) 来实作 三，直接基于 ip 协议来实作 本次采用第三个方法，但是只是个 demo ，时间和精力所限，不可能完整的实现 h.323 协议，所以只借鉴 h.323 协议的部分思想，当然，就不具备 h.323 的通用特性了。 技术难点 : 低带宽的多媒体数据流同步，连续视音频流估计是最大的难点。 因为条件限制，数据压缩只能使用软 codec 。实际应用中肯定会采用相应硬件来实现。 多线程采样编码解码中的参数选择如声音缓冲区的大小和个数需要实验确定。 数据通讯方面， peer-to -peer 方式一般采用面向连接的通讯，即 stream socket ，具有传输可靠，有序的特点，可以较好的保证通讯的质量，但是由于 tcp 的三路握手特性，其速度较慢，且不支持多路特性，经过跟踪分析 netmeeting 可知， netmeeting 只在连接握手时使用 tcp 协议，传送实时视音频并不采用 tcp 协议，而是采用速度更快的 udp 协议。所以本次主要研究 udp 的应用。 广播 (broadcast) 或者多播 (multi-cast) 方式属于 udp socket, 不保证数据的可靠，有序和无重复性，所以编程控制较 tcp stream socket 为复杂。 ( 注意 :atm 网络虽然没有乱序的问题，有数据阻塞和突发的现象 ) 所以消除迟延和包丢失对通讯造成的影响是普遍共同的问题。 仿效 netmeeting ， tcp/ip 连接可用于两端软件的握手和建立连接，实际传输用 udp 。 不能象某些文章介绍的去用tcp/ip实现多媒体流传输， 实用的系统用udp在internet上传输多媒体流信息才是正确的方法。 程序有两种工作方式： 点对点和多播方式 , 通过界面选择工作方式。 点对点 : 等待 tcp/ip 连接，一旦有连接请求，询问用户，如果接收连接，允许 udp 端口双向收发数据。 多播：直接进行，接收方询问后接收。 非压缩情况 : 每秒传输的视频数据 (qcif 为例 ):176*144*24/8=76032 (bytes) 每秒传输的 16bit 单声道音频数据 : samplefrequence*samplebits/8=16k bytes 压缩考虑方案 : 音频 : 考虑以下几种压缩 codec g.711,g.729,g.723.1, 非 h.323 内容： truespeech,gsm 等
视频 codec: h.261,h.263 非 h.323 内容 :wavelets,motion-jpeg, jpeg 的 intel 实现 , 选择压缩率，压缩速度，损失程度几项指标的平衡。 最后选定 m-jpeg codec ，比率 1:24 ，无帧间相关的视频压缩，杜绝了 h.263 那样的花屏现象
本文关键：多媒体
本站最佳浏览方式为 分辨率 1024x768 IE 6.0（或更高版本的 IE浏览器） 
|
