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