博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
JM和x264是什么关系?
阅读量:4142 次
发布时间:2019-05-25

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

       JM包括JM encoder和JM decoder, JM encoder是H.264标准的一个具体实现, JM decoder是对应的解码器. x264和JM encoder一样,都是H.264标准的实现,只是实现的方式不同而已. (H.264是一个标准,可以近似理解为协议或协定或约定或合同)

       实际上, 在H.264标准中,并没有规定编码该怎么编,H.264只规定了编码形成的码流的格式. 也就是说,孙悟空如果不采用H.264的编码器,只要它能做出符合H.264标准的码流,那么孙悟空做出的码流就是正确的H.264码流,自然就能够被H.264的解码器解码.

       对于某一确定的H.264码流,任何H.264解码器解码出来的结果必定完全一样.

 

       再看JM encoder和x264, 自己编码一下,就可以发现,JM encoder实在太慢了,x264则相当快. 为什么呢?因为具体实现的方式不一样,打个简单比方JM encoder就像一个学院派的老师,比较严谨,略带完美主义情结,力求面面俱到, x264更像一个公司的大牛,少去了许多华而不实的东西,奉行实用至上,阉割掉一些看上去很美的东西, 所以编码效率那是相当高啊.

       初学H.264时,听别人说研究学术用JM,实际应用用x264. 其实不然,每个人的需求不同,研究学术就要用JM?要看研究的是什么东西,有些人做的是基于H.264的研究,而不是专门研究H.264, 动辄要编码上千帧,如果用JM,那就太慢了. 对某些基于H.264的研究者来说,运动估计是怎么估计出来的一点都不重要,熵编码是如何实现的一点都不重要,重要的是知道在哪个地方提取什么参量. 话说,人各有志,所以,到底用JM还是x264也是不过是人各有所需罢了.

转载地址:http://iczti.baihongyu.com/

你可能感兴趣的文章
mysql游标嵌套循环
查看>>
oracle函数trunc的使用
查看>>
MySql四舍五入
查看>>
在navicat上设置定时计划执行存储过程
查看>>
mysql 1449 : The user specified as a definer ('root'@'%') does not exist 解决方法
查看>>
js 阻止form表单提交
查看>>
MySQL 将查询出来的一列数据拼装成一个字符串
查看>>
MySQL 存储过程或者函数中传参数实现where id in(1,2,3,...)IN条件拼接
查看>>
iOS 报错信息: dyld: Library not loaded: @rpath/XCTest.framework/XCTest Referenced framework
查看>>
分布式服务框架 Zookeeper -- 管理分布式环境中的数据
查看>>
基于Spring Boot和Spring Cloud实现微服务架构学习(一)-Spring框架介绍
查看>>
自建framework提交审核报错 ERROR ITMS-90087解决办法
查看>>
2017 年你应该学习的编程语言、框架和工具
查看>>
maven提示invalid LOC header (bad signature)的解决办法
查看>>
Ubuntu/kali上安装MySQL,设置远程访问详细教程
查看>>
Tomcat配置HTTPS及访问HTTP自动跳转到HTTPS
查看>>
Mysql错误: ERROR 1205: Lock wait timeout exceeded解决办法
查看>>
MySQL索引背后的数据结构及算法原理
查看>>
MySQL通用优化技巧
查看>>
替代mmm方案的mariadb galera cluster和percona xtradb cluster的简介
查看>>