High Resolution Embedded Video Player System Based on Linux and ...

IJECT Vol. 2, SP-1, Dec. 2011

ISSN : 2230-7109(Online) | ISSN : 2230-9543(Print)

High Resolution Embedded Video Player System Based on Linux and Qt/E 1 1,2,3,4

S.Nagaraju, 2N Usha Rani, 3T.S.S.Naga Pavan Kumar, 4V.Srikanth

Dept. of ECE, Vignan’s Lara Institute of Tech. & Science, Vadlamdui, Guntur, Andhra Pradesh, India

Abstract Now a day’s Video Player is one of the most common things in our day to day life. The traditional video players suffer with drawbacks like they are run with windows based platform with a limited file formats. Some problems of present Embedded GUI such as large occupation space, bad configuration ability and poor real-time performance. Conventional Video Players, also encounters the problem of Audio and video synchronization. The above mentioned drawbacks in Traditional Video Players can be overcome in my Project by using ARM QTOPIA Video Player. In order to improve the reliability, the system uses C++ encapsulation and applies Qt/Embedded and Qtopia with abundant control resources and better portability as basic operating ambient. It also makes use of Simple DirectMedia Layer (SDL) library and shields various kinds of specific operation system’s APIs making it convenient to design the player module. This player also supports most of video formats based on Fast Fourier Transform Media Player Engineering Group (ffmpeg) decode library. Experimental results show that the design simplifies the playing process, supports many video formats and supplies a way to the application of streaming media.

one everyone recommends, because developing embedded Linux systems requires that you become quite familiar with Linux and there is no better way of doing this than using it for your everyday work. A standard PC is our most likely Linux workstation. Linux runs on a variety of hardware and that are not limited to using a PC. In this project Linux is used for the implementation of the work. It lacks an RS232 serial port, but this is easily fixed by adding a USB serial dongle for downloading the files onto target. One may use any of the standard Linux distributions such as Debian, Mandrake, Red Hat, SuSE, or Yellow Dog on your host. In my project Debian is preferred. The embedding of application into the target board from host PC is shown in fig.1 below.

Keywords Video Player, Embedded GUI, Real-time performance, Simple Direct-Media Layer, ffmpeg. I. Introduction As the development and enlargement of electronic production scale, multimedia players should have good real time performance, high reliability, and good interactivity. Accordingly, traditional players cannot meet the requirements mentioned above. But the fast development of embedded technology supplies powerful supports for multimedia players, it makes embedded system technology oriented to multimedia player as a research hotspot. Of course, graphic user interface (GUI) which is important part of embedded system is also paid much attention. The complexity of playing and singleness of supported video file formats are common phenomena of players in embedded systems, which lead to the difficulty of putting the video players in embedded systems to the low-end market. Therefore, aiming at some problems of embedded GUI such as large occupation space, bad configuration ability and poor real-time performance, a video player is designed by using existing mature SDL library to simplify the process of video playing, which is more compatible with the video formats. According to the statements above, it is possible to make the popularization of the embedded video player. II. Overview of the Project In this project initially boot loader, Linux OS has been ported on to the target board which has S3C2440 processor on it, which is the main SOC and heart of the project. The Base board of the project is designed and selected such a way to cater many I/O interfaces. The most common type of development host for embedded Linux systems and it is shown in fig.1. It is also the

36  International Journal of Electronics & Communication Technology

Fig. 1: HOST – TARGET Environment A. Linked Setup In this setup, the target and the host are permanently linked together using a physical cable. This link is typically a serial cable or an Ethernet link. The main property of this setup is that no physical hardware storage device is being transferred between the target and the host. All transfers occur via the link. The host contains the cross-platform development environment. While the target contains an appropriate boot loader, a functional kernel, and a minimal root file system. Alternatively, the target can use remote components to facilitate development. The kernel could, for instance, be available via Trivial File Transfer Protocol (TFTP). The root file system could also be NFS-mounted instead of being on storage media in the target. Using an NFS-mounted root file system is actually perfect during development, because it avoids having to constantly copy program modifications between the host and the target. The linked setup is the most common. Obviously, the physical link can also be used for debugging purposes. It is, however, more common to have another link for debugging purposes. Many embedded systems, for instance, provide both Ethernet and RS232 link capabilities. In such a setup, the Ethernet link is used for downloading the executable, the kernel, the root filesystem, and other large items that benefit from rapid data transfers between the host and the target, while the RS232 link is used for debugging. w w w. i j e c t. o r g

ISSN : 2230-7109(Online) | ISSN : 2230-9543(Print)

III. Architecture of an Embedded Linux System Linux systems are made up of many components; let us take a look at the overall architecture of a generic Linux system is shown in Fig.2. This will enable us to set each component in context and will help you understand the interaction between them and how to best take advantage of their assembly.

Fig. 2: Architecture of a generic Linux system Although the figure abstracts to a high degree the content of the kernel and the other components, the abstractions presented are sufficient for the discussion. Notice that there is little difference in the following description between an embedded system and a workstation or server system, since Linux systems are all structured the same at this level of abstraction. There are some broad characteristics expected from the hardware to run a Linux system. First, Linux requires at least a 32-bit CPU containing a memory management unit (MMU). Second, a sufficient amount of RAM must be available to accommodate the system. Third, minimal I/O capabilities are required if any development is to be carried out on the target with reasonable debugging facilities. This is also very important for any later troubleshooting in the field. Finally, the kernel must be able to load and/or access a root file system through some form of permanent or networked storage. Immediately above the hardware sits the kernel. The kernel is the core component of the operating system. Its purpose is to manage the hardware in a coherent manner while providing familiar high-level abstractions to user-level software. As with other Unix-like kernels, Linux drives devices, manages I/O accesses, controls process scheduling, enforces memory sharing, handles the distribution of signals, and tends to other administrative tasks. It is expected that applications using the APIs provided by a kernel will be portable among the various architectures supported by this kernel with little or no changes. This is usually the case with Linux, as can be seen by the body of applications uniformly available on all architectures supported by Linux. Within the kernel, two broad categories of layered services provide the functionality required by applications. The low-level interfaces are specific to the hardware configuration on which the kernel runs and provide for the direct control of hardware resources using a hardware-independent API. That is, handling registers or memory pages will be done differently on a PowerPC system and on an ARM system, but will be accessible using a common API to higher-level components of the kernel, albeit with some rare exceptions. Typically, low-level services will handle CPU-specific operations, architecture-specific memory operations, and basic interfaces to devices.

IJECT Vol. 2, SP-1, Dec. 2011

of the porting the kernel on to the board. The configuration and writing the suitable interface drivers, making the kernel optimize, so that the un compression of the kernel has to be done successfully and the system should run stable. A. System Startup Three main software components participate in system startup: the bootloader, the kernel, and the init process. The bootloader is the first software to run upon startup and is highly dependent on the target's hardware. The bootloader will conduct low-level hardware initialization and thereafter jump to the kernel's startup code. The early kernel startup code differs greatly between architectures and will conduct initialization of its own before setting up a proper environment for the running of C code. Once this is done, the kernel jumps to the architecture-dependent start_kernel( ) function, which initializes the high-level kernel functionality, mounts the root file system, and starts the init process. The boot loader in my project is vivi bootloader. V. General scheme Embedded video player system mainly includes software and hardware. As shown in Fig. 3. A. Hardware system Samsung (S3C2440) processor is the kernel of the embedded system, including FLASH, SDRAM memory and communication interfaces. Through the LCD interface connector we can play the video on LCD screen. And there are many communication interfaces such as RS232, USB, JTAG, and LAN for the development and debugging

Fig. 3: General framework of the player system B. Software system The basic embedded operating system environment is the operating platform for application, which includes boot program, embedded Linux kernel and root file system. Application programs of the system consist of embedded GUI, video decoding procedures. Qt/Embedded and SDL are based on the framebuffer. Qt/Embedded is a simplified version of Qt for embedded application, and the Qt/X11’s interfaces are compatible with the Qt/Embedded. Framebuffer is used as a bottom and graphic interface. SDL is a bottom multimedia library, mainly for the game development. Player module is designed based on the SDL. In addition, Qt / Embedded and some features of the SDL are directly called by the operating system.

IV. Procedure implemented The Linux kernel is selected according to the project and the target board to suit the on board RAM .There are various stages w w w. i j e c t. o r g

  International Journal of Electronics & Communication Technology  37

IJECT Vol. 2, SP-1, Dec. 2011

Fig. 4: Play interface

Fig. 5: Playing of default video VI. Experiment test and Result The below Fig. 4 & Fig. 5 shows Qtopia is successfully ported onto ARM machine and the demo application tested is the sample video played with the Multimedia player with audio and video support. VII. Conclusion Three most popular embedded operating systems have been discussed in this paper, beside them; there are still some other famous embedded operating systems, such as the VxWorks from the WindRiver Company, Nucleus from the ATI, iTron and WinCE. Lastly, let's sum up the important factors that should be considered when choosing an embedded OS for your ARM CPU. The first factor should be the application of the project. If it is a network appliance or network related embedded system that is to be developed, embedded Linux or uCLinux be the OS but not uC/OS-II . The second factor should be real-time performance of the RTOS. The latest Linux systems have made some great improvement in real-time performance, take the MontaVista Linux (version 2.4.17) for example, its real-time response time is 195 microsecond at best, 436 ms at worst. It is applicable to 90~95% of the embedded system applications. Moreover, if the project desires a faster real-time response, the uC/OS-II system might be more suitable. Besides, conventional embedded Oses such as Vxworks can also provide you with such high real-time performance. The third factor should be availability of developing tools. It is obvious that there are still some gaps between the developing tools of commercial embedded O and those of uC/OS-II, uCLinux and Embedded Linux. At the present time, the most common used developing tool for ARM CPU is the SDT/ADS tool chain, which is really nice in terms of function, stability, and supports from the third parties. More information about developing tools can be found at Embedded Developing Tools. The last factor that should be considered is the compatibility of your hardware platform. For example, uCLinux is not supported by the ARM7TDMI and ARM940T kernel based CPUs (S3C2500/2510 for example), while is Embedded Linux system is not.

38  International Journal of Electronics & Communication Technology

ISSN : 2230-7109(Online) | ISSN : 2230-9543(Print)

References [1] Zu-jue Chen, Zhi-xiong Zhang, Jian-jiang Zhang, “Design and Implementation of Video Player System Based on Embedded System and Qt/E”, IET,2008,PP 468-472 [2] Summerfield, Mark, “Advanced Qt Programming: Creating Great Software with C++ and Qt 4” (1st ed.), AddisonWesley, pp. 550, August 23, 2010 [3] Fitzek, Frank H. P.; Mikkonen, Tommi; Torp, Tony, Qt for Symbian (1st ed.), Wiley, pp. 160, May 17, 2010 [4] Blanchette, Jasmin; Summerfield, Mark, C++ GUI Programming with Qt 4 (2nd ed.), Prentice Hall, pp. 752, February 14, 2008 [5] Summerfield, Mark, Rapid GUI Programming with Python and Qt (1st ed.), Prentice Hall, pp.  648, October 28, 2007 [6] Molkentin, Daniel, The Book of Qt 4: The Art of Building Qt Applications (1st ed.), No Starch Press, pp. 440, July 19, 2007 [7] Cortex-A9 Processor (Click on Specifications tab), ARM, retrieved 5 August 2010 [8] ARM spins multicore-enabled Cortex core - News - Linux for Devices [9] Samsung.com > Application Processor > Cortex A9 Series > Exynos 4210 [10] Zhang, W., Liu, P., Zhai Z. B., “A hardware/softwarecooptimization approach for embedded software of MP3LPC UPC 1619 decoder”, Journal of Zhejiang University: Science A, 2007, vol. 8, no.1, pp. 42-49. [11] [11]. Ahn, S. H., Sul, D. M. , Choi S. C., “Implementation oflight-weight graphic library builder for embedded system”, Proceedings of 8th International Conference Advanced Communication Technology, IEEE, Phoenix Park, South Korea, 2006, pp. 166-168. [12] Khan, G. N., Wee, S. H. “Fault-tolerant embedded computer system-on-chip for endoscope control”, Proceedings of International Symposium on IC Technology, Systems and Applications, Nan-yang Technological University, Singapore, 2001, vol. 9, pp. 102-105. [13] Debrunner, V., Debrunner, L. S., Ta, M. “Embedded computer / communication sub-system for bridge vibration control”, Proceedings of IEEE Conference on Intelligent Transportation Systems, IEEE, Oakland, CA, 2001, pp. 728-733. [14] Lv, Q., Xia, X. Y. “Developing an integrated desktop for GUI applications in embedded systems”, Proceedings of theFourth IASTED International Conference on Communications, Internet, and Information Technology, ActaPress, Cambridge, United States, 2005, pp 68-73. [15] Yu, X. H., Chen, Q. Y., Li, G. Y. “Transplantationand Software Development of MiniGUI Based on EmbeddedLinux”, Journal of Liao-ning Institute of Technology, 2006, vol. 26, no. 2, pp. 90-93. [16] Dalheimer, M.K., Hansen, S.“Embedded developmentwith Qt/embedded”, Dr. Dobb's Journal, 2002, vol. 27, no. 3,pp. 48-53.

w w w. i j e c t. o r g