4

What i seem to understand about PTS (Presentation Time Stamp) is that it is always coded in integer units of a time_base which is a fraction of time in seconds. We have the relationship time=PTS*time_base.

In contrast we have the frame index, usually noted "N" or "POS" in filter expression variables. When we assume a constant frame rate, we usually exploit the relationship N=time*frame_rate=PTS*time_base*frame_rate.

This is what we observe pretty much everywhere in ffmpeg, and especially in output of FFPROBE and showinfo filter, and the variables of setpts filter. All of the aforementionned modules make the clear distinction and naming between time,pts,n,position,frame_rate,time_base.

Well i admit that the drawtext filter prints the time when we access the "pts" function but i think it is an exceptional bad name.

Then i try a command like the following to extract all frames and try to identify them with frame PTS in the filename output of image2 muxer to compare them with the output of FFPROBE easily. SS skips the first second so we may confirm that it is not an index from zero, copyts keeps the source time stamps and vsync=0 guarantees that we output the frames exactly at the time of the source frames without losing or duplicating any. ffmpeg -ss 1 -copyts -i input.mp4 -vsync 0 -f image2 -frame_pts 1 output_%05d.jpg

When i use this command upon a file with frame_rate 25 fps, time_base 1/12800 second, and skip the first second like above, the first file is "output_025.jpg" while ffprobe shows that time 1 second is 12800 PTS. It confirms that PTS=N/frame_rate/time_base=25/25*12800=12800. Same calculus for any probed frame, just different set of PTS, time and position/index.

We should expect -FRAME_PTS to produce a PTS but we instead get the frame index in the filename.

This is also explicitly written in the documentations.

  • In ffmpeg image muxer doc : frame_pts If set to 1, expand the filename with pts from pkt->pts. Default value is 0.
  • In AVPacket Struct Reference : int64_t pts Presentation timestamp in AVStream->time_base units; the time at which the decompressed packet will be presented to the user.

Why is image2 muxer's -frame_pts incoherent like this ? Is it, that it is badly named, or is it, that the behaviour is incorrect ? Am I misunderstanding something ?

Is there a trick to get the PTS anyway in filename ? I do not need help to use an external tool to parse and rename the output but I would rather a much simpler method.

So far i only found this workaround by Gyan and another confused answer. Gyan https://superuser.com/a/1421195/549957 SuperNoobieAU4000 https://superuser.com/a/1479491/549957

With Gyan answer linked above my trouble is

  • understanding why -r option does not contradict -vsync 0 in a breaking way even though the documentation pretty much reads the opposite of each other, with -r one enabling to duplicate/remove frames and vsync 0 other disabling it
    • tldr why do i not get extra frame images when i increase -r, is it because of vsync 0 ?
  • what is a general rule to use the output frame rate to fake the PTS in place of the index ?
    • Gyan wrote about setting -r 1000 to write the number like miliseconds but i want a PTS
    • i think i can use the multiplicative inverse of the time_base as the -r frame rate to cheat the index into reflecting the PTS but i am not sure whether it will work consistently everywhere

1 Answer 1

3

The image2 muxer, by default, will set the time base of the output stream to be the inverse of the output frame rate. This is why I set -r 1000 with -vsync 0, to get an index equivalent to the milliseconds' value.

To keep the input stream time base, add -enc_time_base -1 as an output option.

1
  • Good, it works, even though it was unintuitive until learnt about the default time_base.
    – Link-akro
    Dec 20, 2020 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .