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.
  

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 %d 
> byte", 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 short
> +
> +     PesPayloadOffset = 6 + 3 + Data[8];
> +     if (Count < PesPayloadOffset)
> +        return -1; // too short
> +
> +     if (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 only
> +     PesPayloadOffset += 5;
> +     }
> +  else if ((Data[PesPayloadOffset] & 0xF0) == 0x30) {
> +     // skip PTS and DTS
> +     PesPayloadOffset += 10;
> +     }
> +  else if (Data[PesPayloadOffset] == 0x0F) {
> +     // continueation header
> +     PesPayloadOffset++;
> +
> +     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);
>      if (n != Bite) {
>         Reset();
>         return false;
> @@ -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);
>      if (n != Bite) {
>         Reset();
>         return false;
> @@ -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);
>      if (n != Bite) {
>         Reset();
>         return false;
> @@ -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 buffer 
> overflow", 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 sync 
> on next picture", skippedBytes - 4);
> +                     if (skippedBytes > SkippedBytesLimit)
> +                        esyslog("cVideoRepacker: skipped %d bytes to sync 
> on 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;
> +                           }
> +                        else
> +                           pesHeader[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;
> +                 }
> +              else
> +                 pesHeader[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 next 
> picture", 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;
>      const uchar *limit = Data + Count;
>      // scan data
>      while (data < limit) {
> @@ -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);
>      if (Bite != n) {
>         Reset();
>         Done += n;
> @@ -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);
>      if (Bite != n) {
>         Reset();
>         return false;
>         }
>      Bite = packetLen - pesHeaderLen;
> -     n = ResultBuffer->Put(Data, Bite);
> +     n = Put(ResultBuffer, Data, Bite);
>      if (Bite != n) {
>         Reset();
>         Done += n;
> @@ -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 while 
> syncing
>                continue;
>           case find_77:
>                if (*data != 0x77) {
> @@ -625,18 +727,21 @@ int cDolbyRepacker::Put(cRingBufferLinea
>                data++;
>                done++;
>                todo--;
> +               skippedBytes++; // collect number of skipped bytes while 
> syncing
>                ++(int &)state;
>                continue;
>           case store_chk1:
>                chk1 = *data++;
>                done++;
>                todo--;
> +               skippedBytes++; // collect number of skipped bytes while 
> syncing
>                ++(int &)state;
>                continue;
>           case store_chk2:
>                chk2 = *data++;
>                done++;
>                todo--;
> +               skippedBytes++; // collect number of skipped bytes while 
> syncing
>                ++(int &)state;
>                continue;
>           case get_length:
> @@ -664,6 +769,10 @@ int cDolbyRepacker::Put(cRingBufferLinea
>                   state = find_0b;
>                   continue;
>                   }
> +               // report that syncing dropped some bytes
> +               if (skippedBytes > SkippedBytesLimit)
> +                  esyslog("cDolbyRepacker: skipped %d bytes to sync on 
> next 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 buffer 
> overflow", 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 buffer 
> overflow", 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 AC3 
> frame", 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 %d 
> byte", 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 immediately 
> with softdevices
> +           if (r > 6) { // should be always true
> +              b[r++] = 0x00;
> +              b[r++] = 0x00;
> +              b[r++] = 0x01;
> +              b[r++] = b[3];
> +              if (b[6] & 0x80) { // MPEG 2
> +                 b[r++] = 0x00;
> +                 b[r++] = 0x07;
> +                 b[r++] = 0x80;
> +                 b[r++] = 0x00;
> +                 b[r++] = 0x00;
> +                 }
> +              else { // MPEG 1
> +                 b[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.