Month: Tuesday October 30th, 2012

PPTV XBMC视频插件更新-v1.1.2

本文同步自(最佳显示效果请点击):https://zohead.com/archives/pptv-xbmc-plugin-v1-1-2/ 之前利用闲余时间写了个 PPTV 的 XBMC 多媒体中心系统的视频插件 v1.0 版本(请参考 [这里]),在 htpc XBMC 论坛上公布之外,经过几百个论坛网友下载使用之后,也发现一些问题,经过修正和增强之后更新了 1.1.2 版本的新 PPTV 视频插件。 更新内容如下: 由于 Python 2.5 以下版本不支持三目运算符,为兼容 Xbox XBMC 等老的 Python 环境,将 if else 三目运算符改换为普通的方式; 解决 PPTV 直播电视节目单获取错误的问题; 如果某个 PPTV 直播节目没有节目单,不能直接得到播放页面地址,则尝试通过搜索的方式得到播放页面地址; 引入 XBMC Chinese Keyboard 插件,为本插件增加根据关键字搜索 PPTV 视频的功能; 如果搜索到的视频不是由 PPTV 提供(例如:优酷、土豆之类),则在播放时给出提示; 播放 PPTV VIP 视频时提示用户无法播放 VIP 视频; 解决某些连续剧集节目(例如某些动漫剧场版全集)无法得到视频列表的问题。 针对某些网友提出的选择播放到开始缓冲间有点延时的问题,由于需要从 PPTV 未公开的 API 中获取真实视频地址,暂时没有什么好的办法解决。另外 PPTV 直播视频仍然使用的是 m3u8 格式的 HTTP live stream,需要 XBMC 系统能正常播放这种流媒体视频。 最后放出 1.1.2 版本 PPTV XBMC 视频插件下载地址: http://github.com/downloads/zohead/pptv4xbmc/plugin.video.pptv-v1.1.2.zip 使用此插件过程中有任何问题欢迎指正哦 ^_^

发布PPTV XBMC视频插件v1.0

本文同步自(最佳显示效果请点击):https://zohead.com/archives/pptv-xbmc-plugin/ 最近认识一位朋友想要在 XBMC 多媒体中心软件(http://www.xbmc.org/)上观看 PPTV(http://www.pptv.com/) 视频网站上的视频,看到有 Windows 上的 XBMC PPTV 插件,但都没法在我的 Raspberry Pi 微型电脑板上(板子虽小也支持播放 1080p 高清视频哦)运行,于是想着自己写个能够跨平台的 PPTV 视频的 XBMC 插件,顺便也拿这个练练 Python,HOHO。 既然要跨平台,那首先考虑必须全部用 XBMC 自带的 Python 脚本实现,不能调用 Windows 上 DLL 之类的鬼玩意,而且 Raspberry Pi 的 armhf 系统上也几乎不可能有 PPTV 的动态库可以用的。 基本原理: 通过 Python 插件发送 HTTP 请求时伪装成 iPad 客户端从 PPTV 网站上获取频道列表、视频列表、查询视频,并得到视频的实际 m3u 和 m3u8 地址。后来发现此方法得到的 m3u 和 m3u8 视频地址在 Raspberry Pi 系统中播放有问题,而且不太好直接解决。没办法,咱拿起 Wireshark 抓包神器,终于发现了 PPTV 未公开的 API 方法(其实 PPTV 一直从未公开,哈哈)得到网页 Flash 方式播放的视频地址。不过其中有个视频 key 的问题,没什么太好办法在 Python 中直接得到。最终想到通过 [硕鼠] 网站解决,硕鼠网站得到的 PPTV 视频地址明显有问题,但有个可用之处就是他能通过 Flash 得到 PPTV 的视频 key,那就省点事从硕鼠得到视频 key,从 PPTV 未公开 API 构造视频链接和分段信息(用过 Python 自带的 json 库),最终得到真实的视频地址。 有关 XBMC 的插件编写详细请参考这些链接: http://wiki.xbmc.org/index.php?title=HOW-TO:Write_plugins_for_XBMC http://wiki.xbmc.org/index.php?title=Python_development http://wiki.xbmc.org/index.php?title=Add-on_development 其中遇到的一个问题就是 HTML 的解析问题,刚开始使用的是比较成熟好用的一个 Python 插件:Beautiful Soup。这个插件的最大优势就是对不标准的 HTML 的容错性做的非常好,而且各种查找 HTML DOM 结构的函数也很强大。那就按照 Beautiful Soup 的要求解析 PPTV 的 HTML DOM,结果顺利取得,不久就发现一个问题,在 Raspberry Pi 这种比较弱的嵌入式板子上,下载 HTML 倒挺快,通过 Beautiful Soup 解析查找 HTML DOM 竟然要用去 15 秒左右的时间,这完全无法忍受,可以寻找替代品。 最终在 XBMC 的论坛里发现了比较好的 HTML parser 替代品:Parsedom XBMC Add-on。这是直接包含在 XBMC 库中的一个简单的 HTML DOM 解析扩展,import 之,下载 HTML 然后按照 class、按照 id 解析 HTML 的速度都在 1-2 秒之间,非常满意。后来使用中又发现 Parsedom 中存在的一些问题,查找原因并修正之后无伤大雅,想到干脆去掉 Parsedom 中一些我用不到的代码,直接集成到我的 py 文件中使用 ^_^。 略加奋战,终于在 XBMC 界面上能正常显示了,能显示频道列表了,也能进入频道显示视频列表,结果播放时发现悲剧了,iPad 的 m3u 被 XBMC 自己给分段解析然后尝试播放了,造成文件路径不对无法播放。后来使用手工修改路径的方式,尽管能播放,但造成的“效果”就是每 5-6 秒钟就需要切换一下视频,这对于 Raspberry Pi 这种暂时无法调用外部播放器的系统来说简直没法用。 PPTV 视频 XBMC 插件 1.0 版本功能: 支持 www.pptv.com 上基本所有直播和点播视频; 支持在插件设置中选择视频质量(与实际 PPTV 视频片源对应),暂时支持:标清、高清、超清、蓝光、iPad 超清; 支持按影片类型、时间、更新时间、热度等条件选择过滤视频,并且所有过滤条件全部实时从 PPTV 网站获取,插件中不保存分类; 视频列表支持翻页处理(具体每个连续剧的集数列表没有翻页,默认全部列出来,主要感觉 1-40 集这种列表还弄分页没什么必要); 不依赖任何 PPTV 的 Windows 程序和库,理论上可以在任何 XBMC 系统上使用 由于 XBMC 不能原生支持中文输入等原因,暂时未支持视频搜索功能,后续将会改进。 备注: 本插件默认的视频质量为高清格式,需要超清或蓝光格式的在插件设置界面中进行修改即可。iPad 超清视频和直播视频分别是特殊的 m3u 和 m3u8 格式(指向 mp4 视频),需要XBMC 系统能正常播放 PPTV m3u 和 m3u8 视频(Windows 下的 XBMC 系统应该可以配置使用外部播放器来支持,不过偶懒得安装木有测试过)。 声明: 此插件只是从 PPTV 网站获取视频内容,所有视频版权均与此网站有关,本插件一概不负责。另外由于 PPTV 网站将来会有变化,我不保证能马上修复并解决可能出现的问题,因为说不定 PPTV 就完全把未公开的 API 给禁用了。 插件介绍的截图: 插件设置界面: 视频列表界面: 具体视频播放界面(放的正是 《麦兜》 哈 ^_^): 本 XBMC 插件的 github 源代码库地址: https://github.com/zohead/pptv4xbmc 下载 PPTV 视频 XBMC 插件: http://github.com/downloads/zohead/pptv4xbmc/plugin.video.pptv-v1.0.zip 下载之后拷贝到 XBMC 系统,然后到 XBMC 系统设置中选择压缩包安装即可。我正在申请将此款插件加入 XBMC 的中文插件库,顺利的话安装此插件将会更加简单,并且在以后修改时可以直接在线更新。 各位在使用 PPTV 视频 XBMC 插件中如果发现任何问题,欢迎提出指正哦,另外有问题时最好能描述清楚,能附上看的是哪个视频或者哪个频道下面的话更好。 ^_^

有关Raspberry Pi 32位framebuffer的问题

本文同步自(最佳显示效果请点击):https://zohead.com/archives/raspberry-pi-32bit-fb-color/ 之前写过一篇 Raspberry Pi(以下简称 RPI) 下使用 fbpdf 即 framebuffer 模式下的 PDF 阅读器的文章(详情请点击 [这里]),文中提到需要修改 config.txt 开启 RPI 的 32 位 framebuffer 支持,但需要注意的是 RPI 的 32 位 framebuffer 并不是真正的 32 位的,其实只有 20120615 种颜色,而且实际上还需要忽略 alpha 位,这在使用 fbpdf 软件看 PDF 时似乎没有太大的问题。 但今天用看图的软件看一张 32 位的桌面截图时,有点傻眼了,效果如下: 大家也能看出来,其实这就是 Windows 7 默认的浅蓝色桌面壁纸图片,但实际的显示颜色完全不对了,而去掉 config.txt 中的 32 位 framebuffer 支持则没问题。 另外据 RPI 上 XBMC 媒体中心软件 Raspbmc 的开发人员介绍,32 位的 framebuffer 下 XBMC 软件也会存在问题,由此看来 RPI 默认将 framebuffer 的颜色深度设置为 16 位是有其道理的。 上面的 fbpdf 文章中的 fbpdf 程序已经更新为 16 位 framebuffer 的版本,如果对此有不同见解的欢迎提出指正哦。 ^_^

使用Linux kernel dm-mirror实现设备间同步

本文同步自(最佳显示效果请点击):https://zohead.com/archives/dm-mirror-sync-device/ 在某些场合下,用户需要在 Linux 系统中实现直接的块设备同步方式,需要将一个裸设备中的内容完全同步到另一个裸设备,有时甚至需要能自定义位移和大小进行同步,这时 Linux 自带的 dm-mirror 模块很可能是比较好的实现方案。 dm-mirror 是 Linux kernel 中 device-mapper(DM)模块(device-mapper 内部称为 target)中的一个,可以实现多个块设备间的数据同步,并支持通过 dm-log 模块保存同步时的元数据信息,方便在关机和重启之后能够继续之前的进度进行同步,而且 dm-mirror 的元数据可以选择保存在内存中或者固定的块设备中。LVM 逻辑卷管理中的 pvmove 命令可以在卷组中替换物理卷,pvmove 命令正是基于 dm-mirror 模块实现的。Linux kernel 中还包含了其它的一些 device-mapper target 模块,例如 dm-linear(用于实现 LVM 逻辑卷管理)、dm-crypt(加密数据)、dm-snapshot(用于实现即时快照)等。 dm-mirror 的主要实现代码在 Linux kernel 代码树的 drivers/md/dm-raid1.c 中,dm-mirror 的日志元数据记录功能通过 dm-log 模块实现,同步的区块划分由 dm-region-hash 模块实现,底层的同步实现则由 kcopyd 来实现。kcopyd 的功能就是从一个块设备拷贝一定扇区的数据到另一个或多个块设备,kcopyd 支持异步的完成通知功能,目前主要被 dm-snapshot 和 dm-mirror 模块使用。有关 Linux kernel 中 kcopyd 的说明请参考这里:http://www.kernel.org/doc/Documentation/device-mapper/kcopyd.txt。 dm-mirror 设备的装载通过 dmsetup 命令来实现,以下说明的地址都是以扇区为单位(固定为 512 个字节),先看看 dm-mirror target 的 table 格式: start length mirror log_type #logargs logarg1 … logargN #devs device1 offset1 … deviceN offsetN [#features <features>] 对每个值分别说明如下: start 为虚拟设备起始扇区地址,一般固定为 0 length 为 dm-mirror 设备的大小,也就是同步的总扇区大小 mirror 值固定,表示这是一个 dm-mirror 设备 log_type 指定日志元数据类型,常用的是 core 和 disk 两种类型 #logargs 表示后面的 logarg1 … logargN 一共有多少个 #devs 表示需要同步的设备个数,每个设备都有一个 device 值和一个 offset 值 deviceN offsetN 为每个需要同步的设备的设备路径(或者设备号)和偏移地址 #features 和 features 为可选的值,#features 表示可选项个数 如果指定了 #features,则必须为 1,且 features 必须为 handle_errors(表示 dm-mirror 会自动进行错误处理,即同步出错时自动停止同步并删除 dm-mirror 虚拟设备) 然后是 core 和 disk 两种日志元数据类型的介绍(另外有 clustered_core 和 clustered_disk 两种适用于集群的日志类型,有兴趣可以自己去了解下哦): core 类型(内存): 日志保存在内存中,关机或者重启之后会丢失,因此安全性较差,但由于元数据存放在内存中,性能相对 disk 类型来说是非常好的。#logargs 个数为 1-2 个,日志参数格式为: regionsize [[no]sync]regionsize 为日志区块的大小(512 个字节的扇区为单位),可选的 sync 和 nosync 用于指定 dm-mirror 是否已经同步过。 disk 类型(磁盘): 日志保存在磁盘(块设备)中,因此可以在关机或重启之后继续之前的同步进度,当然性能比 core 类型肯定是要差一些的。#logargs 个数为 2-3 个,日志参数格式为: logdevice regionsize [[no]sync]logdevice 指定日志元数据存放在哪个块设备上,可以使用设备路径或者主从设备号形式,其它参数与 core 类型相同。 Linux 系统中 dm-mirror 具体使用步骤举例如下: 首先加载 dm-mirror 模块: modprobe dm-mirror  准备好需要同步的设备,假设是实际应用中的一种常见需求:Linux 系统盘为 /dev/sda,系统中另外有个数据盘 /dev/sdb。但由于磁盘 /dev/sdb 寿命快到了,需要将 /dev/sdb 磁盘上的数据同步到 /dev/sdc 上,/dev/sdc 的容量比 /dev/sdb 要大。先得到 /dev/sdb 和 /dev/sdc 的容量大小(以 512 个字节的扇区为单位): blockdev --getsz /dev/sdb blockdev --getsz /dev/sdc假设分别为 209715200(100G) 和 314572800(150G)。 在系统中通过文件方式产生 loop 设备用作 dm-mirror 同步存放日志元数据的设备,防止关机或重启之后同步进度丢失,1MB 的文件已完全足够保存日志元数据:dd if=/dev/zero of=meta.dat bs=1024k count=1运行完成将产生一个 1MB 大小的 meta.dat 文件。 准备 loop 设备:losetup -f 得到空闲的 loop 设备名,假设为 /dev/loop0;losetup /dev/loop0 meta.dat 装载 loop 设备。 运行 dmsetup create 命令创建 dm-mirror 设备进行同步:echo “0 209715200 mirror disk 2 /dev/loop0 16384 2 /dev/sdb 0 /dev/sdc 0 1 handle_errors” | dmsetup create mirror0运行成功之后将产生名称为 mirror0 的虚拟 dm-mirror 设备。echo 中间的字符串即为 dm-mirror 的 table 格式:209715200 为同步的大小,disk 指定元数据保存在磁盘中,/dev/loop0 为元数据设备,16384 为区块大小(这里指定为 8MB 为提高同步性能),后面的参数指定将 /dev/sdb(源设备,起始地址为 0)的数据同步到 /dev/sdc(目标设备,起始地址为 0),1 和 handle_errors 表示不忽略同步错误。 查询同步状态和进度:dmsetup status mirror0输出类似下面:mirror0: 0 209715200 mirror 2 8:16 8:32 417/12800 1 AA 3 disk 7:0 A8:16 […]

Raspberry Pi framebuffer PDF阅读器 - fbpdf

本文同步自(最佳显示效果请点击):https://zohead.com/archives/raspberry-pi-fbpdf/ 最近拷了几个 PDF 电子书到 Raspberry Pi 树莓派小主板系统上,准备小充下电,结果在 Debian Wheezy Raspbian 的 Linux X11 系统下用以前用的 xpdf 软件看 PDF 的不爽:由于 Raspberry Pi 的 CPU 是 ARMv6 700MHz 的,性能一般,而且内存只有 256MB,所以跑 Linux X11 虽然没什么问题,但老感觉看大一点的 PDF 有点拖顿。 后来装了比较小巧的 mupdf 软件(Raspbian 系统的话直接用 apt-get install mupdf 命令就可以安装)之后在 X11 环境下看 PDF 电子书似乎情况好了很多,mupdf 功能很简单,甚至都没有独立的启动方式,直接双击 PDF 文件运行,或者通过命令行方式运行,主界面也没有工具栏之类的多余东西,操作全部键盘来完成,浏览 PDF 的速度也很快,对中文支持也很好。关于 mupdf 的介绍请参考其官网:http://www.mupdf.com/。 后来想到平时用 Raspberry Pi 主要还是用命令行模式,我对 Linux X11 一向比较反感 ^_^,感觉是不是可以直接用 framebuffer 的形式看 PDF,结果还真找到一个 fbpdf 软件。 fbpdf 是基于 mupdf 的代码基础上实现的纯 framebuffer 下的 PDF 阅读器,和 mupdf 的功能基本相当,用这个可以省去 X11 和 GTK+ 等一堆臃肿的玩意,在 framebuffer 上看不仅速度快而且占用内存也小,并且可以充分利用 Raspberry Pi 上 framebuffer 的硬件加速。但不幸的是 Raspberry Pi 的 Raspbian 源中没有 fbpdf 包,看来只能自己编译了。 fbpdf 的 Git 版本库地址(可以直接用 git clone 命令弄下来哦): http://repo.or.cz/w/fbpdf.git 首先到 mupdf 官网下载 mupdf 源代码和 mupdf-thirdparty 第三方程序的源代码: http://www.mupdf.com/download/mupdf-1.1-source.tar.gz http://www.mupdf.com/download/mupdf-thirdparty.zip 需要说明的是我的编译环境是 armhf 的 Raspbian 默认开发环境。编译 mupdf 之前需要先安装 libfreetype6-dev、libjbig2dec0-dev、libjpeg8-dev 等开发软件包。mupdf 编译安装好之后会产生 fitz 库的头文件和静态库文件 libfitz.a,libfitz.a 在编译 fbpdf 时需要用到。 特别需要注意的是 mupdf 和 fbpdf 使用的是修改过的 openjpeg-1.5.0 版本的 openjpeg 库,不能直接使用 Raspbian 系统中的 libopenjpeg2 库,因此需要先编译 mupdf-thirdparty 中的 openjpeg-1.5.0 库,为了防止和 Raspbian 默认的 openjpeg 库冲突,建议将 openjpeg-1.5.0 库安装到自定义的目录(非 /usr/lib、/usr/local/lib 等系统默认使用的目录),然后编译 fbpdf 时直接使用 openjpeg-1.5.0 产生的静态库文件 libopenjpeg.a。 在 Raspberry Pi 编译 fbpdf 时会有一些小报错,需要修改下代码和 Makefile,编译 fbpdf 时由于要使用 libfitz.a 静态库,因此生成的 fbpdf 可执行文件也会比较大(我编译产生的将近 6MB)。 在 Raspbian 系统的默认 framebuffer 文本终端下运行 fbpdf /home/xxx.pdf (/home/xxx.pdf 为 PDF 文件的路径)就可以查看 PDF 文件了,你的 Raspberry Pi 在用 fbpdf 打开 PDF 时很可能会遇到这个错误直接退出:fbpdf: fbval_t doesn’t match fb depth。 简单说明下这个错误的原因: fbpdf 程序中默认使用的 framebuffer 颜色数(BPP)是 32 位的,但 Raspberry Pi 默认的 framebuffer 只使用 16 位颜色(也就是下面的 framebuffer_depth 默认为 16),这样 fbpdf 程序运行时检查 framebuffer 参数发现不匹配就会报上面的错误,我尝试过跳过这项检查可以不报错,但 PDF 文件的显示渲染效果相当差。 解决方法也是必须要有的: 注意:不建议使用此方法,建议直接使用最下面的 16 位 framebuffer 版本。 打开启动分区下的 config.txt 配置文件(路径为:/boot/config.txt),加入下面两行然后重启系统就可以解决: framebuffer_depth=32 framebuffer_ignore_alpha=1 第一行 framebuffer_depth=32 指定 Raspberry Pi 的 framebuffer 使用 32 位颜色,第二行 framebuffer_ignore_alpha=1 是在使用 32 位颜色时才需要指定的,表示忽略 ARGB 颜色中的 alpha 通道。需要说明的是即使 config.txt 配置文件中指定了使用 32 位实际上也只有 20120615 种颜色的哦,不过对使用上没有影响的。 有关 Raspberry Pi 的 config.txt 配置文件的详细说明请参考这里:http://elinux.org/RPi_config.txt。 把上面的配置文件修改好重启之后,下面是用我编译好的 fbpdf 程序查看一个 5MB 的 PDF 电子书的截图,在 Raspberry Pi 这样的微型板上速度是相当之快的: 从截图中可以看到图片和中文都是可以正常显示的哦。 framebuffer 模式下的 fbpdf 也是全部通过键盘操作,不过快捷键和 mupdf 是不同的,将常用的快捷键简单介绍如下(注意是 J、K 等单按键是区分大小写的哦),大多数快捷键都可以在前面加数字指定次数之类的(深得 VI 的精髓啊,哈哈)。具体请参考 fbpdf 代码中的 README 说明文档: 快捷键 操作 Ctrl + F 或 J 下一页(5J 跳至下面第 5 页,6J 类推) Ctrl + B 或 K […]