Hi,
I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch).
Besides that, a major change has been made in error reporting. Previous versions often reported a buffer overflow (although there was no buffer overflow) just as an indication for not beeing able to handle the data. Most likely this lead to the assumption that the repacker got stuck.
VDR-1.3.28 will also (most likely) receive the second attached patch "vdr-1.3.27-dvbplayer-sequence-end-code.patch". It will cause a still image to be immediately shown by (softdevices like) vdr-xine, e. g. when moving or jumping to cutting marks. Does this patch have any bad impact on FF-devices?
As old recordings (prior to VDR-1.3.26 or 1.3.27 with cVideoRepacker disabled) can have fragmented frames and VDR doesn't handle them correctly when passing still images to a device, it is hardly possible to edit cutting marks (at least) in vdr-xine for such recordings.
The patch http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patch is a hack to at least fix the I-frames needed for fast forward, fast rewind, slow rewind and editing cutting marks. As you may see, it collides with the attached dvbplayer patch, so you have to decide whether to use the attached one and just edit new recordings or to use the one taken at version 1.3.24 and be able to edit new and old -- but only MPEG2 -- recordings.
Bye.
Hi Reinhard.
Tried the new repacker, but it was not successful : Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:20 media vdr[4970]: ERROR: 1 ring buffer overflow (65 bytes dropped) Jul 18 08:42:26 media vdr[4970]: ERROR: 10022 ring buffer overflows (1884136 bytes dropped) Jul 18 08:42:32 media vdr[4970]: ERROR: 9840 ring buffer overflows (1849920 bytes dropped) Jul 18 08:42:35 media vdr[4968]: ERROR: video data stream broken Jul 18 08:42:35 media vdr[4968]: initiating emergency exit Jul 18 08:42:35 media vdr[4555]: emergency exit requested - shutting down
----- Original Message ----- From: "Reinhard Nissl" rnissl@gmx.de To: "Klaus Schmidinger's VDR" vdr@linuxtv.org Sent: Sunday, July 17, 2005 11:17 AM Subject: [vdr] VDR-1.3.27: updated cVideoRepacker
Hi,
I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch).
Besides that, a major change has been made in error reporting. Previous versions often reported a buffer overflow (although there was no buffer overflow) just as an indication for not beeing able to handle the data. Most likely this lead to the assumption that the repacker got stuck.
VDR-1.3.28 will also (most likely) receive the second attached patch "vdr-1.3.27-dvbplayer-sequence-end-code.patch". It will cause a still image to be immediately shown by (softdevices like) vdr-xine, e. g. when moving or jumping to cutting marks. Does this patch have any bad impact on FF-devices?
As old recordings (prior to VDR-1.3.26 or 1.3.27 with cVideoRepacker disabled) can have fragmented frames and VDR doesn't handle them correctly when passing still images to a device, it is hardly possible to edit cutting marks (at least) in vdr-xine for such recordings.
The patch http://home.vr-web.de/~rnissl/vdr-1.3.24-dvbplayer.patch is a hack to at least fix the I-frames needed for fast forward, fast rewind, slow rewind and editing cutting marks. As you may see, it collides with the attached dvbplayer patch, so you have to decide whether to use the attached one and just edit new recordings or to use the one taken at version 1.3.24 and be able to edit new and old -- but only MPEG2 -- recordings.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
--------------------------------------------------------------------------------
--- vdr-1.3.27-orig/remux.c 2005-06-19 12:17:00.000000000 +0200 +++ vdr-1.3.27/remux.c 2005-07-16 20:54:47.499277234 +0200 @@ -26,17 +26,92 @@ class cRepacker { protected: int maxPacketSize; uint8_t subStreamId;
- static void DroppedData(const char *Reason, int Count) { esyslog("%s
(dropped %d bytes)", Reason, Count); }
- static int Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int
Count)
- {
- int n = ResultBuffer->Put(Data, Count);
- if (n != Count)
esyslog("ERROR: result buffer overflow, dropped %d out of %dbyte", Count - n, Count);
- return n;
- }
- static int AnalyzePesHeader(const uchar *Data, int Count, int
&PesPayloadOffset, bool *ContinueationHeader = 0); public: cRepacker(void) { maxPacketSize = 6 + 65535; subStreamId = 0; } virtual ~cRepacker() {} virtual void Reset(void) {}
- virtual int Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int
Count) = 0;
- virtual void Repack(cRingBufferLinear *ResultBuffer, const uchar *Data,
int Count) = 0; virtual int BreakAt(const uchar *Data, int Count) = 0; virtual int QuerySnoopSize(void) { return 0; } void SetMaxPacketSize(int MaxPacketSize) { maxPacketSize = MaxPacketSize; } void SetSubStreamId(uint8_t SubStreamId) { subStreamId = SubStreamId; } };
+int cRepacker::AnalyzePesHeader(const uchar *Data, int Count, int &PesPayloadOffset, bool *ContinueationHeader) +{
- if (Count < 7)
return -1; // too short- if ((Data[6] & 0xC0) == 0x80) { // MPEG 2
if (Count < 9)return -1; // too shortPesPayloadOffset = 6 + 3 + Data[8];if (Count < PesPayloadOffset)return -1; // too shortif (ContinueationHeader)*ContinueationHeader = ((Data[6] == 0x80) && !Data[7] &&!Data[8]);
return 2; // MPEG 2}- // check for MPEG 1 ...
- PesPayloadOffset = 6;
- // skip up to 16 stuffing bytes
- for (int i = 0; i < 16; i++) {
if (Data[PesPayloadOffset] != 0xFF)break;if (Count <= ++PesPayloadOffset)return -1; // too short}- // skip STD_buffer_scale/size
- if ((Data[PesPayloadOffset] & 0xC0) == 0x40) {
PesPayloadOffset += 2;if (Count <= PesPayloadOffset)return -1; // too short}- if (ContinueationHeader)
*ContinueationHeader = false;- if ((Data[PesPayloadOffset] & 0xF0) == 0x20) {
// skip PTS onlyPesPayloadOffset += 5;}- else if ((Data[PesPayloadOffset] & 0xF0) == 0x30) {
// skip PTS and DTSPesPayloadOffset += 10;}- else if (Data[PesPayloadOffset] == 0x0F) {
// continueation headerPesPayloadOffset++;if (ContinueationHeader)*ContinueationHeader = true;}- else
return 0; // unknown- if (Count < PesPayloadOffset)
return -1; // too short- return 1; // MPEG 1
+}
// --- cVideoRepacker --------------------------------------------------------
class cVideoRepacker : public cRepacker { @@ -61,7 +136,7 @@ private: public: cVideoRepacker(void); virtual void Reset(void);
- virtual int Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int
Count);
- virtual void Repack(cRingBufferLinear *ResultBuffer, const uchar *Data,
int Count); virtual int BreakAt(const uchar *Data, int Count); virtual int QuerySnoopSize() { return 4; } }; @@ -95,7 +170,7 @@ bool cVideoRepacker::PushOutPacket(cRing // to strip off any partially contained start code. int Bite = fragmentLen + (Count >= 0 ? 0 : Count); // put data into result buffer
int n = ResultBuffer->Put(fragmentData, Bite);
int n = Put(ResultBuffer, fragmentData, Bite);@@ -110,7 +185,7 @@ bool cVideoRepacker::PushOutPacket(cRing // to strip off any partially contained start code. int Bite = pesHeaderLen + (Count >= 0 ? 0 : Count); // put data into result buffer
int n = ResultBuffer->Put(pesHeader, Bite);
int n = Put(ResultBuffer, pesHeader, Bite);@@ -122,7 +197,7 @@ bool cVideoRepacker::PushOutPacket(cRing // amount of data to put into result buffer int Bite = Count; // put data into result buffer
int n = ResultBuffer->Put(Data, Bite);
int n = Put(ResultBuffer, Data, Bite);@@ -132,23 +207,29 @@ bool cVideoRepacker::PushOutPacket(cRing return true; }
-int cVideoRepacker::Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int Count) +void cVideoRepacker::Repack(cRingBufferLinear *ResultBuffer, const uchar *Data, int Count) {
- // synchronisation is detected some bytes after frame start.
- const int SkippedBytesLimit = 4;
- // reset local scanner localStart = -1;
// check for MPEG 2
if ((Data[6] & 0xC0) != 0x80)
return 0;// backup PES header
if (Data[6] != 0x80 || Data[7] != 0x00 || Data[8] != 0x00) {
pesHeaderBackupLen = 6 + 3 + Data[8];memcpy(pesHeaderBackup, Data, pesHeaderBackupLen);
- int pesPayloadOffset = 0;
- bool continueationHeader = false;
- int mpegLevel = AnalyzePesHeader(Data, Count, pesPayloadOffset,
&continueationHeader);
- if (mpegLevel <= 0) {
DroppedData("cVideoRepacker: no valid PES packet header found",Count);
return;}
if (!continueationHeader) {
// backup PES header
pesHeaderBackupLen = pesPayloadOffset;
memcpy(pesHeaderBackup, Data, pesHeaderBackupLen);
}
// skip PES header
- int done = 6 + 3 + Data[8];
- int done = pesPayloadOffset; int todo = Count - done; const uchar *data = Data + done; // remember start of the data
@@ -191,15 +272,17 @@ int cVideoRepacker::Put(cRingBufferLinea // the byte count get's negative then the current buffer ends in a // partitial start code that must be stripped off, as it shall be put // in the next packet.
if (!PushOutPacket(ResultBuffer, payload, data - 3 -payload))
return done - 3;
if (!PushOutPacket(ResultBuffer, payload, data - 3 -payload)) {
DroppedData("cVideoRepacker: result bufferoverflow", Count - (done - 3));
return;} // go on with syncing to the next picture state = syncing; } if (state == syncing) { // report that syncing dropped some bytes
if (skippedBytes > 4)esyslog("cVideoRepacker: skipped %d bytes to syncon next picture", skippedBytes - 4);
if (skippedBytes > SkippedBytesLimit)esyslog("cVideoRepacker: skipped %d bytes to syncon next picture", skippedBytes - SkippedBytesLimit); skippedBytes = 0; // if there is a PES header available, then use it ... if (pesHeaderBackupLen > 0) { @@ -222,9 +305,14 @@ int cVideoRepacker::Put(cRingBufferLinea pesHeader[pesHeaderLen++] = Data[3]; // video stream ID pesHeader[pesHeaderLen++] = 0x00; // length still unknown pesHeader[pesHeaderLen++] = 0x00; // length still unknown
pesHeader[pesHeaderLen++] = 0x80;pesHeader[pesHeaderLen++] = 0x00;pesHeader[pesHeaderLen++] = 0x00;
if (mpegLevel == 2) {pesHeader[pesHeaderLen++] = 0x80;pesHeader[pesHeaderLen++] = 0x00;pesHeader[pesHeaderLen++] = 0x00;}elsepesHeader[pesHeaderLen++] = 0x0F; } // append the first three bytes of the start code pesHeader[pesHeaderLen++] = 0x00;@@ -299,8 +387,10 @@ int cVideoRepacker::Put(cRingBufferLinea const uchar *excessData = fragmentData + fragmentLen + bite; // a negative byte count means to drop some bytes from the current // fragment's tail, to not exceed the maximum packet size.
if (!PushOutPacket(ResultBuffer, payload, bite))return done;
if (!PushOutPacket(ResultBuffer, payload, bite)) {DroppedData("cVideoRepacker: result buffer overflow",Count - done);
return;} // create a continuation PES header pesHeaderLen = 0; pesHeader[pesHeaderLen++] = 0x00;@@ -309,9 +399,15 @@ int cVideoRepacker::Put(cRingBufferLinea pesHeader[pesHeaderLen++] = Data[3]; // video stream ID pesHeader[pesHeaderLen++] = 0x00; // length still unknown pesHeader[pesHeaderLen++] = 0x00; // length still unknown
pesHeader[pesHeaderLen++] = 0x80;pesHeader[pesHeaderLen++] = 0x00;pesHeader[pesHeaderLen++] = 0x00;
if (mpegLevel == 2) {pesHeader[pesHeaderLen++] = 0x80;pesHeader[pesHeaderLen++] = 0x00;pesHeader[pesHeaderLen++] = 0x00;}elsepesHeader[pesHeaderLen++] = 0x0F;// copy any excess data while (bite++ < 0) { // append the excess data here@@ -344,22 +440,20 @@ int cVideoRepacker::Put(cRingBufferLinea fragmentLen += bite; } }
- // we've eaten the whole packet ;-)
- return Count;
- // report that syncing dropped some bytes
- if (skippedBytes > SkippedBytesLimit) {
esyslog("cVideoRepacker: skipped %d bytes while syncing on nextpicture", skippedBytes - SkippedBytesLimit);
skippedBytes = SkippedBytesLimit;}}
int cVideoRepacker::BreakAt(const uchar *Data, int Count) {
- // enough data for test?
- if (Count < 6 + 3)
return -1;- // check for MPEG 2
- if ((Data[6] & 0xC0) != 0x80)
return -1;- int headerLen = Data[8] + 6 + 3;
- // enough data for test?
- if (Count < headerLen)
return -1;
- int PesPayloadOffset = 0;
- if (AnalyzePesHeader(Data, Count, PesPayloadOffset) <= 0)
return -1; // not enough data for test- // just detect end of picture if (state == scanPicture) { // setup local scanner
@@ -368,7 +462,7 @@ int cVideoRepacker::BreakAt(const uchar localStart = 0; } // start where we've stopped at the last run
const uchar *data = Data + headerLen + localStart;
const uchar *data = Data + PesPayloadOffset + localStart;@@ -386,7 +480,7 @@ int cVideoRepacker::BreakAt(const uchar } } // just fill up packet and append next start code
- return headerLen + packetTodo + 4;
- return PesPayloadOffset + packetTodo + 4;
}
// --- cDolbyRepacker -------------------------------------------------------- @@ -412,6 +506,7 @@ private: get_length, output_packet } state;
- int skippedBytes; void ResetPesHeader(bool ContinuationFrame = false); void AppendSubStreamID(bool ContinuationFrame = false); bool FinishRemainder(cRingBufferLinear *ResultBuffer, const uchar *const
Data, const int Todo, int &Done, int &Bite); @@ -419,7 +514,7 @@ private: public: cDolbyRepacker(void); virtual void Reset(void);
- virtual int Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int
Count);
- virtual void Repack(cRingBufferLinear *ResultBuffer, const uchar *Data,
int Count); virtual int BreakAt(const uchar *Data, int Count); };
@@ -490,6 +585,7 @@ void cDolbyRepacker::Reset(void) fragmentLen = 0; fragmentTodo = 0; pesHeaderBackupLen = 0;
- skippedBytes = 0;
}
bool cDolbyRepacker::FinishRemainder(cRingBufferLinear *ResultBuffer, const uchar *const Data, const int Todo, int &Done, int &Bite) @@ -499,7 +595,7 @@ bool cDolbyRepacker::FinishRemainder(cRi // output a previous fragment first if (fragmentLen > 0) { Bite = fragmentLen;
int n = ResultBuffer->Put(fragmentData, Bite);
int n = Put(ResultBuffer, fragmentData, Bite); if (Bite != n) { Reset(); return false;@@ -507,7 +603,7 @@ bool cDolbyRepacker::FinishRemainder(cRi fragmentLen = 0; } Bite = fragmentTodo;
int n = ResultBuffer->Put(Data, Bite);
int n = Put(ResultBuffer, Data, Bite);@@ -543,13 +639,13 @@ bool cDolbyRepacker::StartNewPacket(cRin Bite = pesHeaderLen; // enough data available to put PES packet into buffer? if (packetLen - pesHeaderLen <= Todo) {
int n = ResultBuffer->Put(pesHeader, Bite);
int n = Put(ResultBuffer, pesHeader, Bite);
n = ResultBuffer->Put(Data, Bite);
n = Put(ResultBuffer, Data, Bite);@@ -582,11 +678,16 @@ bool cDolbyRepacker::StartNewPacket(cRin return true; }
-int cDolbyRepacker::Put(cRingBufferLinear *ResultBuffer, const uchar *Data, int Count) +void cDolbyRepacker::Repack(cRingBufferLinear *ResultBuffer, const uchar *Data, int Count) {
- // synchronisation is detected some bytes after frame start.
- const int SkippedBytesLimit = 4;
- // check for MPEG 2
- if ((Data[6] & 0xC0) != 0x80)
return 0;
if ((Data[6] & 0xC0) != 0x80) {
DroppedData("cDolbyRepacker: MPEG 2 PES header expected", Count);return;}// backup PES header if (Data[6] != 0x80 || Data[7] != 0x00 || Data[8] != 0x00) {
@@ -616,6 +717,7 @@ int cDolbyRepacker::Put(cRingBufferLinea data++; done++; todo--;
skippedBytes++; // collect number of skipped bytes whilesyncing continue; case find_77: if (*data != 0x77) { @@ -625,18 +727,21 @@ int cDolbyRepacker::Put(cRingBufferLinea data++; done++; todo--;
skippedBytes++; // collect number of skipped bytes whilesyncing ++(int &)state; continue; case store_chk1: chk1 = *data++; done++; todo--;
skippedBytes++; // collect number of skipped bytes whilesyncing ++(int &)state; continue; case store_chk2: chk2 = *data++; done++; todo--;
skippedBytes++; // collect number of skipped bytes whilesyncing ++(int &)state; continue; case get_length: @@ -664,6 +769,10 @@ int cDolbyRepacker::Put(cRingBufferLinea state = find_0b; continue; }
// report that syncing dropped some bytesif (skippedBytes > SkippedBytesLimit)esyslog("cDolbyRepacker: skipped %d bytes to sync onnext AC3 frame", skippedBytes - SkippedBytesLimit);
skippedBytes = 0; // append read data to header for common output processing pesHeader[pesHeaderLen++] = 0x0B; pesHeader[pesHeaderLen++] = 0x77;@@ -676,13 +785,17 @@ int cDolbyRepacker::Put(cRingBufferLinea int bite = 0; // finish remainder of ac3 frame? if (fragmentTodo > 0) {
if (!FinishRemainder(ResultBuffer, data, todo, done,bite))
return done;
if (!FinishRemainder(ResultBuffer, data, todo, done,bite)) {
DroppedData("cDolbyRepacker: result bufferoverflow", Count - done);
return;} } else { // start a new packet
if (!StartNewPacket(ResultBuffer, data, todo, done,bite))
return done;
if (!StartNewPacket(ResultBuffer, data, todo, done,bite)) {
DroppedData("cDolbyRepacker: result bufferoverflow", Count - done);
return;} // prepare for next (continuation) packet ResetPesHeader(state == output_packet); }@@ -693,7 +806,11 @@ int cDolbyRepacker::Put(cRingBufferLinea } } }
- return Count;
- // report that syncing dropped some bytes
- if (skippedBytes > SkippedBytesLimit) {
esyslog("cDolbyRepacker: skipped %d bytes while syncing on next AC3frame", skippedBytes - 4);
skippedBytes = SkippedBytesLimit;}}
int cDolbyRepacker::BreakAt(const uchar *Data, int Count) @@ -845,9 +962,13 @@ void cTS2PES::Clear(void)
void cTS2PES::store(uint8_t *Data, int Count) {
- int n = repacker ? repacker->Put(resultBuffer, Data, Count) :
resultBuffer->Put(Data, Count);
- if (n != Count)
esyslog("ERROR: result buffer overflow, dropped %d out of %d byte",Count - n, Count);
- if (repacker)
repacker->Repack(resultBuffer, Data, Count);- else {
int n = resultBuffer->Put(Data, Count);if (n != Count)esyslog("ERROR: result buffer overflow, dropped %d out of %dbyte", Count - n, Count);
}}
void cTS2PES::reset_ipack(void) @@ -867,7 +988,7 @@ void cTS2PES::reset_ipack(void)
void cTS2PES::send_ipack(void) {
- if (count < 10)
- if (count <= ((mpeg == 2) ? 9 : 7)) // skip empty packets return; buf[3] = (AUDIO_STREAM_S <= cid && cid <= AUDIO_STREAM_E && audioCid) ?
audioCid : cid; buf[4] = (uint8_t)(((count - 6) & 0xFF00) >> 8); @@ -1155,7 +1276,7 @@ cRemux::cRemux(int VPid, const int *APid resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result"); resultBuffer->SetTimeouts(0, 100); if (VPid) -//#define TEST_cVideoRepacker +#define TEST_cVideoRepacker #ifdef TEST_cVideoRepacker ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0x00, 0x00, new cVideoRepacker); #else
--------------------------------------------------------------------------------
--- ../vdr-1.3.27-orig/dvbplayer.c 2005-05-22 13:26:51.000000000 +0200 +++ dvbplayer.c 2005-07-16 22:57:43.000000000 +0200 @@ -666,11 +666,34 @@ void cDvbPlayer::Goto(int Index, bool St int FileOffset, Length; Index = index->GetNextIFrame(Index, false, &FileNumber, &FileOffset, &Length); if (Index >= 0 && NextFile(FileNumber, FileOffset) && Still) {
uchar b[MAXFRAMESIZE];
uchar b[MAXFRAMESIZE + 4 + 5 + 4]; int r = ReadFrame(replayFile, b, Length, sizeof(b)); if (r > 0) { if (playMode == pmPause) DevicePlay();// append sequence end code to get the image shown immediatelywith softdevices
if (r > 6) { // should be always trueb[r++] = 0x00;b[r++] = 0x00;b[r++] = 0x01;b[r++] = b[3];if (b[6] & 0x80) { // MPEG 2b[r++] = 0x00;b[r++] = 0x07;b[r++] = 0x80;b[r++] = 0x00;b[r++] = 0x00;}else { // MPEG 1b[r++] = 0x00;b[r++] = 0x05;b[r++] = 0x0F;}b[r++] = 0x00;b[r++] = 0x00;b[r++] = 0x01;b[r++] = 0xB7;} DeviceStillPicture(b, r); } playMode = pmStill;
--------------------------------------------------------------------------------
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--------------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/49 - Release Date: 16/07/2005
Hi,
Simon Baxter wrote:
Tried the new repacker, but it was not successful :
Thanks for the report. Please specify some additional information:
There are several threads involved (4972, 4969, 4970, 4968). Please send the lines too, where these threads were created, respectively include them in the next report.
Which kind of DVB hardware do you use: S, C or T?
Is it related to a single channel?
How long does it take from switching to the channel until VDR restarts?
Does it just happen for recordings (see below)?
Are you using a FF card or a softdevice solution like vdr-xine?
It might be possible, that at 08:42:04 the cVideoRepacker was resyncing, e. g. due to some garbage that is comming in after switching the channel.
Strange is that there are two threads (4972 and 4969) that are feeding cVideoRepacker. Should there be a racecondition that spawns two threads for this job somewhere else in VDR?
Or are these two theads driving two instances of cVideoRepacker with the same data as both threads report the same messages and sync in 08:42:04?
Please tell us the versions of kernel and dvb-driver. Is NPTL enabled or disabled?
Are you using other plugins that might attach a further receiver (osd-teletext triggered some threading issues some time ago)?
Thread 4968 seems to be a recorder. It considers the data stream to be broken as it hasn't seen any data for MAXBROKENTIMEOUT (= 30 seconds), i. e. since cVideoRepacker got synced. Please add two log messages to cRepacker::Put() so that we can see how cVideoRepacker delivers data after 08:42:04. Maybe a further log message at the beginning and end of cVideoRepacker::Repack() would be useful too, to see whether cVideoRepacker gets stuck.
static int Put(.....) { esyslog(">>>>> cRepacker::Put"); // <============
int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....);
esyslog("<<<<< cRepacker::Put"); // <============
return n; }
void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack()"); // <============
// synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4;
// reset local scanner localStart = -1;
. . .
// report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; }
esyslog("<<<<< cVideoRepacker::Repack()"); // <============ }
Thanks in advance for your help!
Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:20 media vdr[4970]: ERROR: 1 ring buffer overflow (65 bytes dropped) Jul 18 08:42:26 media vdr[4970]: ERROR: 10022 ring buffer overflows (1884136 bytes dropped) Jul 18 08:42:32 media vdr[4970]: ERROR: 9840 ring buffer overflows (1849920 bytes dropped) Jul 18 08:42:35 media vdr[4968]: ERROR: video data stream broken Jul 18 08:42:35 media vdr[4968]: initiating emergency exit Jul 18 08:42:35 media vdr[4555]: emergency exit requested - shutting down
Bye.
Simon Baxter wrote:
Tried the new repacker, but it was not successful :
Thanks for the report. Please specify some additional information:
There are several threads involved (4972, 4969, 4970, 4968). Please send the lines too, where these threads were created, respectively include them in the next report.
attached
Which kind of DVB hardware do you use: S, C or T?
Wintv Nova-T
Is it related to a single channel?
has only happened once - will test further
How long does it take from switching to the channel until VDR restarts?
has only happened once, and it happened 7 mins after switching - will test further
Does it just happen for recordings (see below)?
so far, yes
Are you using a FF card or a softdevice solution like vdr-xine?
yes, vdr-xine
It might be possible, that at 08:42:04 the cVideoRepacker was resyncing, e. g. due to some garbage that is comming in after switching the channel.
Strange is that there are two threads (4972 and 4969) that are feeding cVideoRepacker. Should there be a racecondition that spawns two threads for this job somewhere else in VDR?
sorry couldn't tell you ):
Or are these two theads driving two instances of cVideoRepacker with the same data as both threads report the same messages and sync in 08:42:04?
Please tell us the versions of kernel and dvb-driver. Is NPTL enabled or disabled?
2.6.11.8 and video4linux-20050625-194702 nptl is NOT being used
Are you using other plugins that might attach a further receiver (osd-teletext triggered some threading issues some time ago)?
-P'xine -q -r -s' -P'skincurses' -P'remote -i /dev/input/event2' -P'sysinfo' -P'mplayer' -P'dvd' -P'femon' -P'clock'
Thread 4968 seems to be a recorder. It considers the data stream to be broken as it hasn't seen any data for MAXBROKENTIMEOUT (= 30 seconds), i. e. since cVideoRepacker got synced. Please add two log messages to cRepacker::Put() so that we can see how cVideoRepacker delivers data after 08:42:04. Maybe a further log message at the beginning and end of cVideoRepacker::Repack() would be useful too, to see whether cVideoRepacker gets stuck.
happy to help, but you'll need to help me out here. What should I be adding to where?
static int Put(.....) { esyslog(">>>>> cRepacker::Put"); // <============
int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....); esyslog("<<<<< cRepacker::Put"); // <============ return n;}
void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack()"); // <============
// synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4;
// reset local scanner localStart = -1;
. . .
// report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; }
esyslog("<<<<< cVideoRepacker::Repack()"); // <============ }
Thanks in advance for your help!
Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4972]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1545 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 493 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Jul 18 08:42:04 media last message repeated 5 times Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 1398 bytes while syncing on next picture Jul 18 08:42:04 media vdr[4969]: cVideoRepacker: skipped 4 bytes to sync on next picture Jul 18 08:42:20 media vdr[4970]: ERROR: 1 ring buffer overflow (65 bytes dropped) Jul 18 08:42:26 media vdr[4970]: ERROR: 10022 ring buffer overflows (1884136 bytes dropped) Jul 18 08:42:32 media vdr[4970]: ERROR: 9840 ring buffer overflows (1849920 bytes dropped) Jul 18 08:42:35 media vdr[4968]: ERROR: video data stream broken Jul 18 08:42:35 media vdr[4968]: initiating emergency exit Jul 18 08:42:35 media vdr[4555]: emergency exit requested - shutting down
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.0/49 - Release Date: 16/07/2005
begin 666 Reinhard.txt M2G5L(#$X(# X.C(Q.C4U(&UE9&EA('9D<ELT-S8X73H@8VAA;FYE;" R,R H M8FED('1V*2!E=F5N=" P.#HP," G0FED(&9O<B!A($)A<F=A:6X@3&EV92<@ M<W1A='5S(#0-"DIU;" Q." P.#HR,3HU-B!M961I82!V9');-#4U-5TZ('1I M;65R(#$@*#$@,3$Q,"TQ,C4P("=*=61G92!*=61Y?DIU9&=E($IU9'DG*2!S M970@=&@979E;G0@36]N(#$X+C W+C(P#0HP-2 Q,3HS,"TQ,CHQ-2 G0V%R M($)O;W1Y)PT*2G5L(#$X(# X.C(Q.C4V(&UE9&EA('9D<ELT-34U73H@=&EM M97(@,B H-" P.#(U+3 Y,# @)T5V97)Y8F]D>2!,;W9E<R!287EM;VYD)RD@ M<V5T('1O(&5V96YT($UO;B Q."XP-RX-"C(P,#4@,#@Z,S M,#@Z-34@)T5V M97)Y8F]D>2!,;W9E<R!287EM;VYD)PT*2G5L(#$X(# X.C(Q.C4Y(&UE9&EA M(&=D;2UA=71O;&]G:6XH<&%M7W5N:7@I6S0W,#-=.B!S97-S:6]N(&]P96YE M9"!F;W(@=7-E<B!V9')U<V5R(&)Y("AU:60],"D-"DIU;" Q." P.#HR,CHP M,"!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ('-T87)T:6YG("AV97)S M:6]N(#(N."XQ*2P@<&ED(#0X-#@@=7-E<B G=F1R=7-E<B<-"DIU;" Q." P M.#HR,CHP,"!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ(%)E<V]L=F5D M(&%D9')E<W,@(GAM;#IR96%D;VYL>3HO971C+V=C;VYF+V=C;VYF+GAM;"YM M86YD871O#0IR>2(@=&@82!R96%D+6]N;'D@8V]N9FEG=7)A=&EO;B!S;W5R M8V4@870@<&]S:71I;VX@, T*2G5L(#$X(# X.C(R.C P(&UE9&EA(&=C;VYF M9" H=F1R=7-E<BTT.#0X*3H@4F5S;VQV960@861D<F5S<R B>&UL.G)E861W M<FET93HO:&]M92]V9')U<V5R+RYG8V]N9B(@=&@80T*=W)I=&%B;&4@8V]N M9FEG=7)A=&EO;B!S;W5R8V4@870@<&]S:71I;VX@,0T*2G5L(#$X(# X.C(R M.C P(&UE9&EA(&=C;VYF9" H=F1R=7-E<BTT.#0X*3H@4F5S;VQV960@861D M<F5S<R B>&UL.G)E861O;FQY.B]E=&,O9V-O;F8O9V-O;F8N>&UL+F1E9F%U M;'0-"G,B('1O(&$@<F5A9"UO;FQY(&-O;F9I9W5R871I;VX@<V]U<F-E(&%T M('!O<VET:6]N(#(-"DIU;" Q." P.#HR,CHP,B!M961I82!K97)N96PZ(&-X M.#A?=V%K975P.B T(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I#0I* M=6P@,3@@,#@Z,C(Z,#8@;65D:6$@;&%S="!M97-S86=E(')E<&5A=&5D(#(@ M=&EM97,-"DIU;" Q." P.#HR,CHP-B!M961I82!K97)N96PZ(%5$1BUF<R!) M3D9/(%5$1B P+CDN."XQ("@R,# T+S(Y+S Y*2!-;W5N=&EN9R!V;VQU;64@ M)U-53%1!3E-?3T9?4U=)3D<G+"!T#0II;65S=&%M<" Q.3DY+S T+S U(# T M.C(Y("@Q,#-C*0T*2G5L(#$X(# X.C(R.C Y(&UE9&EA(&ME<FYE;#H@8W@X M.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD;&5D("AS:&]U;&0@8F4@,2D-"DIU M;" Q." P.#HR,CHQ,2!M961I82!G8V]N9F0@*'9D<G5S97(M-#@T."DZ(%)E M<V]L=F5D(&%D9')E<W,@(GAM;#IR96%D=W)I=&4Z+VAO;64O=F1R=7-E<B\N M9V-O;F8B('1O(&$-"G=R:71A8FQE(&-O;F9I9W5R871I;VX@<V]U<F-E(&%T M('!O<VET:6]N(# -"DIU;" Q." P.#HR,CHQ,2!M961I82!K97)N96PZ(&-X M.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I#0I* M=6P@,3@@,#@Z,C(Z,3,@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C$S M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#0@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ-"!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C(Z,30@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@ M,R!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R M.C$T(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD M;&5D("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ-2!M961I82!K97)N M96PZ(&-X.#A?=V%K975P.B V(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E M(#$I#0I*=6P@,3@@,#@Z,C(Z,3<@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U M<#H@,B!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X M.C(R.C$X(&UE9&EA(&QA<W0@;65S<V%G92!R97!E871E9" S('1I;65S#0I* M=6P@,3@@,#@Z,C(Z,3@@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C$Y M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#(@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHQ.2!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B R(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C(Z,C @;65D:6$@=F1R6S0W-S%=.B!L;V%D:6YG("]V M:61E;R]V9'(M,2XS+C(W+W1H96UE<R]S='1N9RUD969A=6QT+G1H96UE#0I* M=6P@,3@@,#@Z,C(Z,C(@;65D:6$@:V5R;F5L.B!C>#@X7W=A:V5U<#H@,R!B M=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L(#$X(# X.C(R.C(R M(&UE9&EA(&ME<FYE;#H@8W@X.%]W86ME=7 Z(#0@8G5F9F5R<R!H86YD;&5D M("AS:&]U;&0@8F4@,2D-"DIU;" Q." P.#HR,CHR,R!M961I82!K97)N96PZ M(&-X.#A?=V%K975P.B U(&)U9F9E<G,@:&%N9&QE9" H<VAO=6QD(&)E(#$I M#0I*=6P@,3@@,#@Z,C0Z-3(@;65D:6$@;G1P9%LS-C S73H@<WEN8VAR;VYI M>F5D('1O($Q/0T%,*# I+"!S=')A='5M(#$P#0I*=6P@,3@@,#@Z,C0Z-3(@ M;65D:6$@;G1P9%LS-C S73H@:V5R;F5L('1I;64@<WEN8R!D:7-A8FQE9" P M,#0Q#0I*=6P@,3@@,#@Z,C4Z,# @;65D:6$@=F1R6S0U-35=.B!T:6UE<B R M("@T(# X,C4M,#DP," G179E<GEB;V1Y($QO=F5S(%)A>6UO;F0G*2!S=&%R M= T*2G5L(#$X(# X.C(U.C P(&UE9&EA('9D<ELT-34U73H@<F5C;W)D("]V M:61E;R]V9'(M,2XS+C(W+T5V97)Y8F]D>5],;W9E<U]287EM;VYD+S(P,#4M M,#<M,3@N,#@Z,C4N.3DN.3D-"BYR96,-"DIU;" Q." P.#HR-3HP,B!M961I M82!V9');-#<V.%TZ(&-H86YN96P@-R H2516,RD@979E;G0@,#@Z,#4@)U%U M:6YC>2<@<W1A='5S(#0-"DIU;" Q." P.#HR-3HP,B!M961I82!V9');-#<V M.%TZ(&-H86YN96P@,3,@*$E45B!.97=S*2!E=F5N=" P.#HP," G2516($YE M=W,G('-T871U<R T#0I*=6P@,3@@,#@Z,C4Z,#(@;65D:6$@=F1R6S0W-CA= M.B!C:&%N;F5L(#,@*$E45C$I(&5V96YT(# W.C P("='3516(%1/1$%9)R!S M=&%T=7,@- T*2G5L(#$X(# X.C(U.C S(&UE9&EA('9D<ELT-S8X73H@8VAA M;FYE;" T("A#:&%N;F5L(#0I(&5V96YT(# W.C,P("=":6<@0G)O=&AE<B<@ M<W1A='5S(#0-"DIU;" Q." P.#HR-3HP,R!M961I82!V9');-#4U-5TZ('-W M:71C:&EN9R!T;R!C:&%N;F5L(#4-"DIU;" Q." P.#HR-3HP,R!M961I82!V M9');-#4U-5TZ(&EN9F\Z($-H86YN96P@;F]T(&%V86EL86)L92$-"DIU;" Q M." P.#HR-3HP,R!M961I82!V9');-#<V.%TZ(&-H86YN96P@." H130I(&5V M96YT(# V.C P("=":6<@0G)O=&AE<B!,:79E)R!S=&%T=7,@- T*2G5L(#$X M(# X.C(U.C T(&UE9&EA('9D<ELT-S8X73H@8VAA;FYE;" V("A)5%8R*2!E M=F5N=" P-CHP," G1TU45C(G('-T871U<R T#0I*=6P@,3@@,#@Z,C4Z,#D@ M;65D:6$@=F1R6S0U-35=.B!S=VET8VAI;F<@=&@8VAA;FYE;" T#0I*=6P@ M,3@@,#@Z,C4Z-3D@;65D:6$@;G1P9%LS-C S73H@:V5R;F5L('1I;64@<WEN M8R!E;F%B;&5D(# P,#$-"DIU;" Q." P.#HR-SHP,R!M961I82!N='!D6S,V M,#-=.B!S>6YC:')O;FEZ960@=&@.#(N.3(N,3DW+C$Q-2P@<W1R871U;2 R M#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS-CDR73H@6S(P,#4O,#<O M,3@@,#@Z,C<Z,3<L(#!=(&YM8F0O;FUB9%]B96-O;65?;&UB+F,Z8F5C;VUE M7VQO8V%L7VUA<W1E<E]S= T*86=E,B@S.38I#0I*=6P@,3@@,#@Z,C<Z,3<@ M;65D:6$@;FUB9%LS-CDR73H@(" J*BHJ*@T*2G5L(#$X(# X.C(W.C$W(&UE M9&EA(&YM8F1;,S8Y,ETZ#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS M-CDR73H@("!386UB82!N86UE('-E<G9E<B!-141)02!I<R!N;W<@82!L;V-A M;"!M87-T97(@8G)O=W-E<B!F;W(@=V]R:V=R;W5P#0I-64=23U50(&]N('-U M8FYE=" Q,2XQ,"XQ,"XQ,0T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1; M,S8Y,ETZ#0I*=6P@,3@@,#@Z,C<Z,3<@;65D:6$@;FUB9%LS-CDR73H@(" J M*BHJ*@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ(%LR,# U M+S W+S$X(# X.C(W.C$W+" P72!N;6)D+VYM8F1?8F5C;VUE7VQM8BYC.F)E M8V]M95]L;V-A;%]M87-T97)?<W0-"F%G93(H,SDV*0T*2G5L(#$X(# X.C(W M.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ(" @*BHJ*BH-"DIU;" Q." P.#HR-SHQ M-R!M961I82!N;6)D6S,V.3)=.@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM M8F1;,S8Y,ETZ(" @4V%M8F$@;F%M92!S97)V97(@345$24$@:7,@;F]W(&$@ M;&]C86P@;6%S=&5R(&)R;W=S97(@9F]R('=O<FMG<F]U< T*35E'4D]54"!O M;B!S=6)N970@,3 N,3 N,3 N,3(-"DIU;" Q." P.#HR-SHQ-R!M961I82!N M;6)D6S,V.3)=.@T*2G5L(#$X(# X.C(W.C$W(&UE9&EA(&YM8F1;,S8Y,ETZ M(" @*BHJ*BH-"DIU;" Q." P.#HS,#HQ,"!M961I82!V9');-#<V.%TZ(&-H M86YN96P@-" H0VAA;FYE;" T*2!E=F5N=" P.#HS," G179E<GEB;V1Y($QO M=F5S(%)A>6UO;F0G('-T871U<R T#0I*=6P@,3@@,#@Z,S4Z,3(@;65D:6$@ M=F1R6S0W-CA=.B!C:&%N;F5L(#,@*$E45C$I(&5V96YT(# X.C,U("='3516 M("T@3$L@5$]$05DG('-T871U<R T#0I*=6P@,3@@,#@Z,S<Z,SD@;65D:6$@ M:6YI=#H@;W!E;B@O9&5V+W!T<R\P*3H@3F@<W5C:"!F:6QE(&]R(&1I<F5C M=&]R>0T*2G5L(#$X(# X.C,X.C S(&UE9&EA("]S8FEN+VUI;F=E='1Y6S0Y M.#E=.B!T='DQ.B!I;G9A;&ED(&-H87)A8W1E<B P>#D@:6X@;&]G:6X@;F%M M90T*2G5L(#$X(# X.C,X.C X(&UE9&EA(&EN:70Z(&]P96XH+V1E=B]P=',O M,"DZ($YO('-U8V@@9FEL92!O<B!D:7)E8W1O<GD-"DIU;" Q." P.#HS.3HP M,"!M961I82!G<&U;,S8T,5TZ("HJ*B!I;F9O(%MM:6-E+F,H,3<V-BE=.@T* M2G5L(#$X(# X.C,Y.C P(&UE9&EA(&=P;5LS-C0Q73H@:6UP<S(Z($%U=&\M M9&5T96-T960@:6YT96QL:6UO=7-E(%!3+S(-"DIU;" Q." P.#HS.3HP,B!M M961I82!I;FET.B!O<&5N*"]D978O<'1S+S I.B!.;R!S=6-H(&9I;&4@;W(@ M9&ER96-T;W)Y#0I*=6P@,3@@,#@Z,SDZ,3 @;65D:6$@:V5R;F5L.B!C>#@X M7W=A:V5U<#H@,B!B=69F97)S(&AA;F1L960@*'-H;W5L9"!B92 Q*0T*2G5L M(#$X(# X.C0P.C R(&UE9&EA(&EN:70Z(&]P96XH+V1E=B]P=',O,"DZ($YO M('-U8V@@9FEL92!O<B!D:7)E8W1O<GD-"DIU;" Q." P.#HT,CHP-"!M961I M82!V9');-#DW,ETZ(&-6:61E;U)E<&%C:V5R.B!F;W5N9"!S>7-T96T@<W1A M<G0@8V]D93H@<W1R96%M('-E96US('1O(&)E('-C<F%M8FQE9"!O#0IR(&YO M="!D96UU;'1I<&QE>&5D#0I*=6P@,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y M-S)=.B!C5FED96]297!A8VME<CH@<VMI<'!E9" Q-30U(&)Y=&5S('=H:6QE M('-Y;F-I;F<@;VX@;F5X="!P:6-T=7)E#0I*=6P@,3@@,#@Z-#(Z,#0@;65D M:6$@=F1R6S0Y-S)=.B!C5FED96]297!A8VME<CH@<VMI<'!E9" T.3,@8GET M97,@=VAI;&4@<WEN8VEN9R!O;B!N97AT('!I8W1U<F4-"DIU;" Q." P.#HT M,CHP-"!M961I82!V9');-#DW,ETZ(&-6:61E;U)E<&%C:V5R.B!S:VEP<&5D M(#(P,SD@8GET97,@=VAI;&4@<WEN8VEN9R!O;B!N97AT('!I8W1U<F4-"DIU M;" Q." P.#HT,CHP-"!M961I82!L87-T(&UE<W-A9V4@<F5P96%T960@-2!T M:6UE<PT*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.3<R73H@8U9I9&5O M4F5P86-K97(Z('-K:7!P960@,3,Y."!B>71E<R!W:&EL92!S>6YC:6YG(&]N M(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.3<R M73H@8U9I9&5O4F5P86-K97(Z('-K:7!P960@-"!B>71E<R!T;R!S>6YC(&]N M(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA('9D<ELT.38Y M73H@8U9I9&5O4F5P86-K97(Z(&9O=6YD('-Y<W1E;2!S=&%R="!C;V1E.B!S M=')E86T@<V5E;7,@=&@8F4@<V-R86UB;&5D(&-"G(@;F]T(&1E;75L=&EP M;&5X960-"DIU;" Q." P.#HT,CHP-"!M961I82!V9');-#DV.5TZ(&-6:61E M;U)E<&%C:V5R.B!S:VEP<&5D(#$U-#4@8GET97,@=VAI;&4@<WEN8VEN9R!O M;B!N97AT('!I8W1U<F4-"DIU;" Q." P.#HT,CHP-"!M961I82!V9');-#DV M.5TZ(&-6:61E;U)E<&%C:V5R.B!S:VEP<&5D(#0Y,R!B>71E<R!W:&EL92!S M>6YC:6YG(&]N(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R.C T(&UE9&EA M('9D<ELT.38Y73H@8U9I9&5O4F5P86-K97(Z('-K:7!P960@,C S.2!B>71E M<R!W:&EL92!S>6YC:6YG(&]N(&YE>'0@<&EC='5R90T*2G5L(#$X(# X.C0R M.C T(&UE9&EA(&QA<W0@;65S<V%G92!R97!E871E9" U('1I;65S#0I*=6P@ M,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y-CE=.B!C5FED96]297!A8VME<CH@ M<VMI<'!E9" Q,SDX(&)Y=&5S('=H:6QE('-Y;F-I;F<@;VX@;F5X="!P:6-T M=7)E#0I*=6P@,3@@,#@Z-#(Z,#0@;65D:6$@=F1R6S0Y-CE=.B!C5FED96]2 M97!A8VME<CH@<VMI<'!E9" T(&)Y=&5S('1O('-Y;F,@;VX@;F5X="!P:6-T M=7)E#0I*=6P@,3@@,#@Z-#(Z,C @;65D:6$@=F1R6S0Y-S!=.B!%4E)/4CH@ M,2!R:6YG(&)U9F9E<B!O=F5R9FQO=R H-C4@8GET97,@9')O<'!E9"D-"DIU M;" Q." P.#HT,CHR-B!M961I82!V9');-#DW,%TZ($524D]2.B Q,# R,B!R M:6YG(&)U9F9E<B!O=F5R9FQO=W,@*#$X.#0Q,S8@8GET97,@9')O<'!E9"D- M"DIU;" Q." P.#HT,CHS,B!M961I82!V9');-#DW,%TZ($524D]2.B Y.#0P M(')I;F<@8G5F9F5R(&]V97)F;&]W<R H,3@T.3DR,"!B>71E<R!D<F]P<&5D M*0T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT.38X73H@15)23U(Z('9I M9&5O(&1A=&$@<W1R96%M(&)R;VME;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA M('9D<ELT.38X73H@:6YI=&EA=&EN9R!E;65R9V5N8WD@97AI= T*2G5L(#$X M(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@96UE<F=E;F-Y(&5X:70@<F5Q M=65S=&5D("T@<VAU='1I;F<@9&]W;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA M('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!C;&]C:PT*2G5L(#$X(# X M.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!F96UO M;@T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O<'!I;F<@ M<&QU9VEN.B!D=F0-"DIU;" Q." P.#HT,CHS-2!M961I82!V9');-#4U-5TZ M('-T;W!P:6YG('!L=6=I;CH@;7!L87EE<@T*2G5L(#$X(# X.C0R.C,U(&UE M9&EA('9D<ELT-34U73H@<W1O<'!I;F<@<&QU9VEN.B!S>7-I;F9O#0I*=6P@ M,3@@,#@Z-#(Z,S4@;65D:6$@=F1R6S0U-35=.B!S=&]P<&EN9R!P;'5G:6XZ M(')E;6]T90T*2G5L(#$X(# X.C0R.C,U(&UE9&EA('9D<ELT-34U73H@<W1O M<'!I;F<@<&QU9VEN.B!S:VEN8W5R<V5S#0I*=6P@,3@@,#@Z-#(Z,S4@;65D M:6$@=F1R6S0U-35=.B!S=&]P<&EN9R!P;'5G:6XZ('AI;F4-"DIU;" Q." P M.#HT,CHS-2!M961I82!V9');-#4U-5TZ(&QO861I;F<@+W9I9&5O+W9D<BTQ M+C,N,C<O=&AE;65S+W-T=&YG+61E9F%U;'0N=&AE;64-"DIU;" Q." P.#HT M,CHS-2!M961I82!V9');-#4U-5TZ('1I;65R(#(@*#0@,#@R-2TP.3 P("=% M=F5R>6)O9'D@3&]V97,@4F%Y;6]N9"<I('-T;W -"DIU;" Q." P.#HT,CHS M-B!M961I82!V9');-#4U-5TZ('-A=F5D('-E='5P('1O("]V:61E;R]V9'(M M,2XS+C(W+W-E='5P+F-O;F8-"DIU;" Q." P.#HT,CHS-B!M961I82!V9'); M-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@8VQO8VL-"DIU;" Q." P.#HT,CHS M-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@9F5M;VX-"DIU M;" Q." P.#HT,CHS-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I M;CH@9'9D#0I*=6P@,3@@,#@Z-#(Z,S8@;65D:6$@=F1R6S0U-35=.B!D96QE M=&EN9R!P;'5G:6XZ(&UP;&%Y97(-"DIU;" Q." P.#HT,CHS-B!M961I82!V M9');-#4U-5TZ(&1E;&5T:6YG('!L=6=I;CH@<WES:6YF;PT*2G5L(#$X(# X M.C0R.C,V(&UE9&EA('9D<ELT-34U73H@9&5L971I;F<@<&QU9VEN.B!R96UO M=&4-"DIU;" Q." P.#HT,CHS-B!M961I82!V9');-#4U-5TZ(&1E;&5T:6YG M('!L=6=I;CH@<VMI;F-U<G-E<PT*2G5L(#$X(# X.C0R.C,V(&UE9&EA('9D M<ELT-34U73H@9&5L971I;F<@<&QU9VEN.B!X:6YE#0I*=6P@,3@@,#@Z-#(Z M,S8@;65D:6$@=F1R6S0U-35=.B!E>&ET:6YG#0I*=6P@,3@@,#@Z-#(Z,S8@ B;65D:6$@=F1R6S0U-35=.B!E;65R9V5N8WD@97AI="$-"@`` ` end
Hi,
Simon Baxter wrote:
Tried the new repacker, but it was not successful :
Thanks for the report. Please specify some additional information:
There are several threads involved (4972, 4969, 4970, 4968). Please send the lines too, where these threads were created, respectively include them in the next report.
attached
Hhm, there is nothing mentioned about these threads. I was looking for messages like the following:
Jul 16 23:13:02 video vdr[3153]: switching to channel 2055 Jul 16 23:13:02 video vdr[3516]: non blocking file reader thread ended (pid=3516, tid=507914) Jul 16 23:13:02 video vdr[3515]: dvbplayer thread ended (pid=3515, tid=491529) Jul 16 23:13:02 video vdr[3573]: transfer thread started (pid=3573, tid=524297) Jul 16 23:13:02 video vdr[3574]: receiver on device 1 thread started (pid=3574, tid=540682) Jul 16 23:13:02 video vdr[3575]: TS buffer on device 1 thread started (pid=3575, tid=557067) Jul 16 23:13:04 video vdr[3573]: setting audio track to 1 Jul 16 23:13:14 video vdr[3153]: switching device 1 to channel 2055 Jul 16 23:13:14 video vdr[3153]: timer 1 (2055 2313-2318 '@TITLE EPISODE') start Jul 16 23:13:14 video vdr[3153]: waiting for EPG info... Jul 16 23:13:18 video vdr[3153]: no EPG info available Jul 16 23:13:18 video vdr[3153]: record /video/@ASTRA_HD/2005-07-16.23:13.50.50.rec Jul 16 23:13:18 video vdr[3153]: creating directory /video/@ASTRA_HD Jul 16 23:13:18 video vdr[3153]: creating directory /video/@ASTRA_HD/2005-07-16.23:13.50.50.rec Jul 16 23:13:18 video vdr[3153]: recording to '/video/@ASTRA_HD/2005-07-16.23:13.50.50.rec/001.vdr' Jul 16 23:13:18 video vdr[3582]: file writer thread started (pid=3582, tid=573452) Jul 16 23:13:18 video vdr[3583]: recording thread started (pid=3583, tid=589837) Jul 16 23:13:18 video vdr[3153]: max. latency time 5 seconds Jul 16 23:18:00 video vdr[3583]: recording thread ended (pid=3583, tid=589837) Jul 16 23:18:00 video vdr[3582]: file writer thread ended (pid=3582, tid=573452)
Do you find any file that contains this data? On my system it is in /var/log/messages. Maybe you have to run vdr with debugging enabled (-l 3).
It might be possible, that at 08:42:04 the cVideoRepacker was resyncing, e. g. due to some garbage that is comming in after switching the channel.
You wrote it happend just once so far (plus once with 1.3.26). Did you get some image distortions from time to time (or just rarely)? Maybe cVideoRepacker just discovered some stream corruption that otherwise (= before 1.3.26) would only have been noticeable on screen. Something like that might also be a driver issue.
Strange is that there are two threads (4972 and 4969) that are feeding cVideoRepacker. Should there be a racecondition that spawns two threads for this job somewhere else in VDR?
sorry couldn't tell you ):
Maybe some of the missing logfile entries would put light on this issue.
Are you using other plugins that might attach a further receiver (osd-teletext triggered some threading issues some time ago)?
-P'xine -q -r -s' -P'skincurses' -P'remote -i /dev/input/event2' -P'sysinfo' -P'mplayer' -P'dvd' -P'femon' -P'clock'
I think, none of them should have any receiver active. Maybe it's just the transfer thread for live-TV and the recorder thread that both have a receiver running. What happend to live-TV at that time?
Thread 4968 seems to be a recorder. It considers the data stream to be broken as it hasn't seen any data for MAXBROKENTIMEOUT (= 30 seconds), i. e. since cVideoRepacker got synced. Please add two log messages to cRepacker::Put() so that we can see how cVideoRepacker delivers data after 08:42:04. Maybe a further log message at the beginning and end of cVideoRepacker::Repack() would be useful too, to see whether cVideoRepacker gets stuck.
happy to help, but you'll need to help me out here. What should I be adding to where?
Sorry, it seems that the below marked lines where not obvious enough. They have to go into remux.c, cRepacker::Put() respectively cVideoRepacker::Repack(). Be aware that these changes will produce big logfiles :-(
static int Put(.....) { esyslog(">>>>> cRepacker::Put"); // <============
int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....);
esyslog("<<<<< cRepacker::Put"); // <============
return n; }
void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack()"); // <============
// synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4;
// reset local scanner localStart = -1;
. . .
// report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; }
esyslog("<<<<< cVideoRepacker::Repack()"); // <============ }
Bye.
Hi,
I'd like to invite you to test the attached patch which now also supports MPEG1 video streams (vdr-1.3.27-remux-repacker.patch).
I only had a single negative report so far. But as it was the only report at all, there are just a few possibilities:
A) there was just a single tester B) all positive testers didn't report their success C) all positive testers are still waiting for failure
Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
Bye.
On Thu, Jul 21, 2005 at 11:05:39PM +0200, Reinhard Nissl wrote:
A) there was just a single tester
You are wrong here :-)
B) all positive testers didn't report their success C) all positive testers are still waiting for failure
I shall go in C) :-)
Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
My VDR runs lots of time with it now, without problem !!!
Hello Reinhard,
On Thu, 21 Jul 2005 23:05:39 +0200 Reinhard Nissl rnissl@gmx.de wrote:
| I only had a single negative report so far. But as it was the only | report at all, there are just a few possibilities: | | A) there was just a single tester | B) all positive testers didn't report their success | C) all positive testers are still waiting for failure | | Anyway, VDR-1.3.28 is right ahead, so please hurry up testing ;-)
Sorry, i haven't have too much time to play with VDR lately, but so far my VDR 1.3.27 has been working really nicely since i've installed it.
I'd like to help you with this, can you just tell me :
- a quick reminder of why this needs to be changed, and - will it break something to my old (and very old) recording, will i still be able to edit them ? - as i don't use the Xine plugin, do i only need the vdr-1.3.27-remux-repacker.patch ?
...
ok i've just patched my already somewhat patched VDR :) and will report any issues
Thanks,
Philippe
FYI: my setup : 1 FF Rev 1.3 TT DVB-S, VDR 1.3.27, Plugins: mplayer/mp3,dvd, dvdselect,femon,weather-ng,streamdev,text2skin
Hi,
Philippe Gramoullé wrote:
I'd like to help you with this, can you just tell me :
- a quick reminder of why this needs to be changed, and
VDR's index file for recordings has byte granularity but adresses complete PES packets. When VDR needs to send an I frame to a device (e. g. for fast forward or editing cutting marks) it seeks to the index of the I frame and reads the data up to the next B frame, i. e. it stops just before the PES packet which contains the start of the B frame. But it is likely that this packet also contains the tail of the I frame before the B frame starts. So VDR will read to few data which results in an incomplete I frame. The result is that xine doesn't show incomplete frames, i. e. moving a cutting mark results in no screen update. A FF card might have shown some garbage or blackness in the last few lines of the image.
cVideoRepacker resolves this issue by ensuring to start a new PES packet when a new frame starts.
- will it break something to my old (and very old) recording, will i still be able to edit them ?
It will not break any old recordings. For old recordings, you still have to apply a (soon to be updated) patch, that resolves the short I frames issue in a different way. The patch is not necessary for new recordings but it won't hurt either.
- as i don't use the Xine plugin, do i only need the vdr-1.3.27-remux-repacker.patch ?
As I expect VDR-1.3.28 to contain both patches, I'd like you to test both, too. As at least most DVD still images contain a sequence end code, I'd expect a FF card to handle it correctly, too.
Bye.
On Samstag, 23. Juli 2005 13:45, Reinhard Nissl wrote:
Hi,
Philippe Gramoullé wrote:
I'd like to help you with this, can you just tell me :
- a quick reminder of why this needs to be changed, and
VDR's index file for recordings has byte granularity but adresses complete PES packets. When VDR needs to send an I frame to a device (e. g. for fast forward or editing cutting marks) it seeks to the index of the I frame and reads the data up to the next B frame, i. e. it stops just before the PES packet which contains the start of the B frame. But it is likely that this packet also contains the tail of the I frame before the B frame starts. So VDR will read to few data which results in an incomplete I frame. The result is that xine doesn't show incomplete frames, i. e. moving a cutting mark results in no screen update.
Are there some sample streams available ? I'm asking this because I get an updated picture upon moving cut marks. That is with softdevice running with vdr-1.3.27 and vdr-1.2.1 recordings.
Perhaps it's time to test your patch too :-) .
Hi,
Stefan Lucke wrote:
- a quick reminder of why this needs to be changed, and
VDR's index file for recordings has byte granularity but adresses complete PES packets. When VDR needs to send an I frame to a device (e. g. for fast forward or editing cutting marks) it seeks to the index of the I frame and reads the data up to the next B frame, i. e. it stops just before the PES packet which contains the start of the B frame. But it is likely that this packet also contains the tail of the I frame before the B frame starts. So VDR will read to few data which results in an incomplete I frame. The result is that xine doesn't show incomplete frames, i. e. moving a cutting mark results in no screen update.
Are there some sample streams available ? I'm asking this because I get an updated picture upon moving cut marks. That is with softdevice running with vdr-1.3.27 and vdr-1.2.1 recordings.
Well, any stream will do, especially HDTV streams. The result depends on the implementation. When softdevice displays incomplete frames, everything works almost properly. Maybe you see that part of the image's last slice may be black or garbage.
xine-lib discards incomplete frames. The problem exists for quite a long time already. My first approach in successfully displaying a still image was to send the data 4 times to xine. But this didn't work anymore when I wanted to edit cut marks for the HDTV broadcast Spiderman. After debugging a lot, I realized that the I frame was incomplete. The last slice was completely missing.
With the patches it is now possible to send the still image just once to xine, which speeds up moving cut marks accordingly.
Bye.
On Samstag, 23. Juli 2005 21:29, Reinhard Nissl wrote:
Hi,
Stefan Lucke wrote:
- a quick reminder of why this needs to be changed, and
VDR's index file for recordings has byte granularity but adresses complete PES packets. When VDR needs to send an I frame to a device (e. g. for fast forward or editing cutting marks) it seeks to the index of the I frame and reads the data up to the next B frame, i. e. it stops just before the PES packet which contains the start of the B frame. But it is likely that this packet also contains the tail of the I frame before the B frame starts. So VDR will read to few data which results in an incomplete I frame. The result is that xine doesn't show incomplete frames, i. e. moving a cutting mark results in no screen update.
Are there some sample streams available ? I'm asking this because I get an updated picture upon moving cut marks. That is with softdevice running with vdr-1.3.27 and vdr-1.2.1 recordings.
Well, any stream will do, especially HDTV streams. The result depends on the implementation. When softdevice displays incomplete frames, everything works almost properly. Maybe you see that part of the image's last slice may be black or garbage.
xine-lib discards incomplete frames. The problem exists for quite a long time already. My first approach in successfully displaying a still image was to send the data 4 times to xine.
Thats the same as softdevice does.
But this didn't work anymore when I wanted to edit cut marks for the HDTV broadcast Spiderman.
Oh, I never tried HDTV streams.
After debugging a lot, I realized that the I frame was incomplete. The last slice was completely missing.
With the patches it is now possible to send the still image just once to xine, which speeds up moving cut marks accordingly.
That sounds fine. I'll try "sending once" in softdevice too. Thanks for your explanation.
Reinhard Nissl wrote:
... xine-lib discards incomplete frames. The problem exists for quite a long time already. My first approach in successfully displaying a still image was to send the data 4 times to xine. But this didn't work anymore when I wanted to edit cut marks for the HDTV broadcast Spiderman. After debugging a lot, I realized that the I frame was incomplete. The last slice was completely missing.
Just curious: why doesn't xine-lib display incomplete frames, just like the FF DVB cards do? Wouldn't it be better to display an almost complete frame, rather than completely drop it?
Just wondering...
Klaus
On Friday 22 July 2005 00:05, Reinhard Nissl wrote:
B) all positive testers didn't report their success C) all positive testers are still waiting for failure
It's been running over a week now so I think it's safe to say it doesn't cause any problems on my setup with dxr3.
-
Gregoire Favre -
Jukka Tastula -
Klaus Schmidinger -
Philippe Gramoullé -
Reinhard Nissl -
Simon Baxter -
Stefan Lucke