[vdr] [PATCH] vdr-plugin-ttxtsubs - Sync subtitles using PTS
Hi!
After i upgraded my vdr to 1.7.27 and fetched latest sources for plugins, i got
serious subtitle timing issues. When viewing live tv the delay needed was about
2500ms and with recordings delay was almost 9000ms.
I have no idea what causes that difference. Previously subtitles have been
pretty well synced in both live and recordings.
Attached patch removes PES and TS delay settings and uses PTS to sync subtitles.
It works pretty well with my system using xinelibouput + vdpau.
Patch has two side effects:
1. when replay of recording is started it sometimes takes 5 to 10 seconds until
first subtitles appear. This is caused by wrong (live) PTS values got from
xineliboutput since actual replaying hasn't started yet when first subtitles are
parsed from stream.
2. when stopping replaying vdr is sometimes unresponsive for a few seconds if
the needed delays are large like in my system. I think the delay sleep in
cTtxtSubsDisplay::TtxtData() needs some tweaking to get rid of this side effect.
Regards,
Matti
diff -ub a/ttxtsubs.c b/ttxtsubs.c
--- a/ttxtsubs.c 2012-05-06 10:32:56.407162991 +0300
+++ b/ttxtsubs.c 2012-05-06 11:38:49.151704383 +0300
@@ -316,8 +316,6 @@
bool cPluginTtxtsubs::SetupParse(const char *Name, const char *Value)
{
if(!strcasecmp(Name, "Display")) { globals.mDoDisplay = atoi(Value); globals.mRealDoDisplay=globals.mDoDisplay; }
- else if(!strcasecmp(Name, "ReplayDelay")) globals.mReplayDelay = atoi(Value);
- else if(!strcasecmp(Name, "ReplayTsDelay")) globals.mReplayTsDelay = atoi(Value);
else if(!strcasecmp(Name, "MainMenuEntry")) globals.mMainMenuEntry = atoi(Value);
else if(!strcasecmp(Name, "FontSize")) globals.mFontSize = atoi(Value);
else if(!strcasecmp(Name, "OutlineWidth")) globals.mOutlineWidth = atoi(Value);
@@ -519,8 +517,6 @@
}
Add(new cMenuEditBoolItem(tr("Display Subtitles"), &mConf.mDoDisplay));
- Add(new cMenuEditIntItem(tr("Replay Delay (PES)"), &mConf.mReplayDelay, 0, 5000));
- Add(new cMenuEditIntItem(tr("Replay Delay (TS)"), &mConf.mReplayTsDelay, 0, 5000));
if(mConf.mMainMenuEntry < 0 || mConf.mMainMenuEntry >= numMainMenuAlts)
mConf.mMainMenuEntry = 0; // menu item segfaults if out of range
Add(new cMenuEditStraItem(tr("Main Menu Alternative"), &mConf.mMainMenuEntry,
@@ -578,8 +574,6 @@
}
SetupStore("Display", mConf.mDoDisplay);
- SetupStore("ReplayDelay", mConf.mReplayDelay);
- SetupStore("ReplayTsDelay", mConf.mReplayTsDelay);
SetupStore("MainMenuEntry", mConf.mMainMenuEntry);
SetupStore("FontSize", mConf.mFontSize);
SetupStore("OutlineWidth", mConf.mOutlineWidth);
diff -ub vdr-plugin-ttxtsubs-orig/ttxtsubsdisplay.c ttxtsubs/ttxtsubsdisplay.c
--- a/ttxtsubsdisplay.c 2012-05-06 10:32:56.407162991 +0300
+++ b/ttxtsubsdisplay.c 2012-05-06 10:55:30.875210862 +0300
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "ttxtsubsglobals.h"
#include "ttxtsubsdisplay.h"
@@ -164,7 +165,7 @@
}
-void cTtxtSubsDisplay::TtxtData(const uint8_t *Data, uint64_t sched_time)
+void cTtxtSubsDisplay::TtxtData(const uint8_t *Data, uint32_t sched_pts)
{
int mp;
int mag; // X in ETSI EN 300 706
@@ -256,8 +257,13 @@
if (_pageState != collecting)
{
-int diff = sched_time - cTimeMs::Now();
-//printf("Got sched_time %llx, diff %d\n", sched_time, diff);
+uint32_t pts = cDevice::PrimaryDevice()->GetSTC();
+int diff = (sched_pts - pts) / 90;
+if( diff > 15000 )
+{
+ isyslog( "ttxtsubs: too long delay (%d ms), discarding", diff );
+ return;
+}
if (diff > 10) cCondWait::SleepMs(diff);
}
diff -ub vdr-plugin-ttxtsubs-orig/ttxtsubsdisplayer.c ttxtsubs/ttxtsubsdisplayer.c
--- a/ttxtsubsdisplayer.c 2012-05-06 10:32:56.407162991 +0300
+++ b/ttxtsubsdisplayer.c 2012-05-06 11:34:36.287264711 +0300
@@ -31,7 +31,7 @@
mDisp(new cTtxtSubsDisplay()),
mGetMutex(),
mGetCond(),
- mRingBuf(94000, true),
+ mRingBuf(188000, true),
mRun(0)
{
mDisp->SetPage(textpage);
@@ -59,9 +59,7 @@
f = mRingBuf.Get();
if(f) {
- uint64_t sched_time;
- memcpy(&sched_time, f->Data() + 46, sizeof(sched_time));
- mDisp->TtxtData(f->Data(), sched_time);
+ mDisp->TtxtData(f->Data(), f->Pts());
mRingBuf.Drop(f);
} else {
// wait for more data
@@ -102,6 +100,7 @@
void cTtxtSubsPlayer::PES_data(uchar *p, int Length, bool IsPesRecording, const struct tTeletextSubtitlePage teletextSubtitlePages[], int pageCount)
{
int i;
+ int64_t pts = 0;
//printf("cTtxtSubsPlayer: len: %d\n", Length); // XXX
@@ -136,14 +135,21 @@
if(mHasFilteredStream && !mFoundLangPage)
SearchLanguagePage(p, Length);
+ if ((p[6] & 0xC0) == 0x80 && (p[7] & 0x80)) {
+ //Copied from xineliboutput/tools/pes.c
+ pts = ((int64_t)(p[ 9] & 0x0E)) << 29 ;
+ pts |=
Re: [vdr] HDMI output detection problems
Hi, Same problem here using Sony receiver and Octava hdmi splitter after receiver (for TV and projector) On 28.7.2012 15:18, Jouni Karvo wrote: hi, since starting to use a AV receiver between TV and VDR, I have had HDMI detection problems. To start X server even when TV is not on, I use custom edid file that I got from the tuner. With this, VDR always starts X properly, so even if VDR has auto-started for recording, the output works. I tried all kind of custom edid files (read from receiver, tv, projector or splitter) none of the files solved negoatiation problems. Card: Nvidia GT220, vdr-xine plugin, Xorg, NAD receiver and Sony TV. If I start TV, though, for some reason, most often there is no negoatiation (or a failed one) between the receiver and VDR, so there will be no picture. Normally there is a sound, though. I have to switch the input selector of the receiver first to DVD input, then back to TV input to get the image. If the tuner and TV are on when X server starts, the image appears correctly. Are there any flags in nvidia-settings or Xorg.conf or Xine configuration that would tell the graphics card to help the tuner to notice that there indeed is an image also on the HDMI cable? I also tried various nvidia flags without luck. I did use custom script to put display to sleep mode (xset dpms force off) and then back on after small delay. Nowdays i have programmable remote control which has support for macros, so it just changes receivers input to dvd and then back to vdr when powering on the system. Regards, Matti yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.3.1
Finnish DVB-T channels not updating. I was building new vdr system and copied only one channel to channels.conf from my current production system and noticed that channels were not updating. Probably something to do with this: - Fixed setting the source value of newly created channels, in case the NIT is received from a different, but very close satellite position (reported by Daniel Ribeiro). The code for handling different NITs has been removed from nit.c, because according to the DVB standard table id 0x40 carries only the NIT of the actual network. After enabling DebugNit and added some more debug messages, i found out that sdtFilter->Trigger(Source) @nit.c:270 was never triggered. With quick'n dirty hack others than currently tuned transponder started to update: --- a/nit.c 2015-10-10 13:42:19.690169490 +0300 +++ b/nit.c 2015-10-10 13:43:04.114821083 +0300 @@ -266,7 +266,7 @@ } } } - if (ISTRANSPONDER(Frequency / 100, Transponder())) + //if (ISTRANSPONDER(Frequency / 100, Transponder())) sdtFilter->Trigger(Source); } break; -Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] EPG data collected but not shown?
On 01/05/17 18:41, Markku Tavasti wrote: Ok, those channels found with w_scan are ok, and that FOX line Klaus formed is also ok. Now, putting VDR to update channels will break some of the channels. Unfortunately you can't use 'Add new transponders' setting in Finland. (Except in Espoo area) Digita is not sending regional NIT data in their DVB streams. That's why you get duplicate channels in channels.conf. For some reason (Laziness..?) Digita is sendng Espoo's transponder information in NIT data and if your regional transponders differs from those, you get duplicates/not working channels in vdr. I have mixed DVB-T/DVB-S system, so i patched vdr to ignore NIT data from DVB-T so i could still use 'Add new transponders' in DVB-S -Matti ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xineliboutput a small patch
Hi all.
I had a small problem with xineliboutput, i didn't find a way to start
playing a file with mediaplayer from the beginning if the file had been
earlier watched till the end. Media player always started from end of file.
So i made a small patch, which saves resume position to 0 seconds if
there was less than 10 seconds till the end of file.
Regards
Matti
--- vdr-1.4.6-vanilla/PLUGINS/src/xineliboutput-1.0.0rc1/media_player.c
2007-03-17 14:41:20.0 +0200
+++ vdr-1.4.6/PLUGINS/src/xineliboutput-1.0.0rc1/media_player.c
2007-03-31 21:50:42.0 +0300
@@ -228,7 +228,7 @@
void cXinelibPlayer::Activate(bool On)
{
- int pos = 0, fd = -1;
+ int pos = 0, fd = -1, len = 0;
if(On) {
if(m_UseResume && !*m_ResumeFile)
m_ResumeFile = cString::sprintf("%s.resume", *m_File);
@@ -267,6 +267,12 @@
pos = cXinelibDevice::Instance().PlayFileCtrl("GETPOS");
if(pos>=0) {
pos /= 1000;
+ len = cXinelibDevice::Instance().PlayFileCtrl("GETLENGTH");
+ len /= 1000;
+ len -= 10;
+ if( pos > len )
+pos = 0;
+
if(0 <= (fd = open(m_ResumeFile, O_WRONLY | O_CREAT,
S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH))) {
if(write(fd, &pos, sizeof(int)) != sizeof(int)) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] reel netclient
Georg Acher wrote: > For the client side, the sources will be published as GPL. Currently we use > a closed source daemon with a dvb loopback driver in the kernel, but that > makes it hard to fully use the tuner virtualization and costs some overhead > for small CPUs. Since we already have a native vdr plugin for that, the > network code will be then forced to be GPL anyway ;-) > Hi Georg. Since there currently isn't v4l looback driver in mainline kernel, I suggest you take part on this ongoing discussion at linux-media mailing list: http://www.mail-archive.com/linux-me...@vger.kernel.org/msg04362.html As you can see, Mauro was going to add that loopback driver on v4l as out-of-tree driver. For end-user it would be a lot easier if your loopback implementation would be integrated on that driver and added to upstream kernel tree :) Regards, Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
Hi! After i changed my sat tuner to Linux4Media cineS2 DVB-S2 Twin Tuner http://www.linuxtv.org/wiki/index.php/Linux4Media_cineS2_DVB-S2_Twin_Tuner femon's frontend info doesn't work anymore on all frontends. Exact cause for that seems to be the way ngene driver registers frontends at /dev/dvb My current /dev/dvb looks like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter2/frontend0 Since femon assumes that vdr card index is same as adapter index, femon shows stats from wrong frontend and can't show stas from /dev/dvb/adapter2 at all. A quick look at vdr's device.h didn't reveal an easy fix for this problem, since cDevice doesn't store device paths or adapter/frontend numbers. - Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
