mirror of
https://projects.vdr-developer.org/git/vdr-plugin-streamdev.git
synced 2023-10-10 19:16:51 +02:00
285 lines
12 KiB
Plaintext
285 lines
12 KiB
Plaintext
This is a "plugin" for the Video Disk Recorder (VDR).
|
|
|
|
Written by: Sascha Volkenandt <sascha@akv-soft.de>
|
|
Current maintainer: Frank Schmirler <vdrdev@schmirler.de>
|
|
|
|
Project's homepage: http://streamdev.vdr-developer.org/
|
|
Former project homepage: http://linux.kompiliert.net/
|
|
|
|
Latest version available at: http://streamdev.vdr-developer.org/
|
|
|
|
See the file COPYING for license information.
|
|
|
|
Contents:
|
|
---------
|
|
|
|
1. Description
|
|
2. Installation
|
|
2.1 VDR 1.2.X
|
|
2.2 VDR 1.3.X and above
|
|
3. Usage
|
|
3.1 Usage HTTP server
|
|
3.2 Usage VDR-to-VDR server
|
|
3.3 Usage VDR-to-VDR client
|
|
4. Other useful Plugins
|
|
5. Known Problems
|
|
|
|
|
|
1. Description:
|
|
---------------
|
|
|
|
This PlugIn is a VDR implementation of the VTP (Video Transfer Protocol)
|
|
Version 0.0.3 (see file PROTOCOL) and a basic HTTP Streaming Protocol.
|
|
|
|
It consists of a server and a client part, but both parts are compiled together
|
|
with the PlugIn source, but appear as separate PlugIns to VDR.
|
|
|
|
The client part acts as a full Input Device, so it can be used in conjunction
|
|
with a DXR3-Card, XINE, SoftDevice or others to act as a working VDR
|
|
installation without any DVB-Hardware including EPG-Handling.
|
|
|
|
The server part acts as a Receiver-Device and works transparently in the
|
|
background within your running VDR. It can serve multiple clients and it can
|
|
distribute multiple input streams (i.e. from multiple DVB-cards) to multiple
|
|
clients using the native VTP protocol (for VDR-clients), or using the HTTP
|
|
protocol supporting clients such as XINE, MPlayer and so on. With XMMS or
|
|
WinAMP, you can also listen to radio channels over a HTTP connection.
|
|
|
|
It is possible to attach as many clients as the bus and network can handle, as
|
|
long as there is a device which can receive a specific channel. Multiple
|
|
channels homed on the same transponder (which is determined by it's frequency)
|
|
can be broadcasted with a single device.
|
|
|
|
Additional clients can be programmed using the Protocol Instructions inside
|
|
the PROTOCOL file.
|
|
|
|
|
|
2. Installation:
|
|
----------------
|
|
|
|
Let's say streamdev's version is 0.3.1 and vdr's version is 1.X.X. If you
|
|
use anything else please exchange the version numbers appropriately (this
|
|
way I don't have to update this section all the times;) ).
|
|
|
|
After compiling the PlugIn as stated below, start either (or both) parts of it
|
|
by specifying "-P streamdev-client" and/or "-P streamdev-server" on the VDR
|
|
command line.
|
|
|
|
What's important is that the client requests a channel using its Unique Channel
|
|
ID. So, in order to find the channel at the server, it must have the same ID
|
|
that is used on the client. You can achieve this by putting the server's
|
|
channels.conf on the client, preferably after scanning (in case you use 1.2.X
|
|
with AutoPID or 1.3.X).
|
|
|
|
If you want to drive additional Input-Devices (with different sources) on the
|
|
client, you can merge the channels.conf files. VDR will detect if the local
|
|
device or the network device can receive the channels.
|
|
|
|
Last, but not least you have to put the provided streamdevhosts.conf.example
|
|
into the "plugins" subfolder of your config-directory (which is equal to your
|
|
video-directory if not specified otherwise), rename it to streamdevhosts.conf
|
|
and adjust it to your needs. The syntax is the same as for svdrphosts.conf, so
|
|
please consult VDR's documentation on how to fill that file, if you can't do
|
|
it on-the-fly. For example, if you didn't specify a separate config-directory,
|
|
and specified your video directory as "/video0", the file has to be put to
|
|
/video0/plugins/streamdevhosts.conf.
|
|
|
|
|
|
2.1 VDR 1.2.X:
|
|
--------------
|
|
|
|
It is recommended that you apply a patch to VDR that improves thread
|
|
cancellation. You can work without it, but you _might_ have delays in switching
|
|
(especially when using VDR-to-VDR streaming) that are around three seconds.
|
|
|
|
cd vdr-1.X.X/PLUGINS/src
|
|
tar xvfz vdr-streamdev-0.3.1.tgz
|
|
ln -s streamdev-0.3.1 streamdev
|
|
cd ../..
|
|
patch -p1 <PLUGINS/src/streamdev/patches/thread.c.diff
|
|
make [options, if necessary] vdr
|
|
make [options, if necessary] plugins
|
|
|
|
2.2 VDR 1.3.X and above:
|
|
------------------------
|
|
|
|
cd vdr-1.X.X/PLUGINS/src
|
|
tar xvfz vdr-streamdev-0.3.1.tgz
|
|
ln -s streamdev-0.3.1 streamdev
|
|
cd ../..
|
|
make [options, if necessary] vdr
|
|
make [options, if necessary] plugins
|
|
|
|
|
|
3. Usage:
|
|
---------
|
|
|
|
Start the server core itself by specifying -Pstreamdev-server on your VDR
|
|
commandline. To use the client core, specify -Pstreamdev-client. Both parts
|
|
can run in one VDR instance, if necessary.
|
|
|
|
The parameter "Suspend behaviour" allows you to specify how the server should
|
|
react in case the client requests a channel that would require switching the
|
|
primary device (i.e. disrupt live-tv). If set to "Offer suspend mode" (the
|
|
default), you will have a new entry in the main menu. Activating that will put
|
|
the server into "Suspend Mode" (a picture is displayed on TV). Then, a client
|
|
may switch the primary card to wherever it likes to. While watching TV (Suspend
|
|
deactivated), the client may not switch the transponder on the primary device.
|
|
If you set the behaviour to "Always suspended", there will be normal live-tv
|
|
on the server, but whenever a client decides to switch the transponder, the
|
|
server will lose it's live-tv. Set to "Never suspended", the server always
|
|
prevents the client from switching transponders. If you set "Client may
|
|
suspend" to yes, the client can suspend the server remotely (this only applies
|
|
if "Offer suspend mode" is selected).
|
|
|
|
NOTE: This mainly applies to One-Card-Systems, since with multiple cards there
|
|
is no need to switch transponders on the primary interface, if the secondary
|
|
can stream a given channel (i.e. if it is not blocked by a recording). If both
|
|
cards are in use (i.e. when something is recorded, or by multiple clients),
|
|
this applies to Multiple-Card-Systems as well.
|
|
|
|
3.1 Usage HTTP server:
|
|
----------------------
|
|
|
|
You can use the HTTP part by accessing the server with a HTTP-capable media
|
|
player (such as XINE, MPlayer, and so on, if you have appropriate MPEG2-codecs
|
|
installed). In the PlugIn's Setup, you can specify the port the server will
|
|
listen to with the parameter "HTTP Server Port". The parameter "HTTP Streamtype"
|
|
allows you to specify a default stream type, which is used if no specific type
|
|
has been requested in the URL (see below). The supported stream types are:
|
|
|
|
TS Transport Stream (i.e. a dump from the device)
|
|
PES Packetized Elemetary Stream (VDR's native recording format)
|
|
PS Program Stream (SVCD, DVD like stream)
|
|
ES Elementary Stream (only Video, if available, otherwise only Audio)
|
|
EXTERN Pass stream through external script (e.g. for converting with mencoder)
|
|
|
|
If you leave the default port (3000), you can access the streams like this:
|
|
|
|
http://hostname:3000/3
|
|
http://hostname:3000/S19.2E-0-12480-898
|
|
|
|
The first one will deliver a channel by number on the server, the second one
|
|
will request the channel by unique channel id. In addition, you can specify
|
|
the desired stream type as a path to the channel.
|
|
|
|
http://hostname:3000/TS/3
|
|
http://hostname:3000/PES/S19.2E-0-12480-898
|
|
|
|
The first one would deliver the stream in TS, the second one in PES format.
|
|
Possible values are 'PES', 'TS', 'PS', 'ES' and 'EXTERN'. You need to specify
|
|
the ES format explicitly if you want to listen to radio channels. Play them
|
|
back i.e. with mpg123.
|
|
|
|
mpg123 http://hostname:3000/ES/200
|
|
|
|
3.2 Usage VDR-to-VDR server:
|
|
----------------------------
|
|
|
|
You can activate the VDR-to-VDR server part in the PlugIn's Setup Menu. It is
|
|
deactivated by default. The Parameter "VDR-to-VDR Server Port" specifies the
|
|
port where you want the server to listen for incoming connections. The server
|
|
will be activated when you push the OK button inside the setup menu, so there's
|
|
no need to restart VDR.
|
|
|
|
3.3 Usage VDR-to-VDR client:
|
|
----------------------------
|
|
|
|
The parameter "Remote IP" uses an IP-Adress-Editor, where you can just enter
|
|
the IP number with the number keys on your remote. After three digits (or if
|
|
the next digit would result in an invalid IP adress, or if the first digit is
|
|
0), the current position jumps to the next one. You can change positions with
|
|
the left and right buttons, and you can cycle the current position using up
|
|
and down. To confirm the entered address, press OK. So, if you want to enter
|
|
the IP address "127.0.0.1", just mark the corresponding entry as active and
|
|
type "127001<OK>" on your remote. If you want to enter "192.168.1.12", type
|
|
"1921681<Right>12<OK>".
|
|
|
|
The parameters "Remote IP" and "Remote Port" in the client's setup specify the
|
|
address of the remote VDR-to-VDR server to connect to. Activate the client by
|
|
setting "Start Client" to yes. It is disabled by default, because it wouldn't
|
|
make much sense to start the client without specifying a server anyway. The
|
|
client is activated after you push the OK button, so there's no need to restart
|
|
VDR. Deactivation on-the-fly is not possible, so in order to deactivate the
|
|
client, you will have to restart VDR. All other settings can be changed without
|
|
restarting VDR.
|
|
|
|
The client will try to connect to the server (in case it isn't yet) whenever
|
|
a remote channel is requested. Just activate the client and switch to a
|
|
channel that's not available by local devices. If anything goes wrong with the
|
|
connection between the two, you will see it in the logfile instantly. If you
|
|
now switch the client to a channel which isn't covered by it's own local
|
|
devices, it will ask the server for it. If the server can (currently) receive
|
|
that channel, the client will show it until you switch again, or until the
|
|
server needs that card (if no other is free) for a recording on a different
|
|
transponder.
|
|
|
|
Only the needed PIDs are transferred, and additional PIDs can be turned on
|
|
during an active transfer. This makes it possible to switch languages, receive
|
|
additional channels (for recording on the client) and use plugins that use
|
|
receivers themselves (like osdteletext).
|
|
|
|
With "Filter Streaming" enabled, the client will receive meta information like
|
|
EPG data and service information, just as if the client had its own DVB card.
|
|
Link channels and even a client-side EPG scan have been reported to work.
|
|
|
|
The last parameter, "Synchronize EPG", will have the client synchronize it's
|
|
program table with the server every now and then, but not regularly. This
|
|
happens when starting the client, and everytime VDR does its housekeeping
|
|
tasks. The only thing that's guaranteed is, that there will be a minimum
|
|
interval of ten seconds between each EPG synchronization. With "Filter
|
|
Streaming" this option has been obsoleted. If you still need to synchronize
|
|
EPG as additional information is available from the server, you should use the
|
|
epgsync-plugin instead (http://vdr.schmirler.de).
|
|
|
|
4. Other useful Plugins:
|
|
------------------------
|
|
|
|
4.1 Plugins for VDR-to-VDR clients:
|
|
-----------------------------------
|
|
|
|
The following plugins are useful for VDR-to-VDR clients (i.e. VDRs running the
|
|
streamdev-client):
|
|
|
|
* remotetimers (http://vdr.schmirler.de/)
|
|
Add, edit, delete timers on client and server
|
|
|
|
* timersync (http://phivdr.dyndns.org/vdr/vdr-timersync/)
|
|
Automatically syncronizes timer lists of client and server. All recordings will
|
|
be made on the server
|
|
|
|
* remoteosd (http://vdr.schmirler.de/)
|
|
Provides access to the server's OSD menu
|
|
|
|
* epgsync (http://vdr.schmirler.de/)
|
|
Import EPG from server VDR
|
|
|
|
* femon (http://www.saunalahti.fi/~rahrenbe/vdr/femon/)
|
|
Display signal information from server's DVB card. SVDRP support must be enabled
|
|
in femon's setup
|
|
|
|
4.2 Plugins for Server:
|
|
-----------------------
|
|
|
|
* dummydevice (http://phivdr.dyndns.org/vdr/vdr-dummydevice/)
|
|
Recommended on a headless server (i.e. a server with no real output device).
|
|
Without this plugin, a budget DVB card could become VDR's primary device. This
|
|
causes unwanted sideeffects in certain situations.
|
|
|
|
4.3 Alternatives:
|
|
-----------------
|
|
|
|
* xineliboutput (http://phivdr.dyndns.org/vdr/vdr-xineliboutput/)
|
|
With its networking option, xineliboutput provides an alternative to streamdev.
|
|
You will get the picture of the server VDR, including its OSD. However you
|
|
won't get independent clients, as they all share the same output.
|
|
|
|
5. Known Problems:
|
|
------------------
|
|
|
|
* In VDR-to-VDR setup, the availability of a channel is checked with a different
|
|
priority than the actual channel switch. The later always uses priority 0.
|
|
Usually a channel switch for live TV has priority 0 anyway, so it is not a
|
|
problem here. However timers usually have a higher priority. Either avoid
|
|
client side recordings or set the priority of client side timers to 0.
|