[vdr] Fix for recording problem in VDR 1.7.20
Klaus.Schmidinger at tvdr.de
Fri Sep 2 23:05:41 CEST 2011
On 02.09.2011 21:37, Reinhard Nissl wrote:
> 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)
>> 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.
More information about the vdr