Why are PTS values different from what's expected?

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

Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be less than 0.1%.

The filter complex is thinned down to just this: settb=1/720000,showinfo

Here is selected lines from the showinfo report (with   ...comments):

[Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000, frame_rate: 24000/1001
    ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
[Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be 30030
[Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be 60060
[Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be 90090
[Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be 120120

The PTS variance is 0.7%.

Why are PTS values different from what's expected?

Note: If I force deltaPTS via setpts=N*30030, then of course I get what's expected.

Thanks. This is critical and your explanation is greatly appreciated!
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: Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:

> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be less than 0.1%.
>
> The filter complex is thinned down to just this: settb=1/720000,showinfo
>
> Here is selected lines from the showinfo report (with   ...comments):
>
> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000, frame_rate: 24000/1001
>     ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be 30030
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be 60060
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be 90090
> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be 120120
>
> The PTS variance is 0.7%.
>
> Why are PTS values different from what's expected?
>
> Note: If I force deltaPTS via setpts=N*30030, then of course I get what's expected.
>
> Thanks. This is critical and your explanation is greatly appreciated!
> Mark.

UPDATE

If I change the filter complex to this:

settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo

all my follow-on processing goes straight into the toilet.

Explanation of the factors in the filter complex:
settb=1/720000   ...mandate 1.3[8..] ms time resolution
setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
fps=fps=48000/1001   ...frame double

However, fps=fps=48000/1001 does more than just frame double. It resets TB to 20.8541[6..] ms time
resolution. Look:

[Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000, frame_rate: 48000/1001
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
[Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3

Gee, I wish the fps filter documention said that it changes TB and sets deltaPTS to '1'.

My follow-on frame processing can't tolerate 20.8541[6..] ms time resolution -- that explains why my
mechanical frame gynmastics have been failing!

Explanation: My follow-on processing does fractional frame adjustment that requires at least
8.341[6..] ms resolution.

Workaround: I can frame double by another method that's somewhat ugly but that I know works and
doesn't trash time resolution.

_______________________________________________
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: Why are PTS values different from what's expected?

pdr0
Mark Filipak (ffmpeg) wrote

> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be
>> less than 0.1%.
>>
>> The filter complex is thinned down to just this: settb=1/720000,showinfo
>>
>> Here is selected lines from the showinfo report (with   ...comments):
>>
>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000,
>> frame_rate: 24000/1001
>>     ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be
>> 30030
>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be
>> 60060
>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be
>> 90090
>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be
>> 120120
>>
>> The PTS variance is 0.7%.
>>
>> Why are PTS values different from what's expected?
>>
>> Note: If I force deltaPTS via setpts=N*30030, then of course I get what's
>> expected.
>>
>> Thanks. This is critical and your explanation is greatly appreciated!
>> Mark.
>
> UPDATE
>
> If I change the filter complex to this:
>
> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo
>
> all my follow-on processing goes straight into the toilet.
>
> Explanation of the factors in the filter complex:
> settb=1/720000   ...mandate 1.3[8..] ms time resolution
> setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
> fps=fps=48000/1001   ...frame double
>
> However, fps=fps=48000/1001 does more than just frame double. It resets TB
> to 20.8541[6..] ms time
> resolution. Look:
>
> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000,
> frame_rate: 48000/1001
> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3
>
> Gee, I wish the fps filter documention said that it changes TB and sets
> deltaPTS to '1'.
>
> My follow-on frame processing can't tolerate 20.8541[6..] ms time
> resolution -- that explains why my
> mechanical frame gynmastics have been failing!
>
> Explanation: My follow-on processing does fractional frame adjustment that
> requires at least
> 8.341[6..] ms resolution.
>
> Workaround: I can frame double by another method that's somewhat ugly but
> that I know works and
> doesn't trash time resolution.

Did you try changing the order? ie. -vf fps first ?




--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
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: Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
On 2021-04-01 11:41, pdr0 wrote:

> Mark Filipak (ffmpeg) wrote
>> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
>>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be
>>> less than 0.1%.
>>>
>>> The filter complex is thinned down to just this: settb=1/720000,showinfo
>>>
>>> Here is selected lines from the showinfo report (with   ...comments):
>>>
>>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000,
>>> frame_rate: 24000/1001
>>>      ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be
>>> 30030
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be
>>> 60060
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be
>>> 90090
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be
>>> 120120
>>>
>>> The PTS variance is 0.7%.
>>>
>>> Why are PTS values different from what's expected?
>>>
>>> Note: If I force deltaPTS via setpts=N*30030, then of course I get what's
>>> expected.
>>>
>>> Thanks. This is critical and your explanation is greatly appreciated!
>>> Mark.
>>
>> UPDATE
>>
>> If I change the filter complex to this:
>>
>> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo
>>
>> all my follow-on processing goes straight into the toilet.
>>
>> Explanation of the factors in the filter complex:
>> settb=1/720000   ...mandate 1.3[8..] ms time resolution
>> setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
>> fps=fps=48000/1001   ...frame double
>>
>> However, fps=fps=48000/1001 does more than just frame double. It resets TB
>> to 20.8541[6..] ms time
>> resolution. Look:
>>
>> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000,
>> frame_rate: 48000/1001
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3
>>
>> Gee, I wish the fps filter documention said that it changes TB and sets
>> deltaPTS to '1'.
>>
>> My follow-on frame processing can't tolerate 20.8541[6..] ms time
>> resolution -- that explains why my
>> mechanical frame gynmastics have been failing!
>>
>> Explanation: My follow-on processing does fractional frame adjustment that
>> requires at least
>> 8.341[6..] ms resolution.
>>
>> Workaround: I can frame double by another method that's somewhat ugly but
>> that I know works and
>> doesn't trash time resolution.
>
> Did you try changing the order? ie. -vf fps first ?

Before the 'settb=1/720000,setpts=N*30030'? That wouldn't be appropriate because I need to guarantee
that the input is forced to 24000/1001fps cfr, first. Only then will fps=fps=48000/1001 actually
double each frame without dropping any -- without such assurance, if any particular frame happens to
have a PTS that's 'faster' than 24000/1001fps, then the shift to 48000/1001fps would drop it because
the fps filter works solely at the frame level.

What I'm trying to do is make a 120000/1001fps cfr in which each frame is a proportionally weighted
pixel mix of the 24 picture-per-second original:
AAAAA AAAAB AAABB AABBB ABBBB.
I'm sure it would be way better than standard telecine -- zero judder -- and I'm pretty sure it
would be so close to motion vector interpolation that any difference would be imperceptible. I'm
also sure that it would be a much faster process than mvinterpolate. The only question would be
resulting file size (though I think they would be very close).

ffmpeg minterpolate is very slow (2+ days for a 2 hour movie) but it induces some fairly distracting
twinkling artifacts. Piping InterFrame to ffmpeg (for finishing and encoding) is much better but
even slower (3+ days for a 2 hour movie). My trials indicate that a 5-level pixel interpolation
would process a 2 hour movie in 6 hours.

If I were to write code, of course buffering, flipping around, and combining frames would be easy.
Using what ffmpeg gives me involves 'buffering' via secondary streams in a filter complex with the
constraint that each of the secondary streams are (and remain) completely unified and continuous
streams (i.e. are not individual frames 'hanging in time'). It's an unfortunate complication. The
complication would be somewhat alleviated if ffmpeg had an actual multiplexer driven by a
programmable sequencer but it doesn't.
_______________________________________________
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: Why are PTS values different from what's expected?

pdr0
This post was updated on .
On 2021-04-01 11:41, pdr0 wrote:
> Mark Filipak (ffmpeg) wrote
>> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
>>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be
>>> less than 0.1%.
>>>
>>> The filter complex is thinned down to just this: settb=1/720000,showinfo
>>>
>>> Here is selected lines from the showinfo report (with   ...comments):
>>>
>>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000,
>>> frame_rate: 24000/1001
>>>      ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should be
>>> 30030
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should be
>>> 60060
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should be
>>> 90090
>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should be
>>> 120120
>>>
>>> The PTS variance is 0.7%.
>>>
>>> Why are PTS values different from what's expected?
>>>
>>> Note: If I force deltaPTS via setpts=N*30030, then of course I get
>>> what's
>>> expected.
>>>
>>> Thanks. This is critical and your explanation is greatly appreciated!
>>> Mark.
>>
>> UPDATE
>>
>> If I change the filter complex to this:
>>
>> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo
>>
>> all my follow-on processing goes straight into the toilet.
>>
>> Explanation of the factors in the filter complex:
>> settb=1/720000   ...mandate 1.3[8..] ms time resolution
>> setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
>> fps=fps=48000/1001   ...frame double
>>
>> However, fps=fps=48000/1001 does more than just frame double. It resets
>> TB
>> to 20.8541[6..] ms time
>> resolution. Look:
>>
>> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000,
>> frame_rate: 48000/1001
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3
>>
>> Gee, I wish the fps filter documention said that it changes TB and sets
>> deltaPTS to '1'.
>>
>> My follow-on frame processing can't tolerate 20.8541[6..] ms time
>> resolution -- that explains why my
>> mechanical frame gynmastics have been failing!
>>
>> Explanation: My follow-on processing does fractional frame adjustment
>> that
>> requires at least
>> 8.341[6..] ms resolution.
>>
>> Workaround: I can frame double by another method that's somewhat ugly but
>> that I know works and
>> doesn't trash time resolution.
>
> Did you try changing the order? ie. -vf fps first ?

Before the 'settb=1/720000,setpts=N*30030'? That wouldn't be appropriate
because I need to guarantee
that the input is forced to 24000/1001fps cfr, first.
>

That's what -vf fps=24000/1001 does. It forces 24000/1001 CFR. Use it first

I'm sure it was mentioned in one of your other threads


normal MKV
pts:     42 pts_time:0.042
pts:     83 pts_time:0.083
pts:    125 pts_time:0.125


-vf fps=24000/1001
pts:      1 pts_time:0.0417083
pts:      2 pts_time:0.0834167
pts:      3 pts_time:0.125125


-vf "fps=48000/1001,settb=1/720000,setpts=N*30030"
pts:  30030 pts_time:0.0417083
pts:  60060 pts_time:0.0834167
pts:  90090 pts_time:0.125125
Reply | Threaded
Open this post in threaded view
|

Re: Why are PTS values different from what's expected?

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote

> On 2021-04-01 11:41, pdr0 wrote:
>> Mark Filipak (ffmpeg) wrote
>>> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
>>>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be
>>>> less than 0.1%.
>>>>
>>>> The filter complex is thinned down to just this:
>>>> settb=1/720000,showinfo
>>>>
>>>> Here is selected lines from the showinfo report (with   ...comments):
>>>>
>>>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000,
>>>> frame_rate: 24000/1001
>>>>      ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should
>>>> be
>>>> 30030
>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should
>>>> be
>>>> 60060
>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should
>>>> be
>>>> 90090
>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should
>>>> be
>>>> 120120
>>>>
>>>> The PTS variance is 0.7%.
>>>>
>>>> Why are PTS values different from what's expected?
>>>>
>>>> Note: If I force deltaPTS via setpts=N*30030, then of course I get
>>>> what's
>>>> expected.
>>>>
>>>> Thanks. This is critical and your explanation is greatly appreciated!
>>>> Mark.
>>>
>>> UPDATE
>>>
>>> If I change the filter complex to this:
>>>
>>> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo
>>>
>>> all my follow-on processing goes straight into the toilet.
>>>
>>> Explanation of the factors in the filter complex:
>>> settb=1/720000   ...mandate 1.3[8..] ms time resolution
>>> setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
>>> fps=fps=48000/1001   ...frame double
>>>
>>> However, fps=fps=48000/1001 does more than just frame double. It resets
>>> TB
>>> to 20.8541[6..] ms time
>>> resolution. Look:
>>>
>>> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000,
>>> frame_rate: 48000/1001
>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3
>>>
>>> Gee, I wish the fps filter documention said that it changes TB and sets
>>> deltaPTS to '1'.
>>>
>>> My follow-on frame processing can't tolerate 20.8541[6..] ms time
>>> resolution -- that explains why my
>>> mechanical frame gynmastics have been failing!
>>>
>>> Explanation: My follow-on processing does fractional frame adjustment
>>> that
>>> requires at least
>>> 8.341[6..] ms resolution.
>>>
>>> Workaround: I can frame double by another method that's somewhat ugly
>>> but
>>> that I know works and
>>> doesn't trash time resolution.
>>
>> Did you try changing the order? ie. -vf fps first ?
>
> Before the 'settb=1/720000,setpts=N*30030'? That wouldn't be appropriate
> because I need to guarantee
> that the input is forced to 24000/1001fps cfr, first. Only then will
> fps=fps=48000/1001 actually
> double each frame without dropping any -- without such assurance, if any
> particular frame happens to
> have a PTS that's 'faster' than 24000/1001fps, then the shift to
> 48000/1001fps would drop it because
> the fps filter works solely at the frame level.

<sorry I was using a web client, sometimes message not posted correctly >


That's what -vf fps=24000/1001 does. It forces 24000/1001 CFR. Use it first

I'm sure it was mentioned in one of your other threads

normal MKV
pts:     42 pts_time:0.042
pts:     83 pts_time:0.083
pts:    125 pts_time:0.125


-vf fps=24000/1001
pts:      1 pts_time:0.0417083
pts:      2 pts_time:0.0834167
pts:      3 pts_time:0.125125


-vf "fps=24000/1001,settb=1/720000,setpts=N*30030"
pts:  30030 pts_time:0.0417083
pts:  60060 pts_time:0.0834167
pts:  90090 pts_time:0.125125




--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
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: Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
On 2021-04-01 13:06, pdr0 wrote:

> Mark Filipak (ffmpeg) wrote
>> On 2021-04-01 11:41, pdr0 wrote:
>>> Mark Filipak (ffmpeg) wrote
>>>> On 2021-04-01 07:13, Mark Filipak (ffmpeg) wrote:
>>>>> The source is MKV. MKV has a 1/1000 TB, so any PTS variance should be
>>>>> less than 0.1%.
>>>>>
>>>>> The filter complex is thinned down to just this:
>>>>> settb=1/720000,showinfo
>>>>>
>>>>> Here is selected lines from the showinfo report (with   ...comments):
>>>>>
>>>>> [Parsed_showinfo_1 @ 00000247d719ef00] config in time_base: 1/720000,
>>>>> frame_rate: 24000/1001
>>>>>       ...So, deltaPTS (calculated: 1/TB/FR) should be 30030.
>>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   1 pts:  30240   ...should
>>>>> be
>>>>> 30030
>>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   2 pts:  59760   ...should
>>>>> be
>>>>> 60060
>>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   3 pts:  90000   ...should
>>>>> be
>>>>> 90090
>>>>> [Parsed_showinfo_1 @ 00000247d719ef00] n:   4 pts: 120240   ...should
>>>>> be
>>>>> 120120
>>>>>
>>>>> The PTS variance is 0.7%.
>>>>>
>>>>> Why are PTS values different from what's expected?
>>>>>
>>>>> Note: If I force deltaPTS via setpts=N*30030, then of course I get
>>>>> what's
>>>>> expected.
>>>>>
>>>>> Thanks. This is critical and your explanation is greatly appreciated!
>>>>> Mark.
>>>>
>>>> UPDATE
>>>>
>>>> If I change the filter complex to this:
>>>>
>>>> settb=1/720000,setpts=N*30030,fps=fps=48000/1001,showinfo
>>>>
>>>> all my follow-on processing goes straight into the toilet.
>>>>
>>>> Explanation of the factors in the filter complex:
>>>> settb=1/720000   ...mandate 1.3[8..] ms time resolution
>>>> setpts=N*30030   ...force the input to exactly 24000/1001fps cfr
>>>> fps=fps=48000/1001   ...frame double
>>>>
>>>> However, fps=fps=48000/1001 does more than just frame double. It resets
>>>> TB
>>>> to 20.8541[6..] ms time
>>>> resolution. Look:
>>>>
>>>> [Parsed_showinfo_3 @ 000001413bf0ef00] config in time_base: 1001/48000,
>>>> frame_rate: 48000/1001
>>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   0 pts:      0
>>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   1 pts:      1
>>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   2 pts:      2
>>>> [Parsed_showinfo_3 @ 000001413bf0ef00] n:   3 pts:      3
>>>>
>>>> Gee, I wish the fps filter documention said that it changes TB and sets
>>>> deltaPTS to '1'.
>>>>
>>>> My follow-on frame processing can't tolerate 20.8541[6..] ms time
>>>> resolution -- that explains why my
>>>> mechanical frame gynmastics have been failing!
>>>>
>>>> Explanation: My follow-on processing does fractional frame adjustment
>>>> that
>>>> requires at least
>>>> 8.341[6..] ms resolution.
>>>>
>>>> Workaround: I can frame double by another method that's somewhat ugly
>>>> but
>>>> that I know works and
>>>> doesn't trash time resolution.
>>>
>>> Did you try changing the order? ie. -vf fps first ?
>>
>> Before the 'settb=1/720000,setpts=N*30030'? That wouldn't be appropriate
>> because I need to guarantee
>> that the input is forced to 24000/1001fps cfr, first. Only then will
>> fps=fps=48000/1001 actually
>> double each frame without dropping any -- without such assurance, if any
>> particular frame happens to
>> have a PTS that's 'faster' than 24000/1001fps, then the shift to
>> 48000/1001fps would drop it because
>> the fps filter works solely at the frame level.
>
> <sorry I was using a web client, sometimes message not posted correctly >
>
>
> That's what -vf fps=24000/1001 does. It forces 24000/1001 CFR. Use it first
>
> I'm sure it was mentioned in one of your other threads

Is this another documentation problem?

https://ffmpeg.org/ffmpeg-filters.html#fps-1
"11.88 fps
Convert the video to specified constant frame rate by duplicating or dropping frames as necessary."

I want to duplicate (specifically, double and only double) all frames. And I want to avoid any
dropping. I guess the key is: What does 'as neccessary' mean?

Like so much of the documentation, it's vague.

That 'said', I've seen fps drop frames that had slightly 'late' PTSs.
_______________________________________________
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: Why are PTS values different from what's expected?

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote

> What I'm trying to do is make a 120000/1001fps cfr in which each frame is
> a proportionally weighted
> pixel mix of the 24 picture-per-second original:
> AAAAA AAAAB AAABB AABBB ABBBB.
> I'm sure it would be way better than standard telecine -- zero judder --
> and I'm pretty sure it
> would be so close to motion vector interpolation that any difference would
> be imperceptible. I'm
> also sure that it would be a much faster process than mvinterpolate. The
> only question would be
> resulting file size (though I think they would be very close).

Is this 120000/1001 CFR intended for a 60Hz display? Do you decimate by 2 to
make it 60000/1001 after ?

"proportionally weighted pixel mix" it sounds like a standard frame blended
conversion . eg. You drop a 23.976p asset on a 120000/1001fps timeline in a
NLE and enable frame blending. Or in avisynth it would be
ConvertFPS(120000,1001)

This zip file example has the original 24000/1001, weighted frame blending
to 120000/1001, and decimation to 60000/1001 - is this something close to
what you had in mind ?
https://www.mediafire.com/file/qj819m3vctx4o4q/blends_example.zip/file

The "textbook" fps conversion categories are 1) duplicates 2) blends 3)
optical flow (such as minterpolate) . Each has various pros/cons

For what you are considering (blends), the frames will be "evenly spaced" in
time - technically less judder -  but there will be "strobing" and blurry
loss of quality (frame blending). Every 5th frame is an "original" frame,
original quality that "snaps" into view. What some people do to reduce that
is offset the timing (resample all frames, instead of keeping every 5th
original), to reduce that jarring effect; same with optical flow - resample
all frames instead of keeping T=0.0 (shift to T=0.1)

The "best" is to get a 120Hz/300Hz judder free display :) And if you're in
that group that likes motion interpolation,  a motion interpolation display





--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
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: Why are PTS values different from what's expected?

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote

>
> Is this another documentation problem?
>
> https://ffmpeg.org/ffmpeg-filters.html#fps-1
> "11.88 fps
> Convert the video to specified constant frame rate by duplicating or
> dropping frames as necessary."
>
> I want to duplicate (specifically, double and only double) all frames. And
> I want to avoid any
> dropping. I guess the key is: What does 'as neccessary' mean?
>
> Like so much of the documentation, it's vague.
>
> That 'said', I've seen fps drop frames that had slightly 'late' PTSs.

It achieves desired framerate by adding or dropping frames. If your
timestamps are "off", the expected results will be "off"

If you have buggy input timestamps , another option might be setts bitstream
filter that was committed recently

https://ffmpeg.org/ffmpeg-bitstream-filters.html#setts





--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
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: Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
In reply to this post by pdr0
On 2021-04-01 13:40, pdr0 wrote:

> Mark Filipak (ffmpeg) wrote
>> What I'm trying to do is make a 120000/1001fps cfr in which each frame is
>> a proportionally weighted
>> pixel mix of the 24 picture-per-second original:
>> AAAAA AAAAB AAABB AABBB ABBBB.
>> I'm sure it would be way better than standard telecine -- zero judder --
>> and I'm pretty sure it
>> would be so close to motion vector interpolation that any difference would
>> be imperceptible. I'm
>> also sure that it would be a much faster process than mvinterpolate. The
>> only question would be
>> resulting file size (though I think they would be very close).
>
> Is this 120000/1001 CFR intended for a 60Hz display? Do you decimate by 2 to
> make it 60000/1001 after ?
>
> "proportionally weighted pixel mix" it sounds like a standard frame blended
> conversion . eg. You drop a 23.976p asset on a 120000/1001fps timeline in a
> NLE and enable frame blending. Or in avisynth it would be
> ConvertFPS(120000,1001)
>
> This zip file example has the original 24000/1001, weighted frame blending
> to 120000/1001, and decimation to 60000/1001 - is this something close to
> what you had in mind ?
> https://www.mediafire.com/file/qj819m3vctx4o4q/blends_example.zip/file

Thanks for that (...I wish I knew how you are making those...).
convertfps_119.88(blends).mp4 actually looks to be the better choice for my 60Hz TV -- the TV is
interpolating well -- but I think the weighting could be tweaked (which is something I planned to do
once my filter complex was working properly).

> The "textbook" fps conversion categories are 1) duplicates 2) blends 3)
> optical flow (such as minterpolate) . Each has various pros/cons

Well, the biggest con is 3+ days to convert a 2 hour movie. Otherwise, InterFrame running in
VapourSynth can't be beat I guess.

The rest of your reply (below) is the subject of my reply to your previous post, so I'll copy the
below to my reply (which was in preparation as 'this' came into my email client).

Thanks, pdr0. I'm glad you're here.

> For what you are considering (blends), the frames will be "evenly spaced" in
> time - technically less judder -  but there will be "strobing" and blurry
> loss of quality (frame blending). Every 5th frame is an "original" frame,
> original quality that "snaps" into view. What some people do to reduce that
> is offset the timing (resample all frames, instead of keeping every 5th
> original), to reduce that jarring effect; same with optical flow - resample
> all frames instead of keeping T=0.0 (shift to T=0.1)
>
> The "best" is to get a 120Hz/300Hz judder free display :) And if you're in
> that group that likes motion interpolation,  a motion interpolation display

_______________________________________________
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: Why are PTS values different from what's expected?

Mark Filipak (ffmpeg)
In reply to this post by pdr0
On 2021-04-01 13:40, pdr0 wrote:

> Mark Filipak (ffmpeg) wrote
>> What I'm trying to do is make a 120000/1001fps cfr in which each frame is
>> a proportionally weighted
>> pixel mix of the 24 picture-per-second original:
>> AAAAA AAAAB AAABB AABBB ABBBB.
>> I'm sure it would be way better than standard telecine -- zero judder --
>> and I'm pretty sure it
>> would be so close to motion vector interpolation that any difference would
>> be imperceptible. I'm
>> also sure that it would be a much faster process than mvinterpolate. The
>> only question would be
>> resulting file size (though I think they would be very close).
>
> Is this 120000/1001 CFR intended for a 60Hz display? ...

Yes, or a 120Hz display.

Please, correct me if I'm wrong.

The 120fps frames are conveying 24 pictures-per-second, i.e. 5 discrete frames per picture with the
1st of each set of 5 being an identical duplicate of the original (e.g. AAAAA), so down converting
to 60fps is not a simple case of dropping alternate frames (i.e. 5/2 is not an integer).
The lines below are: 24FPS / 120FPS / 60FPS (BY ALTERNATE FRAME DROP).
AAAAAAAAAAAAAAAAAAAAAAAAAAAAA.BBBBBBBBBBBBBBBBBBBBBBBBBBBBB.CCCCCCCCCCCCCCCCCCCCCCCCCCCCC.DDDDD...
AAAAA.AAAAB.AAABB.AABBB.ABBBB.BBBBB.BBBBC.BBBCC.BBCCC.BCCCC.CCCCC.CCCCD.CCCDD.CCDDD.CDDDD.DDDDD...
AAAAA.AAABB.ABBBB.BBBBC.BBCCC.CCCCC.CCCDD.CDDDD.DDDDE.DDEEE.EEEEE.EEEFF.EFFFF.FFFFG.FFGGG.GGGGG...

Note how, in the 60FPS stream, there is no BBBBB or DDDDD or FFFFF frames. That continues and any
loss of 'pure' frames would probably be noticeable. ...UPDATE: The loss is noticeable (as flicker).

My cheap 60Hz TV accepts 120fps and it apparently interpolates during down conversion to 60fps. I
assume that's true of all 60Hz TVs because, given that the frames are sent to the TV as raw frames
via HDMI, doing pixel interpolation in real time within the TV is a snap, so all 60Hz TVs probably
do it fine.

>... Do you decimate by 2 to make it 60000/1001 after ?

I haven't tried because I haven't gotten a 120fps that doesn't have PTS errors. But since there are
no identical frames, I don't think decimation will do anything.

> "proportionally weighted pixel mix" it sounds like a standard frame blended
> conversion . eg. You drop a 23.976p asset on a 120000/1001fps timeline in a
> NLE and enable frame blending. Or in avisynth it would be
> ConvertFPS(120000,1001)

Well, I don't know what "NLE" means, so you'll need to enlighten me. I found one such ffmpeg filter
-- I can't remember its name -- but it only added 1 frame of interpolated pixels between 2 original
frames, not 4 frames between 2 input frames.

> This zip file example has the original 24000/1001, weighted frame blending
> to 120000/1001, and decimation to 60000/1001 - is this something close to
> what you had in mind ?
> https://www.mediafire.com/file/qj819m3vctx4o4q/blends_example.zip/file

Oops... It appears I've already responded to this post, so I've gotten my email threads mixed up.
(So, what else is new, eh?) I must have gotten the new email notice for a different incoming.

One last thing: I didn't even try '-vf fps=fps=120000/1001' because I assumed that the TV would be
'smart' and would decimate it and then telecine. I just tried it. I was right. Oh, dear. At least
what I'm trying to do is on the right track, but I reckon that the frame cross-fades (via 'mix'
weights) need to be non-linear, perhaps something like this:

If I can resolve the problems with my approach, I have some other schemes to try.

First, let me redefine AAAAA.AAAAB.AAABB.AABBB.ABBBB.BBBBB as
5A0B.4A1B.3A2B.2A3B.1A4B.0A5B.

Then, using that notation, how about these?
5A1B.4A2B.3A3B.3A3B.2A5B.1A5B [note 1]
9A1B.5A5B.7A3B.3A7B.5A5B.1A9B [note 2]

[note 1] Might produce some additional fuzzing (but less noticeable flicker) for fast motion, but
less fuzzing as A & B approach identity (i.e. slower motion).

[note 2] Might produce a small, 48fps judder in exchange for doubling the flicker rate (which might
be less noticeable).

Have you tried either of those?

Another thing I've discovered in the past is that using a checkerboard mix in lieu of a blended mix
looks much sharper -- perhaps this is a "trick of the eye", human perception thing.

I'd like to try all of the above, but first I need to get my filter complex working (which means
solving its PTS errors (which means discovering the effect on PTS of various filters (which means
more experimenting because the documentation is silent on the issue))). I'm 74 years old and I hope
I can get all this sorted out and my movie collection converted before I wind up in the retirement
home that will undoubtedly be my ultimate residence.  ...So much to do; so little (Mark)x(time). :-)
_______________________________________________
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: Why are PTS values different from what's expected?

pdr0
In reply to this post by Mark Filipak (ffmpeg)
Mark Filipak (ffmpeg) wrote

> On 2021-04-01 13:40, pdr0 wrote:
>>
>> This zip file example has the original 24000/1001, weighted frame
>> blending
>> to 120000/1001, and decimation to 60000/1001 - is this something close to
>> what you had in mind ?
>> https://www.mediafire.com/file/qj819m3vctx4o4q/blends_example.zip/file
>
> Thanks for that (...I wish I knew how you are making those...).
> convertfps_119.88(blends).mp4 actually looks to be the better choice for
> my 60Hz TV -- the TV is
> interpolating well -- but I think the weighting could be tweaked (which is
> something I planned to do
> once my filter complex was working properly).

I'm using avisynth ,because it has preset functions for everything. e.g.
ConvertFPS does blended framerate conversions. It's 1 line.  ie. You don't
have to break it down into select, merge, interleave - but I'll post a
vapoursynth template for you to reproduce it , and you can experiment with
different weights - since you've used vapoursynth before, and you won't be
bothered by PTS issues or frames out of order

On a 60Hz display, those two files should look identical from the way it was
made. The 60Hz display only displays every 2nd frame on the 120000/1001 fps
video.




Mark Filipak (ffmpeg) wrote

> On 2021-04-01 13:40, pdr0 wrote:
>> Mark Filipak (ffmpeg) wrote
>>> What I'm trying to do is make a 120000/1001fps cfr in which each frame
>>> is
>>> a proportionally weighted
>>> pixel mix of the 24 picture-per-second original:
>>> AAAAA AAAAB AAABB AABBB ABBBB.
>>> I'm sure it would be way better than standard telecine -- zero judder --
>>> and I'm pretty sure it
>>> would be so close to motion vector interpolation that any difference
>>> would
>>> be imperceptible. I'm
>>> also sure that it would be a much faster process than mvinterpolate. The
>>> only question would be
>>> resulting file size (though I think they would be very close).
>>
>> Is this 120000/1001 CFR intended for a 60Hz display? ...
>
> Yes, or a 120Hz display.
>
> Please, correct me if I'm wrong.
>
> The 120fps frames are conveying 24 pictures-per-second, i.e. 5 discrete
> frames per picture with the
> 1st of each set of 5 being an identical duplicate of the original (e.g.
> AAAAA), so down converting
> to 60fps is not a simple case of dropping alternate frames (i.e. 5/2 is
> not an integer).
> The lines below are: 24FPS / 120FPS / 60FPS (BY ALTERNATE FRAME DROP).
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAA.BBBBBBBBBBBBBBBBBBBBBBBBBBBBB.CCCCCCCCCCCCCCCCCCCCCCCCCCCCC.DDDDD...
> AAAAA.AAAAB.AAABB.AABBB.ABBBB.BBBBB.BBBBC.BBBCC.BBCCC.BCCCC.CCCCC.CCCCD.CCCDD.CCDDD.CDDDD.DDDDD...
> AAAAA.AAABB.ABBBB.BBBBC.BBCCC.CCCCC.CCCDD.CDDDD.DDDDE.DDEEE.EEEEE.EEEFF.EFFFF.FFFFG.FFGGG.GGGGG...
>
> Note how, in the 60FPS stream, there is no BBBBB or DDDDD or FFFFF frames.
> That continues and any
> loss of 'pure' frames would probably be noticeable. ...UPDATE: The loss is
> noticeable (as flicker).

Looks correct - that's the same thing going on with the
59.94(blends,decimation) file - every 2nd frame is selected (selecteven)

That's also what's going on when you watch the 120000/1001 file on most 60Hz
displays.



> My cheap 60Hz TV accepts 120fps and it apparently interpolates during down
> conversion to 60fps. I
> assume that's true of all 60Hz TVs because, given that the frames are sent
> to the TV as raw frames
> via HDMI, doing pixel interpolation in real time within the TV is a snap,
> so all 60Hz TVs probably
> do it fine.

In what way does it "interpolate ?"

If it's doing anything other than dropping frames, there must be additional
processing in your TV set - and "additional processing" is definitely not
standard for "cheap" sets.  The majority of 60Hz displays will only display
every 2nd frame, no interpolation.



>  
>
>> "proportionally weighted pixel mix" it sounds like a standard frame
>> blended
>> conversion . eg. You drop a 23.976p asset on a 120000/1001fps timeline in
>> a
>> NLE and enable frame blending. Or in avisynth it would be
>> ConvertFPS(120000,1001)
>
> Well, I don't know what "NLE" means, so you'll need to enlighten me.

NLE is a "non linear editor.", used to edit videos.   Blend conversions are
one type of standardized form of conversion. For example many TV stations
used to perform this sort of blend conversions to/from different framerates
(some still do). It's frowned upon in many circles . Pros/cons



> First, let me redefine AAAAA.AAAAB.AAABB.AABBB.ABBBB.BBBBB as
> 5A0B.4A1B.3A2B.2A3B.1A4B.0A5B.

ie. 5 frame cycles, linear interpolation of weights. This is the same
pattern that was posted in the zip file

Here is a vapoursynth template that (almost) does the same thing, until you
get the PTS's sorted out in ffmpeg. The one difference is an extra frame is
added (for programmatic reasons, the 1st frame is spliced onto the repeating
interleave pattern), but they are otherwise identical in the end result
e.g., frame 0 matches frame 0, frame 100 matches frame 100. etc...


import vapoursynth as vs
core = vs.get_core()
clip = core.lsmas.LibavSMASHSource(r'23.976p.mp4')

#create clip offset by 1 frame (trim off first frame)
offset1 = core.std.Trim(clip, first=1)

#weighting
Aweight = core.std.Merge(clip, offset1,  weight=0) #not used in this example
Bweight = core.std.Merge(clip, offset1,  weight=0.2)
Cweight = core.std.Merge(clip, offset1,  weight=0.4)
Dweight = core.std.Merge(clip, offset1,  weight=0.6)
Eweight = core.std.Merge(clip, offset1,  weight=0.8)
Fweight = core.std.Merge(clip, offset1,  weight=1)

#splice first frame plus interleave pattern
interleaved = core.std.Trim(clip, first=0, last=0) +
core.std.Interleave(clips=[Bweight,Cweight,Dweight,Eweight,Fweight])

#assume frame rate (and timestamps)
interleaved = core.std.AssumeFPS(interleaved, fpsnum=120000, fpsden=1001)

selecteven = interleaved[::2] #selecteven

interleaved.set_output()
#selecteven.set_output()




> Then, using that notation, how about these?
> 5A1B.4A2B.3A3B.3A3B.2A5B.1A5B [note 1]
> 9A1B.5A5B.7A3B.3A7B.5A5B.1A9B [note 2]
>
> [note 1] Might produce some additional fuzzing (but less noticeable
> flicker) for fast motion, but
> less fuzzing as A & B approach identity (i.e. slower motion).
>
> [note 2] Might produce a small, 48fps judder in exchange for doubling the
> flicker rate (which might
> be less noticeable).


You can test them in that  vapoursynth template as proof of concept , at
least until  you get the PTS sorted out in ffmpeg.



> Another thing I've discovered in the past is that using a checkerboard mix
> in lieu of a blended mix
> looks much sharper -- perhaps this is a "trick of the eye", human
> perception thing.

Yes I recall in your other thread, I didn't like it personally.


> I'd like to try all of the above, but first I need to get my filter
> complex working (which means
> solving its PTS errors (which means discovering the effect on PTS of
> various filters (which means
> more experimenting because the documentation is silent on the issue))).

I think that setts bsf filter might help, looks promising





--
Sent from: http://ffmpeg-users.933282.n4.nabble.com/
_______________________________________________
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".