• dm8148 jpeg编解码器测试


    测试过程:

    1)于A8将jpeg传送到videoM3解码,然后,videoM3编码。在编译jpeg图像传输到A8,主要是测试jpeg编码的图像需要多少时间;

    1000w像素:  编码时间:43ms。
    800w像素:   编码时间:35ms
    1080P:       编码时间:10ms

    1600w像素:  编码时间:73ms


    当測试到1600w像素时,解码link报错,内存不够。
    在utils_mem.c的utils_memFrameAlloc函数中报错,内存分配错误;


    4096*4096分辨率下。declink分配的内存为:
    memory alloc failed,size=26560512,numFrames=4,file=utils/src/utils_mem.c,line=185

    将建立解码link时,原来是4个buff,改为2个buff
    改动完后,videoM3又报例如以下错误。

    [m3video]  58133: Assertion @ Line: 99 in utils/src/utils_ringbuffer.c: status == 0 : failed !!!

    将编码link的buff内存个数改动成3
    encPrm.numBufPerCh[i] = 3;

    改动完后,1600w像素编码成功。

    我看ti的编解码文档最大支持的分辨率就是4096*4096了。我測试了更高分辨率,5120*5120,解码器报错;

    MA: ChannelID allocated:4
     [m3video]  523256: IPC_BITS_IN   : Create in progress !!!
     [m3video]  523256: SYSTEM: Opening ListMP [HOST_IPC_OUT_28] ...
     [m3video]  523257: SYSTEM: Opening ListMP [HOST_IPC_IN_28] ...
     [m3video]  523258: SYSTEM: Opening MsgQ [HOST_MSGQ] ...
     [m3video]  523261: IPC_BITS_IN   : Create Done !!!
     [m3video]  523261: DECODE: Create in progress ... !!!
     [m3video]  523521: DECODE: Creating CH0 of 5120 x 5120 [PROGRESSIVE] [NON-TILED  ],target bitrate = 8000 Kbps ... 
     [m3video] DECLINK_JPEG:HEAPID:0        USED:14512
     [m3video]  523523: DECODE: All CH Create ... DONE !!!
     [m3video] DECLINK:HEAPID:0     USED:14552
     [m3video]  523524: DECODE: Create ... DONE !!!
     [m3video]  523525: ENCODE: Create in progress ... !!!
     [m3video] prevLinkQueId=0,numQue=1
     [m3video]  EncLink_codecCreateOutObj BitBuf Q Status
     [m3video] Empty Q 0 -> count 1, wrPtr 1, rdPtr 0
     [m3video] Full Q -> count 0, wrPtr 0, rdPtr 0
     [m3video]  523609: ENCODE: Creating CH0 of 5120 x 5120, pitch = (5248, 5248) [PROGRESSIVE] [NON-TILED  ], bitrate = 24000 Kbps ... 
     [m3video] ENCLINK_JPEG:HEAPID:0        USED:4432
     [m3video]  523610: ENCODE: All CH Create ... DONE !!!
     [m3video] ENCLINK:HEAPID:0     USED:4672
     [m3video]  523613: ENCODE: Create ... DONE !!!
     [m3video]  523614: IPC_BITS_OUT   : Create in progress !!!
     [m3video]  523617: IPC_BITS_OUT   : Create Done !!!
     [m3video] 528461:DECLINK::links_m3video/iva_dec/decLink_jpeg.c:[203]::INTERNAL ERROR:-1
     [m3video] ALGPROCESS FAILED:STATUS
     [m3video] 528461:WARN
     [m3video] DECLINK:ERROR in Declink_jpegDecodeFrameBatch.Status[-1]
     [m3video] 530875:DECLINK::links_m3video/iva_dec/decLink_jpeg.c:[203]::INTERNAL ERROR:-1
     [m3video] ALGPROCESS FAILED:STATUS
     [m3video] 530875:WARN
     [m3video] DECLINK:ERROR in Declink_jpegDecodeFrameBatch.Status[-1]

    错误码:

    JPEG Extended error 20008000

    查看错误码:http://www.doc88.com/p-3965543592868.html

    第15位为1表示一个致命的错误。第29位为1。表示不支持的分辨率。width/height;

    错误码:200000 第21位为1表示 :Not supported output chroma format set by the application to the codec

    測试完后。看到一个ti的网页,也有这些性能的測试。

    http://processors.wiki.ti.com/index.php/Latency_Measurement_on_Capture_Encode_Decode_Display_Demo

    http://processors.wiki.ti.com/index.php/QualiTI

    Latency Measurement on Capture Encode Decode Display Demo

    Latency Measurement for Capture Encode/Decode Display application

    This is the latency measurements performed on the sample Capture encode/decode display demo delivered along with the EZSDK 5.x for DM816x and DM814x devices from TI. The demo is created with the chain VFCC->DEI->VENC->VDEC->VFPC-SC->VFDC . This demo is validated on EZSDK 5.03.01.15 and OMX components 5.02.00.30.

    The latency numbers are measured for the following resolutions:

    • 1080p60 (Capture, Encode, Decode and Display @ 1080p60)
    • 1080p30 (Capture, Encode, Decode and Display @ 1080p30)
    • 1080p60-30 ( Capture Display @ 1080p60. Encode Decoder @ 1080p30)
    • 720p60 (Capture, Encode, Decode and Display @ 720p60)

    Usecase Description

    The video data is captured by VFCC component from a HD camera source via HDMI . The captured data is fed to DEI.The DEI output is then encoded by VENC and decoded by VDEC component. The decoded frame is passed to Scalar component ( VFPC Sc) , which does chroma conversion from YUV 420 to YUV 422 format. The scalar ouput is passed to VFDC and the output is displayed on the TV via via on-chip HDMI interface. The IL Client source code is available hereMedia:capture_encode_decode_display.tar.gz


    Capture encode decode display block.png

    Setup Details

    DM816x Base EVM DM816x Rev-C with DDR3 attached with a Video Conferencing Expansion IO (EIO) Card interface. A video source (Tandberg 1080p60 Camera / Sony PS3) is connected to the daughter card via a HDMI interface. The on-chip HDMI out from the DM816x Base EVM is connected to a TV.


    OMX Components Details

    Following are the list of OMX components used in the usecase:

    • VFCC (Video Frame Capture Component)
    • VFPC-DEI (Video Frame Processing Component - Deinterlacer)
    • VENC (Video Encode Component)
    • VDEC (Video Decode Component)
    • VFPC-SC (Video Frame Processing Component - Scalar)
    • VFDC (Video Frame Display Component)

    Measurement Procedure

    1. The IL-client is executed on ARM side and the corresponding firmware binaries are loaded on the Video and VPSS media controller cores.
    2. The HD camera is focused on a running stop watch video. Glass-to-Glass latency is measured by measuring the time difference between the source time stamp and the time stamp displayed on the TV display.
    3. Timestamps corresponding to various OMX component events for consecutive frames are logged for latency measurements
    4. T0 - Start of capture. (start time for encode path)
    5. T1 - Timestamp when capture of frame is complete
    6. T2 - Timestamp when DEI processing is done
    7. T3 - Timestamp when VENC finish encoding the frame
    8. T4 - Timestamp when VDEC starts decoding the frame
    9. T5 - Timestamp when VDEC finish decoding the frame .
    10. T6 - Timestamp when VFPC scaling is done
    11. T7 - Timestamp when VFDC send the frame to HDMI output for display
    12. T8 - Timestamp when the frame is displayed on TV
    13. From the above timestamps, Running average of various latency values are measured
    • Running average: Series of averages is calculated for a fixed window period (8 Frames) of different subsets of the full data set and final average is calculated from the average series

    Results


    Summary

    Metrics

    1. Glass to Glass Latency T8–T0 - Total delay observed in the system including TV delay
    2. Capture-Encode Latency = Capture-Encode Path delay + Buffers in Capture Driver
    3. Decode-Display Latency = Decode delay + Scalar delay + Display delay

    Breakup

    1. Buffers in Capture Driver - Delay due to buffers held in capure driver. Range is from 0.5 to 1 frame
    2. Capture-Encode Path delay- T3–T1
    3. Buffer Hand Off to Decoder - Delay due to buffers held between VENC and VDEC components. Range is from 1 to 1.5 frames
    4. Decode Delay T5–T4
    5. Scalar Delay T6–T5
    6. Scale/Chroma Con. Display Delay T7–T5 - Cummulative delay for scaling, chroma conversion and display
    7. TV/Monitor Delay - Delay due to the internal processing in the TV/monitor (8ms delay is observed in Samsung LCD TV)



    Capture encode decode display latency summary.png


    Download the Latest EZSDK

    The latest EZSDK is available for download from http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html.

    The current version is 5.05.02.00. The supported platforms are DM816x and DM814x.

    版权声明:本文博主原创文章。博客,未经同意不得转载。

  • 相关阅读:
    前端开发之初探五
    前端开发之初探四
    前端开发之初探三
    漫谈
    前端工程师的发展之路
    SVG
    前端开发之初探一
    前端开发之初探二
    详解浏览器缓存
    webStroage案例
  • 原文地址:https://www.cnblogs.com/blfshiye/p/4840537.html
Copyright © 2020-2023  润新知