On 2021-02-26 18:36, Mark Filipak (ffmpeg) wrote:
On 2021-02-26 20:42, Jim DeLaHunt wrote:
On 2021-02-26 17:24, Mark Filipak (ffmpeg) wrote:
'ffmpeg -i input.mkv -vf "showinfo" -codec:a copy -codec:s copy -dn
output.mkv'
[Parsed_showinfo_0 @ 0000013c877124c0] n: 1 pts: 33
pts_time:0.033 pos: 10052 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:B checksum:3CF10BFE plane_checksum:[64208370 00B13226
C5775659] mean:[25 126 131 ] stdev:[12.8 6.1 1.6 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n: 2 pts: 67
pts_time:0.067 pos: 9213 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:B checksum:23A8A65F plane_checksum:[90DC2AA6 37E908C8
779972F1] mean:[27 125 132 ] stdev:[14.8 7.1 1.9 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n: 3 pts: 100
pts_time:0.1 pos: 11086 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:B checksum:1CDF7A80 plane_checksum:[089DE80E C537F4C0
8C4E9D94] mean:[29 125 132 ] stdev:[15.2 6.6 2.3 ]
…[elided for brevity]…
[Parsed_showinfo_0 @ 0000013c877124c0] n: 28 pts: 934
pts_time:0.934 pos: 45167 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:B checksum:8D724A43 plane_checksum:[CD1CE198 DC377EA5
3D51E9E8] mean:[70 113 148 ] stdev:[46.3 11.6 11.5 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n: 29 pts: 968
pts_time:0.968 pos: 40163 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:P checksum:8F6C0D42 plane_checksum:[385DA9F1 7EA37D5A
AD78E5D9] mean:[70 113 148 ] stdev:[46.6 11.6 11.5 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n: 30 pts: 1001
pts_time:1.001 pos: 50467 fmt:yuv420p sar:32/27 s:240x236 i:P
iskey:0 type:B checksum:B511B7BA plane_checksum:[9C9A49A0 B1D583BA
FA0EEA51] mean:[70 113 148 ] stdev:[46.5 11.4 11.6 ]
This output shows a stream which has a varying frame rate. The change
in pts_time is not constant from frame to frame.
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?
Here's an alternate explanation: the tool which generated input1.mkv was
what calculated frame times in integer milliseconds, and thereby
truncated or rounded. That tool used millisecond time resolution,
because that is what the Matroska format encourages. FFmpeg is
faithfully reproducing the varying frame rates and millisecond
resolution which input1.mkv contains.
On 2021-02-26 20:14, Gyan Doshi wrote:
The Matroska timebase is insufficient to precisely store 29.97 fps
timestamps. Nothing to do with ffmpeg.
Gyan is helpful and informative, so let's dig into what Gyan said a
little more. The extension `.mkv` indicates that file `input1.mkv` has a
Matroska container. Take a look at the Matroska specification, section
"TimestampScale"
(https://www.matroska.org/technical/notes.html#timestampscale):
"The TimestampScale Element is used to calculate the Raw Timestamp of a
Block. The timestamp is obtained by adding the Block’s timestamp to the
Cluster’s Timestamp Element, and then multiplying that result by the
TimestampScale. The result will be the Block’s Raw Timestamp in
nanoseconds.… the default value of TimestampScale is 1000000."
The Matroska format stores timestamps as integers. Those integers are
multiplied by the integer TimestampScale value to get times in
nanoseconds. The default value of TimestampScale is 1000000. So the
default resolution of timestamps in MKV containers is 1,000,000
nanoseconds, or 1 millisecond.
So, Mark, unless your test file `input1.mkv` was specially crafted, it
will have a time resolution of 1 ms. The truncation or rounding would
happen as that file was authored.
And, if you want to prove your assertion that it is FFmpeg which is
truncating or rounding, I suggest you follow Carl's good advice:
On 2021-02-26 19:53, Carl Zwanzig wrote:
Instead of using unknown data*, I suggest making your own test video
so you're absolutely sure of all the parameters.… I'd also consider
different containers.
There may also be some test files you can download that can be trusted.
*Unless _known_ to be fully compliant and well-formed, it's not
precision test data; get as close to a primary standard as possible. I
would not trust an extract from a generic dvd until verified as correct.
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".
