0.51 (2011-09-11) 更新Libav,增加解码的JNI接口和Java的使用例子,一些细节改进
下载地址: http://115.com/file/e6586o5h
前一版本(0.5)发布贴: https://tieba.baidu.com/p/1159614744
0.4 版发布贴: https://tieba.baidu.com/f?kz=586018069
UCI相关介绍: https://tieba.baidu.com/f?kz=511089688


nice,加了java例子
不过那个颜色值按什么顺序排的啊，RGB三个byte顺着?
貌似怎么组都还原不出颜色

readme.txt中介绍UCIDecode接口中dst参数的注释中已经提示了: 输出RAW数据的指针(BGR或BGRA格式)
就是说按照BGR和BGRA的次序排列各个字节.

编解码参数差别很大,所以不方便集成使用,另外解码核心统一使用ucidec.dll

现在编码器和解码器各自的代码量都不少, 而且几乎没什么交**并在一起意义不大.
其实很少有编码器和解码器集成在一起的, 大部分都是分开的.

为什么我用10bit的x264反而变大了 - -
是不是10bit不能减少体积？

我一开始就觉得使用10bit能节省码率就是一种误解, 如果能节省, 那么所有8bit都可以转换成10bit编码来节省码率.

还想请问下x264里面的--fps是个什么概念，这个不是控制播放间隔的吗？
为什么同样只有的一帧的情况下设置fps越高文件越小，难道fps还会影响质量？

我刚在UCI里测试过, --fps不会影响结果.

C:\Documents and Settings\Administrator\桌面>x264 --crf 25 -b 0 -r 0 -f 0:-4 -m11 -t 2 --8x8dct --psy-rd 0.0:0.0 --threads 1 --fps 100 -o test.264 test_1440x900.yuvyuv [info]: 1440x900p 0:0 @ 100/1 fps (cfr)x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2x264 [info]: profile High, level 4.2x264 [info]:x264 [info]: started at Sat Sep 17 03:43:05 2011x264 [info]: frame I:1 Avg QP:38.94 size: 65354x264 [info]: mb I I16..4: 13.5% 71.3% 15.2%x264 [info]: 8x8 transform intra:71.3%x264 [info]: coded y,uvDC,uvAC intra: 85.0% 52.2% 16.1%x264 [info]: i16 v,h,dc,p: 8% 7% 56% 29%x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 15% 7% 10% 6% 13% 7% 23%x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 9% 10% 7% 13% 6% 13% 7% 21%x264 [info]: i8c dc,h,v,p: 15% 49% 15% 21%x264 [info]: kb/s:52283.20
encoded 1 frames, 1.49 fps, 52283.20 kb/sx264 [info]: ended at Sat Sep 17 03:43:05 2011x264 [info]: encoding duration 0:00:00
C:\Documents and Settings\Administrator\桌面>x264 --crf 25 -b 0 -r 0 -f 0:-4 -m11 -t 2 --8x8dct --psy-rd 0.0:0.0 --threads 1 --fps 25 -o test.264 test_1440x900.yuvyuv [info]: 1440x900p 0:0 @ 25/1 fps (cfr)x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2x264 [info]: profile High, level 4.0x264 [info]:x264 [info]: started at Sat Sep 17 03:43:59 2011x264 [info]: frame I:1 Avg QP:33.83 size:131551x264 [info]: mb I I16..4: 10.0% 57.5% 32.5%x264 [info]: 8x8 transform intra:57.5%x264 [info]: coded y,uvDC,uvAC intra: 96.1% 65.4% 30.1%x264 [info]: i16 v,h,dc,p: 8% 3% 65% 24%x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 8% 12% 13% 8% 10% 6% 13% 7% 24%x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 10% 9% 7% 12% 6% 15% 7% 23%x264 [info]: i8c dc,h,v,p: 41% 28% 12% 19%x264 [info]: kb/s:26310.20
encoded 1 frames, 0.87 fps, 26310.20 kb/sx264 [info]: ended at Sat Sep 17 03:44:00 2011x264 [info]: encoding duration 0:00:01
上面--fps 100 64k
下面--fps 25 128k
试了下x264.nl和direct264版本的都是这结果


我在UCI里使用了上面的参数,在fps分别是1,25,100的情况,结果都完全相同.
x264版本是x264.nl的2074版

我也用的这版本，见鬼了..
看输出信息
yuv [info]: 1440x900p 0:0 @ 100/1 fps (cfr)
yuv [info]: 1440x900p 0:0 @ 25/1 fps (cfr)
是不是x264转换同一个yuv文件时用了不同的方法？

里面那个imgdec挺好用的
只是不能准确检测是否真正带alpha
比如把没有alpha的png32转成bmp结果是bmp32
能不能在转的时候根据实际alpha判断？
或者能不能加上强制全转成bmp32？

嗯...这个问题找时间看看

没见过无alpha的png32, 能否给个例子?

就是alpha全是0xff的png32
dl.dbank.com/c0aawnu10u

还有就是png8，调色板alpha全为0xff的时候

如果是png32,那只能转换成bmp32, 如果只想要bmp24,那就先把png32转成png24, 智能转换全0xff的alpha不是imgdec的职责, 毕竟有的时候用户就是想要alpha全0xff的bmp32.
至于png8,透明色好像是由用户(或解码软件)决定的,不是png文件本身描述是否有透明, 所以只能这就不好解决, 可以在imgdec中加入参数来指定, 不过可以先用nconvert来处理.

我个人想法是这样，你看看对不对
因为大多数情况下用户并不知道原始图真正定义，比如png8,png24,png32
假设我要使用uci，那我首先会用imgdec把png转成bmp，然后使用ucienc
而这样转出来的uci带上了不必要的alpha通道
不但增加了文件的体积，还增加解码的复杂度


如果要不造成这种情况，就必须把alpha全为0xff的图转成非透明图
只是要决定这个过程放在用户端，还是imgdec，还是ucienc
个人觉得uci意在减少体积，放在用户端不太好
而ucienc只能处理bmp24或bmp32，而拿到bmp32时还要再检测一下
所以我觉得还是放在imgdec比较好一点