[MPlayer-dev-eng] [PATCH] demuxer and MP_NOPTS_VALUE
zaek7q at gmx.net
Sat Apr 21 08:30:40 CEST 2007
let me repeat (and clarify) my interpretation of MP_NOPTS_VALUE and its
connection to correct_pts:
If correct_pts is set, MP_NOPTS_VALUE has to be used as pts value for
packets where no valid pts can be found/determined.
If correct_pts is not set, either MP_NOPTS_VALUE or 0 has to be used as
pts value for packets where no valid pts can be found/determined.
Is there a preference for either MP_NOPTS_VALUE or 0 in the latter setting?
On Sat, 21 Apr 2007 01:40:31 +0200, Uoti Urpala <uoti.urpala at pp1.inet.fi>
> On Fri, 2007-04-20 at 23:04 +0200, Christian Aistleitner wrote:
>> However, libmpdemux/demuxer.c initializes ds->pts to 0 and not
> I think it shouldn't matter much what the initialization value is. It
> might be used in some error case but 0 is probably no worse then. The
> whole ds->pts field is kind of a hack.
I think for people wanting to read code, it is important go give sound
initial values. If my above interpretation is correct, then setting
ds->pts to 0 regardless of correct_pts is misleading (at least it has been
>> Furthermore, fill_buffers handling does not respect pts of
>> MP_NOPTS_VALUE if correct_pts is not set.
> Maybe it would be nicer if it always tested for MP_NOPTS_VALUE, but it
> shouldn't matter with current code.
Actually, I wanted to post a patch to libmpdemux_mpg.c which corrects its
pts handling if no pts can be found (and a follow up patch, which imploves
edl handling with -oac copy). I cannot submit my patch, if there is no
well defined way to indicate missing pts values. So even if it does not
matter for the current code, it might matter for future code.
>> Is my understanding of MP_NOPTS_VALUE flawed?
> I think it's weird to talk about "understanding of MP_NOPTS_VALUE". It's
> just a #define and there's not much to understand about it in isolation.
> Not all uses of it need to have exactly the same semantics.
Are you serious?
More information about the MPlayer-dev-eng