How can I force a 360kHz time base?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
How can I force ffmpeg to use a 360kHz time base? (I spent 1/2 day searching.)

Thanks!
Mark.


With a 1kHz time base:
65535 = largest 16-bit integer.
0:01:05.535 = longest running time for 16-bit integer with 1kHz time base..
Conclusion: FFmpeg cannot be using 16-bit integers.
16777215 = largest 24-bit integer.
4:39:37.215 = longest running time for 24-bit integer with 1kHz time base.
Conclusion: FFmpeg could use 24-bit integers if time base is capped at 1kHz.

With a 90kHz time base:
16777215 = largest 24-bit integer.
00:03:06.4135 = longest running time for 24-bit integer with 90kHz time base.
Conclusion: FFmpeg cannot be using 24-bit integers.
4294967295 = largest 32-bit integer.
13:15:21.8588[3..] = longest running time for 32-bit integer with 90kHz time base.
24/1.001fps ==> deltaPTS = 3753.75.
24fps ==> deltaPTS = 3750.
25fps ==> deltaPTS = 3600.
30/1.001fps ==> deltaPTS = 3003.
30fps ==> deltaPTS = 3000.
50fps ==> deltaPTS = 1875.
60/1.001fps ==> deltaPTS = 1501.5.
60fps ==> deltaPTS = 1500.
Conclusion: Since 24/1.001fps requires rounding, a 90kHz time base is not optimal.

With a 360kHz time base:
4294967295 = largest 32-bit integer.
3:18:50.464708[3..] = longest running time for 32-bit integer with 360kHz time base.
24/1.001fps ==> deltaPTS = 15015.
24fps ==> deltaPTS = 15000.
25fps ==> deltaPTS = 14400.
30/1.001fps ==> deltaPTS = 12012.
30fps ==> deltaPTS = 12000.
50fps ==> deltaPTS = 7200.
60/1.001fps ==> deltaPTS = 6006.
60fps ==> deltaPTS = 6000.
100fps ==> deltaPTS = 3600.
120/1.001fps ==> deltaPTS = 3003.
120fps ==> deltaPTS = 3000.
Conclusion: A 360kHz time base is optimal, even for 100fps & 120fps.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Paul B Mahol
Ever looked at (a)settb filter?

On Fri, Feb 26, 2021 at 9:38 PM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> How can I force ffmpeg to use a 360kHz time base? (I spent 1/2 day
> searching.)
>
> Thanks!
> Mark.
>
>
> With a 1kHz time base:
> 65535 = largest 16-bit integer.
> 0:01:05.535 = longest running time for 16-bit integer with 1kHz time base..
> Conclusion: FFmpeg cannot be using 16-bit integers.
> 16777215 = largest 24-bit integer.
> 4:39:37.215 = longest running time for 24-bit integer with 1kHz time base.
> Conclusion: FFmpeg could use 24-bit integers if time base is capped at
> 1kHz.
>
> With a 90kHz time base:
> 16777215 = largest 24-bit integer.
> 00:03:06.4135 = longest running time for 24-bit integer with 90kHz time
> base.
> Conclusion: FFmpeg cannot be using 24-bit integers.
> 4294967295 = largest 32-bit integer.
> 13:15:21.8588[3..] = longest running time for 32-bit integer with 90kHz
> time base.
> 24/1.001fps ==> deltaPTS = 3753.75.
> 24fps ==> deltaPTS = 3750.
> 25fps ==> deltaPTS = 3600.
> 30/1.001fps ==> deltaPTS = 3003.
> 30fps ==> deltaPTS = 3000.
> 50fps ==> deltaPTS = 1875.
> 60/1.001fps ==> deltaPTS = 1501.5.
> 60fps ==> deltaPTS = 1500.
> Conclusion: Since 24/1.001fps requires rounding, a 90kHz time base is not
> optimal.
>
> With a 360kHz time base:
> 4294967295 = largest 32-bit integer.
> 3:18:50.464708[3..] = longest running time for 32-bit integer with 360kHz
> time base.
> 24/1.001fps ==> deltaPTS = 15015.
> 24fps ==> deltaPTS = 15000.
> 25fps ==> deltaPTS = 14400.
> 30/1.001fps ==> deltaPTS = 12012.
> 30fps ==> deltaPTS = 12000.
> 50fps ==> deltaPTS = 7200.
> 60/1.001fps ==> deltaPTS = 6006.
> 60fps ==> deltaPTS = 6000.
> 100fps ==> deltaPTS = 3600.
> 120/1.001fps ==> deltaPTS = 3003.
> 120fps ==> deltaPTS = 3000.
> Conclusion: A 360kHz time base is optimal, even for 100fps & 120fps.
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
On 2021-02-26 15:51, Paul B Mahol wrote:
> Ever looked at (a)settb filter
Thank you, Paul.

'ffmpeg -i input.mkv -vf "settb=expr=1/360000,showinfo" -codec:a copy -codec:s copy -dn output.mkv'
partial output shown below.

input.mkv is 30.1.001fps constant frame rate. I expected deltaPTS to be 12012.

Look at the 1st frame:
(0.033s/frame)*(360000ticks/s) = 11880ticks/frame,
instead of:
((1.001/30)s/frame)*(360000ticks/s) = 12012ticks/frame.

Why is that? It destroys the resolution improvement of the 1/(360000Hz) time base.

[Parsed_showinfo_1 @ 00000211128f2340] n:   1 pts:  11880 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_1 @ 00000211128f2340] n:   2 pts:  24120 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_1 @ 00000211128f2340] n:   3 pts:  36000 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]
[Parsed_showinfo_1 @ 00000211128f2340] n:   4 pts:  47880 pts_time:0.133   pos:     7431 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:119710AA plane_checksum:[D43E9018 B24CC548 E7AABB2C]
mean:[31 124 133] stdev:[17.0 7.3 2.6]
[Parsed_showinfo_1 @ 00000211128f2340] n:   5 pts:  60120 pts_time:0.167   pos:    15291 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DD84243C plane_checksum:[DC606F90 0745C015 944BF479]
mean:[33 124 134] stdev:[17.3 7.0 3.0]
[Parsed_showinfo_1 @ 00000211128f2340] n:   6 pts:  72000 pts_time:0.2     pos:    14140 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DC5702F7 plane_checksum:[58664923 D8779F91 07D31A34]
mean:[35 123 135] stdev:[19.0 7.5 3.4]
[Parsed_showinfo_1 @ 00000211128f2340] n:   7 pts:  84240 pts_time:0.234   pos:    15885 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:982F77C4 plane_checksum:[F9629DEA F0FC9662 7B844369]
mean:[37 123 135] stdev:[18.5 6.3 3.9]
[Parsed_showinfo_1 @ 00000211128f2340] n:   8 pts:  96120 pts_time:0.267   pos:    11959 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:E1FE3E48 plane_checksum:[D4B07602 1B8663D0 32DC6467]
mean:[39 122 136] stdev:[21.1 7.8 4.2]
[Parsed_showinfo_1 @ 00000211128f2340] n:   9 pts: 108000 pts_time:0.3     pos:    18831 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:3E3AB9E7 plane_checksum:[62FDF2C3 E42D414E 4F1C85C7]
mean:[40 121 137] stdev:[21.8 7.4 4.6]
[Parsed_showinfo_1 @ 00000211128f2340] n:  10 pts: 120240 pts_time:0.334   pos:    19527 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:D0BF9974 plane_checksum:[5C16D379 A215196E 670BAC7E]
mean:[43 121 137] stdev:[24.9 9.6 5.0]
[Parsed_showinfo_1 @ 00000211128f2340] n:  11 pts: 132120 pts_time:0.367   pos:    16969 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:1FCDAD4B plane_checksum:[0873F57B 209AF8E2 FCD5BED0]
mean:[44 120 138] stdev:[24.9 8.9 5.4]
[Parsed_showinfo_1 @ 00000211128f2340] n:  12 pts: 144000 pts_time:0.4     pos:    20576 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:6B674664 plane_checksum:[83DC7146 501EEC71 B06DE88F]
mean:[46 120 138] stdev:[26.4 9.5 5.7]
[Parsed_showinfo_1 @ 00000211128f2340] n:  13 pts: 156240 pts_time:0.434   pos:    24416 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:4B39A727 plane_checksum:[7D7DCD8D 9002D009 66A90982]
mean:[47 119 139] stdev:[27.6 9.2 6.1]
[Parsed_showinfo_1 @ 00000211128f2340] n:  14 pts: 168120 pts_time:0.467   pos:    25561 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:F6E060FD plane_checksum:[0ED972ED 6DF5BBA0 849B3261]
mean:[49 119 140] stdev:[29.2 9.7 6.5]
[Parsed_showinfo_1 @ 00000211128f2340] n:  15 pts: 180360 pts_time:0.501   pos:    22146 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:6C3D4C60 plane_checksum:[D0A87196 9AB1975E 4494435D]
mean:[50 118 140] stdev:[30.3 9.6 6.9]
[Parsed_showinfo_1 @ 00000211128f2340] n:  16 pts: 192240 pts_time:0.534   pos:    29758 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:B80E35AE plane_checksum:[3EEE2D48 B4148D20 9EEF7B37]
mean:[52 118 141] stdev:[31.8 10.0 7.3]
[Parsed_showinfo_1 @ 00000211128f2340] n:  17 pts: 204120 pts_time:0.567   pos:    28824 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:E02EB74A plane_checksum:[C9839D7E 70D47B70 E2C89E4D]
mean:[54 118 142] stdev:[32.7 9.2 7.7]
[Parsed_showinfo_1 @ 00000211128f2340] n:  18 pts: 216360 pts_time:0.601   pos:    30300 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DE1E3F2D plane_checksum:[C8B7238E A1D25AA7 F52CC0E9]
mean:[56 117 142] stdev:[34.7 10.3 8.2]
[Parsed_showinfo_1 @ 00000211128f2340] n:  19 pts: 228240 pts_time:0.634   pos:    26532 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:04DA490F plane_checksum:[0FCB36A9 40BA3BF4 9FABD663]
mean:[57 117 143] stdev:[35.7 10.2 8.6]
[Parsed_showinfo_1 @ 00000211128f2340] n:  20 pts: 240120 pts_time:0.667   pos:    33345 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:B27FEF95 plane_checksum:[B411D21D 52F61823 32E10555]
mean:[59 116 144] stdev:[37.4 10.8 9.1]
[Parsed_showinfo_1 @ 00000211128f2340] n:  21 pts: 252360 pts_time:0.701   pos:    31240 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:33AAFEA0 plane_checksum:[7945E1E2 4DF0022A B0801A94]
mean:[60 116 144] stdev:[38.3 10.4 9.4]
[Parsed_showinfo_1 @ 00000211128f2340] n:  22 pts: 264240 pts_time:0.734   pos:    38152 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:BCCBA0B6 plane_checksum:[1F165EA3 BE8CFC55 FA1A45AF]
mean:[62 116 145] stdev:[39.6 10.8 9.7]
[Parsed_showinfo_1 @ 00000211128f2340] n:  23 pts: 276120 pts_time:0.767   pos:    36999 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:2C47A2CA plane_checksum:[DCB94D3D A49BDC55 52257929]
mean:[64 115 146] stdev:[40.9 10.6 10.2]
[Parsed_showinfo_1 @ 00000211128f2340] n:  24 pts: 288360 pts_time:0.801   pos:    39218 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:2910BBE9 plane_checksum:[E4705C5F 9BB7BCCD 5575A2AE]
mean:[66 114 146] stdev:[42.7 11.0 10.6]
[Parsed_showinfo_1 @ 00000211128f2340] n:  25 pts: 300240 pts_time:0.834   pos:    34109 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:495B2593 plane_checksum:[B62FC80E 12CA9E04 2511BF63]
mean:[68 114 147] stdev:[44.1 11.0 11.1]
[Parsed_showinfo_1 @ 00000211128f2340] n:  26 pts: 312480 pts_time:0.868   pos:    44416 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:F3D875F1 plane_checksum:[EA0508D3 A5C68F7A 1FB0DD95]
mean:[69 114 147] stdev:[45.3 11.4 11.3]
[Parsed_showinfo_1 @ 00000211128f2340] n:  27 pts: 324360 pts_time:0.901   pos:    43409 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:95CF8E78 plane_checksum:[C7B319BE 35EC8591 A12FEF1A]
mean:[71 113 148] stdev:[46.3 10.8 11.5]
[Parsed_showinfo_1 @ 00000211128f2340] n:  28 pts: 336240 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_1 @ 00000211128f2340] n:  29 pts: 348480 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_1 @ 00000211128f2340] n:  30 pts: 360360 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]
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Paul B Mahol
This is math question, and does not belong here.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
On 2021-02-26 18:49, Paul B Mahol wrote:
> This is math question, and does not belong here.

Yes, it's a math question. I'm questioning how ffmpeg is doing math.

By converting TB to periods with millisecond resolution, it limits temporal resolution to 1 part in
1000 parts no matter what the time base is. Attempting to increase resolution by shifting to a
higher time base changes the number of bit of PTS but has no affect on resolution. And it's
resolution (or lack thereof) that causes the problems that ffmpeg clearly has.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Paul B Mahol
On Sat, Feb 27, 2021 at 1:01 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> On 2021-02-26 18:49, Paul B Mahol wrote:
> > This is math question, and does not belong here.
>
> Yes, it's a math question. I'm questioning how ffmpeg is doing math.
>
> By converting TB to periods with millisecond resolution, it limits
> temporal resolution to 1 part in
> 1000 parts no matter what the time base is. Attempting to increase
> resolution by shifting to a
> higher time base changes the number of bit of PTS but has no affect on
> resolution. And it's
> resolution (or lack thereof) that causes the problems that ffmpeg clearly
> has.
>

FFmpeg have no such problem you want to put it on.

Get troll and spread lies somewhere else.

You are constantly being rude and try to badmouth ffmpeg on daily basis.

Also you never provide any useful logs, or inputs.


>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
On 2021-02-26 19:06, Paul B Mahol wrote:

> On Sat, Feb 27, 2021 at 1:01 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> On 2021-02-26 18:49, Paul B Mahol wrote:
>>> This is math question, and does not belong here.
>>
>> Yes, it's a math question. I'm questioning how ffmpeg is doing math.
>>
>> By converting TB to periods with millisecond resolution, it limits
>> temporal resolution to 1 part in
>> 1000 parts no matter what the time base is. Attempting to increase
>> resolution by shifting to a
>> higher time base changes the number of bit of PTS but has no affect on
>> resolution. And it's
>> resolution (or lack thereof) that causes the problems that ffmpeg clearly
>> has.
>>
>
> FFmpeg have no such problem you want to put it on.
>
> Get troll and spread lies somewhere else.

What lies? What have I written that's not 100% true as shown by ffmpeg's own outputs?

> You are constantly being rude and try to badmouth ffmpeg on daily basis.

What rudeness? I have been courteous to you, always. What badmouthing? All I've done is point out
unnecessary loss of resolution that hasn't been disputed. Do you dispute it?

> Also you never provide any useful logs, or inputs.

I provided the showinfo input and output to you. What more do you need?

Are you over your head here, Paul? Let's work on the time base problems together. I'm sure that
would make everyone happier, including you, and including me.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by Paul B Mahol
Let's wipe the screen between us.

What I'm suggesting is that ffmpeg convert to a single, 360000Hz time base for all videos, for all
time. Then, rounding errors would be *zero*. PTSs would be exact.

FFmpeg is superior because, instead of frame numbers, ffmpeg uses PTSs. That decision was very wise.
FFmpeg falls short when frame times or durations must be truncated or rounded to fit into the
millisecond scheme. Well, dump the millisecond scheme.

With a single, uniform, 360000Hz time base, ffmpeg could treat PTS in the same way that other video
apps treat frame numbers, as integers.

Just think about it, eh?

Regards,
Mark.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-26 15:40, Mark Filipak (ffmpeg) wrote:

> 'ffmpeg -i input.mkv -vf "settb=expr=1/360000,showinfo" -codec:a copy
> -codec:s copy -dn output.mkv'
> partial output shown below.
>
> input.mkv is 30.1.001fps constant frame rate. I expected deltaPTS to
> be 12012.
>
> Look at the 1st frame:
> (0.033s/frame)*(360000ticks/s) = 11880ticks/frame,
> instead of:
> ((1.001/30)s/frame)*(360000ticks/s) = 12012ticks/frame.
>
> Why is that? It destroys the resolution improvement of the
> 1/(360000Hz) time base.
>
> [Parsed_showinfo_1 @ 00000211128f2340] n:   1 pts:  11880
> 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_1 @ 00000211128f2340] n:   2 pts:  24120
> 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_1 @ 00000211128f2340] n:   3 pts:  36000
> 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_1 @ 00000211128f2340] n:  28 pts: 336240
> 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_1 @ 00000211128f2340] n:  29 pts: 348480
> 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_1 @ 00000211128f2340] n:  30 pts: 360360
> 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]


Does input1.mkv in fact have a constant frame rate of 24/1.001
frames/second?  If you remove the settb video filter, and just use
showinfo, what pts and pts_time values does it report for the first 30
frames of input1.mkv?

It's important that input1.mkv have a constant Presentation Timestamp
(PTS) increment, and a constant timebase which is a multiple of 24/1.001
ticks/second. Obviously.

       —Jim DeLaHunt


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
On 2021-02-26 20:05, Jim DeLaHunt wrote:

> On 2021-02-26 15:40, Mark Filipak (ffmpeg) wrote:
>
>> 'ffmpeg -i input.mkv -vf "settb=expr=1/360000,showinfo" -codec:a copy -codec:s copy -dn output.mkv'
>> partial output shown below.
>>
>> input.mkv is 30.1.001fps constant frame rate. I expected deltaPTS to be 12012.
>>
>> Look at the 1st frame:
>> (0.033s/frame)*(360000ticks/s) = 11880ticks/frame,
>> instead of:
>> ((1.001/30)s/frame)*(360000ticks/s) = 12012ticks/frame.
>>
>> Why is that? It destroys the resolution improvement of the 1/(360000Hz) time base.
>>
>> [Parsed_showinfo_1 @ 00000211128f2340] n:   1 pts:  11880 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_1 @ 00000211128f2340] n:   2 pts:  24120 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_1 @ 00000211128f2340] n:   3 pts:  36000 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_1 @ 00000211128f2340] n:  28 pts: 336240 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_1 @ 00000211128f2340] n:  29 pts: 348480 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_1 @ 00000211128f2340] n:  30 pts: 360360 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]
>
>
> Does input1.mkv in fact have a constant frame rate of 24/1.001 frames/second?

No, it has a constant frame rate of 30/1.001 frames/second.

 > On 2021-02-26 15:40, Mark Filipak (ffmpeg) wrote:
 >> input.mkv is 30.1.001fps constant frame rate. I expected deltaPTS to be 12012.


'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 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   4 pts:    133 pts_time:0.133   pos:     7431 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:119710AA plane_checksum:[D43E9018 B24CC548 E7AABB2C]
mean:[31 124 133 ] stdev:[17.0 7.3 2.6 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   5 pts:    167 pts_time:0.167   pos:    15291 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DD84243C plane_checksum:[DC606F90 0745C015 944BF479]
mean:[33 124 134 ] stdev:[17.3 7.0 3.0 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   6 pts:    200 pts_time:0.2     pos:    14140 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DC5702F7 plane_checksum:[58664923 D8779F91 07D31A34]
mean:[35 123 135 ] stdev:[19.0 7.5 3.4 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   7 pts:    234 pts_time:0.234   pos:    15885 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:982F77C4 plane_checksum:[F9629DEA F0FC9662 7B844369]
mean:[37 123 135 ] stdev:[18.5 6.3 3.9 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   8 pts:    267 pts_time:0.267   pos:    11959 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:E1FE3E48 plane_checksum:[D4B07602 1B8663D0 32DC6467]
mean:[39 122 136 ] stdev:[21.1 7.8 4.2 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:   9 pts:    300 pts_time:0.3     pos:    18831 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:3E3AB9E7 plane_checksum:[62FDF2C3 E42D414E 4F1C85C7]
mean:[40 121 137 ] stdev:[21.8 7.4 4.6 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  10 pts:    334 pts_time:0.334   pos:    19527 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:D0BF9974 plane_checksum:[5C16D379 A215196E 670BAC7E]
mean:[43 121 137 ] stdev:[24.9 9.6 5.0 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  11 pts:    367 pts_time:0.367   pos:    16969 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:1FCDAD4B plane_checksum:[0873F57B 209AF8E2 FCD5BED0]
mean:[44 120 138 ] stdev:[24.9 8.9 5.4 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  12 pts:    400 pts_time:0.4     pos:    20576 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:6B674664 plane_checksum:[83DC7146 501EEC71 B06DE88F]
mean:[46 120 138 ] stdev:[26.4 9.5 5.7 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  13 pts:    434 pts_time:0.434   pos:    24416 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:4B39A727 plane_checksum:[7D7DCD8D 9002D009 66A90982]
mean:[47 119 139 ] stdev:[27.6 9.2 6.1 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  14 pts:    467 pts_time:0.467   pos:    25561 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:F6E060FD plane_checksum:[0ED972ED 6DF5BBA0 849B3261]
mean:[49 119 140 ] stdev:[29.2 9.7 6.5 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  15 pts:    501 pts_time:0.501   pos:    22146 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:6C3D4C60 plane_checksum:[D0A87196 9AB1975E 4494435D]
mean:[50 118 140 ] stdev:[30.3 9.6 6.9 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  16 pts:    534 pts_time:0.534   pos:    29758 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:B80E35AE plane_checksum:[3EEE2D48 B4148D20 9EEF7B37]
mean:[52 118 141 ] stdev:[31.8 10.0 7.3 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  17 pts:    567 pts_time:0.567   pos:    28824 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:E02EB74A plane_checksum:[C9839D7E 70D47B70 E2C89E4D]
mean:[54 118 142 ] stdev:[32.7 9.2 7.7 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  18 pts:    601 pts_time:0.601   pos:    30300 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:DE1E3F2D plane_checksum:[C8B7238E A1D25AA7 F52CC0E9]
mean:[56 117 142 ] stdev:[34.7 10.3 8.2 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  19 pts:    634 pts_time:0.634   pos:    26532 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:04DA490F plane_checksum:[0FCB36A9 40BA3BF4 9FABD663]
mean:[57 117 143 ] stdev:[35.7 10.2 8.6 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  20 pts:    667 pts_time:0.667   pos:    33345 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:B27FEF95 plane_checksum:[B411D21D 52F61823 32E10555]
mean:[59 116 144 ] stdev:[37.4 10.8 9.1 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  21 pts:    701 pts_time:0.701   pos:    31240 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:33AAFEA0 plane_checksum:[7945E1E2 4DF0022A B0801A94]
mean:[60 116 144 ] stdev:[38.3 10.4 9.4 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  22 pts:    734 pts_time:0.734   pos:    38152 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:BCCBA0B6 plane_checksum:[1F165EA3 BE8CFC55 FA1A45AF]
mean:[62 116 145 ] stdev:[39.6 10.8 9.7 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  23 pts:    767 pts_time:0.767   pos:    36999 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:2C47A2CA plane_checksum:[DCB94D3D A49BDC55 52257929]
mean:[64 115 146 ] stdev:[40.9 10.6 10.2 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  24 pts:    801 pts_time:0.801   pos:    39218 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:2910BBE9 plane_checksum:[E4705C5F 9BB7BCCD 5575A2AE]
mean:[66 114 146 ] stdev:[42.7 11.0 10.6 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  25 pts:    834 pts_time:0.834   pos:    34109 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:P checksum:495B2593 plane_checksum:[B62FC80E 12CA9E04 2511BF63]
mean:[68 114 147 ] stdev:[44.1 11.0 11.1 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  26 pts:    868 pts_time:0.868   pos:    44416 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:F3D875F1 plane_checksum:[EA0508D3 A5C68F7A 1FB0DD95]
mean:[69 114 147 ] stdev:[45.3 11.4 11.3 ]
[Parsed_showinfo_0 @ 0000013c877124c0] n:  27 pts:    901 pts_time:0.901   pos:    43409 fmt:yuv420p
sar:32/27 s:240x236 i:P iskey:0 type:B checksum:95CF8E78 plane_checksum:[C7B319BE 35EC8591 A12FEF1A]
mean:[71 113 148 ] stdev:[46.3 10.8 11.5 ]
[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 ]

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-26 16:53, Mark Filipak (ffmpeg) wrote:

> …What I'm suggesting is that ffmpeg convert to a single, 360000Hz time
> base for all videos, for all time. Then, rounding errors would be
> *zero*. PTSs would be exact. …


As I told you back on 23. February, ffmpeg uses a timebase that is a
rational number, and is an attribute of the video stream, and can take
various values. The timebase could be 1/360000, or 1/24, or 1001/24000.
This already allows integer Presentation TImestamp (PTS) values to
represent time values with zero rounding errors. You dismissed that as
"The Matrix", but this is in fact the data structure which FFmpeg
already uses.

Of course, to achieve zero rounding errors, the input video, and the
user writing the FFmpeg command line, and FFmpeg itself, must all make
wise choices so that the timebase is set to a rational number which
suits the data.

I don't think it is wise for FFmpeg to switch from its present flexible
data structure to a constant, 1/360000 value for timebase. The examples
you present do not make the case for such a change.

If you can establish that FFmpeg is imposing a 1/1000 timebase on a
video with a 1001/24000 timebase, leading to rounding errors, that is
evidence of a bug in FFmpeg's timebase calculation or something. It is
not evidence of the timebase data structure being inadequate.


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

FFmpeg-users mailing list
In reply to this post by Mark Filipak (ffmpeg)
 

    On Saturday, 27 February 2021, 01:27:22 GMT, Mark Filipak (ffmpeg) <[hidden email]> wrote:  
 
> No, it has a constant frame rate of 30/1.001 frames/second.
I'm not really following this, but one question which may be worth asking is where did you get this file, and what is its provenance?
The reason I ask is that many files, especially those from cellphones, emphatically do not have constant frame rate and can tremendously complicate the sort of testing you seem to be interested in.
P  
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-26 17:24, Mark Filipak (ffmpeg) wrote:

> On 2021-02-26 20:05, Jim DeLaHunt wrote:
>> Does input1.mkv in fact have a constant frame rate of 24/1.001
>> frames/second?
>
> No, it has a constant frame rate of 30/1.001 frames/second.

Sorry, my mistake.  I should have said, "Does input1.mkv in fact have a
constant frame rate of 30/1.001 frames/second?"


> '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.

Can you get some output which shows the timebase value, or the frame
times, of input1.mkv, showing that there is a timebase which is a
multiple of 1.001/30, or showing that the time value of each frame
increments by a constant amount?

So far, the output you show is consistent with an input1.mkv which has a
varying frame rate that is 30/1.001 fps, distorted to fit a 1/1000
timebase. Can you show a diagnostic which eliminates that possibility?

     —Jim DeLaHunt


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by Jim DeLaHunt-2
On 2021-02-26 20:32, Jim DeLaHunt wrote:

> On 2021-02-26 16:53, Mark Filipak (ffmpeg) wrote:
>
>> …What I'm suggesting is that ffmpeg convert to a single, 360000Hz time base for all videos, for
>> all time. Then, rounding errors would be *zero*. PTSs would be exact. …
>
>
> As I told you back on 23. February, ffmpeg uses a timebase that is a rational number, and is an
> attribute of the video stream, and can take various values. The timebase could be 1/360000, or 1/24,
> or 1001/24000. This already allows integer Presentation TImestamp (PTS) values to represent time
> values with zero rounding errors. You dismissed that as "The Matrix", but this is in fact the data
> structure which FFmpeg already uses.

Yes, an encoded video can have any time base, as you point out. The encoder will make that time base
whatever is required by the stream (example: MPEG-2 expects 90000Hz). That is not the time base I'm
addressing. I'm concerned with the internal time base in the filter pipeline that's used to resolve
frame ordering, both video and audio.

> Of course, to achieve zero rounding errors, the input video, and the user writing the FFmpeg command
> line, and FFmpeg itself, must all make wise choices so that the timebase is set to a rational number
> which suits the data.

All time bases that are not whole multiples of the frame rate will result in PTS rounding.
Currently, the ffmpeg internal time base appears to be 1kHz. So, every frame rate that, when divided
into 1000, doesn't produce a whole number will result in rounded (or truncated) PTSs.

> I don't think it is wise for FFmpeg to switch from its present flexible data structure to a
> constant, 1/360000 value for timebase. The examples you present do not make the case for such a change.

It doesn't have to be constant. It doesn't have to be 360000Hz. What I'm suggesting is that if it
*is* 360000Hz, that would make a single time base that works for everything. I'm not suggesting that
it be non-modifiable.

I hoped that setting 'settb=expr=1/360000' would produce what I want, but it didn't because ffmpeg's
inherent 1 millisecond time base resolution superseded it. No matter what 'settb' is specified, the
PTS resolution is going to be 1 millisecond.

> If you can establish that FFmpeg is imposing a 1/1000 timebase on a video with a 1001/24000
> timebase, leading to rounding errors, that is evidence of a bug in FFmpeg's timebase calculation or
> something. It is not evidence of the timebase data structure being inadequate.

Technically, it's not a bug. It's a design flaw. The current ffmpeg operates as designed. It's the
design that's flawed.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by FFmpeg-users mailing list
On 2021-02-26 20:35, Phil Rhodes via ffmpeg-user wrote:
>  
>
>      On Saturday, 27 February 2021, 01:27:22 GMT, Mark Filipak (ffmpeg) <[hidden email]> wrote:
>  
>> No, it has a constant frame rate of 30/1.001 frames/second.
> I'm not really following this, but one question which may be worth asking is where did you get this file, and what is its provenance?
> The reason I ask is that many files, especially those from cellphones, emphatically do not have constant frame rate and can tremendously complicate the sort of testing you seem to be interested in.

The source video is a 5 second MKV clip from a commercial DVD.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Jim DeLaHunt-2
In reply to this post by Mark Filipak (ffmpeg)
On 2021-02-26 17:53, Mark Filipak (ffmpeg) wrote:

> … I'm concerned with the internal time base in the filter pipeline
> that's used to resolve frame ordering, both video and audio.…

That is the timebase which FFmpeg stores as a rational number, and is an
attribute of the video stream, and can take various values.

As I read the code, it is stored in struct AVFilterLink, and is referred
to as `link ->time_base`, and has type `AVRational`.


> …Currently, the ffmpeg internal time base appears to be 1kHz.…

Reading the code, and especially the type AVRational for the time_base
value in AVFilterLink, points away from this claim. The evidence you
have presented so far does not prove this claim. The evidence could be
explained by your specific file input1.mkv having a varying frame rate,
rounded to 1ms increments.

       —Jim DeLaHunt


_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Paul B Mahol
In reply to this post by Mark Filipak (ffmpeg)
On Sat, Feb 27, 2021 at 2:56 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> On 2021-02-26 20:32, Jim DeLaHunt wrote:
> > On 2021-02-26 16:53, Mark Filipak (ffmpeg) wrote:
> >
> >> …What I'm suggesting is that ffmpeg convert to a single, 360000Hz time
> base for all videos, for
> >> all time. Then, rounding errors would be *zero*. PTSs would be exact. …
> >
> >
> > As I told you back on 23. February, ffmpeg uses a timebase that is a
> rational number, and is an
> > attribute of the video stream, and can take various values. The timebase
> could be 1/360000, or 1/24,
> > or 1001/24000. This already allows integer Presentation TImestamp (PTS)
> values to represent time
> > values with zero rounding errors. You dismissed that as "The Matrix",
> but this is in fact the data
> > structure which FFmpeg already uses.
>
> Yes, an encoded video can have any time base, as you point out. The
> encoder will make that time base
> whatever is required by the stream (example: MPEG-2 expects 90000Hz). That
> is not the time base I'm
> addressing. I'm concerned with the internal time base in the filter
> pipeline that's used to resolve
> frame ordering, both video and audio.
>
> > Of course, to achieve zero rounding errors, the input video, and the
> user writing the FFmpeg command
> > line, and FFmpeg itself, must all make wise choices so that the timebase
> is set to a rational number
> > which suits the data.
>
> All time bases that are not whole multiples of the frame rate will result
> in PTS rounding.
> Currently, the ffmpeg internal time base appears to be 1kHz. So, every
> frame rate that, when divided
> into 1000, doesn't produce a whole number will result in rounded (or
> truncated) PTSs.
>
> > I don't think it is wise for FFmpeg to switch from its present flexible
> data structure to a
> > constant, 1/360000 value for timebase. The examples you present do not
> make the case for such a change.
>
> It doesn't have to be constant. It doesn't have to be 360000Hz. What I'm
> suggesting is that if it
> *is* 360000Hz, that would make a single time base that works for
> everything. I'm not suggesting that
> it be non-modifiable.
>
> I hoped that setting 'settb=expr=1/360000' would produce what I want, but
> it didn't because ffmpeg's
> inherent 1 millisecond time base resolution superseded it. No matter what
> 'settb' is specified, the
> PTS resolution is going to be 1 millisecond.
>
> > If you can establish that FFmpeg is imposing a 1/1000 timebase on a
> video with a 1001/24000
> > timebase, leading to rounding errors, that is evidence of a bug in
> FFmpeg's timebase calculation or
> > something. It is not evidence of the timebase data structure being
> inadequate.
>
> Technically, it's not a bug. It's a design flaw. The current ffmpeg
> operates as designed. It's the
> design that's flawed.
>


You are living proof that universe is finite and human stupidity/ignorance
is not.


> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by Jim DeLaHunt-2
On 2021-02-26 20:42, Jim DeLaHunt wrote:

> On 2021-02-26 17:24, Mark Filipak (ffmpeg) wrote:
>
>> On 2021-02-26 20:05, Jim DeLaHunt wrote:
>>> Does input1.mkv in fact have a constant frame rate of 24/1.001 frames/second?
>>
>> No, it has a constant frame rate of 30/1.001 frames/second.
>
> Sorry, my mistake.  I should have said, "Does input1.mkv in fact have a constant frame rate of
> 30/1.001 frames/second?"
>
>
>> '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. That produces errors. The PTSs should be constant.

Example: With a 90000kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be
'3003' (=0.0333[6..] milliseconds). The actual resolution depends on milliseconds (0.033) vs.
microseconds (0.033366) vs. nanoseconds (0.033366666) etc.

Example: With a 360000kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be
'12012' (=0.0333[6..] milliseconds).

Example: With a 1kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be
'33.3[6..]', but 33.3[6..] is not an integer, so it gets rounded down to 33. That produces errors,
and the appearance that the video is variable frame rate when it's really constant frame rate.

> Can you get some output which shows the timebase value, or the frame times, of input1.mkv, showing
> that there is a timebase which is a multiple of 1.001/30, or showing that the time value of each
> frame increments by a constant amount?

The ffmpeg report shows "29.97 tbr". I haven't put an oscilloscope on it, but it's from a commercial
DVD and I'd be incredibly surprised if it wasn't constant frame rate.

> So far, the output you show is consistent with an input1.mkv which has a varying frame rate that is
> 30/1.001 fps, distorted to fit a 1/1000 timebase. Can you show a diagnostic which eliminates that
> possibility?

No, I can't except by measuring frames with a physical oscilloscope or logic analyzer. But you know,
that shouldn't matter. If ffmpeg quantizes frame times to 1ms resolution, it's going to produce errors.

A 360000Hz time base is convenient because, for just about all possible video frame rates, it will
produce PTSs that are purely integers (exact, no rounding). Those exact PTSs can then be used
directly when determining frame-to-frame sequencing, even from differing streams, even if they are
differing frame rates. It would be Valhalla.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by Jim DeLaHunt-2
On 2021-02-26 21:28, Jim DeLaHunt wrote:
> On 2021-02-26 17:53, Mark Filipak (ffmpeg) wrote:
>
>> … I'm concerned with the internal time base in the filter pipeline that's used to resolve frame
>> ordering, both video and audio.…
>
> That is the timebase which FFmpeg stores as a rational number, and is an attribute of the video
> stream, and can take various values.

Yes, it stores the time base as a rational number -- as an integer, actually. By default, it obtains
it from the decoder (which presumably obtains it from the video transport header).

> As I read the code, it is stored in struct AVFilterLink, and is referred to as `link ->time_base`,
> and has type `AVRational`.
>
>
>> …Currently, the ffmpeg internal time base appears to be 1kHz.…
>
> Reading the code, and especially the type AVRational for the time_base value in AVFilterLink, points
> away from this claim. The evidence you have presented so far does not prove this claim. The evidence
> could be explained by your specific file input1.mkv having a varying frame rate, rounded to 1ms
> increments.

Yes, AVRational is a value in the code -- I'm taking your word on that. That's not what I'm
'talking' about. What I'm 'talking' about is resolution of frame-to-frame, deltaPTS.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: How can I force a 360kHz time base?

Mark Filipak (ffmpeg)
In reply to this post by Paul B Mahol
On 2021-02-26 21:29, Paul B Mahol wrote:
> You are living proof that universe is finite and human stupidity/ignorance
> is not.

Paul, I know you're a smart guy and can keep 'N' balls in the air at the same time.

How do *you* explain this:

'ffmpeg -i input.mkv -vf "settb=expr=1/360000,showinfo" -codec:a copy -codec:s copy -dn output.mkv'

[Parsed_showinfo_1 @ 00000211128f2340] n:   1 pts:  11880 pts_time:0.033 ...
[Parsed_showinfo_1 @ 00000211128f2340] n:   2 pts:  24120 pts_time:0.067 ...
[Parsed_showinfo_1 @ 00000211128f2340] n:   3 pts:  36000 pts_time:0.1   ...

Why aren't those numbers:

[Parsed_showinfo_1 @ 00000211128f2340] n:   1 pts:  12012 pts_time:0.033 ...
[Parsed_showinfo_1 @ 00000211128f2340] n:   2 pts:  24024 pts_time:0.067 ...
[Parsed_showinfo_1 @ 00000211128f2340] n:   3 pts:  36036 pts_time:0.1   ...
?

They're supposed to be '12012' '24024' '36036'.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
123