[Libav-user] Getting older PTS

[J Decker]

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

_______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20140430/8208eb49/attachment.html>