测试过程:
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
Contents
[hide]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
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
- The IL-client is executed on ARM side and the corresponding firmware binaries are loaded on the Video and VPSS media controller cores.
- 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.
- Timestamps corresponding to various OMX component events for consecutive frames are logged for latency measurements
- T0 - Start of capture. (start time for encode path)
- T1 - Timestamp when capture of frame is complete
- T2 - Timestamp when DEI processing is done
- T3 - Timestamp when VENC finish encoding the frame
- T4 - Timestamp when VDEC starts decoding the frame
- T5 - Timestamp when VDEC finish decoding the frame .
- T6 - Timestamp when VFPC scaling is done
- T7 - Timestamp when VFDC send the frame to HDMI output for display
- T8 - Timestamp when the frame is displayed on TV
- 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
- Detailed latency performance results are available here Media:DM816x_Capture_Encode_Decode_Display_latency_performance_consolidated.zip
Summary
Metrics
- Glass to Glass Latency T8–T0 - Total delay observed in the system including TV delay
- Capture-Encode Latency = Capture-Encode Path delay + Buffers in Capture Driver
- Decode-Display Latency = Decode delay + Scalar delay + Display delay
Breakup
- Buffers in Capture Driver - Delay due to buffers held in capure driver. Range is from 0.5 to 1 frame
- Capture-Encode Path delay- T3–T1
- Buffer Hand Off to Decoder - Delay due to buffers held between VENC and VDEC components. Range is from 1 to 1.5 frames
- Decode Delay T5–T4
- Scalar Delay T6–T5
- Scale/Chroma Con. Display Delay T7–T5 - Cummulative delay for scaling, chroma conversion and display
- TV/Monitor Delay - Delay due to the internal processing in the TV/monitor (8ms delay is observed in Samsung LCD TV)
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.
版权声明:本文博主原创文章。博客,未经同意不得转载。