博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
JM编解码264
阅读量:4948 次
发布时间:2019-06-11

本文共 2027 字,大约阅读时间需要 6 分钟。

看到有人说JM解码编码264 尝试了一下
win7下 vs2010 编译后,得到编码解码可执行文件ldecod.exe lencod.exe
还是使用原来测试编码265的视频序列
这里的264是之前使用X264编码的。

本机环境:
Intel Core i5-3470 3.2GHz 4核心
RAM 4GB
WIN7 SP1 32位的

 

解码部分结果如下:

>ldecod.exe -d default.cfg -p InputFile="g:\multimedia\video\720p50_shields_ter.h264" -p OutputFile="shields.yuv"
-------------------- Average SNR all frames ------------------------------
 SNR Y(dB)           :  0.00
 SNR U(dB)           :  0.00
 SNR V(dB)           :  0.00
 Total decoding time : 175.552 sec (2.871 fps)[504 frm/175552 ms]
--------------------------------------------------------------------------
 Exit JM 18 (FRExt) decoder, ver 18.6
 Output status file                     : log.dec
 504 frames are decoded.

>ldecod.exe -d default.cfg -p InputFile="g:\multimedia\video\720p50_parkrun_ter.h264" -p OutputFile="parkrun.yuv"

-------------------- Average SNR all frames ------------------------------
 SNR Y(dB)           :  0.00
 SNR U(dB)           :  0.00
 SNR V(dB)           :  0.00
 Total decoding time : 221.416 sec (2.276 fps)[504 frm/221416 ms]
--------------------------------------------------------------------------
 Exit JM 18 (FRExt) decoder, ver 18.6
 Output status file                     : log.dec
 504 frames are decoded.

解码部分时间消耗挺长的,解码的画质很好。不过对比编码,这时间还算很短了。

基本上编码一帧消耗的时间是解码的1000倍。
还是刚刚的视频序列。
Frame     Bit/pic    QP   SnrY    SnrU    SnrV    Time(ms) MET(ms) Frm/Fld Ref
-------------------------------------------------------------------------------
00000(NVB)     184
00000(IDR)   23024   28  52.186  47.467  50.301      3756       0    FRM    3
00001( P )      96   28  52.179  47.468  50.302    205985  201178    FRM    2
00002( P )  937976   28  37.510  38.805  40.097    423282  414435    FRM    2
00003( P )   38104   28  37.243  40.129  41.134    578759  571344    FRM    2
00004( P )   99136   28  36.958  39.627  40.893    729596  721931    FRM    2
00005( P )   66144   28  37.348  40.872  41.881    882340  874791    FRM    2
00006( P )  145608   28  37.209  40.671  41.771    814355  806712    FRM    2
^C

消耗时间过长,内存也过多,不得不被迫中止。

默认参数下,编码出来的视频质量和X264差不多。
估算一下文件大小,比X264编码出来的要小很多(但是没有X265编码的小)。
算是牺牲时间来换空间吧。
>>>而同样的工作量 ffmpeg 解码只需要3-5秒钟,编码只需要20秒,感觉自己数的还不到20秒,只是这里显示20秒。

 

>>>而同样的YUV序列使用libx264 编码,需要32秒左右。该命令没有计时,手工计时的结果。

 

转载于:https://www.cnblogs.com/zzugyl/p/3708910.html

你可能感兴趣的文章
iOS SQLite3数据库操作
查看>>
除了 iOS 和 Android,世界第三大移动系统是什么?
查看>>
35.7. FAQ
查看>>
深搜算法实例:老鼠走迷宫(一)
查看>>
VMWare网络设置的3中方式(转)
查看>>
支付这条线上 谁在赚钱谁在哭?
查看>>
机器学习之朴素贝叶斯分类
查看>>
亚信安全参加第六届全国等保技术大会 态势感知助力“等保2.0”落地
查看>>
【设计模式系列】--抽象工厂
查看>>
JqueryValidate 动态添加验证
查看>>
双活数据中心的架构
查看>>
大数据公司Palantir融得7亿美元 曾追踪拉登
查看>>
先行者长虹佳华超融合市场沙龙在京举行
查看>>
建立备份策略的重要性
查看>>
小白用户如何轻松上云 -我的轻量应用服务器探索记
查看>>
BCG与阿里研究院等联合揭秘中国互联网经济:成功的关键是什么?
查看>>
发力IoT领域 Marvell注重生态系统发展
查看>>
数据中心网络布线工程必备七大件
查看>>
20个问题揭穿冒牌数据科学家
查看>>
你应该知道的 RPC 原理
查看>>