[vlc-devel] [PATCH] mux/avformat: normalize pts and dts in AVPacket

[Filip Roséen]

Hi Francois,

On 2017-02-21 14:17, Francois Cartegnie wrote:

> Le 07/02/2017 à 13:15, Filip Roséen a écrit :
> 
> > These changes make sure that we start all timestamps at zero by
> > normalizing each outgoing timestamp to the relative distance from the
> > first entity received for each stream.
> 
> Seems wrong.
> 
> If stream is created late, it should be out of sync then, as the
> absolute offset dissapears.
> 
> http://streams.videolan.org/samples/V-codecs/h264/hdtv-interlaced/stz_split_top_bottom_field.ts

The incoming timestamps (as seen by the *muxer*) are not guaranteed to
start at any particular offset, which further means that there is no
way to know whether a "stream is created late".

All the *muxer* sees is a timestamp, and it will use that as the
starting offset for whatever it is muxing. The changes incorporated in
the proposed patch does not change any behavior in terms of
discontinuity, nor *"late starts"*.

There is no absolute starting point, all incoming timestamps are
relative to each other (not to `0`), ie. the *PCR*.

The proposed changes simply adjust the relative starting position so
that it is at `0`, in order to prevent what has already been explained
here:

 - https://mailman.videolan.org/pipermail/vlc-devel/2017-February/111420.html

> > +    return ( timestamp - *base ) * p_stream->time_base.den /
> > +           CLOCK_FREQ / p_stream->time_base.num;
> 
> Then what are the guarantees in the code that packet duration is still
> correct on output ? PTS(n) - PTS(n-1) == LENGTH(n)

The line you are referring to above is directly equivalent to what is
already in the codebase; if you foresee a problem with the line in
question I propose that this is discussed outside of this patch (as
the behavior is not new).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20170221/25d69946/attachment.html>