~ubuntu-branches/ubuntu/quantal/vdr-plugin-xine/quantal

« back to all changes in this revision

Viewing changes to MANUAL

  • Committer: Bazaar Package Importer
  • Author(s): Thomas Schmidt
  • Date: 2008-04-06 21:34:14 UTC
  • Revision ID: james.westby@ubuntu.com-20080406213414-54lbe5pj1cbbquon
Tags: upstream-0.8.2
ImportĀ upstreamĀ versionĀ 0.8.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
 
 
2
Please read the file "INSTALL" for getting the stuff working a first time :-)
 
3
 
 
4
 
 
5
SETUP-MENU
 
6
==========
 
7
 
 
8
Live-TV buffer [frames]: 4
 
9
 
 
10
Playing live-TV requires a buffer for having data ready when xine needs it for
 
11
decoding. Without such a buffer or when it is not large enough, replaying live
 
12
TV may not be fluently and may degrade into a slide show without sound. On the
 
13
other hand, as buffering takes place before replaying, a too large buffer
 
14
slows down zapping as it takes longer before replaying is started. So one may
 
15
need to play with this value to find a suitable setting. The buffer size is
 
16
specified in video frames, where 25 video frames make up a buffer which can
 
17
hold one second of audio and video. Please note that this buffer is provided
 
18
by VDR and a too large setting may cause an overflow (check VDR's logfile for
 
19
buffer usage).
 
20
 
 
21
 
 
22
Buffer hysteresis [frames]: 4
 
23
 
 
24
Buffer monitoring is a feature of vdr-xine which tries to dynamically increase
 
25
the buffer for certain channels on demand, i. e. whenever the buffer size
 
26
drops below the configured value of "Live-TV buffer" frames. As a result, a
 
27
new buffer will be established which is of size "Live-TV buffer + hysteresis"
 
28
frames, and in the case, where this buffer is still not large enough, vdr-xine
 
29
will internally increase hysteresis each time by one frame so that finally a
 
30
buffer is established which perfectly fits for the current channel.
 
31
 
 
32
 
 
33
Buffer monitoring duration [s]: 60
 
34
 
 
35
Typically, the above mentioned buffer monitoring is only necessary for a
 
36
certain amount of time after switching the channel, because once the buffer
 
37
is established, it should stay constant as the amount of data put into the
 
38
buffer by VDR and the amout of data taken from the buffer by xine should be
 
39
equal. A value of 0 disables buffer monitoring.
 
40
 
 
41
 
 
42
Buffer monitoring mode: Once
 
43
 
 
44
Lets you choose how buffer monitoring is applied.
 
45
 
 
46
* Once
 
47
  After the above mentioned time, buffer monitoring will be bypassed (which
 
48
  reduces CPU and memory load) until a channel switch or audio track selection
 
49
  occurs. 
 
50
 
 
51
* Continuous
 
52
  Buffer monitoring will never be bypassed. After the above mentioned time the
 
53
  internal hysteresis value will be reset to the configured one, to be ready
 
54
  for the next buffering cycle which starts when the buffer size falls below
 
55
  the above mentioned "Live-TV buffer" value. This mode is useful for channels
 
56
  which degrade into a slide show after a certain amout of time.
 
57
 
 
58
 
 
59
OSD display mode: Blend scaled AUTO
 
60
 
 
61
Lets you choose among several processing options for VDR's OSD.
 
62
 
 
63
* X11 overlay
 
64
  Tells xine to use a method for displaying the OSD that is independent of the
 
65
  stream's video resolution. In this so called "unscaled" mode, xine uses a
 
66
  X11 window to overlay the OSD on the video window. The advantage of mapping
 
67
  a single OSD pixel to a single pixel on screen has the disadvantage of not
 
68
  being able to support semi-transparent areas which appear totally opaque in
 
69
  this mode.
 
70
 
 
71
  NOTE: You won't see any OSD in this mode if X11 is not available!
 
72
 
 
73
* Blend clipped
 
74
* Blend scaled LQ
 
75
* Blend scaled HQ
 
76
* Blend scaled SHQ
 
77
* Blend scaled AUTO
 
78
  For these modes xine uses the CPU to blend the OSD into each video frame. As
 
79
  the result depends on the stream's video resolution you may choose among 
 
80
  several modes which require a different amount of CPU time.
 
81
  The first mode simply cuts off all parts of the OSD that do not fit into the
 
82
  video frame. If for example an OSD of size 720x576 is to be blended into a
 
83
  frame of size 480x576 (e. g. VIVA broadcasts at this resolution) then almost
 
84
  one halve of the OSD will be dropped at the right and the OSD will be quite 
 
85
  stretched in horizontal direction.
 
86
  All other modes scale the OSD to fit into the video frame. The difference
 
87
  among them is the scaling quality (Low, High and Super High) which also 
 
88
  leads to increasing CPU load and slows down e. g. navigation in the channels
 
89
  list, etc.
 
90
  The last mode automatically chooses between HQ and SHQ depending on the
 
91
  stream's video resolution. SHQ will be chosen if either width or height
 
92
  are below 360x288.
 
93
 
 
94
  NOTE: Blend scaled is only implemented for VDR 1.3.x (1.3.7 and higher).
 
95
 
 
96
 
 
97
OSD gamma correction [ 123 => 1.23 ]: 123
 
98
 
 
99
When OSD scaling is performed then multiple pixels (or parts of them for SHQ)
 
100
have to be combined into a single one. During this process a so called gamma
 
101
correction is applied in order to give the resulting pixels the correct visual
 
102
representation of the original ones.
 
103
You may adjust this correction within the range 1.00 to 2.50 (by entering 100
 
104
to 250 respectively) to get the best visual representation on your monitor. 
 
105
Changing this value is most noticeable in SHQ scaling mode so you need to
 
106
watch a channel that doesn't broadcast at 720x576 in order to activate OSD
 
107
scaling and to be able to see any change concerning gamma correction.
 
108
 
 
109
 
 
110
4:3 image zoom X [%]: 100
 
111
4:3 image zoom Y [%]: 100
 
112
16:9 image zoom X [%]: 100
 
113
16:9 image zoom Y [%]: 100
 
114
 
 
115
These options may be useful to stretch the video image to fill the screen.
 
116
A value of 133 for example will remove the black borders when showing a 4:3
 
117
image on a 16:9 screen. The drawback is that a part of the images is cut
 
118
away on top and bottom for example. So it may be useful to have different
 
119
values for X and Y (e. g. 133 and 115).
 
120
 
 
121
 
 
122
Audio mode: Dolby on     ***** OBSOLETE FOR VDR >= 1.3.18 *****
 
123
 
 
124
With this option you can control feeding dolby audio data to xine. You may
 
125
want to use this option if you don't have the necessary replay equipment 
 
126
connected to your computer. In that way you can force xine to use a 
 
127
differently coded audio source among the supplied e. g. mp2 or pcm.
 
128
 
 
129
 
 
130
Control xine's volume: Yes (by hardware)
 
131
 
 
132
Allows you to control whether xine shall honor VDR's set volume requests. You
 
133
might need this if you have a special setup (e. g. external audio decoder or 
 
134
amplifier) where changing the volume in xine might mute external audio:
 
135
 
 
136
* No
 
137
  xine isn't instructed to change the volume.
 
138
* Yes (by hardware)
 
139
  xine will change the volume by changing the hardware mixer (won't work
 
140
  when using a digital audio output).
 
141
* Yes (by software)
 
142
  xine will change the volume by using it's internal software mixer (should
 
143
  work even when using a digital audio output).
 
144
 
 
145
 
 
146
Muting: Simulate
 
147
 
 
148
Lets you choose among several options how xine shall process VDR's muting
 
149
requests:
 
150
 
 
151
* Ignore
 
152
  Muting respectively unmuting requests will be ignored.
 
153
* Execute
 
154
  Muting respectively unmuting requests will be executed.
 
155
* Simulate
 
156
  Muting is simulated by setting volume to 0. Unmuting is simulated by
 
157
  restoring the previous volume.
 
158
 
 
159
  NOTE: This happens even if "Control xine's volume" is set to "No"!
 
160
 
 
161
 
 
162
Get primary device when xine connects: Yes ***** REQUIRES VDR >= 1.3.32 *****
 
163
 
 
164
This option is especially useful for owners of full featured DVB cards which
 
165
usually run the OSD on a full featured card (i. e. the full featured card is
 
166
the primary device). 
 
167
With this option set to Yes, vdr-xine automatically makes itself the primary
 
168
device while xine is connected to it. In that way the OSD and live TV are 
 
169
automatically available via vdr-xine without the need to manually switch the
 
170
primary device via remote control nor SVDRP interface.
 
171
 
 
172
 
 
173
Support semi transparent colors: Yes
 
174
 
 
175
Depending on the currently broadcast image the displayed OSD might be hardly
 
176
readable when the OSD is blended semi transparently into the TV image.
 
177
If this option is set to No, vdr-xine simply ignores the semi-transparent
 
178
component of the color and therefore makes such colors opaque which typically
 
179
makes the OSD easier to read.
 
180
 
 
181
 
 
182
Connection interacts with EIT scanner: No
 
183
 
 
184
This option may be useful for users of single card systems. When xine connects
 
185
to vdr-xine, a currently running EPG scan will be interrupted to get into live
 
186
TV mode immediately. On the other hand, when VDR starts an EPG scan, vdr-xine
 
187
will shutdown the connection to xine.
 
188
 
 
189
 
 
190
COMMAND LINE ARGS
 
191
=================
 
192
 
 
193
There are currently two optional arguments.
 
194
 
 
195
        -r      Enable remote control.
 
196
 
 
197
This argument enables Simon Truss' patch which allows controlling VDR by
 
198
pressing buttons in xine. It will also allow control from any other suitably
 
199
patched front end.
 
200
 
 
201
        -iN     Instance number for FIFO directory
 
202
 
 
203
If you want to run two instances of vdr-xine (in different VDR processes) on
 
204
the same computer then you have to use a unique FIFO dir for each instance.
 
205
For example "-i3" will append "3" to the FIFO_DIR given in Makefile. The MRL
 
206
will then have to be like that: "vdr://tmp/vdr-xine3/stream#demux:mpeg_pes".
 
207
 
 
208
        -q      Suppress debug messages on console
 
209
 
 
210
This option is useful if VDR's console is to be used for other output e. g.
 
211
for the OSD implementation of VDR's skin 'curses'.
 
212
 
 
213
        -s      Switch to curses skin while xine is not connected
 
214
 
 
215
Use this switch if it is useful to control VDR via it's controlling terminal
 
216
while xine is not connected to vdr-xine. Requires VDR >= 1.3.20.
 
217
 
 
218
        -XN     default 'SizeX' for GRAB command (720, 1..4096)
 
219
        -YN     default 'SizeY' for GRAB command (576, 1..4096)
 
220
 
 
221
With these switches you may change the default image size for the grabbing
 
222
the current video frame (see VDR's SVDRP command GRAB for details).
 
223
 
 
224
        -p[N]   use socket connections on port N (18701)
 
225
        -bIP    ip address to bind for socket connections (see -p)
 
226
 
 
227
These options control whether vdr-xine shall use sockets instead of fifos,
 
228
which allows you to run xine on a different computer than vdr-xine. To enable
 
229
socket connections, supply the option -p. This will use the default TCP ports
 
230
18701, 18702, 18703 and 18704. You may optionally provide a different base
 
231
port number and vdr-xine will use the next three ports too.
 
232
By default, vdr-xine will listen on all network interfaces. If you want to
 
233
limit connections to a certain inferface, specify option -b with the IP
 
234
address this interface.
 
235
The MRL for xine looks then like that (:port is optional):
 
236
        netvdr://host:port#demux:mpeg_pes
 
237
 
 
238
 
 
239
XINE KEYBINDINGS
 
240
================
 
241
 
 
242
To make use of the remote control feature, you'll have to assign keys in xine
 
243
to VDR's commands. Therefore, you'll find 36 keybindings in xine's key binding
 
244
editor, named 'VDR ...', which control the specified action in VDR. Besides
 
245
those, the following entries are also used for VDR:
 
246
 
 
247
        'enter the number 0' .. 'enter the number 9'
 
248
        'jump to media menu'
 
249
        'menu navigate up'
 
250
        'menu navigate down'
 
251
        'menu navigate left'
 
252
        'menu navigate right'
 
253
        'menu select'
 
254
        'jump to next chapter'
 
255
        'jump to previous chapter'
 
256
 
 
257
 
 
258
GXINE KEYBINDINGS
 
259
=================
 
260
 
 
261
And similarly for gxine...
 
262
 
 
263
You'll find several VDR-specific keybindings in gxine's key binding editor:
 
264
 
 
265
                Used for VDR                            VDR-specific
 
266
 
 
267
        "Play"          Menu bindings                   "Red"
 
268
        "Pause"         Number key bindings             "Green"
 
269
        "Stop"          "Volume +"                      "Yellow"
 
270
        "Up"            "Volume -"                      "Blue"
 
271
        "Down"          "Mute"                          "Record"
 
272
        "Left"                                          "Power"
 
273
        "Right"         "Select/OK"                     "Back"
 
274
        "Rewind / Back 1 min"                           "Audio"
 
275
        "Fast forward / Forward 1 min"
 
276
 
 
277
You'll notice that the menu bindings have their VDR functions in [brackets].
 
278
        
 
279
If not all of these bindings are present, try "Add new default bindings"
 
280
from the Reload menu; if they still aren't, you're running an older version
 
281
of gxine.
 
282
 
 
283
The volume control bindings assume that VDR is passing volume control events
 
284
back to gxine - in the xine plugin's configuration, you need
 
285
        Control xine's volume   Yes
 
286
        Muting                  Execute
 
287
for these bindings to work.
 
288
 
 
289
 
 
290
XINE-LIB CONFIG
 
291
===============
 
292
 
 
293
This applies whether you're using xine, gxine or some other xine-lib front
 
294
end.
 
295
 
 
296
xine uses large buffers to gain smooth playback. The drawback is that VDR puts
 
297
a lot of data into xine's buffers and therefore VDR's progress indicator is 
 
298
way ahead of the position at which xine is currently playing. For a recording
 
299
of a radio channel, xine's default buffers will cause an offset of about 16
 
300
seconds. But this can easily be improved (with almost no noticeable effects)
 
301
to less than 2 seconds by adjusting xine's number of audio buffers. Just edit
 
302
your xine config "~/.xine/config" and add or change the following entry:
 
303
 
 
304
        engine.buffers.audio_num_buffers:4
 
305
 
 
306
The value '4' is the smallest possible value. You may increase it, in case that
 
307
you experience noticeable distortions in audio playback. Another interesting
 
308
option might be the following:
 
309
 
 
310
        audio.synchronization.av_sync_method:resample
 
311
 
 
312
It should totally avoid distortions by adjusting audio data to fill any gaps.
 
313
But it's only usable if your amplifier is not connected via SPDIF.
 
314
 
 
315
Another useful option on less powerful machines is the following:
 
316
 
 
317
        video.output.disable_exact_alphablend:1
 
318
 
 
319
The result will be that a less exact algorithm is used for blending the OSD
 
320
into each video frame and thus CPU time is saved.
 
321
 
 
322
 
 
323
 
 
324
XINE COMMAND LINE OPTIONS
 
325
=========================
 
326
 
 
327
This section is not intended as a replacement for xine's documentation, but it
 
328
may be useful to have a starting point for further reading. So, some useful
 
329
command line options are listed below.
 
330
 
 
331
Options for xine (X11 required):
 
332
 
 
333
        -V vidix         (for normal TV on my Matrox G550)
 
334
        -V xshm          (for watching HDTV)
 
335
 
 
336
        -A alsa          (use alsa sound system)
 
337
 
 
338
        --post vdr_video (highly recommended for correct and immediate OSD
 
339
                          scaling especially when using "xineplayer". It
 
340
                          further enables video scaling and positioning as
 
341
                          used within yaepg)
 
342
 
 
343
        --post vdr_audio (highly recommended for selecting left / right stereo
 
344
                          channel)
 
345
 
 
346
        -D               (enable selected deinterlacer)
 
347
        -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1
 
348
                         (use specified deinterlacer)
 
349
        -L               (disable LIRC support)
 
350
 
 
351
Options for gxine (X11 required):
 
352
 
 
353
        -V vidix         (for normal TV on my Matrox G550)
 
354
        -V xshm          (for watching HDTV)
 
355
 
 
356
        -A alsa          (use alsa sound system)
 
357
 
 
358
        Other options must (as of 0.4.4) be configured from within gxine.
 
359
 
 
360
Options for fbxine (no X11 required):
 
361
 
 
362
        -V vidixfb       (for normal TV on my Matrox G550)
 
363
        -V fb            (for watching HDTV)
 
364
        -V dxr3          (to use a DXR3/Hollywood+ hardware MPEG decoder)
 
365
 
 
366
        -A alsa          (use alsa sound system)
 
367
 
 
368
        --post vdr       (highly recommended for correct and immediate OSD
 
369
                          scaling especially when using "xineplayer". It
 
370
                          further enables video scaling and positioning as
 
371
                          used within yaepg)
 
372
 
 
373
        --post vdr_audio (highly recommended for selecting left / right stereo
 
374
                          channel)
 
375
 
 
376
        -D               (enable selected deinterlacer)
 
377
        -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1
 
378
                         (use specified deinterlacer)
 
379
        -L               (disable LIRC support)
 
380
 
 
381
The default deinterlacer doesn't take too much CPU time, but on the other hand
 
382
it doesn't deinterlace in all situations (e. g. when there is only a small area
 
383
with significant movement on the screen).
 
384
 
 
385
The specified deinterlacer does a good job, but requires much CPU time.
 
386
 
 
387
If you don't like VDR's OSD to be stretched when playing 16:9 material you
 
388
might also use xine's "expand" post processing plugin. It simply puts the
 
389
16:9 images into an 4:3 image (adding a black bar on top and bottom) and
 
390
therefore the OSD will keep it's aspect ratio. To make use of the plugin
 
391
add the following options in this order on (fb)xine's command line:
 
392
 
 
393
        xine ... --post expand --post vdr_video ...
 
394
 
 
395
The expand plugin now also supports a feature called "centre cut out" which
 
396
crops away the black bars around the image when 4:3 material is broadcast in
 
397
a 16:9 stream and displayed on a 4:3 monitor. The command line looks then like
 
398
the following:
 
399
 
 
400
        xine ... --post expand:centre_crop_out_mode=1 --post vdr_video ...
 
401
 
 
402
If you want to listen to mono audio streams in stereo, I'd suggest to use
 
403
the xine's upmix_mono audio post plugin like that:
 
404
 
 
405
        xine ... --post vdr_audio --post upmix_mono ...
 
406
 
 
407
 
 
408
 
 
409
XINEPLAYER
 
410
==========
 
411
xineplayer is a companion of vdr-xine and is used to get the beloved mplayer
 
412
plugin working with vdr-xine. I. e. you'll be able to replay DivX movies 
 
413
directly through xine without the need for CPU expensive recoding. And you'll
 
414
still be able to continue using VDR's OSD while the external file is playing.
 
415
 
 
416
To get it working just install the mplayer plugin. Then edit it's "mplayer.sh"
 
417
and replace
 
418
 
 
419
        # where to find mplayer
 
420
        MPLAYER="mplayer"
 
421
 
 
422
with
 
423
 
 
424
        # where to find mplayer
 
425
        MPLAYER="xineplayer"
 
426
 
 
427
and now you'll only have to make sure that xineplayer is found by your shell.
 
428
xineplayer was built in vdr-xine's source directory so you'll either have to
 
429
copy it to a directory which is contained in your environment variable PATH or
 
430
just enter the absolute path to xineplayer into mplayer.sh as mentioned above.
 
431
That's it.
 
432
 
 
433
NOTE: xineplayer is still under development and currently only supports
 
434
      mplayer plugin's TRADITIONAL mode. Furthermore it ignores any parameter
 
435
      given on the command line besides the last one and expects this to be a
 
436
      MRL recognizable by xine (e. g. a filename). If xine doesn't know how
 
437
      to play the given MRL you'll only see an error message on xine's console.
 
438
 
 
439
As vdr-xine supports an instance number to create an unique FIFO directory it
 
440
will also necessary to tell this number to xineplayer to have it control the
 
441
right instance of vdr-xine. xineplayer's command line looks like that:
 
442
 
 
443
        xineplayer [ --vdr-xine-instance=N ] [ options ] mrl
 
444
 
 
445
NOTE: "--vdr-xine-instance" must be given as the first argument as it might
 
446
      otherwise collide with further options originally intended for mplayer.
 
447