Next Previous Contents

10. Configuring mythfrontend.

Once you have completed configuration of your backend systems, the next step is to configure the frontend client.

When you start mythfrontend for the first time, it will attempt to connect to a configuration database on the local machine. If there is none, a "Database Configuration" screen will appear, and you will need to fill in some details. The "Host name" field needs the backend or database server's IP address or DNS name, and the User or password fields may need to be set to match your database user accounts. After editing those fields, press Enter twice to write these configurations on your local machine, and attempt to connect to the database. If you make any mistakes, the screens will pop up again.

Now that mythfrontend has started up, you should have a number of buttons/choices. Before doing anything, go to TV, then to Setup and configure the frontend client.

NOTE: You should go through the various setup screens in mythfrontend before using any other modules to ensure that the the database is correctly initialized.

10.1 General

The General screen has configuration items that don't really fit anywhere else. The first few configuration items ask you to indicate the number of seconds to record before or after a program, which is useful if the broadcast network or your system clock are out of sync and will help prevent you missing the beginning or end of a program.

To change the value, use the left and right arrow keys to increment and decrement the number of seconds. When you're satisfied with the result, use the down arrow to put the input focus on the Next button or press RETURN to continue to the next page.

The next page has a number of options to do with how channels are displayed on your system. The help text will give you more information. Move the focus to Next and press the space bar to continue.

The last General page sets up some final configuration items. See the help text for more information.

10.2 Appearance

This set of screens is mostly concerned with how MythTV will look on your system. From here, you can choose different themes and set the resolution of your system.

10.3 Program Guide

Fairly self explanatory. Note that the alternate program guide does not use the same font settings as defined in Appearance, so if the EPG is unreadable this is where you make the adjustments to fonts, number of elements displayed, etc.

10.4 Playback

The one configuration item which may cause problems on your system is the "Deinterlace playback" setting. MythTV uses a linear blend algorithm for deinterlacing, which will improve how the image looks on your screen. Deinterlacing requires that your processor support SSE. (Streaming SIMD Extensions, aka "MMX2"). Early Intel Celeron (those that don't use the Coppermine 0.18um core and are usually <600MHz), Pentium Pro and Pentium II CPUs do not have SSE, so make sure you haven't enabled deinterlacing if your processor doesn't support it. If you enable it, and your processor doesn't support SSE, you will get "Illegal Instruction" errors.

To determine if you've got SSE on an Intel processor, you can:

$ cat /proc/cpuinfo
[snip]
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse

Notice the sse at the end of the line - this tells you that this processor will be able to deinterlace correctly.

On an AMD processor, look for "3dnow" in the cpuinfo line; "3dnow" is AMD's implementation of SSE instructions, so if your processor has 3dnow you shouldn't have any issues with deinterlacing.

Video Filters

MythTV provides a means of employing video filters while recording and during playback. These filters can be used to improve or modify the video image, including hiding the effects of an interlaced image or reducing the impact of noise in a poor video signal. The following is a brief introduction to introduce you to the filters that are available in MythTV version 0.20 and higher.

Applying filters

One or more filters can be included in a "filter chain". The filters to be used are identified in a "filter string". A filter string is a group of filter names and parameters separated by commas. To include parameters, the filter name is followed by "=" and the parameter information. There should be no spaces in the filter string. Here is an example filter string:

With parameters: kerneldeint=10:1,denoise3d=12

Without: kerneldeint,denoise3d

Recording filters are set for each individual channel. These may be used when encoding in software (MPEG-4, RTjpeg) but do not apply when using a capture card with hardware encoding such as those supported by the ivtv driver, DVB, HDTV or MJPEG cards. You can run MythTV's "setup" program and select the "Channel Editor". On the first page for each channel, you can enter a filter string in the box titled "Video filters". If you are running "mythweb" on your web server, you can click on "Settings" then "Channels" and enter filter strings in the "videofilters" column.

Playback filters are per-host and apply to any recording you watch from the frontend where filters have been applied. Playback filtering can only work with software decoding so the viaslice, xvmc, and ivtv outputs ignore filters entirely. From "mythfrontend" go to Setup->TV Settings->Playback. Enter your filter string in the box titled "Custom Filters".

Currently Available Filters

"Deinterlace Playback" checkbox.

This implements special behavior needed for the "bobdeint" filter but can also be used to choose any of the deinterlace filters. If you prefer, you may leave this unchecked and include any of the deinterlace filters, other than "bobdeint", in your custom filter chain.

o The "invert" filter

Invert ignores any parameters and inverts the pixel values of the video frames. In other words, a negative image. This would rarely be useful but may be a good example to verify that your filter strings take effect.

o The "linearblend" filter

It is a simple deinterlacing filter that ignores parameters and works by blending adjacent lines. It replaces combing in interlaced video with a less distracting "ghost" image.

o The "bobdeint" filter

This filter splits the interlaced image into two separate fields that can be line doubled then displayed at twice the frame rate. If the display is at the same refresh rate as the recording (59.92Hz NTSC or 50Hz PAL) this will cause each refresh to show objects in motion in a new position with no jagged edges. However, if the display is not synchronous, it will cause flickering or the appearance of the picture moving up and down by one line.

NOTE: This filter requires the frame rate to be doubled and therefore can only be used with the "Deinterlace Playback" checkbox. Do not include this in your filter chain.

o The "kerneldeint" filter

Kerneldeint is a more complex deinterlacing filter which applies a filter kernel using input from several lines. It generally removes combing without a "ghost" image, sometimes leaving a faint outline of the image from the other field. It is considered to be less distracting to watch than linearblend or no filter at all. It accepts one or two integer parameters separated by a colon.

The first parameter is the filter threshold and defaults to 12. Adjacent lines differing by more than the threshold value are filtered. The second option defaults to 0. If set to a non-zero value, it will cause the filter to skip chroma, and filter only the luminance. It may be useful on some capture cards which do not capture the chroma fields of interlaced video correctly.

o The "onefield" filter

This is a simple one-field deinterlacing filter that uses only one field of the interlaced video. By default it keeps the top field, though passing the parameter "bottom" will cause it to keep the bottom field instead.

This filter is primarily useful for those who display 1080i HDTV signals with a video mode that has 540 pixels vertically. The advantage over other deinterlacing filters is that scenes with motion never show combing or ghosting.

o The "adjust" filter

This filter adjusts the digital values for luma and chroma to ensure that they will fall within the ranges specified in the ITU-R601 standard. By default, this corrects a known problem for the luma range used by bt8x8 chips which causes video to look washed out. If parameters are passed, there need to be exactly six. However, passing a single parameter of "-1" will disable the filter.

1: luma minimum input value (int) 2: luma maximum input value (int) 3: luma gamma correction (float) 4: chroma minimum input value (int) 5: chroma maximum input value (int) 6: chroma gamma correction (float)

The default bt8x8 correction values are equivalent to "16:253:1.0:2:253:1.0". Output ranges are fixed at ITU-R601 values (16-235 luma, 16-240 chroma).

NOTE: If it is not already specified in the filter chain, this filter will be automatically applied when recording with the "bttv" driver.

o The "quickdnr" filter

A fast temporal denoiser. This can take 1, 2 or 4 parameters, each being a value from "0" for the least filtering to "255" for the greatest filtering. With one parameter, the filter will compute the values it should use for all of its variables. Two parameters will set the filter strength for luma and chroma independently. If you are interested in how the algorithm works, you may examine the source code to see how four parameter are used.

o The "denoise3d" filter

A slower denoiser that applies a spatial and temporal low-pass filter. The spatial filter can remove some noise that quickdnr can't, but a more powerful CPU is needed. This filter accepts 3 float parameters:

  • luma spatial filter strength
  • chroma spatial filter strength
  • luma temporal filter strength

Reasonable defaults will be selected for omitted parameters. The chroma temporal filter strength is calculated from the other filter strengths.

o The "crop" filter

Covers edges of video with black bars. This helps improve video quality when the edges of the frame are distorted. By default, this removes 16 pixels from each edge. This can optionally take four parameters representing top:left:bottom:right. The number times 16 is the number of pixels to remove so, for example, the default is "=1:1:1:1".

o The "forceyv12" and "forceyuv422p" filters

These force the filter manager to use the given format. You can use one of these at the head of a filter chain to change the capture format. The most likely use would be forceyuv422p to use YUV422P capture on cards with known chroma interlacing problems with YV12.

There are some filters included in the MythTV source code that should not be used:

o The "forcergb24" and "forceargb32" filters

The two RGB formats should not be used because there is no conversion filter for them yet.

o The "convert" filter

It exists but don't use it. The filter manager uses this filter automatically when it is unable to match the input/output formats of two adjacent filters.

o The "postprocess" filter

While this exists in MythTV source code, it is currently not recommended for use.

Usage Considerations

There are trade-offs to consider when deciding if it would be wise to use a filter. Any processing will modify the original image so you should assess if the filter has made a noticeable improvement to the picture in order to justify the impact of the processing. Adding any filter will inherently increase CPU usage. The impact can vary dramatically depending on your CPU type and speed, the resolution of the recording, which filters you are using and other factors. You can only determine what is right for you through experimentation. However, as a starting point, here are some filter strings that you may find useful:

For typical broadcast stations: "kerneldeint,quickdnr"

For stations with poor signal quality: "linearblend,denoise3d=12"

For synchronous TV-out: check Deinterlace with "Bob (2x framerate)"

10.5 Recording

Depending on your capture card, MythTV offers different video encoders. The following types of hardware encoding cards are supported:

For cards without hardware encoding capabilities (all cards supported by V4L not listed above), Myth includes two methods for software encoding: RTjpeg and MPEG-4. RTjpeg has significantly fewer CPU demands than MPEG-4, but it generates larger files than MPEG-4 for a given recording.

For DVB and HDTV cards, no further configuration is required after setting up the card using the 'mythtv-setup' program. For all other cards, configuration is done through MythFrontend. Selecting 'Recording Profiles' from the 'TV Settings' screen will list the profiles currently available for the cards in your system. Depending on what types of cards you have installed you may see:

(Create new profile group)
Software Encoders
Hardware MPEG Encoders
Hardware MJPEG Encoders
Transcoders
The '(Create new profile group)' option will allow you to create custom profiles in case you have multiple backends. Note that custom profiles are per backend and card type. If you have 2 MPEG-2 encoders in a given backend system, creating a custom profile will affect both of them. This option should not be needed otherwise.

The 'Transcoders' group is a little different from the others. Selecting this group will result in a menu with the following options: 'RTjpeg/MPEG-4' and 'MPEG-2'. These types indicate what transcoder options will be used for a given input type (i.e. the 'MPEG-2' settings would be used to transcode MPEG-2 files into MPEG-4. The source of the MPEG-2 stream (DVB, HDTV, or PVR-x50) does not matter. Configuration of the options is the same as below (although any resolution settings will be ignored).

Selecting any of the other options will show a new screen with a list of four profiles:

  • Default
  • Live TV
  • Low Quality
  • High Quality

The Default profile will be used for any recording which does not otherwise have a specific profile assigned. The 'Live TV' profile will be used when watching TV. The remaining two profiles are available for customizing to allow for more precise control over what quality is used for a given program.

Selecting a profile will allow you to adjust the relevant options for that card. The most significant setting is the recording resolution, but you can also choose encoding format, audio format, and tweak other encoder specific properties.

NOTE: although the width and height can be changed to almost anything, if you start MythTV and don't see video or you get "segmentation fault" errors, it is likely that the video4linux (v4l) subsystem did not like the height and width parameters specified. It's best to leave the default as-is until you're sure that MythTV is operational.

See the What capture resolution should I use? How does video work? section for more information.

10.6 Xbox Frontends

MythTV is able to control the LED on the Xbox to indicate backend recording status.

To control the LED, you will need the blink program from the xbox-linux project, which is installed as /bin/led on GentooX. On Xebian (the new Ed's Debian) you must install it yourself. On other distributions it may or may not be installed as a program called blink and should be located in your path. (Type which blink to see if the program is available.) If you do not have blink, you may obtain it from the Xbox-Linux project site at http://xbox-linux.sf.net/. The program you need is part of the eds_i2c_staff module in CVS. Note the spelling.

Once you have installed blink you will need to set permissions. blink needs write permission to the i2c device to function properly. There are three methods to accomplish this. First, you could run mythfrontend as root, which is the simplest method, but could potentially be a security risk. Next, you may make the blink binary setuid root, which allows non-privileged users to run a program with root capability. This is done by typing the command:

$ su
# chmod u+s /path/to/blink
The final technique would be to set the /dev/i2c/0 device read/write for all users, but this is the least preferred method.

Now it's time to setup MythTV for Xbox hardware. Enter Setup -> General. On the second page check the 'Enable Xbox Hardware' option. Upon reentering the settings, you should have a new option named 'Xbox'. Within this option you may select the distribution, LED colors for recording and the update interval. If you select GentooX as the distribution led will be used as the blink binary name, otherwise, blink is used. Colors should be self explanatory. The update interval determines how often the frontend should poll the backend to determine if the status has changed.


Next Previous Contents