Re: [vdr] vdr-1.5.11 subtitling problems
Hi, Jose Alberto Reguero schrieb: I still have problems with this patch and pvrinput and live radio, with CRepacker. If I disable CRepacker, the live radio is ok. Any ideas why to debug it? I need some more information. From what I guess, pvrinput provides a TS stream, VDR runs in transfermode and outputs the remuxed stream via a FF card. Is this correct? What are the problems you are seeing with cAudioRepacker enabled? Are there any problems when you replay a radio recording? Are there any logfile entries mentioning a problem? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
El Domingo, 18 de Noviembre de 2007, Reinhard Nissl escribió: Hi, Jose Alberto Reguero schrieb: I still have problems with this patch and pvrinput and live radio, with CRepacker. If I disable CRepacker, the live radio is ok. Any ideas why to debug it? I need some more information. From what I guess, pvrinput provides a TS stream, VDR runs in transfermode and outputs the remuxed stream via a FF card. Is this correct? Pvrinput is for analog hauppauge cards with harware encoder. Radio is a bit diferent, that tv because the card can't provide a mpeg audio only stream but a mpeg audio stream with a blank mpeg video. Audio channels have pid=0 so remux left only the audio part. If I put video pid in the radio channels in channels.conf then there is no problem with CRepacker. I use xineliboutput for the output. What are the problems you are seeing with cAudioRepacker enabled? The problems I have are that sometimes, the audio is not completely smooth, they have some breaks, in live radio. Are there any problems when you replay a radio recording? The recordings play without problems. Are there any logfile entries mentioning a problem? There are not any messages in the log files. Bye. Thanks. Jose Alberto ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi, What are the problems you are seeing with cAudioRepacker enabled? The problems I have are that sometimes, the audio is not completely smooth, they have some breaks, in live radio. Are there any problems when you replay a radio recording? The recordings play without problems. This sounds like buffer underruns when listening to live radio. When cAudioRepacker is enabled and with the recent ringbuffer patch, you'll get each audio frame (~ 24 ms) as soon as it is available. If the output device starts immediately with playback, it is likely that there are buffer underruns, especially when xine drops some audio frames when syncing. I don't know whether xineliboutput has some setup options to control buffering in live mode. In vdr-xine's setup page you can specify an initial buffer size (e. g. 4 video frames ~ 160 ms) which must first be established before replaying at normal speed starts. BTW: The software decoding solutions need such a buffer to compensate latency issues with the threads involved in the chain from input to output. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi,
Timo J. Rinne schrieb:
Anyways, it's been on for 25 minutes so far and has worked perfectly.
If I notice something in contrary to this, I'll report further.
Nope, it still doesn't quite work. In live mode it seems to skip
subtitles every now and then. It even seems to depend on the program.
Today I watched something and saw maybe one subtitle of ten. Sometimes
it seems to work more or less perfectly.
When I recorded the program that in live mode didn't work too well, the
subtitles were fine in playback.
I have ff card and I think the problems are present mainly (if not only)
in direct live mode. When I forced it to transport mode by
simultaneously recording an encrypted channel and watching fta channel
live (transport mode), subtitles showed OK.
Please try the attached patch on a vanilla VDR-1.5.11. It should write
the subtitle TS and PES packets to separate files at /video. The
additionally recorded timestamps of your system time and the primary
device's STC should allow us to determine whether the packets arrive in
time and get properly remuxed.
Once you've seen enough anomalies, please provide us (a link to) the files.
BTW: the patch is almost untested as there are currently no subtitles
running.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.5.11-orig/device.c ./device.c
--- ../vdr-1.5.11-orig/device.c 2007-11-03 14:30:09.0 +0100
+++ ./device.c 2007-11-12 21:57:36.0 +0100
@@ -210,7 +210,7 @@ int cPesAssembler::PacketSize(const ucha
#define DEFAULTPRIORITY -1
// The minimum number of unknown PS1 packets to consider this a pre 1.3.19 private stream:
-#define MIN_PRE_1_3_19_PRIVATESTREAM 10
+#define MIN_PRE_1_3_19_PRIVATESTREAM 0 /*10*/
int cDevice::numDevices = 0;
int cDevice::useDevice = 0;
diff -Nurp ../vdr-1.5.11-orig/remux.c ./remux.c
--- ../vdr-1.5.11-orig/remux.c 2007-11-03 15:18:07.0 +0100
+++ ./remux.c 2007-11-15 23:02:54.0 +0100
@@ -1387,6 +1387,51 @@ int cDolbyRepacker::BreakAt(const uchar
return -1;
}
+class cLogger {
+ static int instance;
+ FILE *logFileTS;
+ FILE *logFilePES;
+ static void Store(FILE *LogFile, const uchar *Data, int Count);
+public:
+ cLogger(void);
+ ~cLogger();
+ void PutTS(const uchar *Data) { Store(logFileTS, Data, 188); }
+ void PutPES(const uchar *Data, int Count) { Store(logFilePES, Data, Count); }
+ };
+
+int cLogger::instance = 0;
+
+cLogger::cLogger(void)
+{
+ int Instance = instance++;
+ char FileNameTS[200];
+ sprintf(FileNameTS, /video/subtitle_log_%d_%02d.ts, getpid(), Instance);
+ logFileTS = fopen(FileNameTS, wb);
+ char FileNamePES[200];
+ sprintf(FileNamePES, /video/subtitle_log_%d_%02d.pes, getpid(), Instance);
+ logFilePES = fopen(FileNamePES, wb);
+}
+
+cLogger::~cLogger()
+{
+ fclose(logFileTS);
+ fclose(logFilePES);
+}
+
+#include sys/time.h
+#include device.h
+
+void cLogger::Store(FILE *LogFile, const uchar *Data, int Count)
+{
+ timeval tv;
+ gettimeofday(tv, 0);
+ int64_t stc = cDevice::PrimaryDevice()-GetSTC();
+ fwrite(tv, sizeof (tv), 1, LogFile);
+ fwrite(stc, sizeof (stc), 1, LogFile);
+ fwrite(Data, Count, 1, LogFile);
+ fflush(LogFile);
+}
+
// --- cTS2PES ---
#include netinet/in.h
@@ -1474,12 +1519,14 @@ public:
int Pid(void) { return pid; }
void ts_to_pes(const uint8_t *Buf); // don't need count (=188)
void Clear(void);
+cLogger *logger;
};
uint8_t cTS2PES::headr[] = { 0x00, 0x00, 0x01 };
cTS2PES::cTS2PES(int Pid, cRingBufferLinear *ResultBuffer, int Size, uint8_t RewriteCid, uint8_t SubStreamId, cRepacker *Repacker)
{
+logger = (Repacker ? 0 : new cLogger);
pid = Pid;
resultBuffer = ResultBuffer;
size = Size;
@@ -1504,6 +1551,7 @@ cTS2PES::cTS2PES(int Pid, cRingBufferLin
cTS2PES::~cTS2PES()
{
+delete logger;
if (tsErrors || ccErrors)
dsyslog(cTS2PES got %d TS errors, %d TS continuity errors, tsErrors, ccErrors);
free(buf);
@@ -1519,6 +1567,7 @@ void cTS2PES::Clear(void)
void cTS2PES::store(uint8_t *Data, int Count)
{
+if (logger) logger-PutPES(Data, Count);
if (repacker)
repacker-Repack(resultBuffer, Data, Count);
else
@@ -1749,14 +1798,15 @@ void cTS2PES::instant_repack(const uint8
case AUDIO_STREAM_S ... AUDIO_STREAM_E:
case VIDEO_STREAM_S ... VIDEO_STREAM_E:
case PRIVATE_STREAM1:
-
-if (mpeg == 2 found == 9) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 2 found == 9 count found) {
write_ipack(flag1, 1);
write_ipack(flag2, 1);
write_ipack(hlength, 1);
}
-if (mpeg == 1 found == mpeg1_required) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 1 found == mpeg1_required count found) {
write_ipack(flag1, 1);
if
Re: [vdr] vdr-1.5.11 subtitling problems
En/na Reinhard Nissl ha escrit: BTW: the patch is almost untested as there are currently no subtitles running. FYI, if you can see astra 2d I just found that at least CBeebies and BBC4 broadcast dvb subtitles. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi,
Timo J. Rinne schrieb:
Posting to the mailing list seems to be for subscribers only and I'm
reading it only through archive. However ...
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to
allow
retrieving any packet as soon as it is completely available in the
buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do.
Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
See attachment. Tested in transfer mode with audio packets only (=
radio), as there is no broadcast running which would provide
subtitles.
The picture doesn't freeze any longer. But after a while (5-10 minutes)
subtitles disappear.
You'll have to provide some more information. Do you use subtitles with
a FF card?
Can you reproduce the issue in a recording?
Did you apply all the posted fixes?
Attached you'll find a single patch against vanilla VDR-1.5.11. It
contains the remuxer fix and the ringbuffer extension, but also reverts
some changes from 1.5.10 to 1.5.11 which should be addressed by the
other two parts.
I've just watched subtitles now for almost 2 hours on ZDF (ASTRA 19.2E)
with vdr-xine without any issues. But vdr-xine works different (transfer
mode) and may not see issues which happen with FF cards.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.5.11-orig/device.c ./device.c
--- ../vdr-1.5.11-orig/device.c 2007-11-03 14:30:09.0 +0100
+++ ./device.c 2007-11-12 21:57:36.0 +0100
@@ -210,7 +210,7 @@ int cPesAssembler::PacketSize(const ucha
#define DEFAULTPRIORITY -1
// The minimum number of unknown PS1 packets to consider this a pre 1.3.19 private stream:
-#define MIN_PRE_1_3_19_PRIVATESTREAM 10
+#define MIN_PRE_1_3_19_PRIVATESTREAM 0 /*10*/
int cDevice::numDevices = 0;
int cDevice::useDevice = 0;
diff -Nurp ../vdr-1.5.11-orig/remux.c ./remux.c
--- ../vdr-1.5.11-orig/remux.c 2007-11-03 15:18:07.0 +0100
+++ ./remux.c 2007-11-12 21:50:41.0 +0100
@@ -1749,14 +1749,15 @@ void cTS2PES::instant_repack(const uint8
case AUDIO_STREAM_S ... AUDIO_STREAM_E:
case VIDEO_STREAM_S ... VIDEO_STREAM_E:
case PRIVATE_STREAM1:
-
-if (mpeg == 2 found == 9) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 2 found == 9 count found) {
write_ipack(flag1, 1);
write_ipack(flag2, 1);
write_ipack(hlength, 1);
}
-if (mpeg == 1 found == mpeg1_required) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 1 found == mpeg1_required count found) {
write_ipack(flag1, 1);
if (mpeg1_required 7) {
write_ipack(flag2, 1);
@@ -1883,7 +1884,7 @@ cRemux::cRemux(int VPid, const int *APid
skipped = 0;
numTracks = 0;
resultSkipped = 0;
- resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result);
+ resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result, true);
resultBuffer-SetTimeouts(0, 100);
if (VPid)
#define TEST_cVideoRepacker
@@ -1912,7 +1913,7 @@ cRemux::cRemux(int VPid, const int *APid
if (SPids) {
int n = 0;
while (*SPids numTracks MAXTRACKS n MAXSPIDS)
- ts2pes[numTracks++] = new cTS2PES(*SPids++, resultBuffer, SUBTITLE_PACKS, 0x00, 0x20 + n++);
+ ts2pes[numTracks++] = new cTS2PES(*SPids++, resultBuffer, IPACKS /*SUBTITLE_PACKS*/, 0x00, 0x20 + n++);
}
}
diff -Nurp ../vdr-1.5.11-orig/ringbuffer.c ./ringbuffer.c
--- ../vdr-1.5.11-orig/ringbuffer.c 2006-06-16 11:32:13.0 +0200
+++ ./ringbuffer.c 2007-11-10 21:05:47.0 +0100
@@ -151,9 +151,10 @@ void cRingBufferLinear::PrintDebugRBL(vo
}
#endif
-cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description)
+cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description, bool AssumePesContent)
:cRingBuffer(Size, Statistics)
{
+ assumePesContent = AssumePesContent;
description = Description ? strdup(Description) : NULL;
tail = head = margin = Margin;
gotten = 0;
@@ -299,7 +300,7 @@ uchar *cRingBufferLinear::Get(int Count
int cont = (diff = 0) ? diff : Size() + diff - margin;
if (cont rest)
cont = rest;
- if (cont = margin) {
+ if (cont = margin || assumePesContent HasPesPacket(cont)) {
p = buffer + tail;
Count = gotten = cont;
}
@@ -308,6 +309,19 @@ uchar *cRingBufferLinear::Get(int Count
return p;
}
+bool cRingBufferLinear::HasPesPacket(int Count)
+{
+ uchar *p = buffer + tail;
+ if (Count = 6 !p[0] !p[1] p[2] == 0x01) {
+ int Length = 6 + p[4] * 256 + p[5];
+ if (Length = Count) {
+Count = Length;
+return true;
+}
+ }
+ return false;
Re: [vdr] vdr-1.5.11 subtitling problems
El Sábado, 10 de Noviembre de 2007, Reinhard Nissl escribió: Hi, Reinhard Nissl schrieb: Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size). That sounds like the right thing to do. Can you suggest a patch for this? I hope to get something ready till tomorrow 12:00. See attachment. Tested in transfer mode with audio packets only (= radio), as there is no broadcast running which would provide subtitles. Bye. This patch fix problems with pvrinput radio an CRepacker. Thanks. Jose Alberto ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
On 11/06/07 20:57, Reinhard Nissl wrote: Hi, Rolf Ahrenberg schrieb: During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling. The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full. After some testing I'm afraid this only works for Transfer Mode, but not for live mode directly on the primary FF DVB card. In Transfer Mode the result buffer is likely to have 32KB available because it also contains video data. But in direct live mode it only holds subtitle data, which usually takes a while to amount to 32KB. And the result buffer, if set up with Margin=SUBTITLE_PACKS will only deliver data when it has at least 32KB available. Therefore the subtitles are displayed way to late (some 20 to 50 seconds, sometimes even more). I do see the problems Rolf has reported in Transfer Mode, and using SUBTITLE_PACKS for the repacker does help here. But we also need to make it work in direct live mode. One more thought: even in direct live mode the result buffer will only return data if it has at least IPACKS bytes available (assuming the change Reinhard suggested is not applied), which may mean that a small subtitle packet may sit any wait in the buffer until more data arrives and washes it out. This may explain why sometimes in live mode a subtitle line is displayed for a long time when no new text follows it. Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and we should return to IPACKS, and bite the bullet and introduce a repacker for subtitle data, as Reinhard already suggested... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi, Klaus Schmidinger schrieb: After some testing I'm afraid this only works for Transfer Mode, but not for live mode directly on the primary FF DVB card. In Transfer Mode the result buffer is likely to have 32KB available because it also contains video data. But in direct live mode it only holds subtitle data, which usually takes a while to amount to 32KB. And the result buffer, if set up with Margin=SUBTITLE_PACKS will only deliver data when it has at least 32KB available. Therefore the subtitles are displayed way to late (some 20 to 50 seconds, sometimes even more). I do see the problems Rolf has reported in Transfer Mode, and using SUBTITLE_PACKS for the repacker does help here. But we also need to make it work in direct live mode. One more thought: even in direct live mode the result buffer will only return data if it has at least IPACKS bytes available (assuming the change Reinhard suggested is not applied), which may mean that a small subtitle packet may sit any wait in the buffer until more data arrives and washes it out. This may explain why sometimes in live mode a subtitle line is displayed for a long time when no new text follows it. Well, I recall a personal email several months ago where I reported that the last packet in the result buffer cannot be retrieved for the above reason. This is not a matter for normal use, but I had this behavior in a program for testing repackers where the fed in data was shortened for each pass. Maybe introducing SUBTITLE_PACKS wasn't such a good idea after all, and we should return to IPACKS, and bite the bullet and introduce a repacker for subtitle data, as Reinhard already suggested... I had a look into the specs and there is no need for a repacker. The packets are already properly aligned. And splitting the packets into smaller pieces (some of about 20 - 30 bytes) wouldn't help in the above issue. A simple hacked solution might be to put an additional padding packet of size IPACKS into the result buffer whenever it contains less than IPACKS bytes of data. These padding packets (stream ID 0xBE) should be dropped by the recorder and by PlayPESPacket(). Though, a cleaner solution would be to fix the result buffer to allow retrieving any packet as soon as it is completely available in the buffer (final subtitle packets are about 100 bytes in size). Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi,
Reinhard Nissl schrieb:
Though, a cleaner solution would be to fix the result buffer to allow
retrieving any packet as soon as it is completely available in the
buffer (final subtitle packets are about 100 bytes in size).
That sounds like the right thing to do.
Can you suggest a patch for this?
I hope to get something ready till tomorrow 12:00.
See attachment. Tested in transfer mode with audio packets only (=
radio), as there is no broadcast running which would provide subtitles.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.11-orig/ringbuffer.h 2005-12-10 11:54:51.0 +0100
+++ ringbuffer.h 2007-11-10 21:05:47.0 +0100
@@ -60,12 +60,17 @@ private:
int gotten;
uchar *buffer;
char *description;
+ bool assumePesContent;
+ bool HasPesPacket(int Count);
public:
- cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL);
+ cRingBufferLinear(int Size, int Margin = 0, bool Statistics = false, const char *Description = NULL, bool AssumePesContent = false);
/// Creates a linear ring buffer.
/// The buffer will be able to hold at most Size-Margin-1 bytes of data, and will
/// be guaranteed to return at least Margin bytes in one consecutive block.
/// The optional Description is used for debugging only.
+/// AssumePesContent specializes the buffer and changes its behavior when less
+/// than Margin bytes are available. The buffer is then allowed to return at
+/// least a complete PES packet.
virtual ~cRingBufferLinear();
virtual int Available(void);
virtual int Free(void) { return Size() - Available() - 1 - margin; }
--- ../vdr-1.5.11-orig/ringbuffer.c 2006-06-16 11:32:13.0 +0200
+++ ringbuffer.c 2007-11-10 21:05:47.0 +0100
@@ -151,9 +151,10 @@ void cRingBufferLinear::PrintDebugRBL(vo
}
#endif
-cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description)
+cRingBufferLinear::cRingBufferLinear(int Size, int Margin, bool Statistics, const char *Description, bool AssumePesContent)
:cRingBuffer(Size, Statistics)
{
+ assumePesContent = AssumePesContent;
description = Description ? strdup(Description) : NULL;
tail = head = margin = Margin;
gotten = 0;
@@ -299,7 +300,7 @@ uchar *cRingBufferLinear::Get(int Count
int cont = (diff = 0) ? diff : Size() + diff - margin;
if (cont rest)
cont = rest;
- if (cont = margin) {
+ if (cont = margin || assumePesContent HasPesPacket(cont)) {
p = buffer + tail;
Count = gotten = cont;
}
@@ -308,6 +309,19 @@ uchar *cRingBufferLinear::Get(int Count
return p;
}
+bool cRingBufferLinear::HasPesPacket(int Count)
+{
+ uchar *p = buffer + tail;
+ if (Count = 6 !p[0] !p[1] p[2] == 0x01) {
+ int Length = 6 + p[4] * 256 + p[5];
+ if (Length = Count) {
+Count = Length;
+return true;
+}
+ }
+ return false;
+}
+
void cRingBufferLinear::Del(int Count)
{
if (Count gotten) {
--- ../vdr-1.5.11-orig/remux.c 2007-11-03 15:18:07.0 +0100
+++ remux.c 2007-11-10 21:05:47.0 +0100
@@ -1883,7 +1883,7 @@ cRemux::cRemux(int VPid, const int *APid
skipped = 0;
numTracks = 0;
resultSkipped = 0;
- resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result);
+ resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result, true);
resultBuffer-SetTimeouts(0, 100);
if (VPid)
#define TEST_cVideoRepacker
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
On 11/07/07 18:27, VDR User wrote: Can someone make a patch for this fix? --- remux.c 2007/11/03 14:18:07 1.60 +++ remux.c 2007/11/07 16:19:59 @@ -1883,7 +1883,7 @@ skipped = 0; numTracks = 0; resultSkipped = 0; - resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result); + resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, SUBTITLE_PACKS, false, Result); resultBuffer-SetTimeouts(0, 100); if (VPid) #define TEST_cVideoRepacker Thanks to Reinhard for finding this one. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Can someone make a patch for this fix? Thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Rolf Ahrenberg wrote: On Tue, 6 Nov 2007, Reinhard Nissl wrote: The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full. Thanks. I made the necessary modification and haven't noticed any freezes afterwards. I can confirm that. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi,
Klaus Schmidinger schrieb:
Thanks to Reinhard for finding this one.
And the attached patch should fix the incorrectly assembled subtitle PES
packets, which led to triggering pre 1.3.19 Dolby Digital compatibility
mode.
When TS packet's payload looked like that:
a) 00 00 01 bd 1d 7b 85 80 05
b) 27 cb cd b8 8b 20 00 0f ...
The bytes 85 80 and 05 were written to the PES packet as found was 9
after processing TS packet a) which was correct. But for the next TS
packet b), found was still 9 which caused writing the bytes 85 80 and 05
again to the PES packet.
So instead of writing
00 00 01 bd __ __ 85 80 05 27 cb cd b8 8b 20 01 00 00 20 00 0f ...
^^
the following was written:
00 00 01 bd __ __ 85 80 05 85 80 05 27 cb cd b8 8b 20 01 00 00 20 00 0f
^^
As a result PlayPES() didn't find the supported SubStreamId 20 but cd
which activated compatibility mode.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.10-orig/remux.c 2007-09-22 14:08:22.0 +0200
+++ remux.c 2007-11-07 22:25:17.0 +0100
@@ -1748,14 +2193,15 @@ void cTS2PES::instant_repack(const uint8
case AUDIO_STREAM_S ... AUDIO_STREAM_E:
case VIDEO_STREAM_S ... VIDEO_STREAM_E:
case PRIVATE_STREAM1:
-
-if (mpeg == 2 found == 9) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 2 found == 9 count found) {
write_ipack(flag1, 1);
write_ipack(flag2, 1);
write_ipack(hlength, 1);
}
-if (mpeg == 1 found == mpeg1_required) {
+/* make sure to not write the data twice by looking at count */
+if (mpeg == 1 found == mpeg1_required count found) {
write_ipack(flag1, 1);
if (mpeg1_required 7) {
write_ipack(flag2, 1);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi, Rolf Ahrenberg schrieb: During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling. The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
On Tue, 6 Nov 2007, Reinhard Nissl wrote: The problem for this issue is in cRemux::cRemux(): new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, Result); IPACKS needs to be replaced by SUBTITLE_PACKS too. Otherwise a packet larger than IPACKS (up to SUBTITLE_PACKS) cannot be read near the end of the buffer which holds reading the buffer and will finally let the buffer run full. Thanks. I made the necessary modification and haven't noticed any freezes afterwards. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi, Rolf Ahrenberg schrieb: I'm having heavy artifacts with the new vdr-1.5.11 in finnish DVB channels. The picture freezes now very often compared to previous VDR version (I reported about the same rare problem in vdr-1.5.10) and it seems that the problem is the new SUBTITLE_PACKS size. I reverted it back to 2048 and haven't noticed the problem after that. Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
On 11/5/07, Reinhard Nissl [EMAIL PROTECTED] wrote: Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents? I think what you're looking for can be found here: http://www.bjpace.com.cn/data/tec/tec-DVB/DVB%20BlueBooks%20Standards/Specifications%20and%20Standards/subtitling/dvb-sub/Ets300743_e1.pdf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.5.11 subtitling problems
Hi, VDR User schrieb: Thinking about a repacker for subtitles, can anyone provide me some links to documentation about the subtitle PES packet's contents? I think what you're looking for can be found here: http://www.bjpace.com.cn/data/tec/tec-DVB/DVB%20BlueBooks%20Standards/Specifications%20and%20Standards/subtitling/dvb-sub/Ets300743_e1.pdf Thanks for this information. ETS 300 743 V1.3.1 (2006-11) is available -- free of charge -- at www.etsi.org, too. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.5.11 subtitling problems
Hi, I'm having heavy artifacts with the new vdr-1.5.11 in finnish DVB channels. The picture freezes now very often compared to previous VDR version (I reported about the same rare problem in vdr-1.5.10) and it seems that the problem is the new SUBTITLE_PACKS size. I reverted it back to 2048 and haven't noticed the problem after that. During the freeze VDR's transfer buffer gets full and VDR is clearing transfer buffer to avoid overflows. This happens only on channels with DVB subtitling. I'm using 4MB FF card as a primary device, if that makes any difference. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
