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;
Hi Klaus,
On 19.08.2011 18:43, Klaus Schmidinger 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 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é
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 30.08.2011 19:40, Dirk Vornheder wrote:
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:
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
Hi,
Am 02.09.2011 16:08, schrieb Klaus Schmidinger:
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:
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
On Sun, Aug 21, 2011 at 1:20 PM, André Weidemann Andre.Weidemann@web.de wrote:
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!
-
Andreas Regel -
André Weidemann -
Arthur Konovalov -
Dirk Vornheder -
Klaus Schmidinger -
L. Hanisch -
Reinhard Nissl -
VDR User