0.48 (2010-05-22) 更新FFmpeg,取消了作用不大的PGO优化,修正编码器对新版x264输出无用信息的消除,修正yuv2bmp对YUV420处理的严重bug
http://d.namipan.com/d/b4135bfd026deaafef3287d0acf5bf19436bfb84d0140600http://www.brsbox.com/filebox/down/fc/1c5c72ac4b7e2876f80d73c442545796
0.4 版发布贴:https://tieba.baidu.com/f?kz=586018069
0.47 版发布贴:https://tieba.baidu.com/f?kz=741006363
UCI相关介绍:https://tieba.baidu.com/f?kz=511089688


重贴链接:
http://d.namipan.com/d/b4135bfd026deaafef3287d0acf5bf19436bfb84d0140600
http://www.brsbox.com/filebox/down/fc/1c5c72ac4b7e2876f80d73c442545796

这东西好是好，
就是对很多人来说，上手太难，
我小白写个使用说明
将以下文件复制到图片所在目录
imgdec.exe
x264.exe （这个在 http://x264.nl/ 上可以下载）
ucienc.exe
在图片目录下新建一个BAT文件
将以下内容写入，保存
for%%a in (*.jpg;*.png;*.bmp;*.gif;*.tga) do imgdec %%a - | ucienc - -o%%~na.uci -x "--crf 27.0 --thread-input --threads 1 --keyint 1--min-keyint 1 --bframes 0 --ref 1 --no-mbtree --aq-strength 0.6--merange 256 --me tesa --subme 10 --trellis 2 --psy-rd 0.00:0"
运行该BAT文件即可将该目录下的图片文件转换成UCI文件。
调整生成uci文件的质量，
--crf 27.0
27.0这个数字，可以修改为1-50之间任意数字，支持小数点后一位，数字越小，画质约好。
如果对色彩要求很高，建议添加参数 -s，让X264.exe 用yuv 4:4:4比色法
即
for %%a in (*.jpg;*.png;*.bmp;*.gif;*.tga) do imgdec %%a - | ucienc --o %%~na.uci -s -x "--crf 27.0 --thread-input --threads 1 --keyint 1--min-keyint 1 --bframes 0 --ref 1 --no-mbtree --aq-strength 0.6--merange 256 --me tesa --subme 10 --trellis 2 --psy-rd 0.00:0"


--subme 10
和9比起来我仍然没看出有什么改进(应该说是有得有失,综合起来并没有优势), 因为10目前是实验性质的,所以默认参数仍然使用9

我在用 pageheap 调试程序的时候多次发现 ucidec.dll 读取了超过原始长度的数据，
必须分配原始大小
+3
2左右的内存才不会出错
但我再用 pageheap 让 ucidec.exe 解码同一个 uci 时又不出错了……

出错的UCI：
u. 115. com/file/
t138f6a81b

嗯, 解码时超越uci数据读的问题已经发现, 在ffmpeg的get_cabac函数里. 上面的例子只多读了2个字节. 即使把传给ffmpeg数据长度减少几个字节也不能避免. 应该是ffmpeg的bug.
如果不去分析和修改ffmpeg就没有很好的解决办法.
临时的办法有2个:
1.输入数据的结尾留出一些空间
2.ucienc给输出数据追加几个字节

不过一般来说, malloc分配内存会在开头和结尾存一些数据, 多读8个字节以内估计不会有问题.

嗯，以前从来没有察觉，只是这回为了找内存溢出的bug用了pageheap才发现的

pageheap 能监视程序是否读过界? 这个功能很强大.

查了一下资料,了解了pageheap的原理,很聪明的做法, 不过没办法判断向前读过界.

pageheap /?
FLAGS hex value (0x...) has the following structure:
    B7-B0   Bit flags    1 - enable page heap
         01 - enable page heap. If zero normal heap is used.
              In 99% of the cases you will want this to be set.
         02 - collect stack traces (default on checked builds)
         04 - minimize memory impact
         08 - minimize randomly(1)/based on size range(0)
         10 - catch backward overruns
    B15-B8 Percentage of available memory from total memory below
            which allocations will be made from normal heap. Used
            in conjuction with bit flag 04.
    B31-B24 Probability for page heap allocation. Bit 4 and 8 must
            be set.
    B31-B24 Size range start
    B23-B16 Size range end
            Allocations in this size range will be made in page heap.
            Bit 4 must be set and bit 8 must be reset.
就是只要
pageheap /enable PROGRAM 0x10
就可以检查向前读过界了

受到DWING大人指点，BAT 修改如下
for %%a in (*.jpg;*.png;*.bmp;*.gif;*.tga) do imgdec "%%a" - | ucienc - -o "%%~na.uci" -x "--crf 27.0 --thread-input --threads 1 --keyint 1 --min-keyint 1 --bframes 0 --ref 1 --no-mbtree --aq-strength 0.6 --merange 256 --me tesa --subme 9 --trellis 2 --psy-rd 0.00:0"
这样修改，可以支持文件名中带空格。
--subme 改为9


我的makeuci.bat一般是这样的
set /p crf=please input crf value[22]:
if "%crf%" == "" set crf=22
For /r %%i IN (*.jpg *.jpeg *.png *.bmp) DO imgdec "%%~fi" -|ucienc - -o "%%~dpni.uci" -q %crf% -info 2>>convert.log
加到系统%PATH%里面，然后调用makeuci，输入crf，直接回车crf就是22
不过ls参数写得很具体，真的有用吗？


参数写得很具体，也没啥用。
另外，能具体讲下“加到系统%PATH%里面”怎么加么？
还有就是，调用makeuci怎么调用？
谢谢。

win+break->高级->环境变量->系统变量，把makeuci.bat,ucienc,x264所在目录加到Path变量里面去就可以了。找到你要转的目录，随便选张图片，右键->打开方式->选择makeuci.bat->确定就可以了。

试验成功，非常感谢。

处理图片的时候有这么两种情况：
·有一张底图，剩下的图片都是这张底图做了局部变化后得来的
那么设想下一版本的UCI可否这样使用P帧：
ucienc增加一个参数，接受两张输入图片，以第一张为基底得到第二张的P帧，保存第二张为UCI，舍弃第一张的数据（第一张可以用旧的参数得到I帧版的UCI）
ucidec的解码函数接受一个BITMAP数据的输入，以此为参考帧与UCI中的P帧合成输出的结果
至于UCI文件间的关联，可以加上原基底图的文件名来作为关联的参考，也可不加，由第三方程序来管理
·D大可知MNG这格式？有的图片格式内其实由多张相似的图片组成
像GIF这种的多帧图片UCI也可以实现吧
（不过增加了帧速率之类的控制数据就不好组织了）


回复22：
想法是很好的. 其实即使不利用P帧也可以, 可以自己做两张图的差值图, 然后对其单独压缩, 也就是说可以在UCI层之上去做. 而UCI本身目前还不打算做高层开发.
至于目标是动画的情况, 还不如直接压成H.264吧.

对，我现在是自己做了个封装来标记两图的差分数据，用UCI来压缩
但这样做的话边缘部分还是产生了锐利的高频信息，效率大不如264原生的P/B帧来得好……