[MPlayer-dev-eng] [PATCH] reorder pts when needed

[Reimar Döffinger]

On Fri, Nov 25, 2011 at 08:07:06AM +0100, Dan Oscarsson wrote:
> tor 2011-11-24 klockan 19:21 +0100 skrev Reimar Döffinger:
> > On Thu, Nov 24, 2011 at 12:40:09PM +0100, Dan Oscarsson wrote:
> > > sön 2011-11-13 klockan 19:24 +0100 skrev Dan Oscarsson:
> > > > Do not know if this patch was lost but it is needed to get h264 data  in
> > > > mpeg_ts demuxed streams to work correctly. Without it the pts values are
> > > > not in order. I suspect that h264 encoded data in other demuxers would
> > > > also not be in order without it.
> > > 
> > > Nobody interested in getting this fixed?
> > 
> > The point of -nocorrect-pts mode is to work with slightly incorrect pts
> > value.
> 
> When pts values are out of order it is not slight.

It is at most one consecutive PTS value that is wrong and it's only by a
few frame times.
Compared to some possibly really corrupt streams that is minimal.
Particularly since we would usually have one or more following PTS
values.

> > Just fixing the timestamps for one specific problematic case is more
> > hiding the issue than fixing it, even if it makes sense as an additional
> > improvement to a real fix.
> 
> I have the feeling that nobody is going to fix the bad demux_* demuxers
> so they do "correct_pts". From my experience, the demuxer I have used
> that do not set correct_pts generate good enough pts values execpt those
> that do not have pts values in order. In my own patches I have code
> reduces the error in the slightly bad pts values (and the errors in the
> so called correct_pts demuxers) but I cannot fix out of order pts values
> that easy.

What do you consider "slightly bad" when out of order doesn't qualify?
If it can handle actually corrupted pts values I'd expect it should
handle reordering as well, at most hierarchical B might cause problems.