Ross Lippert Edited by FreeBSD supports a wide variety of sound cards, allowing you to enjoy high fidelity output from your computer. This includes the ability to record and playback audio in the MPEG Audio Layer 3 (MP3), WAV, and Ogg Vorbis formats as well as many other formats. The FreeBSD Ports Collection also contains applications allowing you to edit your recorded audio, add sound effects, and control attached MIDI devices. With some experimentation, &os; can support playback of video files and DVDs. The number of applications to encode, convert, and playback various video media is more limited than the number of sound applications. For example as of this writing, there are no good re-encoding applications in the FreeBSD Ports Collection that could be used to convert between formats, as there is with audio/sox. However, the software landscape in this area is changing rapidly. This chapter will describe the necessary steps to configure your sound card. The configuration and installation of X11 () has already taken care of the hardware issues for your video card, though there may be some tweaks to apply for better playback. After reading this chapter, you will know: How to configure your system so that your sound card is recognized. Methods to test whether your card is working. How to troubleshoot your sound setup. How to playback and encode MP3s and other audio. How video is supported by the X server. Some video player/encoder ports which give good results. How to playback DVDs, .mpg and .avi files. How to rip CD and DVD content into files. How to configure a TV card. How to configure an image scanner. Before reading this chapter, you should: Know how to configure and install a new kernel (). Trying to mount audio CDs with the &man.mount.8; command will result in an error, at least, and a kernel panic, at worst. These media have specialized encodings which differ from the usual ISO-filesystem. Moses Moore Contributed by Marc Fonvieille Enhanced by PCI ISA sound cards Before you begin, you should know the model of the card you have, the chip it uses, and whether it is a PCI or ISA card. FreeBSD supports a wide variety of both PCI and ISA cards. Check the supported audio devices list of the Hardware Notes to see if your card is supported. The Hardware Notes will also mention which driver supports your card. kernel configuration To use your sound device, you will need to load the proper device driver. This may be accomplished in one of two ways. The easiest way is to simply load a kernel module for your sound card with &man.kldload.8; which can either be done from the command line: &prompt.root; kldload snd_emu10k1 or by adding the appropriate line to the file /boot/loader.conf like this: snd_emu10k1_load="YES" These examples are for a Creative &soundblaster; Live! sound card. Other available loadable sound modules are listed in /boot/defaults/loader.conf. If you are not sure which driver to use, you may try to load the snd_driver module: &prompt.root; kldload snd_driver This is a metadriver loading the most common device drivers at once. This speeds up the search for the correct driver. It is also possible to load all sound drivers via the /boot/loader.conf facility. If you wish to find out the driver selected for your soundcard after loading the snd_driver metadriver, you may check the /dev/sndstat file with the cat /dev/sndstat command. A second method is to statically compile in support for your sound card in your kernel. The section below provides the information you need to add support for your hardware in this manner. For more information about recompiling your kernel, please see . The first thing to do is add the audio framework driver &man.sound.4; to the kernel; for that you will need to add the following line to the kernel configuration file: device sound Next, you have to add the support for your sound card. Therefore, you need to know which driver supports the card. Check the supported audio devices list of the Hardware Notes, to determine the correct driver for your sound card. For example, a Creative &soundblaster; Live! sound card is supported by the &man.snd.emu10k1.4; driver. To add the support for this card, use the following: device snd_emu10k1 Be sure to read the manual page of the driver for the syntax to use. The explicit syntax for the kernel configuration of every supported sound driver can also be found in the /usr/src/sys/conf/NOTES file. Non-PnP ISA sound cards may require you to provide the kernel with information on the card settings (IRQ, I/O port, etc), as is true of all non-PnP ISA cards. This is done via the /boot/device.hints file. During the boot process, the &man.loader.8; will read this file and pass the settings to the kernel. For example, an old Creative &soundblaster; 16 ISA non-PnP card will use the &man.snd.sbc.4; driver in conjunction with snd_sb16. For this card the following lines must be added to the kernel configuration file: device snd_sbc device snd_sb16 and these to /boot/device.hints: hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x15" In this case, the card uses the 0x220 I/O port and the IRQ 5. The syntax used in the /boot/device.hints file is covered in the &man.sound.4; driver manual page and the manual page for the driver in question. The settings shown above are the defaults. In some cases, you may need to change the IRQ or the other settings to match your card. See the &man.snd.sbc.4; manual page for more information about this card. After rebooting with the modified kernel, or after loading the required module, the sound card should appear in your system message buffer (&man.dmesg.8;) as something like: pcm0: <Intel ICH3 (82801CA)> port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: <Cirrus Logic CS4205 AC97 Codec> The status of the sound card may be checked via the /dev/sndstat file: &prompt.root; cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: <Intel ICH3 (82801CA)> at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) The output from your system may vary. If no pcm devices are listed, go back and review what was done earlier. Go through your kernel configuration file again and make sure the correct device driver was chosen. Common problems are listed in . If all goes well, you should now have a functioning sound card. If your CD-ROM or DVD-ROM drive's audio-out pins are properly connected to your sound card, you can put a CD in the drive and play it with &man.cdcontrol.1;: &prompt.user; cdcontrol -f /dev/acd0 play 1 Various applications, such as audio/workman can provide a friendlier interface. You may want to install an application such as audio/mpg123 to listen to MP3 audio files. Another quick way to test the card is sending data to /dev/dsp, like this: &prompt.user; cat filename > /dev/dsp where filename can be any file. This command line should produce some noise, confirming the sound card is actually working. The device nodes /dev/dsp* will be created automatically when needed. If they are not used, they do not exist and will not appear in the output of &man.ls.1;. Sound card mixer levels can be changed via the &man.mixer.8; command. More details can be found in the &man.mixer.8; manual page. device nodes I/O port IRQ DSP Error Solution sb_dspwr(XX) timed out The I/O port is not set correctly. bad irq XX The IRQ is set incorrectly. Make sure that the set IRQ and the sound IRQ are the same. xxx: gus pcm not attached, out of memory There is not enough available memory to use the device. xxx: can't open /dev/dsp! Check with fstat | grep dsp if another application is holding the device open. Noteworthy troublemakers are esound and KDE's sound support. Another issue is that modern graphics cards often come with their own sound driver, for use with HDMI and similar. This sound device will sometimes be enumerated before the actual soundcard and the soundcard will subsequently not be used as the default playback device. To check if this is the case, run dmesg and look for pcm. The output looks something like this: ... hdac0: HDA Driver Revision: 20100226_0142 hdac1: HDA Driver Revision: 20100226_0142 hdac0: HDA Codec #0: NVidia (Unknown) hdac0: HDA Codec #1: NVidia (Unknown) hdac0: HDA Codec #2: NVidia (Unknown) hdac0: HDA Codec #3: NVidia (Unknown) pcm0: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 0 nid 1 on hdac0 pcm1: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 1 nid 1 on hdac0 pcm2: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 2 nid 1 on hdac0 pcm3: <HDA NVidia (Unknown) PCM #0 DisplayPort> at cad 3 nid 1 on hdac0 hdac1: HDA Codec #2: Realtek ALC889 pcm4: <HDA Realtek ALC889 PCM #0 Analog> at cad 2 nid 1 on hdac1 pcm5: <HDA Realtek ALC889 PCM #1 Analog> at cad 2 nid 1 on hdac1 pcm6: <HDA Realtek ALC889 PCM #2 Digital> at cad 2 nid 1 on hdac1 pcm7: <HDA Realtek ALC889 PCM #3 Digital> at cad 2 nid 1 on hdac1 ... Here the graphics card (NVidia) has been enumerated before the sound card (Realtek ALC889). To use the sound card as default playback device, change hw.snd.default_unit to the unit that should be used for playback, enter the following: &prompt.root; sysctl hw.snd.default_unit=n Here, n is the number of the sound device to use, in this example 4. You can make this change permanent by adding the following line to /etc/sysctl.conf: hw.snd.default_unit=4 Munish Chopra Contributed by It is often desirable to have multiple sources of sound that are able to play simultaneously, such as when esound or artsd do not support sharing of the sound device with a certain application. FreeBSD lets you do this through Virtual Sound Channels, which can be enabled with the &man.sysctl.8; facility. Virtual channels allow you to multiplex your sound card's playback by mixing sound in the kernel. To set the number of virtual channels, there are three sysctl knobs which, if you are the root user, can be set like this: &prompt.root; sysctl dev.pcm.0.play.vchans=4 &prompt.root; sysctl dev.pcm.0.rec.vchans=4 &prompt.root; sysctl hw.snd.maxautovchans=4 The above example allocates four virtual channels, which is a practical number for everyday use. Both dev.pcm.0.play.vchans=4 and dev.pcm.0.rec.vchans=4 are the number of virtual channels pcm0 has for playback and recording, and are configurable once a device has been attached. hw.snd.maxautovchans is the number of virtual channels a new audio device is given when it is attached using &man.kldload.8;. Since the pcm module can be loaded independently of the hardware drivers, hw.snd.maxautovchans can store how many virtual channels any devices which are attached later will be given. Refer to &man.pcm.4; manual page for more information. You cannot change the number of virtual channels for a device while it is in use. First close any programs using the device, such as music players or sound daemons. The correct pcm device will automatically be allocated transparently to a program that requests /dev/dsp0. Josef El-Rayes Contributed by The default values for the different mixer channels are hardcoded in the sourcecode of the &man.pcm.4; driver. There are many different applications and daemons that allow you to set values for the mixer that are remembered between invocations, but this is not a clean solution. It is possible to set default mixer values at the driver level — this is accomplished by defining the appropriate values in /boot/device.hints, e.g.: hint.pcm.0.vol="50" This will set the volume channel to a default value of 50 when the &man.pcm.4; module is loaded. Chern Lee Contributed by MP3 (MPEG Layer 3 Audio) accomplishes near CD-quality sound, leaving no reason to let your FreeBSD workstation fall short of its offerings. By far, the most popular X11 MP3 player is XMMS (X Multimedia System). Winamp skins can be used with XMMS since the GUI is almost identical to that of Nullsoft's Winamp. XMMS also has native plug-in support. XMMS can be installed from the multimedia/xmms port or package. XMMS's interface is intuitive, with a playlist, graphic equalizer, and more. Those familiar with Winamp will find XMMS simple to use. The audio/mpg123 port is an alternative, command-line MP3 player. mpg123 can be run by specifying the sound device and the MP3 file on the command line. Assuming your audio device is /dev/dsp1.0 and you want to play the MP3 file Foobar-GreatestHits.mp3 you would enter the following: &prompt.root; mpg123 -a /dev/dsp1.0 Foobar-GreatestHits.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. Version 0.59r (1999/Jun/15). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Playing MPEG stream from Foobar-GreatestHits.mp3 ... MPEG 1.0 layer III, 128 kbit/s, 44100 Hz joint-stereo Before encoding a CD or CD track to MP3, the audio data on the CD must be ripped onto the hard drive. This is done by copying the raw CDDA (CD Digital Audio) data to WAV files. The cdda2wav tool, which is a part of the sysutils/cdrtools suite, is used for ripping audio information from CDs and the information associated with them. With the audio CD in the drive, the following command can be issued (as root) to rip an entire CD into individual (per track) WAV files: &prompt.root; cdda2wav -D 0,1,0 -B cdda2wav will support ATAPI (IDE) CDROM drives. To rip from an IDE drive, specify the device name in place of the SCSI unit numbers. For example, to rip track 7 from an IDE drive: &prompt.root; cdda2wav -D /dev/acd0 -t 7 The -D 0,1,0 indicates the SCSI device 0,1,0, which corresponds to the output of cdrecord -scanbus. To rip individual tracks, make use of the -t option as shown: &prompt.root; cdda2wav -D 0,1,0 -t 7 This example rips track seven of the audio CDROM. To rip a range of tracks, for example, track one to seven, specify a range: &prompt.root; cdda2wav -D 0,1,0 -t 1+7 The utility &man.dd.1; can also be used to extract audio tracks on ATAPI drives, read for more information on that possibility. Nowadays, the mp3 encoder of choice is lame. Lame can be found at audio/lame in the ports tree. Using the ripped WAV files, the following command will convert audio01.wav to audio01.mp3: &prompt.root; lame -h -b 128 \ --tt "Foo Song Title" \ --ta "FooBar Artist" \ --tl "FooBar Album" \ --ty "2001" \ --tc "Ripped and encoded by Foo" \ --tg "Genre" \ audio01.wav audio01.mp3 128 kbits seems to be the standard MP3 bitrate in use. Many enjoy the higher quality 160, or 192. The higher the bitrate, the more disk space the resulting MP3 will consume--but the quality will be higher. The -h option turns on the higher quality but a little slower mode. The options beginning with --t indicate ID3 tags, which usually contain song information, to be embedded within the MP3 file. Additional encoding options can be found by consulting the lame man page. In order to burn an audio CD from MP3s, they must be converted to a non-compressed WAV format. Both XMMS and mpg123 support the output of MP3 to an uncompressed file format. Writing to Disk in XMMS: Launch XMMS. Right-click on the window to bring up the XMMS menu. Select Preference under Options. Change the Output Plugin to Disk Writer Plugin. Press Configure. Enter (or choose browse) a directory to write the uncompressed files to. Load the MP3 file into XMMS as usual, with volume at 100% and EQ settings turned off. Press Play — XMMS will appear as if it is playing the MP3, but no music will be heard. It is actually playing the MP3 to a file. Be sure to set the default Output Plugin back to what it was before in order to listen to MP3s again. Writing to stdout in mpg123: Run mpg123 -s audio01.mp3 > audio01.pcm XMMS writes a file in the WAV format, while mpg123 converts the MP3 into raw PCM audio data. Both of these formats can be used with cdrecord to create audio CDs. You have to use raw PCM with &man.burncd.8;. If you use WAV files, you will notice a small tick sound at the beginning of each track, this sound is the header of the WAV file. You can simply remove the header of a WAV file with the utility SoX (it can be installed from the audio/sox port or package): &prompt.user; sox -t wav -r 44100 -s -w -c 2 track.wav track.raw Read for more information on using a CD burner in FreeBSD. Ross Lippert Contributed by Video playback is a very new and rapidly developing application area. Be patient. Not everything is going to work as smoothly as it did with sound. Before you begin, you should know the model of the video card you have and the chip it uses. While &xorg; supports a wide variety of video cards, fewer give good playback performance. To obtain a list of extensions supported by the X server using your card use the command &man.xdpyinfo.1; while X11 is running. It is a good idea to have a short MPEG file which can be treated as a test file for evaluating various players and options. Since some DVD players will look for DVD media in /dev/dvd by default, or have this device name hardcoded in them, you might find it useful to make symbolic links to the proper devices: &prompt.root; ln -sf /dev/acd0 /dev/dvd &prompt.root; ln -sf /dev/acd0 /dev/rdvd Note that due to the nature of &man.devfs.5;, manually created links like these will not persist if you reboot your system. In order to create the symbolic links automatically whenever you boot your system, add the following lines to /etc/devfs.conf: link acd0 dvd link acd0 rdvd Additionally, DVD decryption, which requires invoking special DVD-ROM functions, requires write permission on the DVD devices. To enhance the shared memory X11 interface, it is recommended that the values of some &man.sysctl.8; variables should be increased: kern.ipc.shmmax=67108864 kern.ipc.shmall=32768 XVideo SDL DGA There are several possible ways to display video under X11. What will really work is largely hardware dependent. Each method described below will have varying quality across different hardware. Secondly, the rendering of video in X11 is a topic receiving a lot of attention lately, and with each version of &xorg;, there may be significant improvement. A list of common video interfaces: X11: normal X11 output using shared memory. XVideo: an extension to the X11 interface which supports video in any X11 drawable. SDL: the Simple Directmedia Layer. DGA: the Direct Graphics Access. SVGAlib: low level console graphics layer. &xorg; has an extension called XVideo (aka Xvideo, aka Xv, aka xv) which allows video to be directly displayed in drawable objects through a special acceleration. This extension provides very good quality playback even on low-end machines. To check whether the extension is running, use xvinfo: &prompt.user; xvinfo XVideo is supported for your card if the result looks like: X-Video Extension version 2.2 screen #0 Adaptor #0: "Savage Streams Engine" number of ports: 1 port base: 43 operations supported: PutImage supported visuals: depth 16, visualID 0x22 depth 16, visualID 0x23 number of attributes: 5 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_SATURATION" (range 0 to 255) client settable attribute client gettable attribute (current value is 128) "XV_HUE" (range -180 to 180) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 1024 x 1024 Number of image formats: 7 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x36315652 (RV16) guid: 52563135-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x35315652 (RV15) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800 id: 0x31313259 (Y211) guid: 59323131-0000-0010-8000-00aa00389b71 bits per pixel: 6 number of planes: 3 type: YUV (packed) id: 0x0 guid: 00000000-0000-0000-0000-000000000000 bits per pixel: 0 number of planes: 0 type: RGB (packed) depth: 1 red, green, blue masks: 0x0, 0x0, 0x0 Also note that the formats listed (YUV2, YUV12, etc) are not present with every implementation of XVideo and their absence may hinder some players. If the result looks like: X-Video Extension version 2.2 screen #0 no adaptors present Then XVideo is probably not supported for your card. If XVideo is not supported for your card, this only means that it will be more difficult for your display to meet the computational demands of rendering video. Depending on your video card and processor, though, you might still be able to have a satisfying experience. You should probably read about ways of improving performance in the advanced reading . The Simple Directmedia Layer, SDL, was intended to be a porting layer between µsoft.windows;, BeOS, and &unix;, allowing cross-platform applications to be developed which made efficient use of sound and graphics. The SDL layer provides a low-level abstraction to the hardware which can sometimes be more efficient than the X11 interface. The SDL can be found at devel/sdl12. Direct Graphics Access is an X11 extension which allows a program to bypass the X server and directly alter the framebuffer. Because it relies on a low level memory mapping to effect this sharing, programs using it must be run as root. The DGA extension can be tested and benchmarked by &man.dga.1;. When dga is running, it changes the colors of the display whenever a key is pressed. To quit, use q. video ports video packages This section discusses the software available from the FreeBSD Ports Collection which can be used for video playback. Video playback is a very active area of software development, and the capabilities of various applications are bound to diverge somewhat from the descriptions given here. Firstly, it is important to know that many of the video applications which run on FreeBSD were developed as Linux applications. Many of these applications are still beta-quality. Some of the problems that you may encounter with video packages on FreeBSD include: An application cannot playback a file which another application produced. An application cannot playback a file which the application itself produced. The same application on two different machines, rebuilt on each machine for that machine, plays back the same file differently. A seemingly trivial filter like rescaling of the image size results in very bad artifacts from a buggy rescaling routine. An application frequently dumps core. Documentation is not installed with the port and can be found either on the web or under the port's work directory. Many of these applications may also exhibit Linux-isms. That is, there may be issues resulting from the way some standard libraries are implemented in the Linux distributions, or some features of the Linux kernel which have been assumed by the authors of the applications. These issues are not always noticed and worked around by the port maintainers, which can lead to problems like these: The use of /proc/cpuinfo to detect processor characteristics. A misuse of threads which causes a program to hang upon completion instead of truly terminating. Software not yet in the FreeBSD Ports Collection which is commonly used in conjunction with the application. So far, these application developers have been cooperative with port maintainers to minimize the work-arounds needed for port-ing. MPlayer is a recently developed and rapidly developing video player. The goals of the MPlayer team are speed and flexibility on Linux and other Unices. The project was started when the team founder got fed up with bad playback performance on then available players. Some would say that the graphical interface has been sacrificed for a streamlined design. However, once you get used to the command line options and the key-stroke controls, it works very well. MPlayer making MPlayer resides in multimedia/mplayer. MPlayer performs a variety of hardware checks during the build process, resulting in a binary which will not be portable from one system to another. Therefore, it is important to build it from ports and not to use a binary package. Additionally, a number of options can be specified in the make command line, as described in the Makefile and at the start of the build: &prompt.root; cd /usr/ports/multimedia/mplayer &prompt.root; make N - O - T - E Take a careful look into the Makefile in order to learn how to tune mplayer towards you personal preferences! For example, make WITH_GTK1 builds MPlayer with GTK1-GUI support. If you want to use the GUI, you can either install /usr/ports/multimedia/mplayer-skins or download official skin collections from http://www.mplayerhq.hu/homepage/dload.html The default port options should be sufficient for most users. However, if you need the XviD codec, you have to specify the WITH_XVID option in the command line. The default DVD device can also be defined with the WITH_DVD_DEVICE option, by default /dev/acd0 will be used. As of this writing, the MPlayer port will build its HTML documentation and two executables, mplayer, and mencoder, which is a tool for re-encoding video. The HTML documentation for MPlayer is very informative. If the reader finds the information on video hardware and interfaces in this chapter lacking, the MPlayer documentation is a very thorough supplement. You should definitely take the time to read the MPlayer documentation if you are looking for information about video support in &unix;. MPlayer use Any user of MPlayer must set up a .mplayer subdirectory of her home directory. To create this necessary subdirectory, you can type the following: &prompt.user; cd /usr/ports/multimedia/mplayer &prompt.user; make install-user The command options for mplayer are listed in the manual page. For even more detail there is HTML documentation. In this section, we will describe only a few common uses. To play a file, such as testfile.avi, through one of the various video interfaces set the -vo option: &prompt.user; mplayer -vo xv testfile.avi &prompt.user; mplayer -vo sdl testfile.avi &prompt.user; mplayer -vo x11 testfile.avi &prompt.root; mplayer -vo dga testfile.avi &prompt.root; mplayer -vo 'sdl:dga' testfile.avi It is worth trying all of these options, as their relative performance depends on many factors and will vary significantly with hardware. To play from a DVD, replace the testfile.avi with dvd://N -dvd-device DEVICE where N is the title number to play and DEVICE is the device node for the DVD-ROM. For example, to play title 3 from /dev/dvd: &prompt.root; mplayer -vo xv dvd://3 -dvd-device /dev/dvd The default DVD device can be defined during the build of the MPlayer port via the WITH_DVD_DEVICE option. By default, this device is /dev/acd0. More details can be found in the port Makefile. To stop, pause, advance and so on, consult the keybindings, which are output by running mplayer -h or read the manual page. Additional important options for playback are: -fs -zoom which engages the fullscreen mode and -framedrop which helps performance. In order for the mplayer command line to not become too large, the user can create a file .mplayer/config and set default options there: vo=xv fs=yes zoom=yes Finally, mplayer can be used to rip a DVD title into a .vob file. To dump out the second title from a DVD, type this: &prompt.root; mplayer -dumpstream -dumpfile out.vob dvd://2 -dvd-device /dev/dvd The output file, out.vob, will be MPEG and can be manipulated by the other packages described in this section. mencoder Before using mencoder it is a good idea to familiarize yourself with the options from the HTML documentation. There is a manual page, but it is not very useful without the HTML documentation. There are innumerable ways to improve quality, lower bitrate, and change formats, and some of these tricks may make the difference between good or bad performance. Here are a couple of examples to get you going. First a simple copy: &prompt.user; mencoder input.avi -oac copy -ovc copy -o output.avi Improper combinations of command line options can yield output files that are unplayable even by mplayer. Thus, if you just want to rip to a file, stick to the -dumpfile in mplayer. To convert input.avi to the MPEG4 codec with MPEG3 audio encoding (audio/lame is required): &prompt.user; mencoder input.avi -oac mp3lame -lameopts br=192 \ -ovc lavc -lavcopts vcodec=mpeg4:vhq -o output.avi This has produced output playable by mplayer and xine. input.avi can be replaced with dvd://1 -dvd-device /dev/dvd and run as root to re-encode a DVD title directly. Since you are likely to be dissatisfied with your results the first time around, it is recommended you dump the title to a file and work on the file. The xine video player is a project of wide scope aiming not only at being an all in one video solution, but also in producing a reusable base library and a modular executable which can be extended with plugins. It comes both as a package and as a port, multimedia/xine. The xine player is still very rough around the edges, but it is clearly off to a good start. In practice, xine requires either a fast CPU with a fast video card, or support for the XVideo extension. The GUI is usable, but a bit clumsy. As of this writing, there is no input module shipped with xine which will play CSS encoded DVDs. There are third party builds which do have modules for this built in them, but none of these are in the FreeBSD Ports Collection. Compared to MPlayer, xine does more for the user, but at the same time, takes some of the more fine-grained control away from the user. The xine video player performs best on XVideo interfaces. By default, xine player will start up in a graphical user interface. The menus can then be used to open a specific file: &prompt.user; xine Alternatively, it may be invoked to play a file immediately without the GUI with the command: &prompt.user; xine -g -p mymovie.avi The software transcode is not a player, but a suite of tools for re-encoding video and audio files. With transcode, one has the ability to merge video files, repair broken files, using command line tools with stdin/stdout stream interfaces. A great number of options can be specified during the build from the multimedia/transcode port, we recommend the following command line to build transcode: &prompt.root; make WITH_OPTIMIZED_CFLAGS=yes WITH_LIBA52=yes WITH_LAME=yes WITH_OGG=yes \ WITH_MJPEG=yes -DWITH_XVID=yes The proposed settings should be sufficient for most users. To illustrate transcode capacities, one example to show how to convert a DivX file into a PAL MPEG-1 file (PAL VCD): &prompt.user; transcode -i input.avi -V --export_prof vcd-pal -o output_vcd &prompt.user; mplex -f 1 -o output_vcd.mpg output_vcd.m1v output_vcd.mpa The resulting MPEG file, output_vcd.mpg, is ready to be played with MPlayer. You could even burn the file on a CD-R media to create a Video CD, in this case you will need to install and use both multimedia/vcdimager and sysutils/cdrdao programs. There is a manual page for transcode, but you should also consult the transcode wiki for further information and examples. The various video software packages for FreeBSD are developing rapidly. It is quite possible that in the near future many of the problems discussed here will have been resolved. In the mean time, those who want to get the very most out of FreeBSD's A/V capabilities will have to cobble together knowledge from several FAQs and tutorials and use a few different applications. This section exists to give the reader pointers to such additional information. The MPlayer documentation is very technically informative. These documents should probably be consulted by anyone wishing to obtain a high level of expertise with &unix; video. The MPlayer mailing list is hostile to anyone who has not bothered to read the documentation, so if you plan on making bug reports to them, RTFM. The xine HOWTO contains a chapter on performance improvement which is general to all players. Finally, there are some other promising applications which the reader may try: Avifile which is also a port multimedia/avifile. Ogle which is also a port multimedia/ogle. Xtheater multimedia/dvdauthor, an open source package for authoring DVD content. Josef El-Rayes Original contribution by Marc Fonvieille Enhanced and adapted by TV cards TV cards allow you to watch broadcast or cable TV on your computer. Most of them accept composite video via an RCA or S-video input and some of these cards come with a FM radio tuner. &os; provides support for PCI-based TV cards using a Brooktree Bt848/849/878/879 or a Conexant CN-878/Fusion 878a Video Capture Chip with the &man.bktr.4; driver. You must also ensure the board comes with a supported tuner, consult the &man.bktr.4; manual page for a list of supported tuners. To use your card, you will need to load the &man.bktr.4; driver, this can be done by adding the following line to the /boot/loader.conf file like this: bktr_load="YES" Alternatively, you may statically compile the support for the TV card in your kernel, in that case add the following lines to your kernel configuration: device bktr device iicbus device iicbb device smbus These additional device drivers are necessary because of the card components being interconnected via an I2C bus. Then build and install a new kernel. Once the support was added to your system, you have to reboot your machine. During the boot process, your TV card should show up, like this: bktr0: <BrookTree 848A> mem 0xd7000000-0xd7000fff irq 10 at device 10.0 on pci0 iicbb0: <I2C bit-banging driver> on bti2c0 iicbus0: <Philips I2C bus> on iicbb0 master-only iicbus1: <Philips I2C bus> on iicbb0 master-only smbus0: <System Management Bus> on bti2c0 bktr0: Pinnacle/Miro TV, Philips SECAM tuner. Of course these messages can differ according to your hardware. However you should check if the tuner is correctly detected; it is still possible to override some of the detected parameters with &man.sysctl.8; MIBs and kernel configuration file options. For example, if you want to force the tuner to a Philips SECAM tuner, you should add the following line to your kernel configuration file: options OVERRIDE_TUNER=6 or you can directly use &man.sysctl.8;: &prompt.root; sysctl hw.bt848.tuner=6 See the &man.bktr.4; manual page and the /usr/src/sys/conf/NOTES file for more details on the available options. To use your TV card you need to install one of the following applications: multimedia/fxtv provides TV-in-a-window and image/audio/video capture capabilities. multimedia/xawtv is also a TV application, with the same features as fxtv. misc/alevt decodes and displays Videotext/Teletext. audio/xmradio, an application to use the FM radio tuner coming with some TV cards. audio/wmtune, a handy desktop application for radio tuners. More applications are available in the &os; Ports Collection. If you encounter any problem with your TV card, you should check at first if the video capture chip and the tuner are really supported by the &man.bktr.4; driver and if you used the right configuration options. For more support and various questions about your TV card you may want to contact and use the archives of the &a.multimedia.name; mailing list. MythTV is an open source PVR software project. It is well-known in the &linux; world as a complex application with many dependencies, and therefore difficult to install. The &os; ports system simplifies much of the process, but some components must be set up manually. This section is intended to help and guide in setting up MythTV. MythTV is designed to utilise V4L to access video input devices such as encoders and tuners. At this time, MythTV works best with USB DVB-S/C/T cards supported by multimedia/webcamd because webcamd provides a V4L userland application. Any DVB card supported by webcamd should work with MythTV, but a list of known working cards can be found here. There are also drivers available for Hauppauge cards in the following packages: multimedia/pvr250 and multimedia/pvrxxx, but they provide a non-standard driver interface that does not work with versions of MythTV greater than 0.23. HTPC contains a list of all available DVB drivers. Being flexible and modular, MythTV allows the user to have the frontend and backend on different machines. For the frontend, multimedia/mythtv-frontend is required, as well as an X server, which can be found in x11/xorg. Ideally, the frontend computer also has a video card that supports XvMC and, optionally, a LIRC-compatible remote. For the backend, multimedia/mythtv is required, as well as a &mysql; database, and optionally a tuner and storage for recordings. The &mysql; package should be automatically installed as a dependency when installing multimedia/mythtv. To install MythTV, use the following steps. First, install MythTV from the &os; Ports collection: &prompt.root; cd /usr/ports/multimedia/mythtv &prompt.root; make install Set up the MythTV database: &prompt.root; mysql -uroot -p < /usr/local/share/mythtv/database/mc.sql Configure the backend: &prompt.root; mythtv-setup Start the backend: &prompt.root; echo 'mythbackend_enable="YES"' >> /etc/rc.conf &prompt.root; /usr/local/etc/rc.d/mythbackend start Marc Fonvieille Written by image scanners In &os;, access to image scanners is provided by the SANE (Scanner Access Now Easy) API available through the &os; Ports Collection. SANE will also use some &os; device drivers to access to the scanner hardware. &os; supports both SCSI and USB scanners. Be sure your scanner is supported by SANE prior to performing any configuration. SANE has a supported devices list that can provide you with information about the support for a scanner and its status. On systems prior to &os; 8.X the &man.uscanner.4; manual page also provides a list of supported USB scanners. As mentioned above both SCSI and USB interfaces are supported. According to your scanner interface, different device drivers are required. The GENERIC kernel by default includes the device drivers needed to support USB scanners. Should you decide to use a custom kernel, be sure that the following lines are present in your kernel configuration file: device usb device uhci device ohci device ehci On systems prior to &os; 8.X, the following line is also needed: device uscanner On these versions of &os;, the &man.uscanner.4; device driver provides support for the USB scanners. Since &os; 8.0, this support is directly provided by the &man.libusb.3; library. After rebooting with the correct kernel, plug in your USB scanner. A line showing the detection of your scanner should appear in the system message buffer (&man.dmesg.8;): ugen0.2: <EPSON> at usbus0 or on a &os; 7.X system: uscanner0: EPSON EPSON Scanner, rev 1.10/3.02, addr 2 These messages show that our scanner is using either /dev/ugen0.2 or /dev/uscanner0 as device node according to the &os; version we run. For this example, a &epson.perfection; 1650 USB scanner was used. If your scanner comes with a SCSI interface, it is important to know which SCSI controller board you will use. According to the SCSI chipset used, you will have to tune your kernel configuration file. The GENERIC kernel supports the most common SCSI controllers. Be sure to read the NOTES file and add the correct line to your kernel configuration file. In addition to the SCSI adapter driver, you need to have the following lines in your kernel configuration file: device scbus device pass Once your kernel has been properly compiled and installed, you should be able to see the devices in the system message buffer, when booting: pass2 at aic0 bus 0 target 2 lun 0 pass2: <AGFA SNAPSCAN 600 1.10> Fixed Scanner SCSI-2 device pass2: 3.300MB/s transfers If your scanner was not powered-on at system boot, it is still possible to manually force the detection by performing a SCSI bus scan with the &man.camcontrol.8; command: &prompt.root; camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful Then the scanner will appear in the SCSI devices list: &prompt.root; camcontrol devlist <IBM DDRS-34560 S97B> at scbus0 target 5 lun 0 (pass0,da0) <IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1) <AGFA SNAPSCAN 600 1.10> at scbus1 target 2 lun 0 (pass3) <PHILIPS CDD3610 CD-R/RW 1.00> at scbus2 target 0 lun 0 (pass2,cd0) More details about SCSI devices are available in the &man.scsi.4; and &man.camcontrol.8; manual pages. The SANE system is split in two parts: the backends (graphics/sane-backends) and the frontends (graphics/sane-frontends). The backends part provides access to the scanner itself. The SANE's supported devices list specifies which backend will support your image scanner. It is mandatory to determine the correct backend for your scanner if you want to be able to use your device. The frontends part provides the graphical scanning interface (xscanimage). The first step is to install the graphics/sane-backends port or package. Then, use the sane-find-scanner command to check the scanner detection by the SANE system: &prompt.root; sane-find-scanner -q found SCSI scanner "AGFA SNAPSCAN 600 1.10" at /dev/pass3 The output will show the interface type of the scanner and the device node used to attach the scanner to the system. The vendor and the product model may not appear, it is not important. Some USB scanners require you to load a firmware, this is explained in the backend manual page. You should also read &man.sane-find-scanner.1; and &man.sane.7; manual pages. Now we have to check if the scanner will be identified by a scanning frontend. By default, the SANE backends comes with a command line tool called &man.scanimage.1;. This command allows you to list the devices and to perform an image acquisition from the command line. The -L option is used to list the scanner devices: &prompt.root; scanimage -L device `snapscan:/dev/pass3' is a AGFA SNAPSCAN 600 flatbed scanner Or, for example with the USB scanner used in the : &prompt.root; scanimage -L device 'epson2:libusb:/dev/usb:/dev/ugen0.2' is a Epson GT-8200 flatbed scanner This output comes from a &os; 8.X system, the 'epson2:libusb:/dev/usb:/dev/ugen0.2' item gives us the backend name (epson2) and the device node (/dev/ugen0.2) used by our scanner. No output or a message saying that no scanners were identified indicates that &man.scanimage.1; is unable to identify the scanner. If this happens, you will need to edit the backend configuration file and define the scanner device used. The /usr/local/etc/sane.d/ directory contains all backend configuration files. This identification problem does appear with certain USB scanners. For example, with the USB scanner used in the , under &os; 8.X the scanner is perfectly detected and working but under prior versions of &os; (where &man.uscanner.4; driver is used) sane-find-scanner gives us the following information: &prompt.root; sane-find-scanner -q found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0 The scanner is correctly detected, it uses the USB interface and is attached to the /dev/uscanner0 device node. We can now check if the scanner is correctly identified: &prompt.root; scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). Since the scanner is not identified, we will need to edit the /usr/local/etc/sane.d/epson2.conf file. The scanner model used was the &epson.perfection; 1650, so we know the scanner will use the epson2 backend. Be sure to read the help comments in the backends configuration files. Line changes are quite simple: comment out all lines that have the wrong interface for your scanner (in our case, we will comment out all lines starting with the word scsi as our scanner uses the USB interface), then add at the end of the file a line specifying the interface and the device node used. In this case, we add the following line: usb /dev/uscanner0 Please be sure to read the comments provided in the backend configuration file as well as the backend manual page for more details and correct syntax to use. We can now verify if the scanner is identified: &prompt.root; scanimage -L device `epson:/dev/uscanner0' is a Epson GT-8200 flatbed scanner Our USB scanner has been identified. It is not important if the brand and the model do not match the scanner. The key item to be concerned with is the `epson:/dev/uscanner0' field, which give us the right backend name and the right device node. Once the scanimage -L command is able to see the scanner, the configuration is complete. The device is now ready to scan. While &man.scanimage.1; does allow us to perform an image acquisition from the command line, it is preferable to use a graphical user interface to perform image scanning. SANE offers a simple but efficient graphical interface: xscanimage (graphics/sane-frontends). Xsane (graphics/xsane) is another popular graphical scanning frontend. This frontend offers advanced features such as various scanning mode (photocopy, fax, etc.), color correction, batch scans, etc. Both of these applications are usable as a GIMP plugin. All previous operations have been done with root privileges. You may however, need other users to have access to the scanner. The user will need read and write permissions to the device node used by the scanner. As an example, our USB scanner uses the device node /dev/ugen0.2 which is in fact just a symlink to the real device node called /dev/usb/0.2.0 (a quick look at the contents of the /dev directory will confirm it). Both, the symlink and the device node, are owned respectively by the wheel and the operator groups. Adding the user joe to these groups will allow him to use the scanner but, for obvious security reasons, you should think twice before adding a user to any group, especially the wheel group. A better solution would be creating a specific group for using the USB devices and make the scanner device accessible to members of this group. So we will use, for example, a group called usb. The first step is the creation of this group with the help of the &man.pw.8; command: &prompt.root; pw groupadd usb Then we have to make the /dev/ugen0.2 symlink and the /dev/usb/0.2.0 device node accessible to the usb group with the correct write permissions (0660 or 0664), because by default only the owner of these files (root) can write to them. All of this is done by adding the following lines to the /etc/devfs.rules file: [system=5] add path ugen0.2 mode 0660 group usb add path usb/0.2.0 mode 0666 group usb &os; 7.X users will probably need the following lines with the correct device node /dev/uscanner0: [system=5] add path uscanner0 mode 660 group usb Then add the following to /etc/rc.conf and reboot the machine: devfs_system_ruleset="system" More information regarding these lines can be found in the &man.devfs.8; manual page. Now, one will just have to add users to the usb group to allow the access to the scanner: &prompt.root; pw groupmod usb -m joe For more details read the &man.pw.8; manual page.