qyb的博客

Win32 下的音视频软件(开源的和免费的)

下面是科普时间...

LAME
lame 号称是这个星球上 MP3 编码音质最佳的编码器,而且是 GPL 的.

在我的 DV-2-XviD 里面也是采用 lame.exe 来压缩 DV 的音频的。除了 lame .exe 这个命令行工具外,这里可以找到很多基于 lame 的程序。我现在使用的是 winLAME,它除了支持文件转换外,还可以 rip CD,包括去 freedb.org 上寻找 CD 信息,至少我刚从卓越买来的《Unplugged in New York》和《时光漫步》都能被正确识别出来

ffdshow 和 FFmpeg
FFmpeg是一款强大到有些变态的多媒体编码库。它是在 Linux 下开发的,核心是 libavcodec(就是win32下说的Codecs) 和 libavformat(用于文件格式的处理),ffmpeg 只是其前端命令行程序。由于专利权问题(大部分影音编码都是有专利的),Linux 发行版本通常不会把 ffmpeg 作为发行缺省部分。
ffdshow 从其命名来看应该是脱胎于 ffmpeg,主要的解码库也用的是 libavcodec,可以说是 ffmpeg 的 DirectShow 版本。当然随着发展,它已经远远不限于 livavcodec 了,还增加了许多后处理的特性以增强低质量视频的播放效果。要说的是这些特性也多半来自 Mplayer——另一个 Linux 下开发的媒体播放器项目,其实 Linux 下多媒体处理还是很棒的。

BTW,从 Youtube 下载的 flv 格式的文件就是用 ffdshow 来enable相应的 decoder filter 就可以了.

AviSynth
AviSynth 简直可以用神奇来形容。首先解释一下 Frame Server 的概念,通常我们所谓的多媒体处理都是直接处理文件,处理网络媒体流的现在也很常见,那么 Frame Server 就可以说是生成"程序媒体流 or 来自程序的媒体流"的程序。再举一个例子,我们访问 http 服务器请求的只是一个 URL,但是这个 URL 里面可能囊括了图片、视频,现在还有 AJAX 程序... 最终组织成一个丰富多彩的页面;AviSynth 就是一种这样的服务器,它对外展示的只是一个 .avs 脚本,但这个脚本则可以把原视频文件做各种各样的处理,打开这个 .avs 文件得到的就是做过处理以后的视频流。
通常那些压缩 DVD 的人都要写 avs 脚本来去拉丝修改分辨率,渲染一下比如加亮度.. 后,再调用 Codecs 来压缩 avs 流.
AviSynth 目前只能在 Win32 上工作,不过支持 Linux 的 AviSynth 3.0 正在开发中,3.0 还将包括一个 Gstreamer 插件.

另一个有关的消息是 AviSynth 似乎打算放弃维护自己的脚本引擎,而会改用 Python

VirtualDubMod 和 VirtualDub
由于专利问题,VirtualDub 一直拒绝直接支持 MPEG-2 文件的处理,但人们的需求是压缩 DVD,于是就有了一票修改版本们的出现,VirtualDubMod 便是其中的佼佼者,它除了支持 MPEG2 以外,还增加了支持 VBR MP3 等特性。
虽然 VirtualDub/VDubMod 号称是一个视频捕获和处理程序(包括视频编辑),但我一直都用的是它的命令行功能:和 avs 类似,写一段小的 vdub 脚本,然后交给 vdub 去执行。在我的 DV-2-XivD 程序里面,整套执行流程如下:
 1. 写一个 vdub 脚本,将 PCM/Wav 格式的音频从 DV avi 里面分离出来
 2. 调用 lame,将声音压缩成 mp3
 3. 写一个 vdub 脚本,将 DV avi 做 XviD 的 1-pass 压缩,生成 stat 文件

 4. 写一个 vdub 脚本,执行 2-pass 压缩,并且和 mp3 文件 合并到最后的 avi 文件里.

AutoGK 和 DVDdecrypter
上面介绍的全都是 GPL or LGPL 的软件,现在来介绍两个免费软件(freeware)
虽然已经有了很多工具,但把一张 DVD 制作成一张 700M 的 XviD/DivX 还是很麻烦的,于是就有了 Gordian Knot 这个软件包,但我实在搞不明白 Gordian Knot 这个名字是自嘲,还是标榜自己是亚历山大之剑那样的解决方案。
事实上 AutoGK 才是真正的亚历山大之剑,它和 DVDdecrypter(原站点 DVDDecrypter.com 已经在压力下关闭了)的配合可以说天衣无缝,很轻松就能把 DVD 压缩好。我家那些宝宝反复看的 DVD 全都是这么处理的,而且不再担心盘片被宝宝弄坏.

我的 DV-2-XviD 也是来源于 AutoGK,包括 vdub 脚本,我也是学着 autogk 的中间处理结果来生成的.

Celtic Druid
这个不是软件,而是一个网名。这个家伙最擅长的就是在 win32 下 build 从 cvs 里 checkout 出来的代码并发布,doom9 这样的论坛经常可以看到大家谈论 Celtic_Druid build,AutoGK 通常就用他编译的 XviD。

原始站点(celticdruid.no-ip.com/)被 GFW 了,不明白为什么.. 不过还是有很多 mirror 可以访问,很容易可以搜索到。他编译的包括:Media Player Classic、ffdshow、XviD、x264...

====================================

最后是广告时间...

DV-2-XviD
用 Python 写成,GPL
功能是合并多个 DV avi 文件,在画面底部增加拍摄时间码,压缩成 XviD.
目前已知的问题包括:
 1. 只能和 xvid-1.1-test2 一起工作 :(
 2. 压缩 XviD 的文件大小控制有问题

 3. wxPython 窗口在压缩过程中会失去响应

原来我的 DV 是压缩成 MPEG2/SVCD 保存的(而且是用的没有合法许可的软件),最近一年多以来,开始用 XviD 压缩,感觉不错。计划修补完上述缺陷后,再考虑是不是改成 MPEG4 AVC 方案,比如 x264,如果这样的话,这个项目的名字可能也需要改成 DV-2-MPEG4,或者 DVgk?

Topic: 技术

AVI 文件格式(dv_info.py 的文档)

首先声明:本文的内容都是我从开发过程中总结出来的,以我的理解在尽可能短的篇幅里对 DV AVI 文件的分析作介绍。真要作开发还需要参考原始的文档。

AVI 文件总是以 12 个字节开始的,就是 'RIFF' + size + 'AVI '。这里 size 是一个 4 字节的整数,声明其后的字节数(包括'AVI '这4个字节数)

现在问题就出来了,这样的格式就是限定了 size 的最大取值只能是 4G,后来人们就扩展了 AVI 的结构——当分析到声明的字节数后,如果后面是扩展格式,那么就继续分析。

扩展部分类似 AVI 的格式,只不过从 'AVI ' 变成了 'AVIX',而且可能有多个扩展部分。因此这一部分的分析代码就是:

head = struct.unpack('<4sI4s', avifile.read(12))
if head[0] != 'RIFF' or head[2] != 'AVI ':
return None
while True:
xread = readChunk(avifile, head[1]-4, 0) # 分析剩余的数据
s = avifile.read(12)
if 0 == len(s): # 如果没有什么可读的了,自然是分析完了
break
head = struct.unpack('<4sI4s', s)
if head[0] != 'RIFF' or head[2] != 'AVIX':
break

由于 AVI 内部嵌套的数据块的格式也类似 4bytes info + size + data 这样的结构,因此 readChunk 被设计成一个递归函数,返回值为 0 或 -1,中途解析失败就返回 -1,根据此返回值退出嵌套调用。(回过头来看这样一段程序,递归调用分析的可读性很糟糕,主要是因为开始编程的时候对 Python 没有太多的认识所致)

可能是为了便于编程,各个数据块被设计成 4 字节对齐的,但 data 的大小未必是 4 的整数倍,从文件中读出来的 size 只是表示 data 的长度,有时候必须计算对齐。下面两行语句就是作这个的:

page = (head[1] - 1)/4
chunksize = (page + 1) * 4

为了便于播放器去 seek 一个特定的位置,比如从文件的第 12 分 32 秒开始播放,需要一个索引方案可以快速定位到相应的数据。这就是 'idx1' chunk 里面定义的东东。但传统的定义里面偏移量最大只能为 4G,因此扩展格式里面增加了 super index,或者说 index 的 index,里面可以放 longlong 的 64 位整数来避免这种寻址困境,估计在我有生之年都不会有这么大个的数据文件问世。

readChunk 函数的主要功能就是生成一个 index 列表,然后从这个列表的最前面和最后面分别 seek 到相应的数据存储区域,找出时间码。如果发现 AVI 里面有 super index,就在 readChunk 返回后,再根据 super index 生成 index 列表。程序里面这个列表变量名为 offset

分析 DV 格式获取时间的函数是 readtime。DV 可能是每次记录 12000 字节数据(类似磁盘扇区的概念??),因此在每 12000 字节数据里面都会存储一个时间码。我的当时参考的代码里面在每个 index 指向的数据块里循环了 15 次还是 10 次,但我发现我这里只能循环 12 次就碰到了数据的尽头,后来估计是 PAL/NTSC 的差异,也就没有继续追究下去。

Topic: 技术

dada 最新语录

爷爷带她经过游泳池,问她想不想去游泳,回答不会。爷爷说可以去学,奶奶和她一起学,回答:一个太小,一个太老,有点难.

呵呵,上个月奶奶还发现她照镜子用毛笔对着自己的眉毛描来描去,不晓得是学谁的样.

另:今天下午看到了彩虹,记忆中是这辈子第一次看到彩虹,而且是很壮观的彩虹,几乎横跨整个天际,仔细看还能看到另一道很浅颜色的彩虹.. 同时两道彩虹,哇!!

Topic: 生活

AVI 介绍

计划把这一年多以来业余作 Python 相关开发的一些知识整理一下,这是第一篇。

迄今还记得第一次看到的 AVI 文件,在 windows 3.1 上,一个邮票大小的窗口里,一个人(男女实在看不清楚)在滑帆板。那是我们不知道从哪里弄来的一个软件包(当然现在知道是一个 VFW 驱动)里面附带的一个 sample,宣称装了这个东东后计算机就进入多媒体时代;随着后来 .dat/.mpg (VCD) 的流行,对比下 avi 给我的印象就成了落后,低质量的代名词。

进入 BT 时代后,突然就发现下载来的电影文件几乎都是 avi 文件,通常是 700MB,就拥有不输于 DVD 4G 容量的数据所包括的音视频质量。就有了这么一个疑问——AVI,它到底是个什么玩意儿。

专业的回答是这样的:AVI 是一种容器(container)格式。通常来说没有把音视频一起编码的方案(用大脚趾都能想到同时编码的效率一定不高),而是独立编码,然后打包在这样一个容器里面,做成一个单独的文件供人使用。播放的时候首先将容器里包含的不同的数据流分离出来(splitter),再交给不同的引擎(Codecs)去解码(decode),播放器还得根据容器包装的规则让视频音频能同步起来。我们现在使用的那些 avi 文件准确说是包括了 XviD/DivX 压缩的视频流和 AC-3 or MP3 音频流的 container .. 随 XP/2000 提供的缺省多媒体附件包括一个 avi 的 splitter,以及一个 mp3 的 decoder。只要再安装一个 XviD 的解码器和一个 AC-3 的解码器基本上就可以看所有的影片了。

事实上 rmvb 也是一个 container,无需 real 播放器,有一个 rmvb splitter 和合适的 codecs,就可以在任何支持 dshow 的播放器欣赏 rmvb 了;DVD 上的 .vob 就是另外一种容器,里面除了 MPEG-2 图象和 DTS/Dolby 音频外,还会包括 n 条字幕流。

言归正传,qyb 为什么要研究 AVI 格式呢?因为在 DV-2-XviD 这个软件的功能里面,有个需求就是从 DV 抓取的 AVI 文件里面,获取拍摄该视频当时的时间。我要作的事情一是把视频流从 AVI 里面分离出来,然后再从视频流里面获得保存在里面的时间戳。

网上很容易可以搜索到一篇关于 AVI 格式的文档(链接是一个 pdf 文件!),它组织的很好,是我一开始起步时的主要参考,但后来处理 >1G AVI 文件的时候感觉这篇文档描述并不清楚。最后还是依靠这篇完成了 avi 分析部分。

本期科普工作到这里结束,计划下一期简单汉化一下 AVI 相关文档... 可能更类似程序文档吧。

Topic: 技术

Onmyōji


呵呵,也用一次搞怪的标题... Onmyōji (陰陽師, 或者说 Yin-Yang Masters),

前两天一口气把梦枕貘的阴阳师看完, 确实是一部"抓人的小说", 非常精彩不忍释卷. 前言里面提到的鲁迅评《三国》里的诸葛亮:"状诸葛之多智而近妖" .. 呵呵,鲁迅是不是因为深深受日本文化影响,所以才有这样的结论呢?反正在光荣的三国志英杰传里面就叫妖术师;还有玩PS2上的三国无双,里面关于诸葛的CG画面羽扇纶巾,说不出的妖异。日本对这类人物事件的解析还是挺独特的。

鬼故事能写到这个份上,已经是极至了。其中的灵异事件未必很扣人心弦,但作者把平安时期的文化风貌刻画的精致飘逸. 不耐心看源氏物语的,可以从此小说一窥当时的贵族生活。上网搜了搜关于这本小说的信息,发现谈论电影的也大有人在,尤其是大家对狂言师野村万斋饰演的安倍情明更是赞不绝口,不由得生了极大的好奇心,想弄张 DVD 来看看这个号称可以媲美于张国荣的美男子.

关于阴阳师这个很有前途的职业,很早很早以前看《东京巴比伦》的时候就知道了,现在只记得那个叫皇昂流的阴阳师很 COOL,几乎都要忘了里面还有暧昧的同性爱. 小说《阴阳师》里面主角也是两个男人,关系虽然比较隐讳,但从作者强烈要求野村万斋来演电影来看,他还是觉得需要强调一下这两个男人之间的感情吧。不得不承认日本文化的骨子里就有赞赏男子美和同性之爱的强烈倾向。

Topic: 文化 生活

亲历索尼维修服务


很久以前买的 SONY 摄像机 19E 突然坏掉,回放没有问题,但拍摄就全部变形成绿色的竖条纹,简直可以免去后期制作直接开拍午夜凶铃。这摄像机自从泰国归来后就一直没有拍过,我只好将其归罪于北京最近糟糕的天气。

坏了总是要修的,先前已经有过一次去维修的经历,当时说开机检测费就要 200。现在只能怀着忐忑不安的心情,再次杀往位于魏公村的索尼北京技术服务中心

在经过漫长的排队后,客服 MM 看了摄像机的故障现象,说可能是 CCD 坏了,或者是什么其它的问题,如果是 CCD 坏的话可以免费更换,因为已知有一批 SONY 的老机器是有问题的;如果我可以等 20 分钟,就现场做检修,若确认是 CCD 问题,那么立刻就搞定,否则就等修好了再来取。然后很专业的卸下了我的电池,给我一张单子,上面注明维修机器的当前状态:"带 UV 镜和镜头盖,机身有划痕...",我签字确认以后就把机器包好送到了快修室。

索尼的快修室就在前台大厅的一侧,可以透过玻璃看到维修的全过程。于是紧张的看着维修人员很熟练的把我的 DV 大卸八块,焊下 CCD,然后再焊一个新的(或者也只能算良品),测试,哈,很快结论出来,果然是 CCD 故障,于是整套维修服务全部免费。

后来看我的维修单,收费情况是:配件费 105,维修费 220. 费用为索尼承担。在前台大厅还有一张今年5月出台的价目表,关于 DV 的费用是检测费 50,清洁、更换外围附件的人工费用是 250,维修的人工费用是 350;DC 相关的人工费用分别是 200/300。比较起去年维修 Nikon 4300 的经历,发现 SONY 的服务要透明优秀得多,怪不得柯美退出数码相机业务后,把自己的维修服务转包给索尼。从另一张说明上看,快修服务(针对 DC 和 DV)只提供到下午 3:00,确保当天就可以拿到修好后的产品;但我的摄像机去修的时候已经下午 5:00 了,可能是因为我的情况比较特殊吧,也不知道快修服务需要另加多少钱。

我是周六去的,我拿到的号是 177,等我走的时候已经有人排号到 200 了,4 个接待席在马不停蹄的工作。在我等待的1个多小时过程中,绝大部分是 SONY 电脑,其次是 DC、DV. 其它的我只看到一台电视和一台音响。仔细算算,感觉人们使用数码电子产品,维修率还是蛮惊人的.

说实话,本来我是有些鄙视 SONY 的 DC 产品的,可经过这么一次比较爽的维修过程后,感觉再买新 DC 也未必非 Canon/Nikon 不可。当然,从各种媒体上都能看到电子产品维修需要天价的维修费用,也包括索尼,说不定这次只是运气比较好而已.. 是不是以后 DC/DV 这类消费数码产品也会出现 DELL 那样的三年全保服务呢?

Topic: 商业 技术

发现一个软件 Jokosher

不用我多说,看了这张图片就应该知道它是做什么用的了.

以前这类开源软件好像只有 Audacity (有 win32 下的安装包). 在 jokosher 论坛上有人批评 Audacity 对 MIDI 支持不够好..

总之,用 pyGTK 开发,采用 gstreamer 框架,这些都是我所喜欢的东东,所以 Linux 下玩音乐制作的朋友们,这里推荐一下. 哪天我也试试 remix 一个黄建翔解说 MP3. 嘿嘿

Topic: 技术

万里开源

我是在搜索 mysql 的一个功能的时候发现 mysql 居然有了官方的中文手册,然后顺藤摸瓜,知道这个手册是万里开源这个公司提供的。

从缺乏创意的名字,这个公司实在无法在第一时间内获得我们的尊重,但它却是 MySQL 在中国的金牌合作伙伴,真是让人大跌眼镜。在 google 上搜索,关于这个共创Turbolinux 合作产物的介绍是少之又少,首页也是很没有诚意的 "Under constructing....",直接输入 http://greatlinux.com 更是直接去了 turbolinux,不由得让人们对其是否能承担 mysql 金牌合作伙伴(可能还是中国大陆唯一)这一使命而心存疑虑.

但无论如何,对于中国现在如火如荼的以 MySQL 开始其基础架构的创业公司而言,现在有了一个可以近距离获得现场支持的可能,另一方面,这类基于开源产品的专业服务也是中国难能可贵的尝试。至少万里开源的血统还算高贵纯正,如果您确实在担心存储在 MySQL 中的数据有一天可能突然无法访问,那么可以考虑联系一下万里开源,看看他们的实力和姿态是否足以打动你们的 CIO。当然价格也是需要考虑的因素,MySQL 的白金服务也不过 5000$/Year,不晓得万里开源是怎么定义其服务项目和收费标准的。

虽然我得承认我个人并不喜欢它,但这里还是先为其鼓掌吧。

==================================================
后记:这样的写作风格是不是所谓的华尔街体

Topic: 技术

We are the Champions

是在周六到天津的火车上读报的时候知道这条消息.

这个冠军来的有些尴尬?

我可不这么认为。至少我们一直在足球场上 keep on fighting till the end, 所以 no time for losers cause we are the champions - of the italy

不管怎么说,莫拉蒂和扎队配得上这个冠军奖杯

我对新赛季的最大愿望现在改成,超过 Milan 9 分夺冠.

Topic: 运动
订阅 RSS - qyb的博客