Tcpmp source code analysis-a glimpse of leopard

Due to project requirements, I recently read tcpmp (. 72. SC1)Source code. In-depth analysis of tcpmp sources on the InternetCodeOfArticleVery few. The article "porting the compilation process from a tcpmp player to the WindowsCE platform" describes how to compile tcpmp in EVC in detail and is very suitable for getting started. Two articles, "wince tcpmp application" and "boiled tcpmp", briefly introduced the structure of tcpmp and the functions of each part. I personally think that it is far from reaching the boiling stage, but it is worth seeing.

As a powerful open-source player, tcpmp supports arm, MIPS, SH3, x86, and other hardware platforms. I tested tcpmp on the wince armv4 and wince mip ii platforms respectively. I personally feel that tcpmp has better support for the ARM platform than the mipⅱ platform. (Specific models are ARM926EJ-S and AMD/alchemy, MIPS-AU/200 ).

A video file with a resolution of 320x240 and mp43 compression can be played smoothly on the ARM platform, while many cards need to be played on the mipⅱ platform. The 640x480, mp43 compressed videos cannot be displayed on the MIPs platform. What's more, the screen stream files compressed and encoded by TSCC can be played smoothly on the ARM platform, but cannot be displayed on the MIPs platform.

With such a question, this article explores the source code of tcpmp.

codec. the C file contains a process (codec * P, const packet * packet, const flowstate * State) function. c). This function is used to decode and display the video data of each frame. There are two important statements in this function. 1 p-> process (p, packet, State); 2 P-> out. process (p-> out. pin. node, & P-> packet, State); Statement 1 calls the decoder for decoding (the actual call should be FFMPEG. c). Statement 2 calls the video rendering function to render and display the decoded video. (The BLAY function in Overlay. C is actually called ). The blayfunction in Overlay. C actually calls the blayfunction in overlay_gdi.c for video rendering. However, only when certain conditions are met (if (p-> soft & P-> inited & P-> show & Packet-> data [0, to call the blayfunction in overlay_gdi.c. Tracking shows that on the MIPs platform, it is precisely because P-> soft = 0 that the condition is not true and the blayfunction in overlay_gdi.c cannot be executed, so the video cannot be displayed. Why is P-> soft 0 on the MIPs platform?

Before playing a video, tcpmp initializes the video and calls the blitcreate function in blit_soft.c. This function is used to optimize the video rendering code for different platforms and video formats. The blitcreate function calls the blitcompile function to generate different video Rendering Dynamic code for different video formats (YUV, RGB) and platforms (ARM, MIPS, SH3. When it is (RGB arm), The any_rgb_rgb () function is called to generate code. When (YUV arm), The fix_any_yuv () function is called to generate code. When (yuv mips, the fix_rgb_uv () function is called to generate code, but no code is called only when it is (rgb mips. Therefore, after executing the codebuild () function, p-> code. size = 0, so P-> entry is null. Naturally, p-> soft = NULL.

To solve this problem, the any_rgb_rgb function similar to arm4 can be implemented on the MIPs platform. However, it is difficult to understand the command system of MIPS and ARM platform and the any_rgb_rgb code. Another idea is to Convert RGB to YUV before video rendering.

In addition, to open the blittest macro in the common project, instead of calling code optimized for different video formats and platforms, the blituniversal function is called to generate code in a unified manner, at this time, TSCC files under 320x240 can be normally displayed on the MIPs platform. But it is still very difficult. The author suggests that this method is slow and is only used for compatibility and testing.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/yanzel/archive/2009/05/23/4211038.aspx