[MPlayer-cvslog] r25951 - in trunk: cfg-mplayer.h libmpdemux/demux_lavf.c libmpdemux/demux_mkv.c libmpdemux/demux_real.c libmpdemux/demuxer.c libmpdemux/demuxer.h

Uoti Urpala uoti.urpala at pp1.inet.fi
Fri Feb 8 00:04:54 CET 2008


On Thu, 2008-02-07 at 22:40 +0100, Reimar Döffinger wrote:
> I intended to think of something better, but I just had no time to sit
> down and think about it.
> I did not think it is critical, both -correct-pts and -no-correct-pts are
> still available but I noticed I actually did not do this right...

I don't consider it critical (some audio packets with broken timestamps
should not cause total failure, and omitting pts of video packets would
cause problems even if done correctly). I just wasn't sure whether you
really were aware of the breakage.

> Currently attached patch is the least ugly, generally working approach I
> could come up with.

> -    if (user_correct_pts != 0)
> +    if (correct_pts != 0)

I'd revert these lines back to what they were before your earlier patch.
Functionally equivalent, but the original form of this line was "if
(correct_pts)" without the redundant "!= 0".


I think it would be better to set the final value of correct_pts based
on a check against demuxer type in demuxer.c where you now check
user_correct_pts. It would be a less general approach but it would keep
the code in one place. I think individual demuxers shouldn't directly
change a global setting like correct_pts. A full system to indicate how
timestamps from a demuxer should be handled would need more values (at
least 3: "real" dts which includes false/non-time values for packets at
which some standard decoder is not expected to produce output, strictly
proper pts which could be attached to frames and reordered by decoder,
and "non-proper" pts where all timestamps should be treated as real time
values but which cannot be trusted to be strictly properly ordered).




More information about the MPlayer-cvslog mailing list