| Message ID | 4E4E9297.5060509@tvdr.de |
|---|---|
| State | New |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <Klaus.Schmidinger@tvdr.de>) id 1QuSA2-0001OL-A7 for vdr@linuxtv.org; Fri, 19 Aug 2011 18:43:34 +0200 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.75/mailfrontend-1) with esmtps [TLSv1:AES256-SHA:256] for <vdr@linuxtv.org> id 1QuSA2-0006HG-Je; Fri, 19 Aug 2011 18:43:10 +0200 Received: from whale.tvdr.de (whale.tvdr.de [192.168.100.6]) by racoon.tvdr.de (8.14.3/8.14.3) with ESMTP id p7JGh9TI003491 for <vdr@linuxtv.org>; Fri, 19 Aug 2011 18:43:09 +0200 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by whale.tvdr.de (8.14.3/8.14.3) with ESMTP id p7JGh393016808 for <vdr@linuxtv.org>; Fri, 19 Aug 2011 18:43:03 +0200 Message-ID: <4E4E9297.5060509@tvdr.de> Date: Fri, 19 Aug 2011 18:43:03 +0200 From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 MIME-Version: 1.0 To: VDR Mailing List <vdr@linuxtv.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (racoon.tvdr.de [188.40.50.18]); Fri, 19 Aug 2011 18:43:09 +0200 (CEST) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.19.163014 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, NO_URI_FOUND 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0' X-LSpam-Score: -4.2 (----) X-LSpam-Report: No, score=-4.2 required=5.0 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3 autolearn=ham Subject: [vdr] Fix for recording problem in VDR 1.7.20 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Fri, 19 Aug 2011 16:43:34 -0000 Status: O X-Status: X-Keywords: X-UID: 25036 |
Commit Message
Klaus Schmidinger
Aug. 19, 2011, 4:43 p.m. UTC
There have been some reports about recording problems with VDR 1.7.20 on some HD channels. This patch should fix this. Klaus
Comments
Hi Klaus, On 19.08.2011 18:43, Klaus Schmidinger wrote: > There have been some reports about recording problems with VDR 1.7.20 > on some HD channels. > This patch should fix this. > > Klaus > > > --- remux.c 2011/08/15 09:50:14 2.58 > +++ remux.c 2011/08/19 15:33:26 > @@ -974,8 +974,10 @@ > payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; > if (payloadUnitOfFrame != 0 && independentFrame) > payloadUnitOfFrame = 0; > - if (payloadUnitOfFrame) > + if (payloadUnitOfFrame) { > + newPayload = false; > newFrame = false; > + } > } > if (framesPerPayloadUnit <= 1) > scanning = false; Would the log messages look like this without above patch? Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload - buffering Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (23312 > 940) - dropped 23124 bytes Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (3948 > 940) - dropped 3572 bytes Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (24816 > 940) - dropped 24440 bytes Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (26696 > 940) - dropped 26508 bytes Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20116 bytes Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20304 bytes Regards André
On 21.08.2011 22:20, André Weidemann wrote: > Hi Klaus, > > On 19.08.2011 18:43, Klaus Schmidinger wrote: >> There have been some reports about recording problems with VDR 1.7.20 >> on some HD channels. >> This patch should fix this. >> >> Klaus >> >> >> --- remux.c 2011/08/15 09:50:14 2.58 >> +++ remux.c 2011/08/19 15:33:26 >> @@ -974,8 +974,10 @@ >> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >> if (payloadUnitOfFrame != 0 && independentFrame) >> payloadUnitOfFrame = 0; >> - if (payloadUnitOfFrame) >> + if (payloadUnitOfFrame) { >> + newPayload = false; >> newFrame = false; >> + } >> } >> if (framesPerPayloadUnit <= 1) >> scanning = false; > > Would the log messages look like this without above patch? > > Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload - buffering > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (23312 > 940) - dropped 23124 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (3948 > 940) - dropped 3572 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (24816 > 940) - dropped 24440 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (26696 > 940) - dropped 26508 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20116 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while buffering - dropping some data! > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer (20492 > 940) - dropped 20304 bytes Those were the reports I got from users. Klaus
On Sun, Aug 21, 2011 at 1:20 PM, André Weidemann <Andre.Weidemann@web.de> wrote: > Would the log messages look like this without above patch? > > Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of payload - > buffering > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer > (23312 > 940) - dropped 23124 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while > buffering - dropping some data! > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer > (3948 > 940) - dropped 3572 bytes > Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type buffer > (24816 > 940) - dropped 24440 bytes I had massive amounts of those log messages and all of my recordings were empty. This was fixed by the patch Klaus posted. I expect the same will be true for you as well after applying the patch. Only one way to find out!
>> >> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>> There have been some reports about recording problems with VDR 1.7.20 >>> on some HD channels. >>> This patch should fix this. >>> >>> Klaus >>> >>> >>> --- remux.c 2011/08/15 09:50:14 2.58 >>> +++ remux.c 2011/08/19 15:33:26 >>> @@ -974,8 +974,10 @@ >>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >>> if (payloadUnitOfFrame != 0 && independentFrame) >>> payloadUnitOfFrame = 0; >>> - if (payloadUnitOfFrame) >>> + if (payloadUnitOfFrame) { >>> + newPayload = false; >>> newFrame = false; >>> + } >>> } >>> if (framesPerPayloadUnit <= 1) >>> scanning = false; >> >> Would the log messages look like this without above patch? >> >> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >> payload - buffering >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (23312 > 940) - dropped 23124 bytes >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >> buffering - dropping some data! >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (3948 > 940) - dropped 3572 bytes >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (24816 > 940) - dropped 24440 bytes >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >> buffering - dropping some data! >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (26696 > 940) - dropped 26508 bytes >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >> buffering - dropping some data! >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (20492 > 940) - dropped 20116 bytes >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >> buffering - dropping some data! >> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >> buffer (20492 > 940) - dropped 20304 bytes > > Those were the reports I got from users. > > Klaus > Patch for remux.c doesn't fix the problem if i use my Hauppauge PVR-cards 500 ! With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. Aug 29 22:07:44 pcneu vdr: [20700] record /video0/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [20700] recording to '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2/2011-08-29.21.57.13-0.rec Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, tid=21580) Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started (pid=20700, tid=21581) Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - accepted Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread started (pid=20700, tid=21582) Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of payload - buffering Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Dirk
On 29.08.2011 22:30, Dirk Vornheder wrote: > >>> >>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>> There have been some reports about recording problems with VDR 1.7.20 >>>> on some HD channels. >>>> This patch should fix this. >>>> >>>> Klaus >>>> >>>> >>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>> +++ remux.c 2011/08/19 15:33:26 >>>> @@ -974,8 +974,10 @@ >>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>> payloadUnitOfFrame = 0; >>>> - if (payloadUnitOfFrame) >>>> + if (payloadUnitOfFrame) { >>>> + newPayload = false; >>>> newFrame = false; >>>> + } >>>> } >>>> if (framesPerPayloadUnit <= 1) >>>> scanning = false; >>> >>> Would the log messages look like this without above patch? >>> >>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>> payload - buffering >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (23312 > 940) - dropped 23124 bytes >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>> buffering - dropping some data! >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (3948 > 940) - dropped 3572 bytes >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (24816 > 940) - dropped 24440 bytes >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>> buffering - dropping some data! >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (26696 > 940) - dropped 26508 bytes >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>> buffering - dropping some data! >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (20492 > 940) - dropped 20116 bytes >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>> buffering - dropping some data! >>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>> buffer (20492 > 940) - dropped 20304 bytes >> >> Those were the reports I got from users. >> >> Klaus >> > > Patch for remux.c doesn't fix the problem if i use my Hauppauge PVR-cards 500 ! > > With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. > > Aug 29 22:07:44 pcneu vdr: [20700] record /video0/ZIB_2/2011-08-29.21.57.13-0.rec > Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 > Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2/2011-08-29.21.57.13-0.rec > Aug 29 22:07:44 pcneu vdr: [20700] recording to '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' > Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 > Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2/2011-08-29.21.57.13-0.rec > Aug 29 22:07:44 pcneu vdr: [21580] recording thread started (pid=20700, tid=21580) > Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection > Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread started (pid=20700, tid=21581) > Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 - accepted > Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection > Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread started (pid=20700, tid=21582) > Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of payload - buffering > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame type buffer (2444 > 940) - dropped 2444 bytes > Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload while buffering - dropping some data! Can you please provide a 1 minute VDR recording from that device (made with the most recent developer version that works for you) and tell me where to download it? Klaus
>> >> Patch for remux.c doesn't fix the problem if i use my Hauppauge >> PVR-cards 500 ! >> >> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >> >> Aug 29 22:07:44 pcneu vdr: [20700] record >> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [20700] recording to >> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >> (pid=20700, tid=21580) >> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >> started (pid=20700, tid=21581) >> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >> - accepted >> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >> started (pid=20700, tid=21582) >> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >> payload - buffering >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! > > Can you please provide a 1 minute VDR recording from that device (made > with the most recent > developer version that works for you) and tell me where to download it? > I doesn't know a ftp server where i can upload the 111 mb file. Dirk
30.08.2011 0:02, Dirk Vornheder kirjutas: > >>> >>> Patch for remux.c doesn't fix the problem if i use my Hauppauge >>> PVR-cards 500 ! >>> >>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >>> >>> Aug 29 22:07:44 pcneu vdr: [20700] record >>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [20700] recording to >>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >>> (pid=20700, tid=21580) >>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >>> started (pid=20700, tid=21581) >>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >>> - accepted >>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >>> started (pid=20700, tid=21582) >>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >>> payload - buffering >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >>> while buffering - dropping some data! >> >> Can you please provide a 1 minute VDR recording from that device (made >> with the most recent >> developer version that works for you) and tell me where to download it? >> > > I doesn't know a ftp server where i can upload the 111 mb file. You can use any of filesharing providers. Rapidshare, for example. It allows up to 200MB file. A.
Am 29.08.2011 22:49, schrieb Klaus Schmidinger: > On 29.08.2011 22:30, Dirk Vornheder wrote: >> >>>> >>>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>>> There have been some reports about recording problems with VDR 1.7.20 >>>>> on some HD channels. >>>>> This patch should fix this. >>>>> >>>>> Klaus >>>>> >>>>> >>>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>>> +++ remux.c 2011/08/19 15:33:26 >>>>> @@ -974,8 +974,10 @@ >>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >>>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>>> payloadUnitOfFrame = 0; >>>>> - if (payloadUnitOfFrame) >>>>> + if (payloadUnitOfFrame) { >>>>> + newPayload = false; >>>>> newFrame = false; >>>>> + } >>>>> } >>>>> if (framesPerPayloadUnit <= 1) >>>>> scanning = false; >>>> >>>> Would the log messages look like this without above patch? >>>> >>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>>> payload - buffering >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (23312 > 940) - dropped 23124 bytes >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>>> buffering - dropping some data! >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (3948 > 940) - dropped 3572 bytes >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (24816 > 940) - dropped 24440 bytes >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>>> buffering - dropping some data! >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (26696 > 940) - dropped 26508 bytes >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>>> buffering - dropping some data! >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (20492 > 940) - dropped 20116 bytes >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: encountered new payload while >>>> buffering - dropping some data! >>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>> buffer (20492 > 940) - dropped 20304 bytes >>> >>> Those were the reports I got from users. >>> >>> Klaus >>> >> >> Patch for remux.c doesn't fix the problem if i use my Hauppauge >> PVR-cards 500 ! >> >> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >> >> Aug 29 22:07:44 pcneu vdr: [20700] record >> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [20700] recording to >> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >> (pid=20700, tid=21580) >> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >> started (pid=20700, tid=21581) >> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >> - accepted >> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >> started (pid=20700, tid=21582) >> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >> payload - buffering >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >> type buffer (2444 > 940) - dropped 2444 bytes >> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: encountered new payload >> while buffering - dropping some data! > > Can you please provide a 1 minute VDR recording from that device (made > with the most recent > developer version that works for you) and tell me where to download it? > > Klaus > The upload to Sigi's FTP-Server has finished. The filename is problemvdr1720pvr3sat00001.ts ! Dirk
Hi, Am 30.08.2011 19:40, schrieb Dirk Vornheder: > The upload to Sigi's FTP-Server has finished. > > The filename is problemvdr1720pvr3sat00001.ts ! Since it's not impossible that the TS generated by pvrinput may be incorrect, which version of ivtv and pvrinput do you use? Lars. > > > Dirk > > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
> > Am 30.08.2011 19:40, schrieb Dirk Vornheder: >> The upload to Sigi's FTP-Server has finished. >> >> The filename is problemvdr1720pvr3sat00001.ts ! > > Since it's not impossible that the TS generated by pvrinput may be > incorrect, which version of ivtv and pvrinput do you use? > > Lars. > I use ivtv from linux kernel 3.0.3 and git-version of pvrinput. Dirk
On 30.08.2011 19:40, Dirk Vornheder wrote: > Am 29.08.2011 22:49, schrieb Klaus Schmidinger: >> On 29.08.2011 22:30, Dirk Vornheder wrote: >>> >>>>> >>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>>>> There have been some reports about recording problems with VDR 1.7.20 >>>>>> on some HD channels. >>>>>> This patch should fix this. >>>>>> >>>>>> Klaus >>>>>> >>>>>> >>>>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>>>> +++ remux.c 2011/08/19 15:33:26 >>>>>> @@ -974,8 +974,10 @@ >>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >>>>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>>>> payloadUnitOfFrame = 0; >>>>>> - if (payloadUnitOfFrame) >>>>>> + if (payloadUnitOfFrame) { >>>>>> + newPayload = false; >>>>>> newFrame = false; >>>>>> + } >>>>>> } >>>>>> if (framesPerPayloadUnit <= 1) >>>>>> scanning = false; >>>>> >>>>> Would the log messages look like this without above patch? >>>>> >>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>>>> payload - buffering >>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>>> buffer (23312 > 940) - dropped 23124 bytes >>>>> ... >>>> >>>> Those were the reports I got from users. >>>> >>>> Klaus >>>> >>> >>> Patch for remux.c doesn't fix the problem if i use my Hauppauge >>> PVR-cards 500 ! >>> >>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >>> >>> Aug 29 22:07:44 pcneu vdr: [20700] record >>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [20700] recording to >>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >>> (pid=20700, tid=21580) >>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >>> started (pid=20700, tid=21581) >>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >>> - accepted >>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >>> started (pid=20700, tid=21582) >>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >>> payload - buffering >>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>> type buffer (2444 > 940) - dropped 2444 bytes >>> ... >> >> Can you please provide a 1 minute VDR recording from that device (made >> with the most recent >> developer version that works for you) and tell me where to download it? >> >> Klaus >> > > The upload to Sigi's FTP-Server has finished. > > The filename is problemvdr1720pvr3sat00001.ts ! Apparently in this file every TS packet that starts a new PES packet has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this should only be set for TS packets that contain the beginning of an actual payload unit (which may consist of several PES packets). So I would assume that the TS data is in error. Klaus
Am 02.09.2011 16:08, schrieb Klaus Schmidinger: > On 30.08.2011 19:40, Dirk Vornheder wrote: >> Am 29.08.2011 22:49, schrieb Klaus Schmidinger: >>> On 29.08.2011 22:30, Dirk Vornheder wrote: >>>> >>>>>> >>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>>>>> There have been some reports about recording problems with VDR 1.7.20 >>>>>>> on some HD channels. >>>>>>> This patch should fix this. >>>>>>> >>>>>>> Klaus >>>>>>> >>>>>>> >>>>>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>>>>> +++ remux.c 2011/08/19 15:33:26 >>>>>>> @@ -974,8 +974,10 @@ >>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; >>>>>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>>>>> payloadUnitOfFrame = 0; >>>>>>> - if (payloadUnitOfFrame) >>>>>>> + if (payloadUnitOfFrame) { >>>>>>> + newPayload = false; >>>>>>> newFrame = false; >>>>>>> + } >>>>>>> } >>>>>>> if (framesPerPayloadUnit <= 1) >>>>>>> scanning = false; >>>>>> >>>>>> Would the log messages look like this without above patch? >>>>>> >>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>>>>> payload - buffering >>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>>>> buffer (23312 > 940) - dropped 23124 bytes >>>>>> ... >>>>> >>>>> Those were the reports I got from users. >>>>> >>>>> Klaus >>>>> >>>> >>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge >>>> PVR-cards 500 ! >>>> >>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >>>> >>>> Aug 29 22:07:44 pcneu vdr: [20700] record >>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to >>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >>>> (pid=20700, tid=21580) >>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >>>> started (pid=20700, tid=21581) >>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >>>> - accepted >>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >>>> started (pid=20700, tid=21582) >>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >>>> payload - buffering >>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>>> type buffer (2444 > 940) - dropped 2444 bytes >>>> ... >>> >>> Can you please provide a 1 minute VDR recording from that device (made >>> with the most recent >>> developer version that works for you) and tell me where to download it? >>> >>> Klaus >>> >> >> The upload to Sigi's FTP-Server has finished. >> >> The filename is problemvdr1720pvr3sat00001.ts ! > > Apparently in this file every TS packet that starts a new PES packet > has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this > should only be set for TS packets that contain the beginning of an > actual payload unit (which may consist of several PES packets). > > So I would assume that the TS data is in error. I will take a look at the PS-to-TS-code of pvrinput. When I wrote/adjust it I didn't know anything of TS and I had to learn a lot in a short time. Esp. adding PCR etc. Thanks! Lars. > > Klaus > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
Am 02.09.2011 16:08, schrieb Klaus Schmidinger: > On 30.08.2011 19:40, Dirk Vornheder wrote: >> Am 29.08.2011 22:49, schrieb Klaus Schmidinger: >>> On 29.08.2011 22:30, Dirk Vornheder wrote: >>>> >>>>>> >>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>>>>> There have been some reports about recording problems with VDR >>>>>>> 1.7.20 >>>>>>> on some HD channels. >>>>>>> This patch should fix this. >>>>>>> >>>>>>> Klaus >>>>>>> >>>>>>> >>>>>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>>>>> +++ remux.c 2011/08/19 15:33:26 >>>>>>> @@ -974,8 +974,10 @@ >>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % >>>>>>> -framesPerPayloadUnit; >>>>>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>>>>> payloadUnitOfFrame = 0; >>>>>>> - if (payloadUnitOfFrame) >>>>>>> + if (payloadUnitOfFrame) { >>>>>>> + newPayload = false; >>>>>>> newFrame = false; >>>>>>> + } >>>>>>> } >>>>>>> if (framesPerPayloadUnit <= 1) >>>>>>> scanning = false; >>>>>> >>>>>> Would the log messages look like this without above patch? >>>>>> >>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>>>>> payload - buffering >>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>>>> buffer (23312 > 940) - dropped 23124 bytes >>>>>> ... >>>>> >>>>> Those were the reports I got from users. >>>>> >>>>> Klaus >>>>> >>>> >>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge >>>> PVR-cards 500 ! >>>> >>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >>>> >>>> Aug 29 22:07:44 pcneu vdr: [20700] record >>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to >>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >>>> (pid=20700, tid=21580) >>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >>>> started (pid=20700, tid=21581) >>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >>>> - accepted >>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >>>> started (pid=20700, tid=21582) >>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >>>> payload - buffering >>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>>> type buffer (2444 > 940) - dropped 2444 bytes >>>> ... >>> >>> Can you please provide a 1 minute VDR recording from that device (made >>> with the most recent >>> developer version that works for you) and tell me where to download it? >>> >>> Klaus >>> >> >> The upload to Sigi's FTP-Server has finished. >> >> The filename is problemvdr1720pvr3sat00001.ts ! > > Apparently in this file every TS packet that starts a new PES packet > has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this > should only be set for TS packets that contain the beginning of an > actual payload unit (which may consist of several PES packets). > > So I would assume that the TS data is in error. I would say this is the expected behaviour as one PES packet normally is one payload unit. The MPEG2 standard only defines that when the PUSI bit is set a PES packet shall start in the payload of the TS packet. There is no other limitation. Andreas
Am 02.09.2011 19:57, schrieb Andreas Regel: > Am 02.09.2011 16:08, schrieb Klaus Schmidinger: >> On 30.08.2011 19:40, Dirk Vornheder wrote: >>> Am 29.08.2011 22:49, schrieb Klaus Schmidinger: >>>> On 29.08.2011 22:30, Dirk Vornheder wrote: >>>>> >>>>>>> >>>>>>> On 19.08.2011 18:43, Klaus Schmidinger wrote: >>>>>>>> There have been some reports about recording problems with VDR >>>>>>>> 1.7.20 >>>>>>>> on some HD channels. >>>>>>>> This patch should fix this. >>>>>>>> >>>>>>>> Klaus >>>>>>>> >>>>>>>> >>>>>>>> --- remux.c 2011/08/15 09:50:14 2.58 >>>>>>>> +++ remux.c 2011/08/19 15:33:26 >>>>>>>> @@ -974,8 +974,10 @@ >>>>>>>> payloadUnitOfFrame = (payloadUnitOfFrame + 1) % >>>>>>>> -framesPerPayloadUnit; >>>>>>>> if (payloadUnitOfFrame != 0 && independentFrame) >>>>>>>> payloadUnitOfFrame = 0; >>>>>>>> - if (payloadUnitOfFrame) >>>>>>>> + if (payloadUnitOfFrame) { >>>>>>>> + newPayload = false; >>>>>>>> newFrame = false; >>>>>>>> + } >>>>>>>> } >>>>>>>> if (framesPerPayloadUnit <= 1) >>>>>>>> scanning = false; >>>>>>> >>>>>>> Would the log messages look like this without above patch? >>>>>>> >>>>>>> Aug 21 16:15:12 vdr vdr: [3138] frame type not in first packet of >>>>>>> payload - buffering >>>>>>> Aug 21 16:15:12 vdr vdr: [3138] ERROR: too many bytes for frame type >>>>>>> buffer (23312 > 940) - dropped 23124 bytes >>>>>>> ... >>>>>> >>>>>> Those were the reports I got from users. >>>>>> >>>>>> Klaus >>>>>> >>>>> >>>>> Patch for remux.c doesn't fix the problem if i use my Hauppauge >>>>> PVR-cards 500 ! >>>>> >>>>> With DVB-T-/DVB-C-/DVB-S-cards/-channels everything works fine. >>>>> >>>>> Aug 29 22:07:44 pcneu vdr: [20700] record >>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video0/ZIB_2 >>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>>> /video0/ZIB_2/2011-08-29.21.57.13-0.rec >>>>> Aug 29 22:07:44 pcneu vdr: [20700] recording to >>>>> '/video0/ZIB_2/2011-08-29.21.57.13-0.rec/00001.ts' >>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory /video4/ZIB_2 >>>>> Aug 29 22:07:44 pcneu vdr: [20700] creating directory >>>>> /video4/ZIB_2/2011-08-29.21.57.13-0.rec >>>>> Aug 29 22:07:44 pcneu vdr: [21580] recording thread started >>>>> (pid=20700, tid=21580) >>>>> Aug 29 22:07:44 pcneu vdr: [20700] closing SVDRP connection >>>>> Aug 29 22:07:44 pcneu vdr: [21581] receiver on device 10 thread >>>>> started (pid=20700, tid=21581) >>>>> Aug 29 22:07:44 pcneu vdr: [20700] connect from 127.0.0.1, port 49816 >>>>> - accepted >>>>> Aug 29 22:07:45 pcneu vdr: [20700] closing SVDRP connection >>>>> Aug 29 22:07:45 pcneu vdr: [21582] PvrReadThread of /dev/video2 thread >>>>> started (pid=20700, tid=21582) >>>>> Aug 29 22:07:45 pcneu vdr: [21580] frame type not in first packet of >>>>> payload - buffering >>>>> Aug 29 22:07:45 pcneu vdr: [21580] ERROR: too many bytes for frame >>>>> type buffer (2444 > 940) - dropped 2444 bytes >>>>> ... >>>> >>>> Can you please provide a 1 minute VDR recording from that device (made >>>> with the most recent >>>> developer version that works for you) and tell me where to download it? >>>> >>>> Klaus >>>> >>> >>> The upload to Sigi's FTP-Server has finished. >>> >>> The filename is problemvdr1720pvr3sat00001.ts ! >> >> Apparently in this file every TS packet that starts a new PES packet >> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) this >> should only be set for TS packets that contain the beginning of an >> actual payload unit (which may consist of several PES packets). >> >> So I would assume that the TS data is in error. Would that mean that the PUSI bit should only be set in packets where a picture start code is contained? > I would say this is the expected behaviour as one PES packet normally is one payload unit. The MPEG2 standard only > defines that when the PUSI bit is set a PES packet shall start in the payload of the TS packet. There is no other > limitation. I just know what Wikipedia tells me... :-) Lars. > > Andreas > > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
Hi, Am 02.09.2011 16:08, schrieb Klaus Schmidinger: > Apparently in this file every TS packet that starts a new PES packet > has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) > this > should only be set for TS packets that contain the beginning of an > actual payload unit (which may consist of several PES packets). > > So I would assume that the TS data is in error. I don't think that this assumption is correct. The playload start is related to carried payload only, i. e. PES packets in case of the video stream. And it would be sufficient to put there just a single byte of the PES packet to set this bit, i. e. the first 0x00 of the start code sequence 0x00, 0x00, 0x01. Furthermore it is specified that no second PES packet is allowed to start in the same TS packet. The PES layer itself has no access unit (= e. g. image) start indicator. But when a PTS is part of the PES header, it has to be applied to the first access unit (= e. g. image) which starts in that PES packet (once again, it would be sufficient to put there just the first byte of the start code sequence at the tail of the PES packet). So you may use the PTS flag as Access Unit Start Indicator ("AUSI"), which tells you that this PES packet will start a new image but you cannot tell where, i. e. it is likely that the PES packet will carry the tail of the previous image in front of the new image. Using the "AUSI" is only of hint quality as not every access unit (= e. g. image) will have a PTS attached. Some stations label only I frames while others label every frame or field. In video streams, it is common use to have PES packets with a zero length indicator which means the TS layer has to tell you where the next PES packet starts. So such streams are likely to have just a single PES packet per access unit (= e. g. image) and as a result you see the TS PUSI at the same time as the PES "AUSI". Bye.
On 02.09.2011 21:37, Reinhard Nissl wrote: > Hi, > > Am 02.09.2011 16:08, schrieb Klaus Schmidinger: > >> Apparently in this file every TS packet that starts a new PES packet >> has the "Payload Unit Start Indicator" flag set. Normally (AFAIK) >> this >> should only be set for TS packets that contain the beginning of an >> actual payload unit (which may consist of several PES packets). >> >> So I would assume that the TS data is in error. > > I don't think that this assumption is correct. The playload start is related to carried payload only, i. e. PES packets in case of the video stream. And it would be sufficient to put there just a single byte of the PES packet to set this bit, i. e. the first 0x00 of the start code sequence 0x00, > 0x00, 0x01. Furthermore it is specified that no second PES packet is allowed to start in the same TS packet. > > The PES layer itself has no access unit (= e. g. image) start indicator. But when a PTS is part of the PES header, it has to be applied to the first access unit (= e. g. image) which starts in that PES packet (once again, it would be sufficient to put there just the first byte of the start code > sequence at the tail of the PES packet). So you may use the PTS flag as Access Unit Start Indicator ("AUSI"), which tells you that this PES packet will start a new image but you cannot tell where, i. e. it is likely that the PES packet will carry the tail of the previous image in front of the new > image. Using the "AUSI" is only of hint quality as not every access unit (= e. g. image) will have a PTS attached. Some stations label only I frames while others label every frame or field. > > In video streams, it is common use to have PES packets with a zero length indicator which means the TS layer has to tell you where the next PES packet starts. So such streams are likely to have just a single PES packet per access unit (= e. g. image) and as a result you see the TS PUSI at the same > time as the PES "AUSI". Hmm, I guess you're right. Looks like it was sheer luck that this change fixed the problems with TS streams where the picture start code extends over two packets. I guess I'll go back to the earlier version then and make sure there are always at least two TS packets at the start of a payload to look at. Klaus
--- remux.c 2011/08/15 09:50:14 2.58 +++ remux.c 2011/08/19 15:33:26 @@ -974,8 +974,10 @@ payloadUnitOfFrame = (payloadUnitOfFrame + 1) % -framesPerPayloadUnit; if (payloadUnitOfFrame != 0 && independentFrame) payloadUnitOfFrame = 0; - if (payloadUnitOfFrame) + if (payloadUnitOfFrame) { + newPayload = false; newFrame = false; + } } if (framesPerPayloadUnit <= 1) scanning = false;