Your partner for your innovative projects ...                                            

 Actualités OSELIS

 

contact

 
French (Fr)English (United Kingdom)
E-mail Print PDF

DVSDK — Tsunami v1 documentation

 

DVSDK

Installation

DVSDK is a development environment done by TI for its platforms, enabling an efficiently use of DSP capabilities for applications such as streaming video encoding and decoding.

DVSDK is available via open embedded (recipes/ti), however it is better to use the TI version as it corresponds to the last version for our platform.

In order to download the DVSDK, you need to login on TI website and go to: http://focus.ti.com/docs/toolsw/folders/print/linuxdvsdk-omap3530.html .

To avoid any failure, installation must be done via the console:

./dvsdk_omap3530-evm_4_01_00_09_setuplinux --mode console

The Codesourcery toolchain path will be requested at the beginning of the installation. The dvsdk uses this specific version, Sourcery G++ Lite 2009q1-203, downloadable at http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057.

Module compilation

Once dvsdk is installed, the following compilations must be done:

make -j8 linux
make dsplink
make cmem
make c6run
make c6accel
make codecs
make dmai
make demos

The linux “module” corresponds the the system kernel. By default, the psp kernel (psp/linux-2.6.32-psp03.00.01.06) is used by dvsdk. Even if Technexion basis uses the default kernel, it is preferable to change the kernel by modifying the following variable in the Rules.make file:

LINUXKERNEL_INSTALL_DIR=/path/to/technexion/kernel

During the tutorial, the kernel sources from Technexion are placed at 2 locations:

/root/tao-3530/tao-20110401/kernel
/home/account/open_embedded/tao3530/work/tao3530-angstrom-linux-gnueabi/linux-tao3530-2.6.32-r101/linux_src_ti-psp_03.00.01.06

In order to avoid any problem, it is better not to use any sources from the root directory. The 2nd path is then a better choice, or it is possible to copy the sources from the 1st one in another location and change permission (chown -R account:account).

The dsplink is then used for the communication between the GPP (cortex-A8) and the DSP. It is generated as a module, this is why the kernel must be firstly generated.

The cmem is a module as well, allowing contiguous memory, which is mandatory for DSP memory access. Cmem is then necessary in order to use dsplink. If for instance we want to encode a video, the frames are collected by the GPP and must be stored in the cmem, so the DSP can read them. The DSP will then encode the frames and will store the result in another location of the cmem. The GPP can get back the encoded data with the FS, for instance within a test.mpeg4 file.

c6run is a tool used to easily code on the DSP, decreasing the ARM CPU load:

c6accel allows to use DSP optimized algorithms developped by TI. They are called via an API from the GPP, allowing all required functions.

codecs contains all audio, image and video encoders and decoders. There are a number of default codecs proposed by TI, and it’s possible to add others, or even to develop your own algorithms:

ls codecs-omap3530_4_00_00_00/packages/ti/sdo/codecs/
aachedec  deinterlacer  g711dec  g711enc  h264dec  h264enc  jpegdec  jpegenc  mpeg2dec  mpeg4dec  mpeg4enc

dmai is a DVSDK high level API to access several functions such as video streaming, display, use of dsplink to encode/decode, manage the hardware accelerators like resizing ... The API documentation is generated by Doxygen:

firefox dmai_2_20_00_14/docs/html/index.html

Here are some examples:

ls dmai_2_20_00_14/packages/ti/sdo/dmai/apps/
app_common.cfg   audio_decode_io1  fc_common.cfg     image_encode_io1  speech_decode_io1  video_decode_io2  video_encode_io_multich1  video_loopback_copy
app_common.tci   audio_encode1     image_decode_io   Makefile          speech_encode1     video_display     video_loopback            video_loopback_resize
audio_decode1    audio_encode_io1  image_decode_io1  Makefile.app      speech_encode_io1  video_encode_io   video_loopback_blend
audio_decode_io  dmai.gel          image_encode_io   speech_decode1    video_decode_io    video_encode_io1  video_loopback_convert

demos is an example for audio and video decode, audio and camera streaming encode, and Sobel filtering. The SMAI API is demonstrated, with C6ACCEL API for the last example.

ls dvsdk-demos_4_00_00_21/omap3530/
ctrl.c  ctrl.h  ctrl.o  decode  demo.h  edge_detection  encode  Makefile  ui.c  ui.h  ui.o

Target installation

Firstly, the modules have to be copied to the rootfs:

cp ./linuxutils_2_25_05_11/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.ko /root/oe_tao3530/home/root/
cp ./dsplink_1_65_00_02/dsplink/gpp/export/BIN/Linux/OMAP3530/RELEASE/dsplinkk.ko /root/oe_tao3530/home/root/

Then the examples:

cp ./codecs-omap3530_4_00_00_00/packages/ti/sdo/server/cs/bin/cs.x64P /root/oe_tao3530/home/root/
cp dvsdk-demos_4_00_00_21/omap3530/decode/decode /root/oe_tao3530/home/root/
cp dvsdk-demos_4_00_00_21/omap3530/encode/encode /root/oe_tao3530/home/root/

The file cs.x64P is the DSP executable file. cs stands for codec server, each codec used by the application is integrated as a server (ex: h264enc, mpeg4dec ...). Each server can be called once a time, but several codec servers can be used at the same time.

The decode and encode files correspond to the application for the gpp, that is to say which will be launched by linux.

The 3 files must be located in the same directory as the application will be loaded on the DSP when the application will start.

Display

Links explaining OMAP3530 video architecture:

The architecture is a bit different using Technexion Kernel, because 3 frame buffers are used:

  • /dev/fb0 est relié à l’overlay0 (gfx)
  • /dev/fb1 est relié à l’overlay1 (vid1)
  • /dev/fb2 est relié à l’overlay2 (vid2)

The frame buffers fb0, fb1 and fb2 require the video streaming to be in RGB format. This means for instance, that to display a video from a camera which is in YUV format, a conversion is needed (UYUV -> RGBA).

The following architecture is also available:

  • /dev/fb0 –> overlay0 (gfx)
  • /dev/video1 –> overlay1 (vid1)
  • /dev/video2 –> overlay2 (vid2)

In this case, only gfx, via the frame buffer fb0, uses RGB format, and the overlays 1 and 2 accept YUV format. This is very useful to display a video from a camera without the need of a format conversion, which requires a lot of CPU resources.

The DMAI API is configured in order to work with this architecture, and needed to properly run the examples.

To configure then this video architecture, the Tsunami defconfig variables must be modified as follow:

CONFIG_VIDEO_OMAP2_VOUT=m

CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB_OMAP2_NUM_FBS=1

To recompile the kernel and modules:

export PATH=$PATH:/opt/arm-2009q1/bin
make ARCH=arm omap3_tsunami_defconfig
--> modify .config file
make -j8 ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage
make -j8 ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- modules

The display module can then be find in ./drivers/media/video/ti-media/omap-vout.ko, to be copied on the rootfs as previously done.

Audio decoding

In this chapter, we will learn how to decode an audio file, and play it through the audio output. This can be done using the ‘decode’ example of DVSDK.

As seen previously, the following files are copied:

  • cmemk.ko
  • dsplinkk.ko
  • decode
  • encode
  • cs.x64P

To enable the decoding feature, the 2 modules have to be loaded (omap-out.ko is useful for the next steps), with cmemk using several arguments.The ./codec-engine_2_26_01_09/examples/apps/system_files/OMAP3530/loadmodules.sh file is enough in this audio decode case.

./loadmodules.sh

You however should get an error and will need to add a parameter for the boot: mem=80M. This means that Linux will use 80MB of the RAM, the remaining memory size will be available for functions such as cmem (default is 16MB on OMAP3530).

The u-boot command is the following:

setenv linux_args setenv bootargs console=${console} nfsroot=${serverip}:/root/oe_tao3530 ip=${ipaddr}:${serverip}:192.168.1.254:255.255.255.0::eth0:off mem=80M; tftpboot 84000000 uImage; run linux_args; bootm 84000000

Before you can play the audio, the volume must be adjusted using alsamixer. To install it on the target:

opkg install alsa-utils alsa-utils-alsamixer alsa-utils-amixer

To correctly display the ncurses menu from alsa-mixer, you need a ssh connection. In order to adjust the volume, DAC2 must be activated and all activated pre-dividers set to 100%.

The audio decode function is then usable:

# ./decode -a Guitare.aac
Decode demo started.
ARM Load: 2% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 37 kbps Time: 00:00:01 Demo: Decode Display: VGA Video Codec: N/A Resolution

ARM Load: 0% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 26 kbps Time: 00:00:02 Demo: Decode Display: VGA Video Codec: N/A Resolution

ARM Load: 2% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 27 kbps Time: 00:00:03 Demo: Decode Display: VGA Video Codec: N/A Resolution

ARM Load: 0% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 25 kbps Time: 00:00:04 Demo: Decode Display: VGA Video Codec: N/A Resolution

ARM Load: 0% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 25 kbps Time: 00:00:06 Demo: Decode Display: VGA Video Codec: N/A Resolution

ARM Load: 1% DSP Load: 0% Video fps: 0 fps Video bit rate: 0 kbps Sound bit rate: 27 kbps Time: 00:00:07 Demo: Decode Display: VGA Video Codec: N/A Resolution

End of clip reached, exiting..

Video decoding

To decode a video using an available codec (h264, mpeg4, mpeg2), you need again to modify the boot parameters:

setenv linux_args setenv bootargs console=${console} nfsroot=${serverip}:/root/oe_tao3530 ip=${ipaddr}:${serverip}:192.168.1.254:255.255.255.0::eth0:off mem=80M consoleblank=0 omapdss.def_disp="lcd"; tftpboot 84000000 uImage; run linux_args; bootm 84000000;

The extra consoleblank=0 parameter allows to the OSD (overlay0 or /dev/fb0) not to fall down in standby mode after 5 minutes.

Then the file loadmodules.sh needs to be modified as follow.

loadmodules.sh file, to be used:

insmod omap-vout.ko video1_numbuffers=3 video2_numbuffers=3 video1_bufsize=644000 video2_bufsize=644000 vid1_static_vrfb_alloc=y vid2_static_vrfb_alloc=y


CMEM_MODPARAMS="phys_start=0x85000000 phys_end=0x86000000 pools=6x835584,2x3000000,2x692224,4x829440"

if [ -e cmemk.ko ]
    then
 insmod cmemk.ko $CMEM_MODPARAMS

    else
 modprobe cmemk $CMEM_MODPARAMS
fi

# Allow cmem driver to be used by all users
if [ -e /dev/cmem ]

    then
 chmod 666 /dev/cmem
fi

# insert DSP/BIOS Link driver
if [ -e dsplinkk.ko ]

    then
 insmod dsplinkk.ko
    else
 modprobe dsplinkk
fi

# Allow dsplink driver to be used by all users
if [ -e /dev/dsplink ]

    then
 chmod 666 /dev/dsplink
fi

# insert Local Power Manager driver
if [ -e lpm_omap3530.ko ]

    then
 insmod lpm_omap3530.ko
    else
 modprobe lpm_omap3530
fi

# Allow lpm driver to be used by all users
if [ -e /dev/lpm0 ]

    then
 chmod 666 /dev/lpm*
fi

A first line for omap-vout has been added, and the second line for cmem has been modified.

The insertion of omap-vout module will create the nodes /dev/video1 and /dev/video2. This can be different if for instance video0, video1 and video2 are already used. In this case the video3 and video4 will be created. The number and sizes of buffers are set in the parameters. The decode example uses 3 buffers, and the size is related to the display size (480*272*2=261120 in our case with a touch panel of 480*272, multiplied by 2 because of YUV format).

The cmem parameters enable then to set the number and size of POOLS. In practical terms, the 16MB used by cmem are divided into POOL, with the size defined in the parameters. The decode application uses 9 POOL with 4 for displaying and 5 for decoding. So if you’re decoding a PAL or NTSC video (pal->720*576 and ntsc->720*480), 9 pools of 720*576*2 = 829440 are needed.

The modifications in the code are located in the file dvsdk-demos_4_00_00_21/omap3530/decode/display.c:

  • The functions force30HzLCD() and restore60HzLCD() have to be removed in order to avoid the application to modify the LCD parameters (via sysfs ou fbset).
  • To remove transparency between the framebuffer (including a console for instance) and the vidéo, the fonctions enableAlphaBlending() and disableAlphaBlending() need to be removed.

Then, the node corresponding to vid1 has to be defined since the application uses the Display_Attrs_O3530_VID_DEFAULT structure. Its definition is in the file dmai_2_20_00_14/packages/ti/sdo/dmai/linux/Display.c and the name of the node has to be set against the first node created by omap-vout (cat /sys/class/video4linux/videoX/name).

The following modules need then to be recompiled:

make dmai_clean
make dmai
make demos_clean
make demos
sudo cp dvsdk-demos_4_00_00_21/omap3530/decode/decode /root/oe_tao3530/home/root

And the decoding is practical:

# ./decode -t 10 -v davincieffect_pal.264
Decode demo started.
ARM Load: 29% DSP Load: 14% Video fps: 0 fps Video bit rate: 13 kbps Sound bit rate: 0 kbps Time: 00:00:01 Demo: Decode Display: VGA Video Codec: H264 BP Res

ARM Load: 19% DSP Load: 24% Video fps: 12 fps Video bit rate: 10 kbps Sound bit rate: 0 kbps Time: 00:00:02 Demo: Decode Display: VGA Video Codec: H264 BP Re

ARM Load: 11% DSP Load: 85% Video fps: 26 fps Video bit rate: 4627 kbps Sound bit rate: 0 kbps Time: 00:00:03 Demo: Decode Display: VGA Video Codec: H264 BP

ARM Load: 14% DSP Load: 83% Video fps: 29 fps Video bit rate: 4601 kbps Sound bit rate: 0 kbps Time: 00:00:04 Demo: Decode Display: VGA Video Codec: H264 BP

ARM Load: 18% DSP Load: 84% Video fps: 28 fps Video bit rate: 3927 kbps Sound bit rate: 0 kbps Time: 00:00:06 Demo: Decode Display: VGA Video Codec: H264 BP

ARM Load: 9% DSP Load: 84% Video fps: 29 fps Video bit rate: 3917 kbps Sound bit rate: 0 kbps Time: 00:00:07 Demo: Decode Display: VGA Video Codec: H264 BP

Regarding the encode example, the camera video stream is used. The DMAI API requires the video input to be S-VIDEO or Composite for the capture. Because the Tsunami board has only a S-Video input, an other way is to use a USB camera.

This is possible to encode the streaming from a USB camera with a couple of modifications to do:

© Copyright 2011, Oselis. Created using Sphinx 0.6.4.

White papers

 Adding a module to the kernel : A module can be loaded and unloaded on demand, the benefit of a module is that it does'nt reside into the monolithic kernel image. Read more...

 ARM simulation with qemu and NFS : First step, the development PC station configuration. This phase consists to add and configure a "bridge". Read more...

 Getting started with OMAP3530 : Basic environment setup of Tsunami board, TechNexion PSP installation Read more...

Buildroot on OMAP3530 : In this toturial, the 2011.02 version of builroot was used. Read more...

Open embedded on OMAP3530 : Configuration of Tsunami board. The OE reference tutorial is under... Read more...

DVSDK on OMAP3530 : DVSDK is a development environment done by TI for its platforms, enabling an... Read more...