posts - 34, comments - 90, trackbacks - 0, articles - 0

视频学习之路

     摘要: 这是JRTPLIB@Conference系列的第六部《G.711编码事例程序》,本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部《JRTPLIB@Conference DIY视频会议系统 五、PCM 和G.711编码相关》
这一部我们来做个实验,就是把用windows录音机录下来的"PCM 8.000 kHz, 16 位, 单声道"WAV文件转换成为我们要用的8位8000Hz a-law格式PCM。要注意的是录音机默认的方式是PCM 44.100 kHz, 16 位, 立体声,我们不想去进行采样频率的更改,因为这个要进行插值,而且也没必要,因为我们写软件时采样频率我们是可以更改的。所以我们要先把录音另为"PCM 8.000 kHz, 16 位, 单声道"格式。  阅读全文

posted @ 2009-01-03 19:47 猫头鹰 阅读(10188) | 评论 (8)  编辑 |

     摘要: 这是JRTPLIB@Conference系列的第五部《PCM 和G.711编码相关》,本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部《JRTPLIB@Conference DIY视频会议系统 四、JRTPLIB组成的文字会议测试 》
这一部的主要内容是研究音频编码的,现在VOIP在语音编码方面已经取得了很多的成果,5到6Kbps的带宽就能传送一路高质量语音,也就是说,就用我97年上网时用的那个33.6K的猫上网,都能传6-7路语音。当然,我们不会在这里谈这个高级编码器,我们可会把它们放在这一系列的后面作扩展的时候研究,看到时候的情况吧。我们现在要谈的是两个非常重要的编码,一个是PCM,一个是G.711。PCM就是我们Windows下的一堆WAV文件的基本音频编码  阅读全文

posted @ 2009-01-03 18:40 猫头鹰 阅读(5338) | 评论 (0)  编辑 |

     摘要: 这是JRTPLIB@Conference系列的第四部《JRTPLIB组成的文字会议测试 》,本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部《JRTPLIB@Conference DIY视频会议系统 三、JRTPLIB的几个重要类说明 》
这一部的主要内完是完成基于组播的视频会议系统中的其中一部份--会话管理。我们将通过一个文字会议测试程序来测试JRTPLIB的会话管理。当然,这里用的是RTP本身的基于组播会话管理,没有你们梦想的SIP,更没有庞大的H323。SIP和H323等我研究到了再写。  阅读全文

posted @ 2009-01-03 17:26 猫头鹰 阅读(2954) | 评论 (30)  编辑 |

     摘要: 这是JRTPLIB@Conference系列的第三编《JRTPLIB的几个重要类说明》,本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部《JRTPLIB@Conference DIY视频会议系统 二、基本例程分析 》
这一部的主要内容是要研究一个JRTPLIB常用的几个非常重要的类,在进行JRTPLIB或RTP编程时会经常和这个几类打交道,或都从这些类中继承。

这是续上一编《JRTPLIB@Conference DIY视频会议系统 三、JRTPLIB的几个重要类说明 》的,上一编中,我们研究了JRTPLIB中的一个重要的类RTPPacket,我们现在来讲一下另外一个类RTPSourceData。  阅读全文

posted @ 2009-01-02 21:32 猫头鹰 阅读(2580) | 评论 (1)  编辑 |

     摘要: 这是JRTPLIB@Conference系列的第三编《JRTPLIB的几个重要类说明》,本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部《JRTPLIB@Conference DIY视频会议系统 二、基本例程分析 》
这一部的主要内容是要研究一个JRTPLIB常用的几个非常重要的类,在进行JRTPLIB或RTP编程时会经常和这个几类打交道,或都从这些类中继承。  阅读全文

posted @ 2009-01-02 10:28 猫头鹰 阅读(5361) | 评论 (6)  编辑 |

     摘要: 这是JRTPLIB@Conference系列的第二部《基本例程分析》本系列的主要工作是实现一个基于JRTPLIB的,建立在RTP组播基础上的多媒体视频会议系统。这只是一个实验系统,用于学习JRTPLIB、RTP、和多媒体相关的编程,不是一个完善的软件工程。而且,我只会在业余的时间出于兴趣写一写。有志同道合的朋友可以通过tinnal@136.com这个邮箱或博客回复(推荐)和我交流。
上一部:《JRTPLIB@Conference DIY视频会议系统 一、开编 》
这一部的原文为《linux下基于jrtplib库的实时传送实现》,这编文章虽然没有和媒体流相关,但作为JRTPLIB库的函数说明来看还是不错的。 主要的任务是通过例子初步看看如何通过JRTPLIB进行编程。这是进行JRTPLIB或RTP编程的入门编。  阅读全文

posted @ 2009-01-01 23:45 猫头鹰 阅读(5296) | 评论 (0)  编辑 |

     摘要: 前段时间一直在研究视频相关的东西。也有了一定的成果,包括MPEG流媒体服务器代码(当然了,是实验而已,当中的RTP也是手工写的,没有RTCP)和H263@S3C2410系列(打算在S3C2410上进行视频的H263采集、压缩、解压缩和显示)。收到了一些读者的来信,我也很高兴,但要声明的是我从做的行业与视频无关,有时候我对一些问题也是无能为力,我也只是因为感兴趣玩玩而已。下面谈谈JRTPLIB@Conference这个系列的情况。  阅读全文

posted @ 2009-01-01 22:38 猫头鹰 阅读(7238) | 评论 (7)  编辑 |

     摘要: 我们的实验所用的代码都取自VideoNet。包括改造后的Karl Lillevold的Tmndecoder、改造后的Roalt Aalmoes 的h.263快速编码库TMN。同时,我们还会对VideoNet进行改造以对我们的代码进行测试,让它来发H263数据,S3C2410开发板来收数据。最后,当然是在S3C2410上进行收和发测试了。至于音频,后面再说吧。
VideoNet的原码可在下面下载:http://100.qqmdm.com/ContentPane.aspx?down=ok&filepath=tinnal%2fmedia%2fVideoNet_src.zip
该程序可以用于两个人在LAN/Intranet(或者Internet)上进行视频会议。现在有许多视频会议程序,每个都有各自的性能提升技术。主要的问题是视频会议视频帧的尺寸对于传输来说太大。因此,性能依赖于对帧的编解码。我使用快速h263编码库来达到更好的压缩率提高速度。该程序做些小改动也可以在Internet上使用。   阅读全文

posted @ 2008-12-23 11:11 猫头鹰 阅读(1451) | 评论 (4)  编辑 |

     摘要: 好久没有写有关视频的东西了。前两周一个学习说要做视频相关的实验,就开了个题,用S3C2410实现H263视频会议。同时,也希望通过把这个开发过程写下来,汇聚了下个系列。
要完成H263的视频解压,而要完成视频的解压缩,又必须完成QCIF文件的播放。下面的播放器程的主程序。  阅读全文

posted @ 2008-12-22 22:04 猫头鹰 阅读(1414) | 评论 (1)  编辑 |

     摘要: JPEG 的图片使用的是 YCrCb 颜色模型, 而不是计算机上最常用的 RGB. 关于色彩模型, 这里不多阐述. 只是说明, YCrCb 模型更适合图形压缩. 因为人眼对图片上的亮度 Y 的变化远比色度 C 的变化敏感. 我们完全可以每个点保存一个 8bit 的亮度值, 每 2x2 个点保存一个 Cr Cb 值, 而图象在肉眼中的感觉不会起太大的变化. 所以, 原来用 RGB 模型, 4 个点需要 4x3=12 字节. 而现在仅需要 4+2=6 字节; 平均每个点占 12bit. 当然 JPEG 格式里允许每个点的 C 值都记录下来; 不过 MPEG 里都是按 12bit 一个点来存放的, 我们简写为 YUV12.   阅读全文

posted @ 2008-09-08 09:40 猫头鹰 阅读(788) | 评论 (3)  编辑 |

     摘要: 1. 色彩模型

JPEG 的图片使用的是 YCrCb 颜色模型, 而不是计算机上最常用的 RGB. 关于色彩模型, 这里不多阐述. 只是说明, YCrCb 模型更适合图形压缩. 因为人眼对图片上的亮度 Y 的变化远比色度 C 的变化敏感. 我们完全可以每个点保存一个 8bit 的亮度值, 每 2x2 个点保存一个 Cr Cb 值, 而图象在肉眼中的感觉不会起太大的变化. 所以, 原来用 RGB 模型, 4 个点需要 4x3=12 字节. 而现在仅需要 4+2=6 字节; 平均每个点占 12bit. 当然 JPEG 格式里允许每个点的 C 值都记录下来; 不过 MPEG 里都是按 12bit 一个点来存放的, 我们简写为 YUV12.
  阅读全文

posted @ 2008-09-08 09:38 猫头鹰 阅读(420) | 评论 (0)  编辑 |

     摘要: linux 下基于jrtplib库的实时传送实现
一、RTP 是进行实时流媒体传输的标准协议和关键技术
实时传输协议(Real-time Transport Protocol,PRT)是在 Internet 上处理多媒体数据流的一种网络协议,利用它能够在一对一(unicast,单播)或者一对多(multicast,多播)的网络环境中实现传流媒体数据的实时传输。RTP 通常使用 UDP 来进行多媒体数据的传输,但如果需要的话可以使用 TCP 或者 ATM 等其它协议。

协议分析 :每一个RTP数据报都由头部(Header)和负载(Payload)两个部分组成,其中头部前 12 个字节的含义是固定的,而负载则可以是音频或者视频数据。  阅读全文

posted @ 2008-09-03 18:17 猫头鹰 阅读(1295) | 评论 (0)  编辑 |

     摘要: 一、流媒体简介
随着Internet 的日益普及,在网络上传输的数据已经不再局限于文字和图形,而是逐渐向声音和视频等多媒体格式过渡。目前在网络上传输音频/视频(Audio/Video,简称A/V)等多媒体文件时,基本上只有下载和流式传输两种选择。通常说来,A/V文件占据的存储空间都比较大,在带宽受限的网络环境中下载可能要耗费数分钟甚至数小时,所以这种处理方法的延迟很大。如果换用流式传输的话,声音、影像、动画等多媒体文件将由专门的流媒体服务器负责向用户连续、实时地发送,这样用户可以不必等到整个文件全部下载完毕,而只需要经过几秒钟的启动延时就可以了,当这些多媒体数据在客户机上播放时,文件的剩余部分将继续从流媒体服务器下载。  阅读全文

posted @ 2008-09-03 17:41 猫头鹰 阅读(6995) | 评论 (2)  编辑 |

     摘要: 最近这几天研究H.263编码,前几天把标准H.263解码库TMNDEC2.0理解了,这两天把H.263的标准编码库研究了一下,编码库的使用明显比解码库要复杂,一眼看上去好你多了很多的代码,令的有点眼花。花了点时间,注释了代码,发现比解码多出来的,主要是进行码率的控制的。而且还使用了两种方法,其它多出来的,就是很多的编码参数(它都弄成全局变量了)。过几天弄一个固定帧率(变码率)的精简版本DEMO出来。  阅读全文

posted @ 2008-09-03 09:26 猫头鹰 阅读(2801) | 评论 (9)  编辑 |

     摘要: 前一段时间以MPEG2为基础研究了RTP协议,并且完成了在RTP上承载MPEG2 ES流的程序,本来是想编写一个在JRTPLIB上的MPEG2视频广播程序的。但是由于这段时间另外一个视频标准吸引了我,那就是H.263标准,MPEG2和H.263是由两个不同的标准制定组织制定的,MPEG2注重的是高质量(DVD大家都熟悉了吧,数字有线电视的高清大家向往吧),和MPEG2相反,H.263注重的是码率,因此它是可视电话的视频压缩标准,它可以在64Kb/s的ISDN线路上进视频聊天(现在的ADSL更爽啦)。呵呵,爽。  阅读全文

posted @ 2008-08-28 16:31 猫头鹰 阅读(1978) | 评论 (0)  编辑 |

Full 视频学习之路 Archive