DVSDK

Installation

Le DVSDK est un environnement de développement fournis par TI pour ses platformes, permettant de tirer profit des capacités du DSP pour des applications tels l’encodage et le décodage vidéos de flux audio.

Ce dvsdk est disponible via open embedded (recipes/ti), mais il est préférable d’installer le dvsdk de TI car il correspond à la dernière version pour notre platforme.

Pour télécharger ce DVSDK de 1,5G, il faut s’inscire sur le site de TI et se rendre au lien suivant: http://focus.ti.com/docs/toolsw/folders/print/linuxdvsdk-omap3530.html .

Il faut l’installer via la console pour ne pas avoir de ‘bug’:

./dvsdk_omap3530-evm_4_01_00_09_setuplinux --mode console

Au début de l’installation, le path de la toolchain codesourcery va être demandé. Le dvsdk utilise une version bien précise, la Sourcery G++ Lite 2009q1-203, qui peut être téléchargée au même endroit: http://www.codesourcery.com/sgpp/lite/arm/portal/subscription3057.

Compilation de chaque module

Une fois le dvsdk installé, il faut effectuer les compilations suivantes:

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

Le “module” linux correspond au noyau du système. Il peut être préférable de le changer de noyau, car par défaut, celui du psp (psp/linux-2.6.32-psp03.00.01.06) est utilisé par dvsdk. Même si le noyau Technexion est basé sur le noyau utilisé par défaut, il est préférable de changer de noyau. Pour cela il faut modifier la variable suivante dans le fichier Rules.make:

LINUXKERNEL_INSTALL_DIR=/path/to/technexion/kernel

Au cours du tutoriel, les sources du noyau de technexion sont placés à 2 endroits:

/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

Afin d’éviter certains problème, il est mieux utiliser des sources qui n’appartiennent pas au root. Donc le 2ème path est un meilleur choix, ou alors copier les sources du 1er autre part, et changer la permission (chown -R account:account).

Ensuite le dsplink sert à effectuer la communication entre le GPP (cortex-A8) et le DSP. Il est généré sous forme de module, c’est pour cela que le noyau doit être généré en premier.

Le cmem est aussi un module, et il permet d’avoir de la mémoire contiguë ce qui est obligatoire pour que le DSP puisse lire la mémoire. Donc, si l’on veut utiliser le dsplink, il est obligatoire d’utiliser le cmem. Par exemple, si l’on souhaite encoder une video, les frames sont récupérées via le GPP. Ces frames doivent être stockées dans le cmem afin que le DSP soit en mesure de pouvoir les lire. Ensuite le DSP encode celles-ci et écrit le résultat dans une autre partie du CMEM. Le GPP les récupère et les écrit sur le FS, dans un fichier test.mpeg4,par exemple, dans le cas d’un encodage en mpeg4.

c6run permet de développer facilement du code pour le DSP. Cela permet de décharger le cpu ARM sur le DSP:

• http://processors.wiki.ti.com/index.php/Introduction_to_C6Run
• http://processors.wiki.ti.com/index.php/C6Run_FAQ.

c6accel permet d’utiliser des algorithmes optimisés et développés par TI, pour le DSP car ils sont très demendeur en ressources. Ils sont appelés depuis le GPP, via une API, contenant tous les opérations possibles.

• http://processors.wiki.ti.com/index.php/C6EZAccel_FAQ
• http://processors.wiki.ti.com/index.php/C6Accel
• http://processors.wiki.ti.com/index.php/Using_C6Accel_on_DM6467_with_DVSDK_3.x
• http://processors.wiki.ti.com/index.php/C6Accel_Signal_Processing_API_Reference_guide
• http://processors.wiki.ti.com/index.php/C6Accel_Image_Processing_API_Reference_guide
• http://processors.wiki.ti.com/index.php/C6Accel_Math_API_Reference_guide

codecs contient les différents codecs pour encoder/décoder des vidéos, images, sons. TI en propose quelque uns par défaut, et il est possible d’en ajouter d’autres, ou de créer ses propres codecs:

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

dmai est une API haut niveau du DVSDK qui permet d’effectuer plusieurs choses comme récupérer le flux d’une caméra, accéder au display, utiliser le dsplink pour encoder/décoder, utiliser le resizer hard ... Toutes les fonctionnalités de l’API sont présentées dans une documentation générée avec doxygen:

firefox dmai_2_20_00_14/docs/html/index.html

Il y a aussi quelques exemples dans:

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 contient un exemple pour décoder de l’audio ou de la vidéo, un autre pour l’encodage soit d’une caméra ou d’une entrée audio, et un troisième pour appliquer un filtre sobel sur le flux d’une caméra. L’API DMAI est utilisée et l’API C6ACCEL est utilisée en plus pour le dernier exemple.

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

Installation sur la cible

Il faut tout d’abord copier les modules sur le 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/

Ensuite les programmes exemples:

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/

Le fichier cs.x64P correspond à l’executable DSP. cs signifie codec server, c’est-à-dire que chaque codec utilisé dans l’application y est intégré sous forme de serveur (ex: h264enc, mpeg4dec ...). Chaque serveur ne peut être utilisé qu’une seule fois par l’application à un moment donné, mais plusieurs codec server peuvent être utilisé en même temps.

Les fichiers decode et encode correspondent à l’application pour le gpp, c’est-à-dire qui va être lancé depuis linux. Les 3 fichiers doivent se trouver dans le même répertoire car l’application du gpp va charger l’application sur le dsp, au démarrage de l’application.

Display

Liens pour comprendre l’architecture vidéo sur le omap3530:

• http://processors.wiki.ti.com/index.php/UserGuideDisplayDrivers_PSP_03.00.00.05
• http://processors.wiki.ti.com/index.php/DSS2_SYSFS_Examples
• http://processors.wiki.ti.com/index.php/OMAP3_DSS2_Architecture

Avec le noyau technexion, l’architecture n’est pas la même car 3 framebuffers sont utilisés:

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

L’inconvéniant de cette architecture est que la plupart des caméras renvoient un flux UYUV. Donc, pour afficher un flux video, il faut effectuer une conversion RGBA -> UYUV à chaque frame. Si vid1 est aussi en UYUV, aucune conversion “inutile” doit être effectuée.

Le but sera d’avoir l’architecture présentée dans les liens ci-dessus:

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

De plus, l’API DMAI est configuré pour travailler avec ce type d’architecture, ce qui est nécessaire pour faire fonctionner les exemples.

Afin d’avoir cette architecture vidéo, il faut changer les variables suivantes du defconfig de la tsunami:

CONFIG_VIDEO_OMAP2_VOUT=m
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB_OMAP2_NUM_FBS=1

Pour ensuite recompiler le noyau, ainsi que les 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

Le module pour le display se trouve ensuite dans ./drivers/media/video/ti-media/omap-vout.ko, à copier sur le rootfs comme précédemment.

Décodage d’un son

Dans cette partie, nous allons voir comment décoder un fichier audio, et le renvoyer sur la sortie audio. Ceci peut être réalisé grâce à l’exemple ‘decode’ du DVSDK.

Précédemment, les fichiers suivants ont été copiés:

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

Afin de faire fonctionner le décodage, il faut charger les 2 modules (omap-out.ko est utile pour la suite), dont cmemk prend en paramètres plusieurs arguments. Le fichier ./codec-engine_2_26_01_09/examples/apps/system_files/OMAP3530/loadmodules.sh est suffisant pour charger les 2 modules dans le cas d’un décodage audio:

./loadmodules.sh

Cela va normalement échouer car il faut ajouter un paramètre au boot: mem=80M. Cela signifie que Linux va prendre 80M de la mémoire RAM et le reste sera laissé pour les autres fonctionnalités comme cmem (16 MB par défaut sur l’omap3530). La commande u-boot est donc maintenant la suivante:

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

Avant de jouer le son, le volume doit être réglé via alsamixer, qu’il faut installer sur la cible:

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

Il faut ensuite se connecter en ssh, afin d’afficher correctement le menu ncurses d’alsa-mixer. Pour régler le volume, il faut le DAC2 soit activé et que le tous les prédiviseurs soit activés à 100%.

Le décodage audio est ensuite fonctionnel:

# ./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..

Décoder une video

Pour effectuer le décodage d’une video, parmis les codec disponible (h264, mpeg4, mpeg2), il faut, encore, changer les paramètres de boot:

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;

Le paramètre supplémentaire consoleblank=0 permet à l’OSD (overlay0 ou encore /dev/fb0) de ne pas se mettre en veille au bout de 5 minutes.

Ensuite il faut aussi changer le fichier loadmodules.sh sur plusieurs points.

Fichier loadmodules.sh, à utiliser:

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

La première ligne pour omap-vout a été ajoutée, et la deuxième ligne pour le cmem a été modifiée.

L’insersion du module omap-vout va créer les noeuds /dev/video1 et /dev/video2. Cela peut être différent si par exemple video0, video1 et video2 sont déjà pris. Les noeuds video3 et video4 seront alors créés. Dans les paramètres, le nombre de buffers et leurs tailles sont précisés. L’exemple décode utilise 3 buffers, et la taille dépend de la taille de l’afficheur (480*272*2=261120 dans notre cas avec une dalle tactile en 480*272 et *2 car le format et UYUV).

Ensuite, les paramètres du modules cmem permettent de préciser le nombre de POOLS et leurs tailles. Concrètement, les 16MB réquisitionné par cmem sont découpés en POOL, dont la taille est définie par les paramètres. L’application décode utilise 9 POOL, 4 pour le display et 5 pour le décodage. Si l’on prévoit de décoder une vidéo en PAL ou NTSC (pal->720*576 et ntsc->720*480), il faut donc 9 pools de 720*576*2 = 829440.

Ensuite dans le code, les modifications se situent au niveau du fichier dvsdk-demos_4_00_00_21/omap3530/decode/display.c:

• Il faut empécher le programme de modifier les paramètres du LCD (via sysfs ou fbset). Pour cela, il faut enlever les fonctions force30HzLCD() et restore60HzLCD().
• Afin d’enlever la transparence entre le framebuffer(contenant une console par exemple) et la vidéo, il faut enlever les fonctions enableAlphaBlending() et disableAlphaBlending().

Enfin, il faut préciser le noeuds correspondant à vid1 car le programme utilise la structure Display_Attrs_O3530_VID_DEFAULT. Sa définition se trouve dans le fichier dmai_2_20_00_14/packages/ti/sdo/dmai/linux/Display.c et le nom du noeud est à changer en fonction du premier noeuds créé par omap-vout (cat /sys/class/video4linux/videoX/name).

Les modules suivants sont donc à recompiler:

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

Le décodage est fonctionnel:

# ./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

Concernant l’exemple encode, il encode le flux video d’une caméra. L’API DMAI ne supporte que des entrées S-VIDEO ou Composite pour la capture. Etant donné que la carte tsunami ne dispose que d’une entrée S-Video, l’autre moyen est d’avoir une caméra USB.

Cela est possible d’encoder le flux d’une caméra USB, mais il y a plusieurs modifications à effectuer:

• La récupération du flux vidéo doit se faire avec l’api video4linux2 (http://v4l2spec.bytesex.org/spec/capture-example.html).
• Une fois le flux vidéo récupérer, il faut copier chaque frame dans un buffer se situant dans la mémoire cmem (buffer alloué par le thread qui encode).