[Libav-user] Getting older PTS

[wm4]

On Wed, 30 Apr 2014 09:49:06 -0700
J Decker <d3ck0r at gmail.com> wrote:

> On Wed, Apr 30, 2014 at 3:05 AM, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Tue, 29 Apr 2014 12:13:01 -0700
> > J Decker <d3ck0r at gmail.com> wrote:
> >
> > > I had the same sort of sequential PTS in some videos; another place to
> > > ignore that and use your own frame count based PTS... like MP4 clips come
> > > in ticks, mkv come in milliseconds in the PTS and some are sequential
> > > counts (avi)  and even playing from disk I got backwards numbers
> >
> > Seems like you don't understand timestamps at all.
> >
> > First, PTS can go backwards on the packet level. This is because some
> > codecs reorder frames on decoding. Packet PTS are in encoded order, not
> > in display order, and the decoder will reorder the PTS to display order
> > for you (just like it reorders the decoded pictures). See AVFrame
> > fields for more info.
> >
> > Second, timestamps in ffmpeg are always relative to a timebase. The
> > timebase tells you in what units the PTS values are in. You just divide
> > the PTS by the timebase, and you get the time in seconds. The
> > demuxer will tell you the timebase; see AVStream.time_base.
> >
> 
> 
> if that was true, which is what the documentation would lead one to
> beleive... then I wouldn't need the three exceptions based on input format
> to figure how to use the PTS.
> 
> if( file->pFormatCtx->duration_estimation_method == AVFMT_DURATION_FROM_PTS
> )
> {
> if( file->pVideoCodecCtx->time_base.num == 1 &&
> file->pVideoCodecCtx->time_base.den > 50000 )
> 
> the PTS is already in milliseconds... so a value at the beginning '133'
> would not be unreasonable... applying the time_base ... 133 * 1 / 65535 =
> 0... so for most of the movie I get a 0 value if I use the time_base as
> suggested.
> 
> but that's not the topic... and I diverge

For e.g. Matroska, I get a time_base of 1/1000, which tells you that
the PTS is in milliseconds.