1. s60 uses a multimedia framework (MMF) for video and audio playback and recording. It has a plug-in architecture and can use multiple types of plug-ins for media playback and recording, for example, the RealPlayer engine is a plug-in for the MMF controller and supports video and audio playback and stream. 2. The s60 built-in player uses the RealPlayer engine. HTTP streaming media is not supported, because all video data must be read into the cache at one time before display. 3. the common formats of s60 are MP4 (H.263 and MPEG4 encoding/decoding standards), 3GP (H.263 and MPEG4) 4. the s60 platform supports C ++ for multimedia development. The following table summarizes how to use C ++ to implement multimedia applications.
Use Cases |
Symbian C ++ |
Use the s60 Media Player and RealPlayer engine to play local files and RTSP streams. |
Use apparc API (rapalssession) to start the s60 Media Player application. |
Use a custom user interface and the RealPlayer engine to play local files and RTSP streams. |
Create your own user interface and use cvideoplayerutility API to play and control files or URLs. |
Use your player to play local files. |
Create your own player. Use cmdaaudiooutputstream for audio rendering (1) and use cdirectscreenaccess API for video rendering. |
Use your own player to implement streaming video content. |
Use Network APIs (rsocketserv, rconnection, rsocket) to connect to the network (2 ). Then, use cmdaaudiooutputstream for audio rendering and cdirectscreenaccess API for video rendering. |
5. draw a conclusion from the table above that cvideoplayerutility is used to develop the playback and recording of video clips. To develop a player that reads local files or RTSP streams in the format of MP4, 3GP, or rmvb, use cvideoplayerutility. However, if you need to read network data streams, you must use network APIs to connect to the network to obtain data, and then use the cdirectscreenaccess API to draw the screen. The main steps include RTP transmission, MPEG4/h264 decoding, and yuv2rgb conversion. Without Symbian APIs, live555 can be transplanted for streaming media transmission, and FFMPEG can be used for video/audio decoding.
With the rapid development of the mobile phone monitoring market, mobile phone monitoring can achieve real
Lt;/span> "anytime, anywhere, anydevice" (anytime, anywhere) has received increasing attention from security companies. Currently, the operating system of smartphones is dominated by Symbian, WinCE, and Linux. To truly implement the "anydevice" (any device) for mobile phone monitoring, you must support at least the above three mobile phone operating systems. Due to the similarities between wince and Windows development platforms, there are currently many open-source code for the h264 decoding library on the wince platform for reference. The code that can be referenced online mainly includes FFMPEG, JM, and t264, x264. I searched for the h264 decoding library on Symbian on the Internet and found that there is no open source project for reference. Therefore, this article focuses on implementing the above functions on the Symbian platform.
Shows the system structure:
The video server implements dual-bitrate, which can ensure the requirements of common monitoring and meet special requirements such as mobile phone monitoring. Considering the actual bandwidth and decoding capabilities of the network, we recommend that you use the resolution of CIF or qcif on your mobile phone. The frame rate should be lower than 15 frames.
Shows the software framework:
The net engine module is mainly responsible for obtaining data from the video server and implementing an RTSP protocol, which extracts control information and audio and video data from the RTSP package and RTP package respectively and sends them to the video stream queue. For more information about RTSP protocol negotiation, see the RFC documentation.
The stream data queue module is mainly used to store audio and video data. There is no need to describe it in detail.
The h264 Video Decoder Module is mainly responsible for video data decoding. The decoding library uses the transplanted FFMPEG, which is the longest part of the program. The transplantation of FFMPEG mainly requires memory alignment, in addition, some parameters that can be used on the PC can be used only after breakpoint debugging and Modification on the Symbian platform.
Amr audio decoder and AAC audio decoder can search for pure C code on the Internet. They can be used after a slight porting. We recommend that you first Debug on the window platform and port it to the Symbian platform.
In symbain, the actual storage of RGB colors is actually in the brg sequence. For example, the red color is actually stored as 0x0000ff rather than 0x00ff0000. So if other platforms useSymbianIn the color, pleaseNote:Conversion. FFmpeg decoding output fish yuv420, which can be converted to rgb565 display on PC, and converted to bgr565 on Symbian.
For the conversion part, refer to the yuvtorgb of the mobiflv project. H and yuvtorgb. CPP two files, the author used a look-up table optimization for the conversion process, the efficiency is very good, and this type of support for proportional scaling of the video, the effect is good.
For video display, you can use cfbsbitmap for texture display, but this is not the most efficient. Using the cdirectscreenaccess class to directly write the screen can improve the efficiency. The audio can be played directly by calling the cmdaaudiooutputstream class of the system.
Shows the playback effect,
Portrait Screen
Landscape Screen
The RTSP address connected by the above program is rtsp: // 88.107.126.1: 3838/live.3gp, and the image quality is CIF, 5FP/s, and 32kb. The video server is located in the UK. If you are interested, try it. The program also implements remote cloud platform control, controls the movement and scaling of the lens, and enriches the mobile phone monitoring function.
The program passed the test on e71, n81, and N95.
Disadvantage: When cmwap is selected for the access point, the video stream cannot be connected. Because the server does not provide the RTSP stream proxy function, the client needs to penetrate the mobile gateway. Considering the slow speed of cmwap and the future development of the network, the implementation is not significant, so I gave up this part of work.
If you are interested, you can contact me to exchange and learn.