先初步查了一下, 发现es和dvb的内嵌字幕类似, 都是spu的. 找了例子文件发现每个视频对应两个文件, 一个.sub的文件是pes封装的spu流, 一个.idx文本文件, 包含字幕的描述信息, 每个时间戳对应字幕在.sub文件的偏移. 每组.sub和.idx文件可包含多组(多种语言)的字幕, 用id区分.
开始没发现每组文件可包含多种语言的字幕, 按照惯用的模式, 做成绘制前解析读取的模式, 后来改成预解析.idx文件, 提取时间戳和在.sub文件偏移, 做成链表, 每种语言对应一个链表(实际上扫描字幕时预解析有几个语言的字幕, 将每个语言对应一个字幕轨).
很快就可以看到字幕显示了, 但显示不正确, 有很多条文和阴影.
仔细观察有时是一行字按奇偶行拆成两份, 显示在不同的位置.
对应代码发现spu格式确实按顶底场打包的, 每个包大概是[包长 + rle长 + rle数据 + 控制字], 解析时先跳过rle数据读取控制字, 控制字中包含顶底场在rle数据中的偏移.
因此初步定为为控制字读取有误. 开始怀疑是去pes包头有误造成的, 查了很久确认没有问题. 在测试文件中对应pes包长, spu包长, rle长度等信息, 发现无法与包尾的控制字位置对应.
观察发现有些字幕的显示是没有问题的, 没问题的字幕解析可以准确读取控制字.
进一步观察发现了一个规律, 没问题的字幕包长都较小, 小于2000字节. 想了很久猜测或许是打包时有某种trunk机制, 超过某个长度后分包. 根据猜测尝试发现, 如果包长超过2048字节时跳过24个字节恰好可以全部正确播放. 查了vlc, mplayer等的代码没有发现按trunk读取的地方.
之后在测试文件的2048字节处观察, 发现了00 00 01 BA, 00 00 01 BD等pes包头的串, 此时思路豁然开朗, 打包时一个spu包被拆分到了多个pes包中, 之前想当然地认为一个spu包肯定会放入一个pes包中, 没有考虑这种情况. 后来看到一个spu打包代码的注释才发现windows上有限制, 一个pes包不能超过2048字节.
很老的一个”寓言故事”, 不想分析其中的各种深刻含义, 每个人都有自己的理解. 我是觉得这个故事很传神地刻画了一种心里问题, 不知该用什么专业术语描述. 我有一点, 也见过有人非常严重, 估计不少人都多少有一些吧.
从前, 有一个人要用斧子, 可是他自己家里却没有, 于是, 他打算向邻居借斧子, 可是又担心邻居不肯借给他.于是他在前往邻居家的路上一直在胡思乱想:
“如果他说自己正在用怎么办?”
“要是他说找不到怎么办?”
“如果他不肯借给我怎么办?”
这个人后来越想越多:
“邻里之间应该和睦相处．他为什么不肯借给我?”
“假如他向我借东西, 我一定会很高兴地借给他.”
“这个人真是太小气了! 哼!”
最后, 这个人越想越生气, 于是等到敲开邻居的门后, 他说的不是”请把你的斧子借给我用一下好吗?”, 而是张嘴说道: “呸! 留着你的破斧子吧, 有什么了不起的, 我才不借呢!”
说完, 他就气呼呼地走掉了, 结果弄得邻居莫名其妙.
Oprofile是Linux下类似vtune的profile工具, 在内核添加支持, 支持基于事件和时间的, 精确度高于gprof.
1. 内核编译
如果编译内核时没有打开相应选项则需要修改配置重新编译.
开始运行opcontrol时一直出现下面错误就是由于没有打开内核的支持导致.
mount: mounting nodev on /dev/oprofile failed: No such device
make menuconfig添加oprofile选项general step –> profiling support –> oprofile system profiling
kernel/arch/arm/configs/vc0882_vortex_mmc_defconfig
修改.config文件
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
make vc0882_vortex_mmc_defconfig
make uImage
2. opcontrol
Android版的opcontrol和linux的不一样, 是个C程序, linux的是个python脚本.
运行时有”Cannot open /dev/oprofile/1/enabled: No such file or directory”的错误. debian 6上/dev/oprofile下是有0, 1等目录的, 这些目录由内核生成, 对比了debian 6和使用的Android内核代码, 发现debian 6有生成的代码, Android没有. 注掉了相应的代码, 后续使用中还未发现有何影响.
external/oprofile合并了hi的代码.
3. sample转换
Android上生成sample如果不做转换是无法用PC上的opreport和opannotate分析的, 会出现”invalid argument”的错误. 开始没留意这一点, 为这个错误折腾了很久, 差点就放弃了.
使用了hi的转换工具.
4. 分析
opreport可生成各模块cpu占用情况的列表.
opannotate可将cpu占用情况对应到每行代码.
还有很多其他功能, 如二级缓存命中率等, 这个没有尝试.
在使用Oprofile方面要赞一下hi平台, 他们修改过的Oproile可以使用, 并提供了文档手册.
本次折腾的原因是ffmpeg aac解码有些片源cpu占用很高, 打开neno优化也不见效果. 分析后发现cpu占用的大部分在一些浮点运算, 高维数组访问上, 貌似是某些高级的profile的特性, 估计ffmpeg没有做相应优化. 权衡各方面因素后决定先不花时间做优化, 以后闲了可以再看看, 或许未来新版的ffmpeg也会做优化.
另外ffmpeg编译成动态库时没有分析出具体的符号信息, 后来改成了静态库.
2011是迷茫的一年, 就像生活在<盗梦空间>里的潜意识边缘, 彷徨, 焦虑, 像在梦里, 却怎么也清醒不过来.
工作方面还是很认真的, 相对2010年更用心一些, 因为工作内容还算有吸引力, 没有一堆杂事整天打扰. 年时初继续*api 2.1的重构. 5月份去深圳出差闲了一个月. 回来后着手stagefright的可用性评估和自主omx播放器的开发, 11月初基础版本完成, 领导看了演示还算满意. 之后到了一个新部门, 做了几周的st sdk封装, 刚理清头绪就被派去做vm平台的播放器开发了, st的丢在一边. vm的开发是继续之前的omx播放器, 对我来说吸引力应该是更大一些, 将来看着自己的成果良好运转在公司的重要产品上还是很有成就感的.
学习方面重温了
共享软件方面基本没什么成果. 研究了下QT的stylesheet, 做了两个自己还算满意的, 可以运行时切换. qfs的skin版做完了, 但没有发布. 规划的两个图像处理软件每次都做几天就丢到一边了, 到现在连基本框架还未搭起来.
下半年不少时间都浪费在研究房地产方面了, 相关知识了解了不少, 想法也是过一阵子变化一下, 不能再浪费太多时间在上面了, 稍微关注下就行了. 终身大事还是八字没一撇.
总体上说意志有些不够坚强, 不知是不是老了的缘故. 很多事情都是三天打鱼两天晒网的, 东关注下, 西关注下, 结果啥都没干好. 另一方面可能是关注的东西也太多了, 精力比较分散. 不能再这样下去了, 意志要坚定些, 关注点要精简些.
2010年底公司的一个副总Y离职去了L公司, 据说是跟老板闹僵了, 具体神马原因不太清楚. 从年初开始公司的邮箱经常会收到些有意思的匿名群发邮件, 大概也就是工作如何操蛋了, 新来的某些员工年薪多少多少了, 比我们这些工作几年的老员工高很多, 人的能力很一般. 虽然发这种匿名邮件的事比较龌龊, 但邮件的内容其实谁心里也有数, 说的都是事实, 也引起了不少共鸣, 只是一般人嘴上不说罢了. 我一般都是后知后觉, 过了很久以后才听说是Y干的.
5月多的时候又被发到深圳, 结果由于管理上的失误在那边一个多月没有事情做. 那段时间, 深圳那边每过一两周就有人离职, 又时不时地听说北京这边谁谁也离职了, 一片人心涣散的气氛, 我的心思也开始活动了. 这其中还有两方面的重要因素, 一方面手头的工作已经做的差不多了, 再做下去也学不到新东西了, 能交给别人的已经交出去了, 但环顾四周却找不到喜欢的方向可以发展. 另一方面, 当初到SW工作的时候就设定了一个心里预期, 就是在SW踏实干三年不换工作, 不计较薪水, 将技术基础打扎实, 之后的发展再做下一步打算. 而此时刚好三年期满…
阅读全文…
儿时总喜欢缠着妈妈讲故事，如今大都已记忆模糊了，但那个小马过河的故事却还时常在脑海里浮现.
多少时候我又何尝不是那个的懵懂小马, 耳边萦绕着小松鼠的警告, 在所谓的困难面前踌躇不前. 但又有多少次, 通过了所谓的困难才发现, 那根本算不上困难.
有些时候, 耳边那告诫的声音不是来自小松鼠, 而是源于自己. 有时初涉某事, 还未开窍就已尝到了苦头, 留下了心理阴影. 之后再次涉足时尽管自身实力早已发生变化, 但那道坎却始终还在心里.
事实上, 人与人之间是有很大差异的. 对一些人自然而然水到渠成的事情, 对另一些人却像天堑鸿沟一样很难跨越. 对一些人像大山一样堵在面前的难题, 另一些人却可轻松翻越. 因此:
1. 要认清自己, 准确估量自己的优势劣势. 就像小马要先知道自己有多高.
2. 要认清问题, 估量问题的困难程度, 就像小马要弄清水的实际深度.
3. 实际上小马不下水是无法弄清水有多深的, 因此无法认清问题时, 还是要实际尝试一下.
4. 小马是幸运的, 如果河水很深, 河堤很陡, 小马可能就一脚下去上不来了, 因此尝试时要谨慎, 避免被拖进漩涡.
3. 参考别人的意见, 同时要保持自己的头脑清醒, 不盲目迷信.
4. 要有信心, 相信自己是一只天赋超群, 潜力无限的小马.
今天验证rk的omx模块, 经历了一番折腾, 终于走到dlopen打开omx库的地方了, 却一直返回空句柄, dlerror也没有任何错误提示信息. 开始时怀疑文件路径不正确, 但在失败后尝试用fopen打开文件发现没有问题. 最后快要放弃了, 发现还有一个so库似乎没有拷过去, 之前在网上查dlopen的失败原因时有人提到这种情况也会导致失败, 拷过去那个库后发现果然成功了.
单线程解码没有问题, 因此怀疑是ffmpeg多线程解码的bug.
但发现ts流没有问题, 多次对比发现flv, mkv, mp4均有问题.
这两类片源都是通过ffmpeg读取文件的, 一个区别是ts流里的h264 es流是nalu封装的, 而flv, mkv, mp4文件里的h264 es是avc封装的, 为了统一处理, 解码前将avc封装的es流转换成了nalu封装的. 因此怀疑是转换这里出错了, 进一步怀疑很可能是添加sps, pps这里出错了. 在这里纠缠了许久但还是没有发现问题.
此时有一个最大的疑点是单线程解码没有问题, 因此将着眼点放在多线程这里. 根据日志的错误信息观察sps, pps之后的第一帧解码总是失败, 第一帧一定是个关键帧, 因此怀疑第一帧解码失败导致后面一段时间的解码帧无法参考该帧而导致花屏. 做了一个实验发现将出错的这一帧再送给解码器一次就好了.
但这样并不是解决问题的办法, 要找到这个错误的根源. 在错误信息的附近加打印发现有一个比较多线程解码后slice类型的地方不对, 感觉送完头信息后应该重置些什么东西, 是不是转换后的码流里少了什么? 但纠结了很久没有找到原因. 偶然间灵感想到是不是头信息不应该作为单独的一帧呢? 因为出错的位置显示多线程解码的slice类型不匹配, 并且ffmpeg多线程解码时似乎是是拆成slice分配给各个线程的, 会不会头信息里没有一个视频帧就导致出错了呢? 验证后发现果然如此.
不仅送给解码器的码流内容不对会导致出错, 送的方式不对也会出错.
理论依据
人们对音频速率的变化较视频更敏感, 并且很多情况下音频可能无法重采样调整速率, 丢帧/重复帧不宜频繁. 因此应尽量调整视频的速率适应音频.
//—————————————————————————————-
同步方式
* 切入频道后如果先解析到音频帧则等待, 直到有视频帧解析出来. 此时判断音视频时间戳的差距.
* 视频比音频提前时先输出视频, 直到有音频后开始输出音频.
* 音频在视频输出后才开始输出, 视频未输出前等待或丢弃.
normal: 音频较视频提前较多时丢弃音频, 直到音频和视频差异很小.
fast: 一解析出视频即开始显示, 之后调整音视频的播放速率逐渐同步. 切入频道后的一段时间内可能音视频不同步.
bestfit: 介于normal和fast之间, 音视频差异较大时丢弃, 差异减小到某个阈值内后开始播放并逐步调整.
//—————————————————————————————-
播放速率调整
* 为了保持音视频同步, 调整播放速率时音频和视频同时慢放和快放. 音频允许重采样时对解码的pcm数据重采样, 否则采用丢帧或重复帧.
* 直播时, 长时间后本地时钟的漂移可能导致缓冲区上溢, 因此直播时定时检测缓冲区的数据量, 数据量超过一定范围时略微加快播放速率.
* 切入频道时或直播长时间播放后的本地时钟漂移可能导致缓冲区下溢, 音视频播放线程读取输出帧失败时触发下溢事件, 下溢时略微降低播放速率. 播放速率的降低程度与下溢事件的更新频率有关. 调整期间可能有一段时间的卡顿.
* 下溢降低播放速率后保持一定事件(目前为5s), 之后逐渐恢复.
* realtime时, 检测缓冲区的上溢和下溢情况.
* 非realtime时, 缓冲区下溢时慢放. 缓冲区充裕时不做调整.
* 对服务器发包速率变化容忍范围: 95%~130%.
//—————————————————————————————-
时间参考
视频参考音频. realtime时, 根据stc同时调整音频和视频
//—————————————————————————————-
仅有视频的情况
有pts: 按照pts输出
没有pts: 按照码流打包的framerate或默认的framerate输出
+ stc矫正
仅有音频的情况: 自由输出 + stc矫正
一直感觉, 新信息的获取更容易冲淡头脑中一些遥远的记忆, 而我又喜欢将各种信息往头脑里塞, 一些是有意的(这种通常来自学习, 我可是很爱学习的哦…), 还有无意的, 不知何时何故就对某样东西产生了兴趣, 不知不觉相关的信息也就溜进脑袋里, 哪怕有时只是只言片语, 积少成多, 时间久了有时竟能连贯疏通. 趁那些依稀的记忆还没有消失, 还是先用文字记录下来吧, 好记性不如烂笔头(记起初中的数学老师很爱说这句话), 若干年后还可以翻出来回味一下.
不知何故, 小时一直对刀子之类的东西情有独钟, 玩刀子割破手是家常便饭, 大部分孩子此时恐怕是要哇哇大哭的, 而我总听母亲说起的一次是割破手后将血在墙上蹭干, 然后背到身后去不让母亲看到. 大多时候手割破了不是很在意, 几天也就好了, 但记忆中有一次伤口是发了炎, 情况有些严重, 其实最开始本来也是一个很小的刀口, 不小心被母亲关注到了, 那时也没有创可贴什么的(但我现在依然认为创可贴什么的贴了不如不贴), 非要我涂点牙膏, 紫药水什么的, 最后这么一折腾倒是更为严重了, 不过最后不知怎么也还是好了, 但现在一直怀疑手上的那个伤疤是不是那时候留下的, 这个记不清楚了.
小时候很喜欢爬高上低的(但一直不会爬树, 这一点很遗憾…), 用老家的土话描述就是这孩子挺猴的, 一次母亲的一个同时聊天时随意说了一句, 结果被父亲听到了, 父亲还为这个说法生了好一阵子气, 由于父亲是南方人听不懂老家的一些土话. 就这样, 我虽然很猴, 但也从未因此出过什么大的危险, 这应该归功于母亲从小灌输的安全意识, 另一方面也是因为我天生胆小吧. 但小时还是受过一次伤, 严重到右臂骨折的地步, 不过这次受伤却挺冤枉的, 不是因为我爬高上低引起. 那时候七八岁, 有天吃完午饭从椅子上下来, 是那种老式配合写字台的木椅, 下面有个横梁, 不知怎么脚就踩空跌了下来, 稀里糊涂手臂就骨折了, 开始还没有觉得特别疼, 过了一会才反应过来. 那天母亲刚好去盟里出差, 家里只有父亲和奶奶, 父亲将我背在背上汗流浃背地跑到医院, 挂号拍片, 手忙脚乱地也不知怎么好. 后来碰巧遇到母亲的同事, 帮忙联系到母亲, 母亲连夜赶了回来. 那天熬了一夜, 我没怎么哭闹, 疼痛中迷迷糊糊地躺着, 父母由于担心一夜没休息. 第二天找车去了张家口, 听人介绍去了一家私人医院, 父母陪着我在那里住院一个多月, 据母亲说她就是从那时候起有了白发. 那个主刀医师的技术真是不错, 现在手臂上只是看到那道伤疤, 其他一点都没受影响.
最近看到两则关于电纸书行业变得不景气, 汉王大幅亏损, 盛大转型的新闻.
电纸书火了不到一年怎么就行业亏损, 无人问津了呢?
我觉得初期的火热是广告打出来的, 给消费者一个新鲜的事物, 一些追逐新奇时尚的消费者蜂拥买来尝鲜.
但实际上电纸书在功能用途上还没有达到它的售价带给人的心里期望. 在初期的盲目消费者之后, 理性的消费者在衡量其售价功能, 与其他产品的同类功能(如手机阅读可能更方便)做对比后, 会发现购买的理由并不充分.
消费者购买一样东西, 首先计算的不是你这个东西成本有多高, 而是根据其功能, 用途等方面能带来的收益和满足感愿意支付多少钱.
在源代码里写<!–more–>标签后, 点预览, more标签会被自动改为下面这样:
<div id=’extendedEntryBreak’ name=’extendedEntryBreak’></div>
所以每次加上more标签后就不能预览了.
我的WLW版本号是14.0.8117.416 zh-cn, google了一下, 发现2008年就有人在微软的支持论坛里报这个bug, 都2011年了还在, 唉…
http://social.microsoft.com/Forums/en/writerbeta/thread/bda1c2de-10c0-425b-8145-74b1c4db6a41
摘自柳城的博客: http://liucheng.name/581/
以默认外观为基准:
1.到默认外观目录下（你正在使用的外观目录下）,复制single.php文件, 并改名为guestbook.php;
2.打开guestbook.php文件, 在顶部添加代码
<?php
/*
Template Name: GuestBook
*/
?>
保存.
3.进入站点后台管理添加一个页面,页面模板选guestbook.php, (如果用了Rewrite功能, 请设置好日志缩略名)保存
4.复制comments.php文件, 并改名为guestcomments.php
5.打开guestbook.php文件, 修改
<?php comments_template();?>
为
<?php comments_template(‘/guestcomments.php’);?>
6.如果你想个性化这个留言本的话，请修改guestcomments.php的样式体现
