NVIDIA Tegra Tegra Linux Driver Package
Developers' Guide

June 11, 2012
R15 Release


Getting Started
This section contains information to help you get started using this pre-release of NVIDIA® Tegra® Linux Driver Package. It covers the following topics:
Requirements
The following lists the requirements to use this Tegra Linux Driver Package (L4T) release:
A kernel image (zImage). L4T does contain a kernel image (zImage), and you can also download and rebuild from source. After you have a zImage, you can create the vmlinux.uimg that is used for U-Boot booting. For more information, see Synchronizing Kernel Sources in this guide.
Boot loader. This can be Fastboot or U-Boot. Flashing on Tegra 3 series (code-named Cardhu) and Tegra 2 series (code-named Ventana) developer boards requires a boot loader. This boot loader can be either the Fastboot utility or U-Boot, both of which are included in this release.
A rootfs device which can be an SD card, a USB hard disk, or USB stick formatted to EXT3.It is also possible to use the target device’s internal memory, or your Linux Host PC hard-drive through NFS.
(Cardhu) A USB Micro-B plug to USB Std A female cable to plug into the board’s recovery port.
(Ventana) A USB Micro-B plug to Std A female cable to plug into the board’s recovery port [J10].
Note: The NVIDIA binaries provided for Tegra 2 devices code-named “Ventana” may be able to support the Tegra 2 devices code-named “Harmony”.
Boot Options
It is currently possible to boot L4T on the Tegra 2 series Ventana developer board, as well as Tegra 3 series Cardhu with a root file system from:
USB stick or USB hard disk
Setting Up Your Environment
The following subsections contain information to help you get started using this pre-release of L4T. They cover the following topics:
Extracting Tegra Linux Driver Package
Note: The procedures in this document assume you extract the release package in ~/.
To extract Tegra Linux Driver Package
$ sudo tar -vxjf <platform>_Tegra-Linux-R15.1.0_<release_type>.tbz2
where <release_type> is armel (for softfp ABI) or armhf (for hardfp ABI).
Setting Up Your Board
L4T requires a Tegra 2 series developer board (Ventana), or a Tegra 3 series (Cardhu) as well as a host PC running Linux. Please consult your board documentation for steps on how to setup and configure your board.
Prerequisites
You have a device specified above in the “Boot Options” topic (formatted to EXT3). (It can also be a memory card with a USB adapter.)
You have a mini-B USB male-to-USB Std A female cable to plug into the board’s recovery port [J3].
In your environment for the developer board, if your developer board is Ventana you have set:
$ export TARGET_BOARD=ventana
Or, if your developer board is Cardhu you have set:
$ export TARGET_BOARD=cardhu
Setting Up Your File System
This section describes the steps for setting up your file system. You must set up the root file system and copy the file system to your boot device.
About the Root File System
To replicate the sample file system, ttyS0.conf, nv.conf, and other files have been added to the base Linux release and will be copied alongside the drivers. Both are accessible from base.tgz, should you decide to replicate the rootfs.
The provided sample root file system was created with Rootstock 0.1.99.4 using this command:
$ sudo rootstock --fqdn tegra-ubuntu --login ubuntu --password ubuntu --imagesize 1G -d natty --seed ubuntu-minimal,xserver-xorg-core,xinit,xterm,alsa-utils,wireless-tools,wpasupplicant,x11-xserver-utils,openssh-client,openssh-server
This creates a file system with the hostname tegra-ubuntu, the username ubuntu, and the password ubuntu.
Note: The provided sample target file system does not come with pre-generated ssh host keys. These host keys can be re-generated with the following command:
$ ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
View the ssh-keygen man page for other -t options.
We have also made the following changes:
Added: /etc/init/{ttyS0.conf, nv*, wpa_supplicant.conf}, ./etc/udev/rules.d/99-tegra-devices.rules
Modified: /etc/{init/ssh.conf, X11/Xwrapper.conf, resolve.conf}
Deleted: /etc/ssh/ssh_host_*
To replicate these changes in your own rootstock file-system, copy or make similar modifications from those files to your own rootstock file system.
The following packages are installed by default:
Setting Up the Root File System
The next step in booting the target board is to configure the root file system. Follow the procedures in this section to set up the rootfs and to copy the file system to the rootfs device.
Note: The instructions below use the sample file system that is provided by NVIDIA as the base. If you would like to use your own, set the LDK_ROOTFS_DIR environment variable to point to where your rootfs is located and skip Steps 1 and 2.
To set up the rootfs
1.
Download the following file to your home directory:
Tegra-Linux-Sample-Root-Filesystem_<release_type>.tar.gz
where <release_type> is armel (for softfp ABI) or armhf (for hardfp ABI).
This file contains the NVIDIA-provided sample root file system.
2.
Extract the compressed file as follows:
Navigate to the rootfs directory for the extracted NVIDIA driver package with this command:
$ cd <your_L4T_root>/Linux_for_Tegra/rootfs
where <your_L4T_root> is your L4T root directory, which is assumed to be your home directory (~).
For more information, see Extracting Tegra Linux Driver Package in this section.
$ sudo tar zxpf ../../Tegra-Linux-Sample-Root-Filesystem_<release_type>.tar.gz
3.
Run the apply_binaries.sh script to copy the NVIDIA user space libraries into the target file system:
$ sudo ./apply_binaries.sh
Note: The apply_binaries.sh installs the appropriate default version, for the provided sample file system, of the Tegra X driver by creating a sym-link to point to the proper ABI. The script installs the sym-link to the following location in the rootfs:
./usr/lib/xorg/modules/drivers/tegra_drv.so
If you are using a different rootfs, or if you already have configured your rootfs, you can apply the NVIDIA user space libraries by setting the LDK_ROOTFS_DIR environment variable to point to your rootfs. Then run the script, as shown above, to copy the binaries into your target file system.
To install a different ABI:
Use the apply_binaries.sh script and pass the –abi <number> flag by executing:
$ sudo ./apply_binaries.sh --xabi <number>
where <number> is the ABI version to install, either 5, 6, 7, 8, 10, 11, or 12. The ABI default value for the X driver is ‘X ABI version 10’ and it is the version that is compatible with the provided sample file system. You can find the version to use in the sample file system by following the directions listed below.
To determine the X driver ABI of the X server used in the root file system:
Examine the resulting file /var/log/Xorg.0.log, which will contain something like the following:
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 8.0
The X.Org Video Driver line reports the ABI version. The sample Ubuntu 11.04-based root file system uses X driver ABI 10.
If the apply_binaries.sh script is installed correctly, the last message output from the script is “Success!”.
4.
5.
6.
To copy the file system to the external rootfs device
1.
2.
If your device is not formatted as Ext3, enter the following command to format it with an Ext3 file system:
$ sudo mkfs.ext3 /dev/sd<port>1
where <port> is the port your device is mounted. You can use the dmesg command to determine the port.
3.
If needed, mount your device with the following command:
$ sudo mount /dev/sdX1 <mntpoint>
where <mntpoint> is your rootfs device’s mount point.
4.
$ cd ${LDK_ROOTFS_DIR}
$ sudo tar -cpf - * | ( cd <mntpoint> ; sudo tar -xpf - )
If it is not set, copy the rootfs directory that is included in the release by executing the following commands:
$ cd <your_L4T_root>/rootfs
$ sudo tar -cpf - * | ( cd <mntpoint> ; sudo tar -xpf - )
Once you have flashed your board, you can then unmount the disk and plug it to the board. For more information about flashing, see the Flashing the Boot Loader and Kernel topic in this section. For information about configuring your board setup, see the hardware documentation for your developer board.
Updating Drivers on an Existing Target System
These instructions are for the situation where there was a previous release or driver package loaded onto a target board and that target device is booted.
Prerequisite
You must attach an Ethernet cable to the device through either the Ethernet port (if available) or through the USB Ethernet adaptor. Alternatively, you can connect through Wi-Fi if the appropriate driver and firmware are enabled and installed.
To update drivers on an existing target system
1.
2.
Download the NVIDIA Tegra Linux driver release and the additional support packages (for example the codec's package) from the nvidia.com links with wget. For example, to download the last (not the latest) release do the following:
wget http://developer.nvidia.com/sites/default/files/akamai/tools/files/l4t/r15_beta/cardhu_Tegra-Linux-R15.beta.1.0_armel.tbz2
wget http://developer.nvidia.com/sites/default/files/akamai/tools/files/l4t/r15_beta/cardhu_Tegra-Linux-codecs-R15.beta.1.0_armel.tar.gz
Note: The release shown in this example is a previous release and not the current release.
3.
Extract the release. For more information, see Extracting Tegra Linux Driver Package in this section.
4.
$ export LDK_ROOTFS_DIR=/
$ echo ${LDK_ROOTFS_DIR}
5.
$ cd Linux_for_Tegra
6.
Run the apply_binaries.sh script to install the NVIDIA drivers onto your target board. For more information, see Setting Up the Root File System in this section.
7.
(Optional) Change your X driver ABI as a variable passed into apply_binaries. For more information, see Setting Up the Root File System in this section.
8.
For the codecs, or other additional packages, extract the files, being sure to extract them to your root '/' directory. For more information, see Installing Additional Packages in this section.
Determining the Success of a Driver Update
You can determine whether a driver update went successfully.
To determine the success of a driver update
$ cat /etc/nv_tegra_release | grep -v -P '^#.*$' | sha1sum -c
Increasing the Internal Memory Partition Size for the Root File System
The suggested rootfs partition size for Ventana and Cardhu is 1073741824 bytes and is specified by default in the flash.sh script. This 1 GB reserved in internal memory for the rootfs partition may be insufficient for installation of additional packages. Packages such as ubuntu-desktop, gst, and other gnome plug-ins may require additional space.
The “-S <size-in-bytes>” argument to flash.sh can be used to change the partition size.
To flash for a larger partition
$ sudo ./flash <target_device> -S <size_in_bytes> <rootdev>
Where:
<target_device> is either cardhu or ventana.
<size_in_bytes> is the desired size for the partition.
<rootdev> is the rootfs partition’s internal memory, for example mmcblk0p1.
Installing Additional Packages
This section explains how to install the additional NVIDIA packages, additional Ubuntu packages, and Google Chrome.
Installing Additional NVIDIA Packages
Additional NVIDIA packages may be posted alongside the release. To make full use of the features in the release, these additional packages must be installed. These may include the following packages:
restricted_codecs.tbz2, which is included in the <target_board>_Tegra-Linux-codecs-<version>_<release_type>.tar.gz
Directly after the "apply_binaries" step in Setting Up the Root File System, you can install the package into the configured rootfs.
To install an NVIDIA package when the rootfs is already installed on the device
1.
$ sudo mount <device> /mnt
where <device> is the device such as /dev/sda1.
2.
$ tar -C /mnt -xjf <path-to>/$<package_name>
where <package_name> is one of the packages.
For example, if you have the restricted_codecs.tbz2 file located in:
<home>/restricted_codecs.tbz2
then your line will look like:
$ tar -C /mnt -xjf <home>/restricted_codecs.tbz2
3.
Unmount the device with this command:
$ sudo umount <device>
and attach the device to the target board.
Installing Additional Ubuntu Packages
This section explains how to install additional packages from Ubuntu by using the provided sample file-system. For example, you may wish to download the following packages:
openssh-server for remotely logging in
ubuntu-desktop for the standard Ubuntu graphical user interface
You can receive notifications from Update Manager when new Ubuntu packages are available.
Note: L4T is tested with base Ubuntu packages only. No updated packages have been tested.
To receive notifications
1.
Locate and edit the following file:
/etc/apt/sources.list
2.
deb http://ports.ubuntu.com/ubuntu-ports <distribution>-updates main universe
Where <distribution> is the name of the Ubuntu distribution your rootfs is based on. For example, add the line:
deb http://ports.ubuntu.com/ubuntu-ports natty-updates main universe
for a rootfs based on the Natty Narwhal distribution of Ubuntu.
Prerequisite
You have attached an Ethernet cable to the device through either the Ethernet port (if available) or through the USB Ethernet adaptor, or connect through Wi-Fi if the appropriate driver and firmware are enabled and installed.
To install more packages
1.
Boot the target device.
2.
Turn on networking by executing:
$ sudo dhclient
Note: You may need to specify eth0/eth1 and other parameters to assign an IP address to the appropriate interface.
3.
Install packages using apt-get. For example, to install wget execute this command:
$ sudo apt-get install wget
Installing Google Chrome
You can install Google Chrome from the command line, without using a browser.
Note: These installation procedures are untested.
To install Google Chrome from the command line
1.
$ wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
2.
$ sudo add-apt-repository 'deb http://dl.google.com/linux/chrome/deb/ stable main'
3.
$ sudo apt-get update
4.
$ sudo apt-get install google-chrome-stable
Or install the beta version (latest version) with:
$ sudo apt-get install google-chrome-beta
For instructions on installing Google Chrome, see:
http://www.ubuntuupdates.org/ppa/google_chrome
Configuring NFS Root on the Linux Host
To boot the target device from NFS, you must provide an NFS root mount point on your Linux host machine. The procedure in this section describes the basic steps to do so.
Prerequisites
You must have an Ethernet connection on the target, as well.
To configure NFS root on the Linux host
1.
Install the nfs components on your host machine:
$ sudo apt-get install nfs-common nfs-kernel-server
2.
Modify /etc/exports to look somewhat like this:
$ /nfsroot *(rw,nohide,insecure,no_subtree_check,async,no_root_squash)
After adding the entry, restart using the following command:
$ sudo /etc/init.d/nfs-kernel-server restart
3.
Create an /nfsroot directory on your Linux host machine:
$ sudo mkdir /nfsroot
4.
$ cd ./rootfs
$ sudo tar -cpf - * | ( cd /nfsroot ; sudo tar -xpf - )
5.
$ sudo exportfs -a
Alternatively, you can export or un-export all directories by using the -a and -u flags. The following command un-exports all directories:
$ sudo exportfs -au
6.
(Optional) If the Ubuntu firewall blocks NFS root access, it must be disabled depending upon your configuration. You can do so with the following command:
$ sudo ufw disable
7.
If there are issues performing the NFS boot, to separately verify everything on the ‘host’ machine is configured properly, you can perform the following step on a booted target board through USB/SD/internal eMMC. It should be possible to mount the host NFS root point on the target device:
$ mkdir rootfs
$ sudo mount -v -o nfsvers=3 <IP-ADDR>:/nfsroot rootfs
Where <IP-ADDR> is the IP address of the Linux Host machine as taken from the “ifconfig” command. This proves that the host configuration is correct.
Note: You must install the nfs-common package using the following command prior to executing the mount command on the target machine:
$ sudo apt-get install nfs-common
To boot the target with the NFS root point, see the Flashing the Boot Loader and Kernel topic in this section and be sure to include the -N option for the nfs root point.
Setting Power Saving Options
This section explains how to enable the hotplug driver and the Tegra CPU power-gated state (LP2) for power savings on the target board.
Enabling the Auto-Hotplug Driver
The auto-hotplug driver implements the policy for when to bring cores online/offline. The auto-hotplug driver also implements the policy for when to switch clusters, i.e. when to switch from companion CPU to main CPU or vice versa. Cluster switching is transparent to the OS. The switch happens when software enters a power-gated state on one CPU core and hardware resumes the execution on a different physical CPU core.
To enable the auto-hotplug driver
$ echo 1 > /sys/module/cpu_tegra3/parameters/auto_hotplug
Enabling the Tegra CPU Power-Gated State (LP2)
With the LP2 power state, the CPU core is power-gated if supported by the hardware. If all CPU cores on the VDD_CPU power rail are in LP2, Tegra hardware signals the PMIC to turn off the regulator.
To enable the LP2 power state
$ echo Y > /sys/module/cpuidle/parameters/lp2_in_idle
Flashing the Boot Loader and Kernel
This section describes the steps that must be taken to boot the target board (Ventana or Cardhu) and provides usage information for the flash.sh script.
Flash Procedure
The first step is to flash the board with the boot loader and kernel.
Prerequisites
The following directories must be present:
/bootloader—boot loader plus flashing tools (NvFlash, CFG, BCTs, etc.)
/kernel—a kernel zImage/vmlinux.uimg plus scripts to sync/build the kernel
/rootfs—the root file system that you download
/nv_tegra—NVIDIA® Tegra® user space binaries
You must also have the USB cable connected to the recovery port prior to running the commands listed below. For more information, see the Requirements topic in this section.
To flash the boot loader and kernel
1.
2.
Now run the flash.sh script that is in the top level directory of this release. The script must be supplied with the device name that it will have in the root file system:
$ sudo ./flash.sh <target_board> <rootdev>
If the root file system will be on a USB disk, execute the script as follows:
$ sudo ./flash.sh <target_board> sda1
Otherwise, if the root file system will be on an SD card, execute the script as follows:
$ sudo ./flash.sh <target_board> mmcblk1p1
Where <target_board> is ventana or cardhu, depending upon your target device.
The above examples are for fastboot. For U‑Boot, add the following argument:
-L <PATH_TO_U-BOOT_BIN_FILE>
For example:
$ sudo ./flash.sh –L bootloader/<target_board>/u-boot.bin <target_board> <rootdev>
The boot loader and kernel will load.
For more information on U-Boot see the U-Boot Guide chapter of this document.
Flash Script Usage
You can find the most up-to-date usage information by running flash.sh h (using the flash.sh script included in the release). The basic usage information is as follows.
Usage
sudo ./flash.sh [options] <target_board> <rootdev>
Where you specify the required parameters and one or more of the options shown in the following table.
Is one of ventana or cardhu.
Is one of following:
Specifies the kernel command line. Warning: This manual kernel command line should be *FULL SET*. Upon detecting the manual command line, the boot loader overrides the entire kernel command line with this <cmdline> input.
Specifies initrd file. Null initrd is the default.
Specifies the X driver ABI TBZ2 file.
Specifies the xorg.conf file to override the default.
Synchronizing the Kernel Sources
You can manually rebuild the kernel used for this package. Internet access is required to do so. All the related scripts are located in the kernel directory.
Prerequisites
You have installed Git. This can be done on Ubuntu 10.04 by running the following command:
$ sudo apt-get install git-core
Your system has the default Git port 9418 open for outbound connections.
To rebuild the kernel
1.
$ ./source_sync.sh -k
Which will prompt you to enter a ‘tag’ name, which is provided in the release notes. Alternatively, you can provide the ‘tag’ name when calling the script. For example:
$ ./source_sync.sh -k<TAG_NAME>
—Or—
You can also manually sync the sources, as follows:
$ cd <myworkspace>
$ git clone git://nv-tegra.nvidia.com/linux-2.6.git kernel_sources
$ cd kernel_sources
$ git checkout <TAG_NAME>
where <TAG_NAME> is the ’tag’ name that is available in the release notes.
You can sync to any Linux tag you would like, but the tag provided in the release notes will sync the sources to the same sources the release binary was built from. To see a list of the available release tags, use:
$ git tag –l ‘tegra-l4t*
Building the NVIDIA Kernel
Follow the steps in this procedure to build the NVIDIA kernel.
Prerequisites
To build the Tegra Kernel
1.
$ export CROSS_COMPILE=<crossbin>
$ export TEGRA_KERNEL_OUT=<outdir>
$ export ARCH=arm
where:
<crossbin> is the prefix applied to form the path to the tool chain for cross compilation, e.g., gcc. For a CodeSourcery tool chain, it will look something like:
<csinstall>/arm-2009q1-203-arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-
<outdir> is the desired destination for the compiled kernel.
2.
$ cd <myworkspace>/kernel
$ mkdir $TEGRA_KERNEL_OUT
$ make O=$TEGRA_KERNEL_OUT tegra3_defconfig
$ make O=$TEGRA_KERNEL_OUT tegra_defconfig
Where <myworkspace> is the parent of the Git root.
Configuring ALSA
This topic documents how to configure the Advanced Linux Sound Architecture (ALSA) to enable playback. It pertains to both the Cardhu and Ventana boards.
To playback using board speaker
amixer cset numid=46 2
amixer cset numid=47 2
amixer cset numid=44 63,63
amixer cset numid=49 1
amixer cset numid=50 1
amixer cset numid=51 1
amixer cset numid=52 1
amixer cset numid=53 1
amixer cset numid=54 1
amixer cset numid=63 1
amixer cset numid=64 1
amixer cset numid=33 120,120
amixer cset numid=48 63,63
OpenGL/EGL Gears Test Application
If you would like to run a sample OpenGL/EGL test application, you can run the open-source Gears application.
To install and run Gears test application
1.
$ sudo apt-get install mesa-utils-extra
2.
Manually create the sym-links in the target root file-system for /usr/lib/libEGL.so.1 and /usr/lib/libGLESv2.so.2.
$ mv /usr/lib/libEGL.so /usr/lib/libEGL.so.1
$ mv /usr/lib/libGLESv2.so /usr/lib/libGLESv2.so.2
$ ln -s /usr/lib/libEGL.so.1 /usr/lib/libEGL.so
$ ln -s /usr/lib/libGLESv2.so.2 /usr/lib/libGLESv2.so
3.
$ export DISPLAY=:0
$ X&
$ /usr/bin/es2gears
GStreamer-based Multimedia Playback (NvGstPlayer)
You can use the GStreamer open source multimedia framework and the NvGstPlayer utility for testing multimedia local playback and HTTP/RTSP streaming playback use cases. The NvGstPlayer can be used as a reference implementation.
This section tells you how to install and use these applications. This section includes the following sub-topics.
Installing GStreamer
You install GStreamer from the Internet directly on the target. There is a wrapper library called gst-openmax that is an interface between GStreamer and OpenMAX, which enables accelerated NVIDIA plug-ins in the GStreamer framework
For more information about GStreamer, see the following website:
http://gstreamer.freedesktop.org
NvGstPlayer is a multimedia player test application.
To install GStreamer on the target
1.
$ sudo apt-get -y install gstreamer-tools
$ sudo apt-get -y install gstreamer0.10-plugins-good
$ sudo apt-get -y install gstreamer0.10-plugins-bad
$ sudo apt-get -y install gstreamer0.10-plugins-ugly
$ sudo apt-get install gstreamer0.10-plugins-base
$ sudo apt-get -y install alsa-utils
$ sudo apt-get -y install gstreamer0.10-alsa
$ sudo apt-get –y install gstreamer0.10-ffmpeg # required for nvgstcapture
2.
Once this is installed you can see if the installation is complete by typing the following:
gst-inspect | grep qtdemux
To install GStreamer-0.10 on Cardhu
xinit &
export DISPLAY=:0
Using NvGstPlayer
NvGstPlayer is a command line media file player. It will play audio/video files encapsulated in MP4, 3GP, AVI, ASF, WMA, MKV, M2TS, WEBM, and MOV. NvGstPlayer supports local file playback and playback over RSTP, HTTP, and UDP. This section describes NvGstPlayer usage, runtime commands, default settings, and important notes.
Usage
./nvgstplayer [OPTIONS]
Options
For the complete list of options, see the Help menu.
./nvgstplayer --help
Most options are self-explanatory. Some of the more complicated commands are described in the following sections:
Simple Execution
./nvgstaplayer -i <uri>
Examples
./nvgstplayer -i /home/test.mp4
./nvgstplayer -i file:///home/test.mp4
./nvgstplayer -i udp://192.168.2.5:123
Operating Modes
NvGstPlayer operates in two modes:
Playbin2 (option: --use-playbin)
Decodebin2 (option: --use-decodebin; this is more flexible, allowing users to choose the elements of their choice)
Audio/Video Decoder Chain (--sad/--svd)
The audio/video decoder chain usage takes in a decode chain for a particular URI, either through the -i or -u option URI file.
Examples
--sad=”ffdec_mp3”
--sad=”amrdec; variant=1 ! audioresample ! audioconvert”
--sad=”aacparse ! faad; min-latency=4000000”
--svd=”ffdec_h264; prop=val; prop2=val2”
Note: Use of the colon (;) delimiter and the exclamation mark (!) after every token.
Audio/Video Post-Process Chain (--sac/--svc)
The audio/video post-process chain usage takes in a post-process chain for a particular URI, either through the -i or -u option URI file.
Examples
--sac=”audioconvert ! audioresample”
--svc= “my_video_postprocess; prop1=val1 ! ffmpegcolorspace ! videoscale”
Note: Use of the colon (;) delimiter and the exclamation mark (!) after every token.
To include this in your pipeline
Ensure you have the –disable-anative and --disable-vnative option.
—Or—
Through the URI file native_video=0 and native_audio=0.
Audio/Video Render Chain (--sas/--svs)
The audio/video render chain usage takes in a render chain for a particular URI, either through the -i or -u option URI file.
Examples
--sas=”alsasink; device=hw:0,0”
--sas=”audioconvert ! alsasink”
--svs= “xvimagesink”
--svs = “ffmpegcolorspace ! videoscale ! ximagesink; sync=0”
Note: Use of the colon (;) delimiter and the exclamation mark (!) after every token.
Elements File (--elemfile/-e)
The elements file usage is an input file containing the elements: sources, decoders, parsers, post-process, sinks.
Decoders/Parsers Chain Format
The following shows the format for audio and video decoder/parser chains:
[capabilties]
type=val <val>
pipe=<my_chain>
where <val> is sad or svd.
Post-Process/Render Chain Format
The following shows the format for post-process and render chains:
[type]
pipe=<my_chain>
Example
[video/x-h264]
type=svd
pipe=h264parse ! my_h264_dec; prop1=val1
 
[svs]
pipe=xvimagesink
 
[sas]
pipe=audioconvert ! osssink; device=/dev/dsp1; latency-time=20000;
 
[video/mpeg, mpegversion=4]
type=svd
pipe= ffdec_mpeg4
 
[audio/mpeg, mpegversion=1, layer=3]
type=sad
pipe= mp3parse ! mad
 
[audio/mpeg, mpegversion=4]
type=sad
pipe=faad
 
[svc]
pipe= ffmpegcolorspace; qos=0 ! videoscale
Command Sequence Expression (--cxpr/-x)
The command sequence expression option (as a string) provides a series of commands in an expression format. The following table shows the commands that can be inserted in the expression.
Plays for <val> seconds until next command in the expression.
Pauses for <val> seconds until next command in the expression.
Stops for <val> seconds until next command in the expression.
Does nothing for <val> seconds until next command in the expression.
Seeks to absolute time <val> seconds.
Seeks to absolute time <val> in % of duration.
Seeks to relative time <val> seconds from current position.
Seeks forward by 10 seconds.
Seeks backward by 10 seconds.
Goes to the next track.
Goes to the previous track.
Resets the current track.
Examples
r10.5,s80,w5,p7,r
Does the following, in the following order:
Plays the media for 10.5 seconds.
Seeks to 80 milliseconds from the start of the media.
Waits, doing nothing (not playing or pausing or performing any other action) for 5 seconds.
Pauses for 7 seconds.
Plays the media continuously.
This iterates the expression 2 times:
2{p10,r,w7,s90.55,w2,p,w10,r2}
This iterates the expression 2 times:
2{r20,s10,w5,p10, 2{s10,w6,r9}, 3{r10, p20}}
This iterates the expression 5 times:
5{r8, p10, s90, w10}, 8{s10, w2, p20}
Random Command Sequence Expression (--cxpr=*)
Use cxpr as "*"for a random command sequence expression.
Example
This generates a random command sequence expression of up to 100 characters.
./nvgstplayer -i <uri> --cxpr=*
URI File (--urifile/-u)
The URI file is a file containing a list of URIs. The player plays all URIs listed in the file. The options for the URI listed in the URI file override the same options set by the application through command line arguments for that particular URI.
URI File Format
The following shows the format for a URI file:
[uri1]
option1=val1
option2=val2
..........
..........
 
[uri2]
option1=val1
..........
..........
URI File Options
The following table shows the possible options for URIs inside the URI file.
If 1, disables the global cxpr, if given as command-line argument.
Starts playback time in seconds or percentage of URI duration.
1 indicates that the start option will be a % value.
Maximum size of bytes in queue for buffering.
Maximum size of buffers in queue for buffering.
Maximum size time in queue for buffering.
Image display time in seconds, if URI is an image file.
Video post-processing chain.
Audio post-processing chain.
HTTP source chain.
RTSP source chain.
UDP source chain.
Example
./nvgstplayer -u TestURIfile
Where TestURIfile contains:
[/home/user/test.avi]
cxpr=2{p5, r, w10, s20.5, w6.6, p3, 2 {r, w10, p4}}
start=10.45
repeats=3
audio=0
native_video=0
svd=my_h264dec
svc=ffmpegcolorspace ! my_pp; prop1=shuba; prop2=val2; ! videoscale
 
[/home/user/test.mp3]
sas=audioconvert ! alsasink
 
[/home/user/test.mp4]
nop=1
video=0
Note: The elements can be provided through various methods, such as:
This overrides the value inside the elements file, if present.
This overrides the command line argument, if given, as well as the value inside the elements file, if present.
Example
The URI list can be looped forever by providing --loop-forver option.
./nvgstplayer -u <uri_file> --loop-forever
Gstreamer-based Camera Capture (NvGstCapture)
The NvGstCapture application supports GStreamer version 0.10.32. NvGstCapture can capture audio and video data using microphone and camera and encapsulate encoded A/V data in the container file.
Installing NvGstCapture
Follow these steps to install the nvgstcapture application.
To install nvgstcapture
1.
2.
Verify the device is running GStreamer version 0.10.32 by executing the following command:
$ gst-inspect --version
3.
$ export DISPLAY=:0
$ xinit &
4.
To enable audio capture using the built-in microphone on cardhu, set the following amixer settings:
$ amixer cset numid=82 on
$ amixer cset numid=71 1
$ amixer cset numid=1 on
$ amixer cset numid=4 on
$ amixer cset numid=77 0
$ amixer cset numid=74 on
$ amixer cset numid=42 63,63
$ amixer cset numid=2 31,31
$ amixer cset numid=5 31,31
5.
$ nvgstcapture
6.
When nvgstcapture is running you can type commands to do video and camera capture.
Note: At this point, the nvgstcapture application does not look like it is accepting input but it is.
Additional Notes
The output image/video files (JPG/MP4) are generated in the same directory as the nvgstcapture application.
The filenames are named as nvgsttest(%d).jpg or nvgsttest(%d).mp4.The %d indicates a counter starting from 0 every time the application is launched.
CAUTION: Be sure to backup the recorded files if you need them before launching the application again; otherwise, if you start nvgstcapture and take an image, then close it and restart and take another image, the image taken originally taken is overwritten.
To encode H.263, you must use either 3GP or AVI container formats, as the MP4 container is not supported for H.263 encode.
The nvgstcapture application also supports camerabin2 and GstPhotography, with the pre-requisite that GStreamer is version 0.10.36 at minimum. To use GstPhotography and camerabin2, you must compile and install GStreamer version 0.10.36 on device.
Using NvGstCapture
NvGstCapture supports both command-line and runtime options.
Usage
./nvgstcapture [OPTIONS]
Options
./nvgstcapture –help
This section includes the following topics:
Command-Line Options
The following table shows the command-line options for NvGstCapture.
Video capture width and height
Image capture width and height
Capture ISO value
Capture edge enhancement value
Capture image filter value
Capture white balance value
Stereo mode (0=Off 1=Left Only 2=Right Only 3=Stereo full)
Camera sensor ID (0=Primary(Left-back) 1=Secondary(Front) 3=stereo)
The -d option is only valid if sensorid=3 is set, for example:
./nvgstcapture -q 3 -d 2
Runtime Options
The following table shows the runtime options for NvGstCapture. Most of the options are simple to understand (use --help).
Enter j, or
Followed by a timer (jx5000 to capture after 5 seconds), or
Followed by multishot count (j:6 to capture 6 images).
Set zoom value
Get zoom value
Set container file type (0=mp4 1=3gp 2=avi)
Get container file type
Set image capture resolution (only in image mode
Set video capture resolution (only in video mode)
Set contrast
Set color-tone mode control
Get color-tone mode control
Set scene mode
Set noise-reduction mode
Get noise-reduction mode
Set stereo mode (only applicable if sensorid=3)
Capture Resolution Support
The following shows the supported capture resolutions.
Image Encode
176 x 144
320 x 240
480 x 480
640 x 480
800 x 600
720 x 480
1280 x 720
1280 x 960 (1 MP)
1600 x 1200 (2 MP)
2048 x 1536 (3 MP)
2240 x 1680 (4 MP)
2560 x 1920 (5 MP)
Video Encode
H.264 / MPEG-4 (supports mp4/3gp/avi containers)
176 x 144
320 x 240
640 x 480
720 x 480
1280 x 720
1920 x 1080
H.263 (supports 3gp/avi containers)
176 x 144 (QCIF)
352 x 288 (CIF)
704 x 576 (4CIF)