On 2021-02-26 23:20, Mark Filipak (ffmpeg) wrote:
On 2021-02-27 01:37, Jim DeLaHunt wrote:
On 2021-02-26 22:08, Mark Filipak (ffmpeg) wrote:
On 2021-02-27 00:55, Jim DeLaHunt wrote:
On 2021-02-26 18:36, Mark Filipak (ffmpeg) wrote:
That's exactly the point. It is not constant because ffmpeg
calculates frame times in integer milliseconds, and thereby
truncates or rounds.…
Mark, what makes you so sure that it is FFmpeg which is truncating
or rounding?
The issue, Jim, is not with the MKV above. The issue is with the
next video in the work flow: An MKV that was made from the MKV above
but with '-vf settb=expr=1/360000,showinfo'. That 'showinfo' should
have shown a 360000Hz time base. It does, but the PTSs are wrong.
Well, you are spinning up multiple issues, Mark.
It's all aspects of one issue, Jim.
Issue 1. Your contention that "ffmpeg calculates frame times in
integer milliseconds". This branch of the thread is about that claim
of yours.
Not quite. When I explicitly set TB to 1/360000 via
'settb=expr=1/360000', the resulting PTSs are wrong.
What FFmpeg does with the file `input1.mkv` when you apply the filter
'settb=expr=1/360000' is Issue 2. This is the part of the message for
Issue 1. Issue 1 is your contention that "ffmpeg calculates frame times
in integer milliseconds". Answer: No.
Answer: No, FFmpeg calculates frame times exactly. You authored the
input file to millisecond time resolution because that's what the
format you chose encourages.
I did not author to millisecond resolution. The encoder did that.
You used some tool to author `input1.mkv`. That tool authored to
millisecond resolution (so the evidence indicates). I won't quibble
about wheter it was you or the too that authored. The point is, that
file existed, and had millisecond resolution, before the FFmpeg
experiment you ran.
But that doesn't really matter, does it? If I take *any* video and
'settb=expr=1/360000', then the source's TB should be ignored,
shouldn't it?
What FFmpeg does with the file `input1.mkv` when you apply the filter
'settb=expr=1/360000' is Issue 2.
Issue 2. Given an input file `input1.mkv`, which has varying frame
times in millisecond resolution which add up to 1001 ms per 30
frames, when you apply the FFmpeg `settb` filter, why are the output
Presentation Timestamp (PTS) values 11880, 24120, 36000, … instead of
12012, 24024, 36036, …?
Answer: Because the input frame presentation times are 11,880/360,000
= 0.03300, 24,120/360,000 = 0.06700, 36,000/360,000 = 0.10000, …
which exactly matches the frame times of the input video, with a
360kHz time base.
The PTSs should be 12012, 24024, 36036 because
1001/30000*360000=12012, 12012+12012=24024, and 24024_12012=36036.
No, the PTSs and timebase which FFmpeg issues as a result of
'settb=expr=1/360000' should be computed from the frame times and time
base of the input video. The input video had frame times at millisecond
resolution (so the evidence indicates).
Perhaps you wish that the FFmpeg `settb` filter would adjust frame times
from the input video's varying, millisecond-resolution times to a
constant 1.001/30 second frame time. The `settb` filter doesn't do that.
It changes time base, preserves frame times, and changes PTS values to
reproduce the input frame times using the new time base. This is a
useful behaviour, and it is proper that `settb`.
Perhaps what you actually want is a different filter, one which takes an
input video with varying frame times in millisecond resolution, and
changes the frame times to exactly 1.001/30 seconds between frames. That
is different than forcing a 360kHz time base. That is adjusting frame
times from varying to constant. Hint: the `fps` filter does something
close to what you want, but you may find it repeats some frames and
drops others in a way you don't like. Try it, and see.
showinfo reports 11880, 24120, 36000 because that's what ffmpeg has
calculated based on rounded ms (milliseconds).
No, showinfo reports 11880, 24120, 36000 because that's what the input
video's frame times are. The input video does not have constant frame
time increments (so the evidence indicates).
Of course, (33ms/tick)*(360000ticks/s)=11880. That doesn't make it
right. It's not 12012 because 33.3[6..]ms has been rounded down to 33ms.
No, the reason it's not 12012 because the authoring tool rounded the
frame time of 33.3[6..]ms hdown to 33.00ms.
Imagine frame 1 of 4 videos: [elided]
I don't think these imaginary videos explain anything. They are just
entrenching your misunderstanding.
FFmpeg is taking the fps, turning it into rounded ms, then turning the
rounded ms into PTSs. That's not right. It should take the fps, turn
that into exact PTSs, and then turn exact PTSs into approx ms --
actually, ms is superfluous because codecs key into PTSs.
No, the encoding tool which generates the input1.mkv file is what is
taking the fps, turning it into rounded ms, then turning the rounded ms
into PTSs. Yes, that's not what you want. Your choice of the Matroska
container, and your acceptance of the default TimestampScale value of
1,000,000 for that encoding, appears to be the proximate cause of your
dissatisfaction.
Issue 3. What integer size does FFmpeg use to store PTS values? You
initiated this thread with that question, remember?
I know that MPEG PTS is 33 bits. I don't know for sure what ffmpeg does…
Well, you did ask the question of integer size at the start of the
thread. Sometimes, when you ask a question you don't really want the
answer to, you get the answer anyway.
…except that it doesn't set PTSs properly.
How FFmpeg sets PTSs, and whether it is proper or improper, is Issue 2.
See above. Answer: FFmpeg is computing correctly as you are asking it
to. Your input video does not have the constant frame rate which you want.
Best regards,
—Jim DeLaHunt
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
