dwing的个人资料

TSAC: Very Low Bitrate Audio Compression 大神 Fabrice Bellard 真会玩, 继bpg后又出tsac.

UCI 0.611 (十周年纪念版) (今后如果没有大的变化, 不再发帖和公布下载链接了, 有兴趣可以关注下面的github链接, 那里会不定期更新) UCI是一种基于H.264/HEVC intra帧压缩算法和数据流格式的静态图像封装格式. 而且不受图像宽高的一些限制,支持alpha透明通道等特性, 与JPEG,JPEG2000,HD-Photo等静态图像压缩算法相比具有更高的压缩效率. 目前公开的命令行工具暂时只支持24/32位BMP与UCI格式的相互转换, 同时提供二次开发用的dll/lib, 也可以用于XnView和Susie的解码插件. 编码工具只支持x264/x265作为编码内核, 解码内核使用FFmpeg中的libavcodec解码器. HEVC编码的uci文件只能用0.6以后版本的UCI来解码. 编码时加"-hevc"参数,使用x265.exe来编码, 其它使用方法均未改变. 编码所需的x264.exe和x265.exe需要另外下载(链接见readme.txt)或自己编译. 与bpg相比, uci的编解码性能貌似更好,可自定义编码参数, 画质差不多. 下载: pan。baidu。com/s/1I6HFmp4ZLZJfzAinocCwiQ 源码: github。com/dwing4g/uci UCI相关介绍: tieba.baidu.com/p/511089688 0.61版发布贴: tieba.baidu.com/p/5551010529 0.6 版发布贴: tieba.baidu.com/p/4816306191 0.4 版发布贴: tieba.baidu.com/p/586018069 最近更新历史: 0.611(2018-11-08) 更新FFmpeg至4.1 ,使用MinGW-GCC 8.2和VC2017(15.8.9)编译,默认二进制发布版本使用VC2017编译(不再附带x265) 0.61 (2018-02-13) 更新FFmpeg至3.4.2,使用MinGW-GCC 7.3和VC2017(15.5.6)编译,默认二进制发布版本使用VC2017编译(发布附带x265 8-bit 2.6+37),增加64位编译版本 0.602(2017-06-08) 更新FFmpeg至3.3.2,使用MinGW-GCC 7.1和VC2017编译,默认二进制发布版本使用VC2017编译(发布附带x265 8-bit 2.4+14) 0.601(2016-12-21) 更新FFmpeg至3.2.2,调整x265默认编码参数(发布附带x265 8-bit 2.1+69) 0.6 (2016-10-10) 更新FFmpeg至3.1.4,支持x265编码,支持VC2015编译,默认二进制发布版本使用VC2015编译(发布附带x265 8-bit 2.1+20)

UCI 0.61 (增加64位版本) UCI是一种基于H.264/HEVC intra帧压缩算法和数据流格式的静态图像封装格式. 而且不受图像宽高的一些限制,支持alpha透明通道等特性, 与JPEG,JPEG2000,HD-Photo等静态图像压缩算法相比具有更高的压缩效率. 目前公开的命令行工具暂时只支持24/32位BMP与UCI格式的相互转换, 编码工具只支持x264/x265作为编码内核, 解码内核使用FFmpeg中的libavcodec解码器. HEVC编码的uci文件只能用0.6以后版本的UCI来解码. 编码时加"-hevc"参数,使用x265.exe来编码, 其它使用方法均未改变. 发布包 uci0610.7z 附带的 x265.exe 修正了原版的一个bug 所以目前必须使用这个exe来编码(具体原因见0.6版本发布贴的2楼) 与bpg相比, uci的编解码性能貌似更好,可自定义编码参数, 画质差不多下载: pan。baidu。com/s/1nvUwAZv 源码: github。com/dwing4g/uci 最近更新历史: 0.61 (2018-02-13) 更新FFmpeg至3.4.2,使用MinGW-GCC 7.3和VC2017(15.5.6)编译,默认二进制发布版本使用VC2017编译(发布附带x265 8-bit 2.6+37),增加64位编译版本 0.602(2017-06-08) 更新FFmpeg至3.3.2,使用MinGW-GCC 7.1和VC2017编译,默认二进制发布版本使用VC2017编译(发布附带x265 8-bit 2.4+14) 0.601(2016-12-21) 更新FFmpeg至3.2.2,调整x265默认编码参数(发布附带x265 8-bit 2.1+69) 0.6 (2016-10-10) 更新FFmpeg至3.1.4,支持x265编码,支持VC2015编译,默认二进制发布版本使用VC2015编译(发布附带x265 8-bit 2.1+20) 0.602 版发布贴: tieba.baidu.com/p/5153765630 0.6 版发布贴: tieba.baidu.com/p/4816306191 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

UCI 0.602 UCI是一种基于H.264/HEVC intra帧压缩算法和数据流格式的静态图像封装格式. 而且不受图像宽高的一些限制,支持alpha透明通道等特性, 与JPEG,JPEG2000,HD-Photo等静态图像压缩算法相比具有更高的压缩效率. 目前公开的命令行工具暂时只支持24/32位BMP与UCI格式的相互转换, 编码工具只支持x264/x265作为编码内核, 解码内核使用FFmpeg中的libavcodec解码器. HEVC编码的uci文件只能用0.6以后版本的UCI来解码. 编码时加"-hevc"参数,使用x265.exe来编码, 其它使用方法均未改变. 发布包 uci0602.7z 附带的 x265.exe 修正了原版的一个bug 所以目前必须使用这个exe来编码(具体原因见0.6版本发布贴的2楼) 与bpg相比, uci的编解码性能貌似更好,可自定义编码参数, 画质差不多下载: pan。baidu。com/s/1i5eKcdR 源码: github。com/dwing4g/uci 最近更新历史: 0.602(2017-06-08) 更新FFmpeg至3.3.2,使用MinGW-GCC 7.1和VC2017编译,默认二进制发布版本使用VC2017编译(发布附带x265 8-bit 2.4+14) 0.601(2016-12-21) 更新FFmpeg至3.2.2,调整x265默认编码参数(发布附带x265 8-bit 2.1+69) 0.6 (2016-10-10) 更新FFmpeg至3.1.4,支持x265编码,支持VC2015编译,默认二进制发布版本使用VC2015编译(发布附带x265 8-bit 2.1+20) 0.526(2016-09-30) 更新FFmpeg至3.1.3,使用MinGW-GCC 6.2编译 0.6 版发布贴: tieba.baidu.com/p/4816306191 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

UCI 0.601 从0.6版本开始, 支持HEVC编码的uci文件, 编码器目前只支持x265 编码时加"-hevc"参数,使用x265.exe来编码, 其它使用方法均未改变 HEVC编码的uci文件只能用0.6以后版本的UCI来解码发布包 uci0601.7z 附带的 x265.exe 修正了原版的一个bug 所以目前必须使用这个exe来编码(具体原因见前一版本发布贴的2楼) 与bpg相比, uci的编解码性能貌似更好,可自定义编码参数, 画质差不多下载: pan。baidu。com/s/1dFusajv 源码: github。com/dwing4g/uci 最近更新历史: 0.601(2016-12-21) 更新FFmpeg至3.2.2,调整x265默认编码参数(发布附带x265 8-bit 2.1+69) 0.6 (2016-10-10) 更新FFmpeg至3.1.4,支持x265编码,支持VC2015编译,默认二进制发布版本使用VC2015编译(发布附带x265 8-bit 2.1+20) 0.525(2013-12-20) 更新FFmpeg,使用MinGW-GCC 4.8.2编译,发布五周年开源纪念版前一版本(0.6)发布贴: tieba.baidu.com/p/4816306191 0.525发布贴: tieba.baidu.com/p/2769912710 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

关于压制分辨率的选择问题在视频压制领域, 有一个比较有争议的问题是: 如果给定了码率(或者固定了视频时间和文件大小), 如果码率给的不是很高, 那么是否要降低分辨率压制? 这个问题也可以说成: 选择"高分辨率低质量", 还是"低分辨率高质量"? 这个问题在注明的压制论坛doom9上有几位牛人给出了自己的解答: forum。doom9。org/showthread.php?t=171929 解答的人数并不多, 看来在专业的论坛上并不需要很多争论, 答案真的是国内大部分压制者所想的那样么. 为了更好地普及解释这个问题, 我翻译主要的解答贴: CarlEdman: 一般来说, 我建议总是保持片源的分辨率,然后设置编码参数来达到想要的目标码率. 理由是降低采样(分辨率)也算是一种有损压缩, 而且是很垃圾的一种, 直接把视频信号中的高频信息全部丢掉了. H264(或特指x264)是很智能的压缩, 它能从时间和空间两个角度丢弃高频信息, 就像降低采样一样, 但它也有选项保留普通降采样所损失的细节. 通常, 你应该尽可能使用智能的算法来做整体压缩, 而不是无脑地使用垃圾压缩算法(降采样)后再用智能压缩算法(H264). 当然, 你用更低的码率压制会损失很多细节, 但你用降采样通常会损失更多. 以上规则仅有的例外,我想有这几种: (a)当你一定要降低目标分辨率,无所谓高频信号的损失时; (b)当你编解码时间很有限,无法满足片源分辨率的编解码时; (c)极端低码率的情况,h264的块效应会很明显. 其它情况, 还是按片源分辨率用x264来压制吧. 也有人提到, 很多片源的细节并不丰富, 不值得保留1080p, 720p就够了, 甚至在播放时提高画面锐度也不错, 这也算一种例外吧. 还有人不相信x264的智能, 怕码率太低导致比降分辨率更难看的结果. 以上基本解释了整个问题以及争论点. 我个人再补充一点, 如果码率给的充足,或者动态画面并不多,或动画类型的,低一些码率其实也够充足时, 那么降分辨率的做法几乎是完败. 当然这也说明码率给的不合理, 如果用crf模式压基本不会出现这种情况. 国内有很多压HDTV影视剧, 在给了>1Mbps码率的情况下, 不敢用720p, 而降低到1024x576去压, 恐怕大多都选错了吧.

UCI 0.6 发布 (支持HEVC) 主要改进: 增加HEVC(x265)编解码的支持, 使用VS2015编译FFmpeg和UCI 新版本可在编码时加"-hevc"参数,使用x265.exe来编码, 其它使用方法均未改变 HEVC编码的uci文件只能用0.6以后版本的UCI来解码与bpg相比, uci的编解码性能貌似更好,可自定义编码参数, 画质差不多, 需要进一步测试下载: pan。baidu。com/s/1mii48XE 源码: github。com/dwing4g/uci 最近更新历史: 0.6 (2016-10-10) 更新FFmpeg至3.1.4,支持x265编码,支持VC2015编译,默认二进制发布版本使用VC2015编译 0.526(2016-09-30) 更新FFmpeg至3.1.3,使用MinGW-GCC 6.2编译 0.525(2013-12-20) 更新FFmpeg,使用MinGW-GCC 4.8.2编译,发布五周年开源纪念版前一版本(0.525)发布贴: tieba.baidu.com/p/2769912710 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

USI(Ultra Scaled Image) 比waifu2x快10倍以上的图像2倍放大算法自创的算法, 目前尚在实验中, 质量和性能仍有改进空间, 预览对比如下(左:原图, 中:USI, 右:waifu2x):

最小的围棋AI图形界面软件前些天各地都炒作了G00GLE的AlphaGo如何厉害, 实质上就是结合了深度神经网络和蒙特卡罗搜索树算法, 目前也只有这两个算法适合围棋AI,而且可以很好地配合, 神经网络算法比较复杂,调优也很费时费力, 而蒙特卡罗算法很简单,无需棋类经验,只要有规则即可, 对RAM/ROM要求非常低,主要依赖CPU整数计算, 而且极易分布式计算,不过不太适合用GPU计算. 我写了不到200行核心代码就实现了围棋规则和蒙特卡罗算法,并做了高度优化. 然后还有一个简单的界面也只有200行左右, 暂时没有做多核支持,甚至AI计算也在主线程中,AI思考时不要乱动界面. 编译压缩后只有6K,虽然棋力只能看作玩具, 不过这是纯粹的毫无经验的推断AI,就像刚学会规则却从未下过也没看过一盘棋. 放在这里当作新春礼物吧,源代码会在合适的时间开放. 链接: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu.com%2Fs%2F1c1howJe&urlrefer=7447b4c95cff5df9e172d2a361c19c99 密码: x96h

G00GLE新出的无损压缩算法brotli 优势是接近LZMA算法压缩率的同时, 解压速度比zip的deflate还快. 不过想达到接近LZMA的压缩率, 压缩速度是很慢的, 不过也提供了更快压缩的档位.

[转载]Facebook移动端照片预览背后的技术当在 Facebook 移动端上浏览某个人的用户资料或页面时，首先看到的往往是图片。这些图片是构成 Facebook 体验不可缺少的一部分，但有时候，图片的下载与展示非常慢，在低速或移动网络中尤其如此。而在像印度这样的发展中国家市场上，许多 Facebook 新用户主要是使用 2G 网络。近日，Facebook 工程师 Brian K Cabral 和 Edward Kandrot撰文描述了 Facebook 解决这一问题的过程。　　封面照片是屏幕上最显眼的部分，但它也是加载最慢的部分之一。这主要有两个原因：一是封面照片的大小常常达到 100KB，而 2G 连接的传输速度可能只有 32KB/秒；二是应用程序需要发送两个网络请求才能显示封面照片。它首先向 GraphQL 服务器发送请求，获得照片 URL，然后发送第二个网络请求，使用该 URL 从 CDN 获取照片。第二个网络请求的延迟相当长，比第一个长许多。　　为了解决上述问题，他们希望能够由原照片生成一张 200 字节大小的效果图，然后将其作为 GraphQL 响应的一部分在第一次请求应答中直接返回，这样可以省掉第二次请求，极大地缩短用户资料和页首的显示延迟。当然，他们最终还是要从 CDN 下载完整照片并进行展示，但这可以在后台进行。至此，问题变成如何将照片压缩成 200 字节。　　他们希望照片的效果图有一种磨砂玻璃的效果。这既有趣，又能与原始照片保持一致。磨砂玻璃效果采用高斯滤波器比较容易实现，而且图片越模糊，分辨率就越低，图片的尺寸就越小。不过，为了提供良好的用户体验，分辨率也不能太低。通过多次尝试，他们得出，42x42 的图片可以达到他们想要的效果，而分辨率再高一些并不会带来更好的效果。但是，即使只显示图片的 DC 分量，每个像素仍然需要 3 个字节，那么 42x42x3 就是 5292 字节，远远超出 200 字节的目标。　　他们开始评估标准的压缩技术，试图找出一种最好的方法，将数据压缩至 200 字节。遗憾的是，只是对图片进行熵编码（比如 zlib）的话，只能将图片压缩一半，仍然太大。他们还评估了其它若干非标准技术，但最终，他们决定试一下 JPEG 图像编码。遗憾的是，JPEG 头本身就有几百个字节的大小。不过，去掉 JPEG 头，编码的数据有效负荷接近 200 字节。　　于是，他们开始探索，JPEG 图片是否有可能使用一个固定的头，那样就可以将其存储在客户端，而不需要传输。JPEG 头包含多个表。在Q值一定的情况下，量化表是不变的。通过试验，他们发现，Q20 生成的图片可以满足他们的要求。虽然他们的图片不是固定尺寸，但基本上都限制在 42x42 以下。他们还仔细查看了 JPEG 头中的其它内容，发现只有 Huffman 表会随着图片的不同发生变化。Q值、图片数据及图片尺寸决定着 Huffman 表中的频率值，每一项变化都会导致不同的压缩比和有效负荷字节数。他们在一组图片上进行了试验，并最终找出了一个可以作为标准的 Huffman 表。　　虽然他们处理了大量的图片，但总有一些该方案不适用的情况。为此，他们增加了一个版本号。如果发现任何极端情况，或者未来发现了更好的 Huffman 表，那么他们就可以更新相关图片的版本号，并将新表发送给客户端。最终的格式包含一个字节的版本号、一个字节的宽度、一个字节的高度和大约 200 字节的有效负荷。服务器只将这一格式作为 GraphQL 响应的一部分发送，然后由客户端将 JPEG 体附加到预定义的 JPEG 头上，生成一个普通的 JPEG 图片。经过标准的 JPEG 解码后，客户端可以运行预定的高斯模糊，并拉伸其尺寸以适应窗口大小。　　最终，他们获得一种可以满足需求的格式。在网速缓慢的情况下，这帮助他们将用户资料和页面加载时间缩短了 30%。而在网速非常快的情况下，这可以确保用户立即看到封面照片预览，提升了整体体验。

UCI 0.525 (五周年开源纪念版) UCI (Ultra Compact Image) 0.525 by dwing 2013-12-20 开源托管站点: http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fcode&urlrefer=422815d4fc0590d72faef4fce38fc526。google。com/p/ultra-compact-image/ 已编译文件包(uci0525.7z): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu.com%2Fs%2F1vN6Aq&urlrefer=07b04544990e70d064fb2005da95387a * 简介 UCI是一种基于H.264 intra帧压缩算法和数据流格式的静态图像封装格式. 而且不受图像宽高的一些限制,支持alpha透明通道等特性, 与JPEG,JPEG2000,HD-Photo等静态图像压缩算法相比具有更高的压缩效率. * 更新历史 0.525(2013-12-20) 更新FFmpeg,使用MinGW-GCC 4.8.2编译,发布五周年开源纪念版 0.524(2013-05-17) 更新FFmpeg,命令行程序使用unicode处理所有字符串 0.523(2013-04-28) 更新FFmpeg,修正上个版本解码的色彩空间转换问题 0.522(2013-04-05) 更新FFmpeg,使用MinGW-GCC 4.8.0编译,修正偶尔YUV420->RGB转换越界访问的bug,防止多线程同时解码,部分改用libswscale转换色彩空间,使画质更好 0.521(2012-07-06) 更新FFmpeg,使用MinGW-GCC 4.7.1编译 0.52 (2012-01-19) 更新FFmpeg,编码时YUV通道改用10bit输入,同时支持8/10bit x264编码及解码,支持指定x264的程序名,调整默认参数,取消支持非全范围YUV的编码及无用的Y通道修正 0.511(2011-12-23) 更新FFmpeg,使用MinGW-GCC 4.6.3pre编译,C++的例子改为C的例子,修正susie接口在MangaMeeya中的崩溃bug 0.51 (2011-09-11) 更新FFmpeg,增加解码的JNI接口和Java的使用例子,一些细节改进 0.5 (2011-07-29) 更新FFmpeg,新增4种格式的编解码,支持全范围YUV映射,直接支持H.264的YUV444编码,取消支持以前的YUV444编码,更新默认subme参数为11 0.494(2011-07-15) 更新FFmpeg,增加UCIDebug接口,改用MinGW-GCC 4.6.1编译 0.493(2011-03-13) 更新FFmpeg,改用VC2010(sp1)编译,编码质量的范围从1~50改为0~51,修正0.492版质量0的alpha通道的解码问题,增加LuaJIT的使用例子 0.492(2011-02-01) 更新FFmpeg,改用VC2010(sp1-beta)编译 0.491(2010-11-13) 更新FFmpeg 0.49 (2010-07-26) 更新FFmpeg,支持新版x264设置图像大小的参数 0.48 (2010-05-22) 更新FFmpeg,取消了作用不大的PGO优化,修正编码器对新版x264输出无用信息的消除,修正yuv2bmp对YUV420处理的严重bug 0.47 (2010-04-03) 更新FFmpeg,改用VC2010编译,启用PGO优化,取消了作用不大的MMX优化 0.46 (2010-03-13) 更新FFmpeg,改用VC2010(rc1)编译 0.45 (2010-01-17) 更新FFmpeg,修正前一版本的几个bug 0.44 (2009-12-12) 更新FFmpeg,改用VC2010(beta2)编译,使用线性插值改进YUV420到RGB的转换,修正访问susie插件接口可能导致崩溃的bug 0.43 (2009-11-28) 更新FFmpeg,改用VC2010(beta1)编译,去掉了一些无用的容错处理(减小体积并可能提升解码速度) 0.42 (2009-07-12) 更新FFmpeg,禁用interlace(减小体积并可能提升解码速度),对新版x264参数的修正,修正上一版本MMX解码优化没有启用的bug 0.41 (2009-06-27) 更新FFmpeg,少部分解码代码使用MMX优化,RGB->YUV转换略微调整,修正例子程序中的错误 0.4 (2009-05-30) 更换解码接口,YUV420相关转换使用MMX优化,更新FFmpeg,增加imgdec工具,增加Susie解码插件的支持 0.31 (2009-04-18) 更新FFmpeg,增加UCI格式描述和C++/C#的使用例子 0.30 (2009-02-27) 更新FFmpeg,为了避免一些兼容性和性能问题程序不再加壳 0.29 (2009-02-15) 支持直接编码YUV420格式,默认去掉x264的一些无用信息,修正一些参数和细节 0.28 (2009-02-12) 更新FFmpeg,增加YUV2BMP程序,--quiet参数改为-quiet,少量细节修正 0.27 (2009-02-03) 修正XnView浏览32位图偏色bug,解码初始化改在载入ucidec.dll时执行 0.26 (2009-02-02) 更新FFmpeg,增加--quiet参数,修正图像宽度为奇数可能对图像解码有误的bug 0.25 (2009-01-31) 修正图像宽度或高度为某些值时无法正常解码的bug 0.24 (2009-01-28) 支持分离YUV编码,编码时增加输出YUV文件的选项,一些细节修正 0.23 (2009-01-23) 提升解码速度,改善UV通道的编码质量,修正某种情况下x264进程阻塞的bug 0.22 (2009-01-18) 支持目前最新版XnView读取UCI的插件,修正可能导致程序阻塞的bug 0.21 (2009-01-17) 编解码器支持stdin/stdout,编码器不再使用临时文件,修正一些细微bugs 0.2 (2009-01-10) 减小编解码器体积,优化解码速度,修正解码接口返回值的2个bugs 0.11 (2008-12-27) 编码器增加Y通道修正,其它一些细节修正及速度略微优化,FFmpeg版本:svn16354 0.1 (2008-12-20) 初始内部测试版本,FFmpeg版本:svn16238 前一版本(0.524)发布贴: tieba.baidu.com/p/2333527735 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

x264压制参数经验积累此楼仅用于x264参数对压制结果影响的备忘记录, 用于总结大家每次压片后的经验积累评论请尽量写在每楼的回复中, 不要占楼

UCI 0.524 近期更新记录: 0.524(2013-05-17) 更新FFmpeg,命令行程序使用unicode处理所有字符串 0.523(2013-04-28) 更新FFmpeg,修正上个版本解码的色彩空间转换问题下载: pan.baidu。com/share/link?shareid=472667&uk=2047110340 前一版本(0.522)发布贴: tieba.baidu.com/p/2253276711 0.4 版发布贴: tieba.baidu.com/p/586018069 UCI相关介绍: tieba.baidu.com/p/511089688

UCI 0.523 此版本更新记录: 0.523(2013-04-28) 更新FFmpeg,修正上个版本解码的色彩空间转换问题下载: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu&urlrefer=33d03bcf1f2d767f1211aa322671b7ca。com/share/link?shareid=441180&uk=2047110340 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.kuaipan&urlrefer=643c6c394bd427fb48a9b39f1870143c。cn/file/id_22946077527245460.htm 前一版本(0.522)发布贴: http://tieba.baidu.com/p/2253276711 0.4 版发布贴: http://tieba.baidu.com/p/586018069 UCI相关介绍: http://tieba.baidu.com/p/511089688

UCI 0.522 又时隔了半年多,这次在解码中又改用回libswscale,貌似画质更好,尤其是默认YUV420方式压缩的情况,编码基本没有改动至于体积又增大了这次暂时这样,只是为了早点放出来供测试,以后还会再想优化的办法此版本更新记录: 0.522(2013-04-05) 更新FFmpeg,使用MinGW-GCC 4.8.0编译,修正偶尔YUV420->RGB转换越界访问的bug,防止多线程同时解码,部分改用libswscale转换色彩空间,使画质更好下载: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu&urlrefer=33d03bcf1f2d767f1211aa322671b7ca。com/share/link?shareid=407491&uk=2047110340 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.kuaipan&urlrefer=643c6c394bd427fb48a9b39f1870143c。cn/file/id_22946077527245426.htm 前一版本(0.521)发布贴: http://tieba.baidu.com/p/1707378094 0.4 版发布贴: http://tieba.baidu.com/p/586018069 UCI相关介绍: http://tieba.baidu.com/p/511089688

国产H.265(HEVC)解码器试用报告最近迅雷和PPS等几个国内视频领域厂商突然宣布支持H.265, 并很快提供了测试渠道, 很让人出乎意料. 且不说普通用户, 很多压片专业用户估计也始料未及, 国内竟然有这么高调推广新技术, 而且还是这种硬功夫的编解码器领域. 虽然可以不对这些商业化的宣传抱有期望, 甚至是严重怀疑的态度, 但对新技术的推广有利的话, 我们这些技术宅还是应该感到很期待的. 我还没去来得及更新迅雷看看, 就从某处得到了所用的解码器, 而且是dshow的filter, 这种形式很正常, 也比较容易集成到迅雷看看之中. 简单看了下, 解码器分FLVSplitter.ax和HEVCDecFltr.dll两个, 前者应该是修改过的FLV分离器, 后者才是真正的HEVC解码器. 很明显, 解码器的资源暴露了来源: 公司是Strongene, 产品名称为Lentoid Codec, 版本是2.0.0.10 很快就找到所属的官方网站: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fxhevc.com&urlrefer=4c37cf389ace83d16a429300d2771ff2 和介绍的一样, 是和北京大学计算机科学技术研究有关联的新公司, 以视频和图像编码技术为核心. 网站提供了简单的技术介绍、视频样本和解码器, 和我下载到的一模一样, 可惜没有公开编码器. 技术介绍中值得一提的是"比H.264少一半的码率提供相同清晰度", "编码器仅比x264慢5倍", 并没有提到解码器性能慢多少, 只能自己来测试了. 视频样本有源版以及和x264编码对比的各种分辨率样本, 至少大家能自己来测试的对比这个HEVC的质量, 即使没有编码器. (待续)

vp9 最近发现google vp8的下一代视频编码vp9已经是可用状态了, 但还没有正式发布. 听说vp9标准添加了很多特性, 虽然仍然不支持B帧和多参考帧, 但对intra帧应该有很多改进, 如果测试画质能达到x264的效果, 那么uci有可能改用vp9内核. 这里给大家提供了当前最新版本的win32平台编译版本, 有兴趣的可以测试一下图像和视频的编解码编译器: MinGW-gcc 4.7.2-1 + msys 1.0.18-1 编译参数: --target=x86-win32-gcc --disable-vp8 --enable-vp9 --disable-multithread --disable-unit-tests vp9版本: v1.2.0-1547-gb46d58a 下载地址: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu.com%2Fshare%2Flink%3Fshareid%3D234363%26uk%3D2047110340&urlrefer=9b283a893f858a7a9ff3fab572c8bac6 PS: xiph也有个正在开发的视频编码项目daala, 据说也是下一代视频编码, 和vp9都是与h.265(hevc)竞争的无专利编码, 但目前进度缓慢, 完成度还差很多, 暂时观望.

百度云网盘进驻由于115的不稳定,已经不再维护上面的文件, 以后将主要在百度网盘发布文件这是我的邀请链接(如果想申请网盘的话可以点这个,不过我已经有60多G的空间,不是很在乎大小了) http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fpan.baidu.com%2Fdisk%2Fbeinvited%3Fuk%3D2047110340&urlrefer=be320ede60bb61c10337c0ff6bf4500b

UCI 0.521 此版本没有功能变化,是时隔半年的维护版本 0.521(2012-07-06) 更新Libav,使用MinGW-GCC 4.7.1编译下载: 115。com/file/be1nrfjj www。kuaipan。cn/file/id_22946077527245244.html 前一版本(0.52)发布贴: http://tieba.baidu.com/p/1380574262 0.4 版发布贴: http://tieba.baidu.com/p/586018069 UCI相关介绍: http://tieba.baidu.com/p/511089688

迅雷xv格式视频解密的lua脚本 -- 迅雷xv格式视频解密的lua脚本,仅供娱乐 s=io.open(arg[1],"rb")s:seek("set",2097152)h=s:read(1024)a,b,c =h:byte(1,3)a=a-70 if b-a~=76 or c-a~=86 then print"bad file!" return end d=io.open(arg[2],"wb")for i=1,1024 do b=h:byte(i)-a d:write(string.char(b%256))end while 1 do a=s:read(0x100000)if not a then break end d:write(a)end s:close()d:close()print"OK"

UCI 0.52 0.52 (2012-01-19) 更新Libav,编码时YUV通道改用10bit输入,同时支持8/10bit x264编码及解码,支持指定x264的程序名,调整默认参数,取消支持非全范围YUV的编码及无用的Y通道修下载: 115.com/file/anh53yyf www.kuaipan.cn/index.php?ac=file&oid=22946077527245058

百度贴吧监视器 0.43 0.43(12-01-18): 支持新版贴吧,一些细节改进. 115.com/file/e7zecdl0

【高亮】Rewrite 共通线汉化补丁V2发布！此补丁仍然只有共通线, 改进如下: 1.大量文本错误修正（包括贴吧到现在为止反馈的问题） 2.修正和追加部分汉化图片 3.使用专用的补丁安装程序, 自动查找安装位置（原版需要正常途径安装，绿色版仍然要自己选择安装补丁的位置） 4.更新说明文件这次直接给115提取码: bh0j9mjj 如果发现任何补丁的安装和运行问题，请在下面跟贴。文字错误仍然发到之前的楼: http://tieba.baidu.com/p/1226901762

UCI 0.51 0.51 (2011-09-11) 更新Libav,增加解码的JNI接口和Java的使用例子,一些细节改进下载地址: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2F115.com%2Ffile%2Fe6586o5h&urlrefer=09494b4e52e73713f8cf0f644ec93d7c 前一版本(0.5)发布贴: http://tieba.baidu.com/p/1159614744 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

UCI 0.5 0.5 (2011-07-29) 更新Libav,新增4种格式的编解码,支持全范围YUV映射,直接支持H.264的YUV444编码,取消支持以前的YUV444编码,更新默认subme参数为11 下载地址: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fu.115.com%2Ffile%2Fe6y4sh8d&urlrefer=1014928eca34e389a0f3a899cd34a278 前一版本(0.494)发布贴: http://tieba.baidu.com/p/1142484454 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

UCI 0.494 0.494(2011-07-15) 更新Libav,增加UCIDebug接口,改用MinGW-GCC 4.6.1编译这个版本由于使用GCC编译,并且加入所有的汇编优化,所以解码器体积非常大,但解码速度会比以前略有提升.如果对体积有需求,请使用前一版本.因为下一版本可能要考虑使用H.264本身的4:4:4来处理原始采样,目前无法保证会与之前版本兼容,所以此版本可能是保持向后兼容的最后一个版本了. 下载地址:http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fu.115.com%2Ffile%2Fbh5dscwd%23&urlrefer=67962aaef94b83ced4c43f1fe9041a5d

x264 刚刚加入 4:4:4 编码和 RGB 编码嗯...看来要找时间测试一下, 没问题之后准备改造UCI.

LuaJIT 真是个给力的项目 LuaJIT的git上最新版本刚刚支持了字节码的导出和运行, 到现在LuaJIT在功能上已经很完善了. 它的字节码设计,字节码文件格式的设计都比官方Lua好很多,无论是解释还是编译,运行性能都高于原版Lua,而且一直是一个人持续近5年的开发,仅仅依靠的是不多的资金捐助,真是很令人敬佩. 至于我的基于官方Lua 5.2的lua-lab项目,一些特性已经在LuaJIT中支持,还有一些特性很容易在LuaJIT用其它方法实现,剩下的特性意义不是很大,所以不打算再继续更新和开发了,推荐以后用LuaJIT代替官方Lua开发相关项目.

Lua 语言终于挤入编程语言排行前十这是著名的TIOBE统计结果:http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.tiobe.com%2Findex.php%2Fcontent%2Fpaperinfo%2Ftpci%2Findex.html&urlrefer=607c1eda6a5f652fdaaa6478e12c5cdc 当然这个靠搜索引擎计算流行度偶尔会受到一些著名项目的影响, 比如 Angry Birds

UCI 0.493 UCI进入维护期,不定期更新维护版本 0.493(2011-03-13) 更新FFmpeg,改用VC2010(sp1)编译,编码质量的范围从1~50改为0~51,修正0.492版质量0的alpha通道的解码问题,增加LuaJIT的使用例子下载地址: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fdl.dbank.com%2Fc0336cxsd8&urlrefer=1b8e46c909a1ca09e5f8e9d7c328d704 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.rayfile.com%2Fzh-cn%2Ffiles%2F3191df61-4d12-11e0-8c51-0015c55db73d%2F&urlrefer=67d73a25523c9b3dc7a2d0428c8d21ad http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fu&urlrefer=ee9660235a2dfa0db796b5c492998114。115。com/file/f3eaafe7bf

LuaJIT - FFI 前几天开始关注新版 LuaJIT 的时候, 发现增加了一个新的库 FFI, 把本地静态语言很巧妙地和 Lua 这种纯动态语言结合在一起, 让脚本级别的语言拥有C语言几乎所有的控制能力. 声明和调用C函数(自动透明地转换和访问): local ffi = require("ffi") ffi.cdef[[ int MessageBoxA(void *w, const char *txt, const char *cap, int type); ]] ffi.C.MessageBoxA(nil, "Hello world!", "Test", 0) 创建和使用C结构体(和C二进制兼容的格式): local ffi = require("ffi") ffi.cdef[[ typedef struct { uint8_t red, green, blue, alpha; } rgba_pixel; ]] local n = 100 local img = ffi.new("rgba_pixel[?]", n) for i=0, n-1 do img[i].green = i img[i].alpha = 255 end 对动态/脚本语言有兴趣的可以在这里讨论一下看法

x264 Main Profile VS High Profile Mencoder x264 r1834 param: ......:no8x8dct:profile=main x264 [info]: profile Main, level 3.0 Video stream: 486.932 kbit/s (60866 B/s) size: 401517734 bytes 6596.697 secs 197704 frames x264 [info]: frame I:891 Avg QP:23.44 size: 19783 x264 [info]: frame P:101883 Avg QP:26.86 size: 3271 x264 [info]: frame B:94929 Avg QP:32.80 size: 533 param: ......:8x8dct x264 [info]: profile High, level 3.0 Video stream: 528.301 kbit/s (66037 B/s) size: 435629881 bytes 6596.697 secs 197704 frames x264 [info]: frame I:891 Avg QP:23.45 size: 18876 x264 [info]: frame P:101883 Avg QP:26.80 size: 3574 x264 [info]: frame B:94929 Avg QP:32.75 size: 577

wininet的严重bug http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fsupport.microsoft.com%2Fkb%2F263754%2F&urlrefer=6d31df0218089981ed08a74ea6be9e71 今天碰巧遇到了,微软7年多都没修复,看来wininet这个经典的HTTP接口改抛弃了.

UCI 0.491 UCI进入维护期,不定期更新维护版本 0.491 (2010-11-13) 更新FFmpeg 下载地址见下面跟贴

UCI 0.49 0.49 (2010-07-26) 更新FFmpeg,支持新版x264设置图像大小的参数 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F7e4fd2f86d22c0aafc39e02c6da019e7&urlrefer=42ebe0573591bd873767b9b8da0a8288 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fu.115.com%2Ffile%2Ft0e780d8c3&urlrefer=ef6e3bf300fc693a7a40c8c4cf794a8b 0.48 版发布贴: http://tieba.baidu.com/f?kz=777235398 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

DirectX June 2010 DirectX End-User Runtimes (June 2010) http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F8%2F4%2FA%2F84A35BF1-DAFE-4AE8-82AF-AD2AE20B6B14%2Fdirectx_Jun2010_redist.exe&urlrefer=52cea9124c2d1d923f22c13531c11dae DirectX SDK (Software Development Kit) (June 2010) http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FA%2FE%2F7%2FAE743F1F-632B-4809-87A9-AA1BB3458E31%2FDXSDK_Jun10.exe&urlrefer=eb702394b8bdcec10b03c78e474764d3 这个版本的DirectX增加了VS2010的支持, 貌似不再支持VS2005了. 另外还发现和上一版本的SDK相比, DirectDraw的开发支持被去掉了.

使用chrome浏览贴吧的bug: 粘贴文字会丢换行符在发帖内容框里粘贴文字,会丢掉大部分换行,只有连续两个换行会变成一个换行

UCI 0.48 0.48 (2010-05-22) 更新FFmpeg,取消了作用不大的PGO优化,修正编码器对新版x264输出无用信息的消除,修正yuv2bmp对YUV420处理的严重bug http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2Fb4135bfd026deaafef3287d0acf5bf19436bfb84d0140600http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F1c5c72ac4b7e2876f80d73c442545796&urlrefer=bcfd17a91940b7a16bc482f8cc279226 0.4 版发布贴:http://tieba.baidu.com/f?kz=586018069 0.47 版发布贴:http://tieba.baidu.com/f?kz=741006363 UCI相关介绍:http://tieba.baidu.com/f?kz=511089688

UCA 0.14 和UCI类似,UCA的目标最佳低码率高质量的语音编码,以弥补HE-AAC在此领域的不足. 当前使用的是AMR-WB+的编解码内核实现,由于目标只是语音,所以编码只锁定在单声道,码率范围在10~24kbps,有效采样率在24~38kHz. 0.14 公开测试版本(包含命令行的编解码器,解码DLL等): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2Fa5850c382ed524e7ec4d7d7e57c73e1e&urlrefer=dfdb4b5eb56031fcf90a6ace0f2b91ea http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F9cae09ffd44379cd551151504671078797db2363bd1d0200&urlrefer=c32266a694a13bb7afc830f8478a8a13 0.14 (2010-05-08) 支持2种采样率输出,支持指定输出长度,修正几个细微bugs 0.13 (2010-04-29) 重新定义编码器参数,修正解码器对非标准isf的解码问题,全部使用VC2008编译 0.12 (2010-04-18) 修正输入过小文件无法编码的问题,去掉了不使用的编码器参数支持,暂时全部使用VC2003编译 0.11 (2010-02-01) 解码器改用VC2010(beta2)编译,修正编码时缺少结尾0.1秒音频的bug 0.1 (2009-09-19) 初始公开测试版本 0.13 版发布贴: http://tieba.baidu.com/f?kz=760119653 0.1 版发布贴: http://tieba.baidu.com/f?kz=644960305 PS: 这个版本支持新的解码参数,为了兼容以前的版本,新的解码函数是UCADecode2,以前的UCADecode保持不变. 输出的WAV暂时只支持44.1kHz及48kHz.

UCA 0.13 和UCI类似,UCA的目标最佳低码率高质量的语音编码,以弥补HE-AAC在此领域的不足. 当前使用的是AMR-WB+的编解码内核实现,由于目标只是语音,所以编码只锁定在单声道,码率范围在10~24kbps,有效采样率在24~38kHz. 0.13 公开测试版本(包含命令行的编解码器,解码DLL等): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F0612313b9ce7c233c2c33b9662a89f70&urlrefer=2a338b862b944808564439cc88b33536 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F63f85594b13d5ee1f50a1d35725207eade75574394180200&urlrefer=56cc31b836eadae850cc1e9b8a340a47 0.13 (2010-04-29) 重新定义编码器参数,修正解码器对非标准isf的解码问题,全部使用VC2008编译 0.12 (2010-04-18) 修正输入过小文件无法编码的问题,去掉了不使用的编码器参数支持,暂时全部使用VC2003编译 0.11 (2010-02-01) 解码器改用VC2010(beta2)编译,修正编码时缺少结尾0.1秒音频的bug 0.1 (2009-09-19) 初始公开测试版本 0.12 版发布贴:http://tieba.baidu.com/f?kz=751587134 0.1 版发布贴:http://tieba.baidu.com/f?kz=644960305 PS: 注意这个版本的编码参数有变化, mi的取值范围由16~23改成0~7, isf的取值范围由0.5~1.5改为-7~5,而以前的isf虽然为浮点值,但实际会从13个离散值中选择,所以改成整数参数更为直观. -mi简化成-m, -isf简化为-f, 而且-m和-f的默认参数分别为1和0

UCA 0.12 和UCI类似,UCA的目标最佳低码率高质量的语音编码,以弥补HE-AAC在此领域的不足. 当前使用的是AMR-WB+的编解码内核实现,由于目标只是语音,所以编码只锁定在单声道,码率范围在10~24kbps,有效采样率在24~38kHz. 0.12 公开测试版本(包含命令行的编解码器,解码DLL等): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2Fe512bb4532c5c6899176ffaafc15f9ce&urlrefer=875389e2964dc7756863f03406227b85 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F9249fa29da986d7fb2a3661216785c85fb9fbc3ca1860200&urlrefer=186618b5889d9627a0b3c588cd72620b 0.12 (2010-04-18) 修正输入过小文件无法编码的问题,去掉了不使用的编码器参数支持,暂时全部使用VC2003编译 0.11 (2010-02-01) 解码器改用VC2010(beta2)编译,修正编码时缺少结尾0.1秒音频的bug 0.1 (2009-09-19) 初始公开测试版本 0.11 版发布贴:http://tieba.baidu.com/f?kz=705298827 0.1 版发布贴:http://tieba.baidu.com/f?kz=644960305

UCI 0.47 0.47 (2010-04-03) 更新FFmpeg,启用PGO优化,取消了作用不大的MMX优化 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2Fd8ebf25b06397e2da5e099b883609da86e0058ae200e0600&urlrefer=706460eea0ec467b63a55a51e286588f http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F1d3f2e3a8b5e461a0367c7015023dd49&urlrefer=d30e38006154f352a51ab7eb4187c343 0.4 版发布贴:http://tieba.baidu.com/f?kz=586018069 0.46 版发布贴:http://tieba.baidu.com/f?kz=728472585 UCI相关介绍:http://tieba.baidu.com/f?kz=511089688 PS: 为了PGO,使用了4种类型的典型图做试验,不过最后PGO优化的结果也并不很明显.

UCI 0.46 0.46 (2010-03-13) 更新FFmpeg,改用VC2010(rc1)编译 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F9c1f4550a3b6fed023c970c59ee004e6f9c4125386fc0500&urlrefer=6383d06afba560a5682d0a86dafc2260 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F1f4cba9664dc744596824301dd611627&urlrefer=9427ea98c2843d88f13491778ea8fc93 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 0.45 版发布贴: http://tieba.baidu.com/f?kz=697265765 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

建了一个开源项目: lua-lab http://tieba.baidu.com/mo/q/checkurl?url=https%3A%2F%2Fcode.google.com%2Fp%2Flua-lab%2F&urlrefer=9bbddc7d754128c3e998c700ca567698 Lua 编程语言内核的实验性扩展项目。增加或修改一些代价低、实用性强的一些功能。刚刚加入了 Lua 5.2(work2)的官方源码, 以后有时间会陆续做修改. 如果有对 Lua 感兴趣的, 可以提一些建议.

Visual Studio 2010 RC / .NET 4.0 RC 开放下载前一段时间据说只提供给MSDN用户,不过貌似直接公开了: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fmsdn.microsoft.com%2Fen-gb%2Fvstudio%2Fdd582936.aspx&urlrefer=6ed6e54e73f348a5bb9b04e80e290ce7

DirectX Feb 2010 Runtime Library: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.microsoft.com%2Fdownloads%2Fdetails.aspx%3FFamilyID%3D0CEF8180-E94A-4F56-B157-5AB8109CB4F5%26displaylang%3Den&urlrefer=8ebf0a32bd3e43f05ddd7eb0493c94ad SDK(为避免正版验证,直接给出下载链接): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FF%2F1%2F7%2FF178BCE4-FA19-428F-BB60-F3DEE1130BFA%2FDXSDK_Feb10.exe&urlrefer=be943ae0744beec98deda056e2925110 这个版本的DirectX貌似不支持XP SP2了,而支持XP SP3.具体支持的系统如下: Supported Operating Systems: Windows 7; Windows Server 2003; Windows Server 2008; Windows Vista; Windows XP 64-bit; Windows XP Service Pack 3 而且也声明下一版本将支持VS2010,同时取消支持VS2005.

UCA 0.11 和UCI类似,UCA的目标最佳低码率高质量的语音编码,以弥补HE-AAC在此领域的不足. 当前使用的是AMR-WB+的编解码内核实现,由于目标只是语音,所以编码只锁定在单声道,码率范围在10~24kbps,有效采样率在24~38kHz. 0.11 (2010-02-01) 解码器改用VC2010(beta2)编译,修正编码时缺少结尾0.1秒音频的bug 0.1 (2009-09-19) 初始公开测试版本 0.11 公开测试版本(包含命令行的编解码器,解码DLL等): http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2Facb56ccea5353561937e44a205b508c74aaea46d23b60200&urlrefer=93c1c714d1def05a9a801ab34a6410bc http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2F7592d5ac1c0737167b18e2bb0f55e756&urlrefer=b39e27a7cf471afd2e99c6c634c03249 0.1 版发布贴: http://tieba.baidu.com/f?kz=644960305 PS: 1. 编码器使用VC2010编译后,编码结果不正常,原因以后找时间再查 2. 编码后的音频是以帧为单位的,每帧80毫秒,0.11版在编码时如果不足一帧采样,会扩展成一帧

UCI 0.45 0.45 (2010-01-17) 更新FFmpeg,修正前一版本的几个bug(0.44版发布贴里发现的bug) http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F05058083b75270b8a27b1ff03a60cbccb095e0224afa0500&urlrefer=0cf1d8f6d57b99e6c85930077656d554 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.brsbox.com%2Ffilebox%2Fdown%2Ffc%2Fad4086182b21fc298346ca077cb35685&urlrefer=d12981aa77691d25fd70d110b289de5d 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 0.44 版发布贴: http://tieba.baidu.com/f?kz=680823043 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

百度贴吧: http://61.135.163.220 (仅供应急之用) 百度首页: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2F220.181.6.19%2F&urlrefer=7d77b9527a697c2bc3ef595641ac6ee0 http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2F220.181.6.18%2F&urlrefer=ee8887c7fc879b4a147184fcdb636d88 (可能经常换) 百度贴吧: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2F61.135.163.220%2F&urlrefer=68dae0c737d4fbc8f9c71359abe43c8a 百度百科: http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2F61.135.163.86%2F&urlrefer=80bd215e01e26ed2742c239ad0fee603 Google DNS 8.8.8.8 8.8.4.4 OpenDNS 208.67.222.222 208.67.220.220

关于SSE指令的优化问题今天才发现辛辛苦苦找的查表优化的整数开方算法性能还不如用SSE里的浮点整数转换+sqrtps指令. 不过之后又发现一个怪现象. 连续几次做开方运算,每次前后加rdtsc取时间,并printf显示. 结果第一次计算不到100cycles(这个足够快了),后几次都是1000+cycles. 然后我在程序最前面加了一个printf("aaa"),结果都是1000+cycles了. 难道SSE指令还会受到某些因素的影响而降低效率? 注: 开方运算放到单独的一个函数里执行,rdtsc包括函数调用开销,rdtsc统计内的代码除函数调用外没有分支. 我想这里有对SSE熟悉的朋友,想想原因.

UCI 0.44 0.44 (2009-12-12) 更新FFmpeg,改用VC2010(beta2)编译,使用线性插值改进YUV420到RGB的转换,修正访问susie插件接口可能导致崩溃的bug http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.dmpan.com%2Ffile%2F4azLt2M.html&urlrefer=7b12f04188f2ab6515100ba780dbd40c http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2F8c877a7adf53039f8c702a1f6c57175731002faf34f40500&urlrefer=ec15ee61f5036ecaae62b79d73c13f5f 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 0.43 版发布贴: http://tieba.baidu.com/f?kz=674604180 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

Visual C++ 编译选项 /QIfist 的一处 bug Visual C++ 开启 /QIfist 选项可以提高浮点数取整的速度, 精度可能会有影响, 但今天却碰巧发现了一处很严重的问题. 下面两行代码应该都显示 -1.0 才对, 但如果开启 /QIfist, 前者是正确的, 而后者会输出 -2.0. 我想这不是精度的问题, 而是bug才对. printf("%f\n", (float)(int)(-1.5)); printf("%f\n", (float)(int)atof("-1.5")); 已测试 VC6, VC2003, VC2010 均能重现 (注意在编译选项中加入参数"/QIfist")

计算字符串表达式的程序因为有时候要用,所以写了一个,本以为会比较复杂,从编译原理的思想入手,但转个方向感觉算法其实是可以很简单的,于是随手写了一个. 支持范围:简单浮点数的+-*/运算和多层括号的支持,如果数值前要加+-号,必须用()括起来,如(-3). 表达式例子: 25/((2+3)*5)+(4-(1+2)) double CalcNative(const char*& p, int dep = 0) { for(double a = 0.f;;) switch(*p) { case '+': if(dep) return a; a += CalcNative(++p, 1); break; case '-': if(dep) return a; a -= CalcNative(++p, 1); break; case '*': if(dep > 1) return a; a *= CalcNative(++p, 2); break; case '/': if(dep > 1) return a; a /= CalcNative(++p, 2); break; case '(': a = CalcNative(++p); break; case ')': if(dep) return a; ++p; case 0: return a; default: if(*p >= '0' && *p <= '9') for(a = atof(p++); *p >= '0' && *p <= '9' || *p == '.'; ++p); else ++p; } } double Calc(const char* p) { return CalcNative(p); } PS: 这个程序只为代码量优化,不考虑速度

UCI 0.43 0.43 (2009-11-28) 更新FFmpeg,改用VC2010编译,去掉了一些无用的容错处理(减小体积并可能提升解码速度) http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fwww.dmpan.com%2Ffile%2F4W8AKNC.html&urlrefer=b24ed15fe290ecd2dab77964f9afa44a http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Fd.namipan.com%2Fd%2Fa4ffb28ac6a6dc353e5f7dd99a31e5428d58f01202e10500&urlrefer=7fe9500e4bc51adce942b77e834629d1 0.4 版发布贴: http://tieba.baidu.com/f?kz=586018069 0.42 版发布贴: http://tieba.baidu.com/f?kz=608539944 UCI相关介绍: http://tieba.baidu.com/f?kz=511089688

无意中发现VC6/VC2003的编译器有严重bug // VC6/VC2003 使用/O2编译(默认的release模式), 输出结果有"impossible!!!" #include <stdio.h> int main() { static const int T[1] = {0}; int n = 0; for(int i = 536000000; i < 536000004; ++i) { if(i < 0) { printf("impossible!!!\n"); break; } if(i >= 0 && i < 1) n += T[i]; } printf("end\n"); getchar(); return n; }

超越极限的图像压缩?! 说是图像压缩有点牵强.不知道还有多少人关注demo界.现在经常有用shader程序渲染静态图的小demo. 下面就是一个例子,生成这张图的程序只有3.9KB,而且可以生成和屏幕一样分辨率的图,我生成的1440x900即使用UCI默认质量去压缩也有74KB. 程序下载: ftp://ftp.untergrund.net/users/stan_1901/Watering.rar

Memories Off Duet 到手结果又发现这字体 - -

放几个关键词看看会不会有人搜索到这里 strSavedKey strSavedName bSysLocalHash bValidInit bufSvrSealEnc bufRandKeyEnc PS: 不清楚含义的请不要回帖.