vdr-plugin-streamdev/client/setup.c

104 lines
3.9 KiB
C
Raw Normal View History

2004-12-30 23:43:55 +01:00
/*
* $Id: setup.c,v 1.10 2010/06/08 05:55:17 schmirl Exp $
2004-12-30 23:43:55 +01:00
*/
#include <vdr/menuitems.h>
#include "client/setup.h"
#include "client/streamdev-client.h"
2004-12-30 23:43:55 +01:00
#ifndef MINPRIORITY
#define MINPRIORITY -MAXPRIORITY
#endif
2004-12-30 23:43:55 +01:00
cStreamdevClientSetup StreamdevClientSetup;
cStreamdevClientSetup::cStreamdevClientSetup(void) {
StartClient = false;
RemotePort = 2004;
Timeout = 2;
2004-12-30 23:43:55 +01:00
StreamFilters = false;
HideMenuEntry = false;
LivePriority = 0;
MinPriority = MINPRIORITY;
MaxPriority = MAXPRIORITY;
#if APIVERSNUM >= 10700
NumProvidedSystems = 1;
#endif
2004-12-30 23:43:55 +01:00
strcpy(RemoteIp, "");
Fixed problems related to VTP filter streaming like ringbuffer overflows, stuttering or aborting video stream (refs #2045) Toerless Eckert wrote: This patch tries to resolve problems in streamdev-client that can occur when enabling "StreamFilters". Enabling this option is necessary to receive certain programs with dynamic PIDs such as some german "regional" broadcast (eg: NDR). Problem: Without this fix, the following behavior was observed on a Raspberry PI running streamdev-0.6.1-git with VDR-2.6.1: - Buffer overflows of filter data - Stop/go video on channels - Total stopping of video More logs in: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237- streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/ Analysis: VDR expect section data from filters separately from the main program stream. Historically, it received each filter data via a separate file descriptor from the DVB card. In the streamdev-client module, a socketpair is used to feed filter data to the main VDR code. During certain operations in VDR, such as startup or channel change (depending also on the speed of initialization of the video output driver), VDR does not consume the filter data as fast as it is provided by streamdev-client, resulting in overflow of the default socket buffers used by streamdev-client. To add to the problem of overflowing the socketpair buffers, the streamdev-client code sends several times a second short packets into the socketpair to determine if the receiving side (VDR) has closed the socketpair (IsClosed(), CarbageCollect()). This further clogs up the socketpair() buffer. The raspberry PI socketpair buffering behavior seems to be the same as that of other 3.x linux systems, the socket buffer size is by default 163840, and it can be increased via sysctl net.core.wmem_max. During startup, it can take up to 10 seconds before VDR will consume filter data, so the socketpair buffer can fill up with 10 seconds worth of data. Solution 1. IsClosed()/CarbageCollect() where removed from client/filter.c and replaced by explicitly tracking when VDR closes a filter socket. This alone seems to already resolve the problem of hanging or stop&go video and seems to be sufficient to receive dynamic-PID channels reliably. 2. filter.c was enhanced to request a larger socket buffer size if config option FilterSockBufSize is set. 3. If supported (if streamdev-client runs on linux), the socketpair queue is "flushed" to reduce the amount of "random" packet drop messages and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
FilterSockBufSize = 0;
2004-12-30 23:43:55 +01:00
}
bool cStreamdevClientSetup::SetupParse(const char *Name, const char *Value) {
if (strcmp(Name, "StartClient") == 0) StartClient = atoi(Value);
else if (strcmp(Name, "RemoteIp") == 0) {
if (strcmp(Value, "-none-") == 0)
strcpy(RemoteIp, "");
else
strcpy(RemoteIp, Value);
}
else if (strcmp(Name, "RemotePort") == 0) RemotePort = atoi(Value);
else if (strcmp(Name, "Timeout") == 0) Timeout = atoi(Value);
2004-12-30 23:43:55 +01:00
else if (strcmp(Name, "StreamFilters") == 0) StreamFilters = atoi(Value);
else if (strcmp(Name, "HideMenuEntry") == 0) HideMenuEntry = atoi(Value);
else if (strcmp(Name, "LivePriority") == 0) LivePriority = atoi(Value);
else if (strcmp(Name, "MinPriority") == 0) MinPriority = atoi(Value);
else if (strcmp(Name, "MaxPriority") == 0) MaxPriority = atoi(Value);
Fixed problems related to VTP filter streaming like ringbuffer overflows, stuttering or aborting video stream (refs #2045) Toerless Eckert wrote: This patch tries to resolve problems in streamdev-client that can occur when enabling "StreamFilters". Enabling this option is necessary to receive certain programs with dynamic PIDs such as some german "regional" broadcast (eg: NDR). Problem: Without this fix, the following behavior was observed on a Raspberry PI running streamdev-0.6.1-git with VDR-2.6.1: - Buffer overflows of filter data - Stop/go video on channels - Total stopping of video More logs in: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237- streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/ Analysis: VDR expect section data from filters separately from the main program stream. Historically, it received each filter data via a separate file descriptor from the DVB card. In the streamdev-client module, a socketpair is used to feed filter data to the main VDR code. During certain operations in VDR, such as startup or channel change (depending also on the speed of initialization of the video output driver), VDR does not consume the filter data as fast as it is provided by streamdev-client, resulting in overflow of the default socket buffers used by streamdev-client. To add to the problem of overflowing the socketpair buffers, the streamdev-client code sends several times a second short packets into the socketpair to determine if the receiving side (VDR) has closed the socketpair (IsClosed(), CarbageCollect()). This further clogs up the socketpair() buffer. The raspberry PI socketpair buffering behavior seems to be the same as that of other 3.x linux systems, the socket buffer size is by default 163840, and it can be increased via sysctl net.core.wmem_max. During startup, it can take up to 10 seconds before VDR will consume filter data, so the socketpair buffer can fill up with 10 seconds worth of data. Solution 1. IsClosed()/CarbageCollect() where removed from client/filter.c and replaced by explicitly tracking when VDR closes a filter socket. This alone seems to already resolve the problem of hanging or stop&go video and seems to be sufficient to receive dynamic-PID channels reliably. 2. filter.c was enhanced to request a larger socket buffer size if config option FilterSockBufSize is set. 3. If supported (if streamdev-client runs on linux), the socketpair queue is "flushed" to reduce the amount of "random" packet drop messages and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
else if (strcmp(Name, "FilterSockBufSize") == 0) FilterSockBufSize = atoi(Value);
#if APIVERSNUM >= 10700
else if (strcmp(Name, "NumProvidedSystems") == 0) NumProvidedSystems = atoi(Value);
#endif
2004-12-30 23:43:55 +01:00
else return false;
return true;
}
cStreamdevClientMenuSetupPage::cStreamdevClientMenuSetupPage(cPluginStreamdevClient *Plugin) {
m_Plugin = Plugin;
2004-12-30 23:43:55 +01:00
m_NewSetup = StreamdevClientSetup;
Add(new cMenuEditBoolItem(tr("Hide Mainmenu Entry"), &m_NewSetup.HideMenuEntry));
Add(new cMenuEditIntItem (tr("Simultaneously used Devices"), &m_NewSetup.StartClient, 0, STREAMDEV_MAXDEVICES));
Add(new cMenuEditIpItem (tr("Remote IP"), m_NewSetup.RemoteIp));
Add(new cMenuEditIntItem (tr("Remote Port"), &m_NewSetup.RemotePort, 0, 65535));
Add(new cMenuEditIntItem (tr("Timeout (s)"), &m_NewSetup.Timeout, 1, 15));
Add(new cMenuEditBoolItem(tr("Filter Streaming"), &m_NewSetup.StreamFilters));
Fixed problems related to VTP filter streaming like ringbuffer overflows, stuttering or aborting video stream (refs #2045) Toerless Eckert wrote: This patch tries to resolve problems in streamdev-client that can occur when enabling "StreamFilters". Enabling this option is necessary to receive certain programs with dynamic PIDs such as some german "regional" broadcast (eg: NDR). Problem: Without this fix, the following behavior was observed on a Raspberry PI running streamdev-0.6.1-git with VDR-2.6.1: - Buffer overflows of filter data - Stop/go video on channels - Total stopping of video More logs in: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237- streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/ Analysis: VDR expect section data from filters separately from the main program stream. Historically, it received each filter data via a separate file descriptor from the DVB card. In the streamdev-client module, a socketpair is used to feed filter data to the main VDR code. During certain operations in VDR, such as startup or channel change (depending also on the speed of initialization of the video output driver), VDR does not consume the filter data as fast as it is provided by streamdev-client, resulting in overflow of the default socket buffers used by streamdev-client. To add to the problem of overflowing the socketpair buffers, the streamdev-client code sends several times a second short packets into the socketpair to determine if the receiving side (VDR) has closed the socketpair (IsClosed(), CarbageCollect()). This further clogs up the socketpair() buffer. The raspberry PI socketpair buffering behavior seems to be the same as that of other 3.x linux systems, the socket buffer size is by default 163840, and it can be increased via sysctl net.core.wmem_max. During startup, it can take up to 10 seconds before VDR will consume filter data, so the socketpair buffer can fill up with 10 seconds worth of data. Solution 1. IsClosed()/CarbageCollect() where removed from client/filter.c and replaced by explicitly tracking when VDR closes a filter socket. This alone seems to already resolve the problem of hanging or stop&go video and seems to be sufficient to receive dynamic-PID channels reliably. 2. filter.c was enhanced to request a larger socket buffer size if config option FilterSockBufSize is set. 3. If supported (if streamdev-client runs on linux), the socketpair queue is "flushed" to reduce the amount of "random" packet drop messages and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
if(m_NewSetup.StreamFilters)
Add(new cMenuEditIntItem (tr("Filter SockBufSize"), &m_NewSetup.FilterSockBufSize, 0, 8192000));
Add(new cMenuEditIntItem (tr("Live TV Priority"), &m_NewSetup.LivePriority, MINPRIORITY, MAXPRIORITY));
Add(new cMenuEditIntItem (tr("Minimum Priority"), &m_NewSetup.MinPriority, MINPRIORITY, MAXPRIORITY));
Add(new cMenuEditIntItem (tr("Maximum Priority"), &m_NewSetup.MaxPriority, MINPRIORITY, MAXPRIORITY));
#if APIVERSNUM >= 10715
Add(new cMenuEditIntItem (tr("Broadcast Systems / Cost"), &m_NewSetup.NumProvidedSystems, 1, 15));
#elif APIVERSNUM >= 10700
Add(new cMenuEditIntItem (tr("Broadcast Systems / Cost"), &m_NewSetup.NumProvidedSystems, 1, 4));
#endif
2004-12-30 23:43:55 +01:00
SetCurrent(Get(0));
}
cStreamdevClientMenuSetupPage::~cStreamdevClientMenuSetupPage() {
}
void cStreamdevClientMenuSetupPage::Store(void) {
SetupStore("StartClient", m_NewSetup.StartClient);
if (strcmp(m_NewSetup.RemoteIp, "") == 0)
SetupStore("RemoteIp", "-none-");
else
SetupStore("RemoteIp", m_NewSetup.RemoteIp);
SetupStore("RemotePort", m_NewSetup.RemotePort);
SetupStore("Timeout", m_NewSetup.Timeout);
2004-12-30 23:43:55 +01:00
SetupStore("StreamFilters", m_NewSetup.StreamFilters);
SetupStore("HideMenuEntry", m_NewSetup.HideMenuEntry);
SetupStore("LivePriority", m_NewSetup.LivePriority);
SetupStore("MinPriority", m_NewSetup.MinPriority);
SetupStore("MaxPriority", m_NewSetup.MaxPriority);
#if APIVERSNUM >= 10700
SetupStore("NumProvidedSystems", m_NewSetup.NumProvidedSystems);
#endif
Fixed problems related to VTP filter streaming like ringbuffer overflows, stuttering or aborting video stream (refs #2045) Toerless Eckert wrote: This patch tries to resolve problems in streamdev-client that can occur when enabling "StreamFilters". Enabling this option is necessary to receive certain programs with dynamic PIDs such as some german "regional" broadcast (eg: NDR). Problem: Without this fix, the following behavior was observed on a Raspberry PI running streamdev-0.6.1-git with VDR-2.6.1: - Buffer overflows of filter data - Stop/go video on channels - Total stopping of video More logs in: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/125237- streamdev-client-filter-daten-streamen-ndr-raspberry-haengt/ Analysis: VDR expect section data from filters separately from the main program stream. Historically, it received each filter data via a separate file descriptor from the DVB card. In the streamdev-client module, a socketpair is used to feed filter data to the main VDR code. During certain operations in VDR, such as startup or channel change (depending also on the speed of initialization of the video output driver), VDR does not consume the filter data as fast as it is provided by streamdev-client, resulting in overflow of the default socket buffers used by streamdev-client. To add to the problem of overflowing the socketpair buffers, the streamdev-client code sends several times a second short packets into the socketpair to determine if the receiving side (VDR) has closed the socketpair (IsClosed(), CarbageCollect()). This further clogs up the socketpair() buffer. The raspberry PI socketpair buffering behavior seems to be the same as that of other 3.x linux systems, the socket buffer size is by default 163840, and it can be increased via sysctl net.core.wmem_max. During startup, it can take up to 10 seconds before VDR will consume filter data, so the socketpair buffer can fill up with 10 seconds worth of data. Solution 1. IsClosed()/CarbageCollect() where removed from client/filter.c and replaced by explicitly tracking when VDR closes a filter socket. This alone seems to already resolve the problem of hanging or stop&go video and seems to be sufficient to receive dynamic-PID channels reliably. 2. filter.c was enhanced to request a larger socket buffer size if config option FilterSockBufSize is set. 3. If supported (if streamdev-client runs on linux), the socketpair queue is "flushed" to reduce the amount of "random" packet drop messages and to rather drop sequential messages.
2015-01-24 00:19:04 +01:00
SetupStore("FilterSockBufSize", m_NewSetup.FilterSockBufSize);
2004-12-30 23:43:55 +01:00
StreamdevClientSetup = m_NewSetup;
m_Plugin->Initialize();
2004-12-30 23:43:55 +01:00
}