vdr-plugin-ttxtsubs

I've been using the original version for the patch for some days and found it working fine for the rare ttxtsubs use cases I have.

I've been using patch v2 for couple of days now and it works fine for both live tv and recordings. I used to have subs ~10s early and now subs appear to be spot on. Channels tested: Canal+ and Animal Planet on Sonera Cable in Helsinki, Finland.

Similar good experiences still here with the v2 patch, DNA/Welho cable in Espoo, FI.

in order to be able to use this patch I had to remove the "return;" or all the subs were discarded for certain channels

the second point is that for live view it works perfectly and for recording of the same live view there is delay

dimeptr wrote:

in order to be able to use this patch I had to remove the "return;" or all the subs were discarded for certain channels

How long delays did you got in logs when all subs were discarded ?

Currently pactch assumes delays longer than 15 sec are bogus, so increasing this limit should fix your problem better than removing "return;"

dimeptr wrote:

the second point is that for live view it works perfectly and for recording of the same live view there is delay

Can you make a short recording of such case and upload it somewhere ?

Sorry for late response, I did not Watch the issue so far.

this is the curren delay:

Jul 13 23:55:26 vdr: [3001] ttxtsubs: delay (-43540515 ms)
Jul 13 23:55:43 vdr: [3001] ttxtsubs: delay (-43557195 ms)
Jul 13 23:55:46 vdr: [3001] ttxtsubs: delay (-43559755 ms)
Jul 13 23:55:48 vdr: [3001] ttxtsubs: delay (-43562435 ms)


and usually the numbers are this huge.

I will try to upload a recording as soon as possible

Sorry for a very late response on this.
I have been debugging my problem yesterday, and it seems that the problem is that in this great delay is caused because the PTS is not set at all.

vdr: [29331] ttxtsubs: delay (-33911664 ms) sched_pts=0 pts=3052049776
vdr: [29331] ttxtsubs: delay (-33911704 ms) sched_pts=0 pts=3052053376
vdr: [29331] ttxtsubs: delay (-33914384 ms) sched_pts=0 pts=3052294576

I have searched the net and it seems that in this situations they use the PTS from the audio stream:
http://sydney.edu.au/engineering/it/~efax/DVBTextSub.html
but for this I guess the Ttxtsubs-plugin-hook.patch should be modified.

I have a recording if it still helps

The v3 patch doesn't compile for me on Fedora 18 x86_64:

ttxtsubsdisplay.c: In member function 'void cTtxtSubsDisplay::TtxtData(const uint8_t*, int64_t)':
ttxtsubsdisplay.c:281:54: error: no matching function for call to 'min(int64_t&, long long int)'
ttxtsubsdisplay.c:281:54: note: candidate is:
In file included from /usr/include/vdr/i18n.h:14:0,
                 from /usr/include/vdr/config.h:19,
                 from /usr/include/vdr/osd.h:16,
                 from ttxtsubsdisplay.c:28:
/usr/include/vdr/tools.h:54:28: note: template<class T> T min(T, T)
/usr/include/vdr/tools.h:54:28: note:   template argument deduction/substitution failed:
ttxtsubsdisplay.c:281:54: note:   deduced conflicting types for parameter 'T' ('long int' and 'long long int')

Changing the offending 250LL to (int64_t)250 seems to fix the build.

scop wrote:

The v3 patch doesn't compile for me on Fedora 18 x86_64:

[...]

Changing the offending 250LL to (int64_t)250 seems to fix the build.

this should fix that:

diff --git a/ttxtsubsdisplay.c b/ttxtsubsdisplay.c
index 6376a79..8a75db4 100644
--- a/ttxtsubsdisplay.c
+++ b/ttxtsubsdisplay.c
@@ -278,7 +278,7 @@ void cTtxtSubsDisplay::TtxtData(const uint8_t *Data, int64_t
                 //isyslog( "ttxtsubs: delay (%ld ms) sched_pts=%lld pts=%lld\n" 
                 while( diff > 10 )
                 {
-                    cCondWait::SleepMs(min(diff,250LL));
+                    cCondWait::SleepMs(min(diff,int64_t(250)));
                     if( !_doDisplay ) return;
                     diff -= 250;
                 }