Porting Embedded Windows CE 6.0 R2 to the OMAP-L138: Part 3
Encoding and decoding of video
When using the H.264, MPEG4 and audio (MP3, AAC) codecs provided by TI in combination with Windows CE 6.0 OS, the company offers a new package with source codes to support Direct Show filters for Windows Media Player.
Figure 11 shows the sequence of calls when using DVSDK 1.00.00.05 WinCE package. When using Direct Show filters, it is necessary to use an intermediate layer for connection of Direct Show filter and the VISA API (Video, Image, Speech, Audio), which further uses codecs at the DSP subsystem via Codec Engine library. The TIMM.DLL dynamic library operates as this intermediate layer, generating primitive elements for working with video and audio flows.
Click on image to enlarge.
Figure 11. Sequence of calls when using codecs in DSP subsystem for Windows Media Player
The standard DVSD K WinCE 1.00.00.xx package does not contain source code for the OMAP-L138 SoC. For implementation of OMAP projects, we ported the source codes from the DVSD K 4.02 package for Linux Embedded OS (which supports the GStreamer framework for codecs where a DSP core has been used) and combined it with the DVSD K WinCE 1.00.00.05 package. This is necessary only for the OMAP3530 SoC, though the option of adding new platforms is reserved. Any remake operations take time and require a comprehensive setting of all components (Codec Server, Codec Engine, DSPLink, DS How Filter, and Windows CE 6.0 OS itself).
However, at Axionim we’ve managed to initialize decoding of the AVI container - which contains video flow - with a resolution of 720х576 (MPEG4) and MP3 audio data. The resulting reproduction rate is 30 frames per second with an ARM core load of about 30% (network reproduction of video).
Another way to use codecs on the DSP subsystem side is to use the DVSD K package and develop your own customized application, a much more common design option when using the Windows Direct Show and Windows Media Player components. As for AVI containers, the analyzer needs to be written independently and ported from projects with an open code. Confined to just the encoding of the video flow obtained from video input (VPIF), this method is much more beneficial from the point of view of resources exploitation.
Figure 12 shows the sequence of system calls during development of the application using the DVSDK package. With such an approach, the development of an application includes preparation of the libaries for the DMAI (Digital Multimedia Application Interface), Codec Engine, and DSPlink as well as for a codecs container. Using examples presented in DMAI library (video_encode_io1, video_ decode_io2, audio_decode_io1, etc.), the developer can generate applications to which all the static components needed for operation of these examples can be attached. Thus, unification of the interaction interface with the DSP subsystem and codecs container is possible.
The codecs container includes completely operational codec libraries from TI in binary form. However, the developer also has the option of adding his or her own codecs to the container, using the unified VISA interface to access them.
Click on image to enlarge.
Figure 12. Sequence of calls when using codecs in DSP subsystem during user application development
Testing of ARM core with Embedded Windows CE 6.0
Image testing using the standard board support packages has been performed independently by MPC Data Company and is presented in the form of Excel tables in appendix to the BSP that MPC provides (Figure 13). Testing was performed using a LogicPD OMAP-L138 SOM-M1 module.
Click on image to enlarge.
Figure 13: Whetstone performance test
This module uses 166-MHz mDDR memory for 128 Mbytes, though it is possible to use DDR 2 memory up to 512 Mbytes in size, which significantly improves performance. In these tests, using the Marvell PXA270, TI OMAP-L138 and Cirrus Logic EP9315 processors Windows CE 6.0 R2 OS was operating but additional libraries of floating point functions support were not used.
Conclusion
The ARM926EJ-S core is useful in applications of moderate performance with frequencies of up to 456 MHz operating independently, and up to 300 MHz when equipped with a peripherals set (such as a SATA, module for working with SD/MMC-cards) and used with McASP, McBSP, and additional DSP cores.
Based on our experiences using it in the design of a matrix RGB LED display controller (Figure 14), we believe the OMAP-L138 can be used as a basic core not only in mobile applications but in traditional fixed systems where it is necessary to resolve a wide range of tasks connected with reproduction and storage of media content.
Click on image to enlarge.
Figure 14: LED display controller based on OMAP-L138 with Windows CE 6.0 and Xilinx Spartan6 FPGA
The LED display controller was based on the TI OMAP-L138 SoC and the Xilinx Spartan6 FPGA as video controller. We used Windows Embedded CE 6.0 R3 as the main OS to receive MPEG2/4/H.264 video streams over Ethernet/3G, then decode them and display on an LED screen.
We think the methodology we followed with the OMAP-L138 SoC and C6-Integra family will allow development of systems that can easily be integrated into many medical equipment and factory automation processes.
To read Part 1, go to "The basics of the two platforms"
To read Part 2, go to "The OMAP Programmable Real Time Unit."
Artsiom Staliarou and Denis Mihaevich are founders of the AXONIM Devices Company, a Microsoft Embedded Partner and independent embedded electronics system design center and system integrator with 25 engineers based in Minsk, Belarus. E-mail: info@axonim.by, Skype: axonim.by.
Artsiom has a degree in radiophysics and has more than 10 years of experience in embedded system design based on ARM/Blackfin/TI DSP C2x/C5x/C6x)/x86 devices and using Embedded Linux/Windows Embedded OSes.
Denis also has a degree in radiophysics and more than 12 years of experience in embedded system design and video analysis algorithm development, and has a certificate in optoelectronics.
Loading comments... Write a comment