zoukankan      html  css  js  c++  java
  • JM编解码264


    看到有人说JM解码编码264 尝试了一下
    http://iphome.hhi.de/suehring/tml/download/
    win7下 vs2010 编译后,得到编码解码可执行文件ldecod.exe lencod.exe
    还是使用原来测试编码265的视频序列 http://www.cnblogs.com/zzugyl/p/3678865.html
    这里的264是之前使用X264编码的。


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

    解码部分结果如下:
    >ldecod.exe -d default.cfg -p InputFile="g:multimediavideo720p50_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:multimediavideo720p50_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秒左右。该命令没有计时,手工计时的结果。

  • 相关阅读:
    k8s 资源管理
    Kubernetes核心组件
    python复习
    项目发布
    tornado
    斯巴达系统(一)
    Tornado-第三篇-tornado支持websocket协议
    Tornado-第二篇-异步非阻塞
    Tornado-第一篇-搭建网页
    python--面向对象的特殊方法(反射,内置方法)
  • 原文地址:https://www.cnblogs.com/zzugyl/p/3708910.html
Copyright © 2011-2022 走看看