[vlc-devel] [PATCH] ts: fix applying pcr offset in PCRCheckDTS()

[Francois Cartegnie]

Le 09/03/2016 11:49, Petri Hintukainen a écrit :
>>
>> That's the problem. I've ran into random DVB regressions showing that
>> debug code, which I can't reproduce at will.
>> Waiting now to hit those since the offset on invalid dts fix.
> 
> I've tried with lot of DVB ts recordings that used to trigger the bug,
> but I can't reproduce this anymore either. So, at least the most common
> cases seem to be fixed.

This is a timing based issue. But if people are reporting it on mailing
list, that means it already happens too often.

> I can't see how it could be handled outside of ts demuxer. Data is left
> hanging there because of still frame PES length is unknown. And there
> is no next video frame (PUSI flag set) to trigger output before it is
> too late.
> 
> I don't know if it would make any sense to look at previous frames PCR
> -DTS difference too. That could add some more safety margin.
> We could apply the fix only if the stream had sane PTS-DTS margin
> earlier (or this is the first frame of the stream). I think most of
> those broken streams have i_pcroffset > 0 ?

Positive offset is correct. Early pcr isn't.

> Another possible check could be requiring two PCR packets with no video
> data in between.
> 
> Similar issue can be seen at the end of stream ; I think currently the
> last frame is not flushed from demuxer ?

That's just a flushing issue because no PCR arrives at the end.
That can be fixed when destroying pat.
But this won't prevent truncated frame length, as no timing will be sent.

>> If you have a reproduceable case without BD drive (ts dump), then I
>> could have a look at it.
> 
> Here's one such file (00399.m2ts):
> > 
> It starts with still frame, followed by long sequence of increasing PCR
> packets. At the end there's another still frame.

It starts with PCRs, frame and PCRs.
Can be fixed by checking all gathered data dts, when a pcr appears, and
commit that data.
Or checking the adaptation field which does the padding on the last
packet, but will fail if video payload aligns on TS payload.
Or check framing until end marker (see below).

> VLC doesn't seem to show the still frame (except with bluray input that
> adds end of sequence code), but ffplay shows the still image.

The spec says packet length = 0 is only valid for video streams, and the
video has end markers (0xB7).
So, the right fix, might be to pass packets directly to packetizer, and
not doing any packet 'gathering' for those streams at TS level.

That's what i'm trying right now.

Francois