Filter documentation -- PTSs

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

Filter documentation -- PTSs

Mark Filipak (ffmpeg)
Disclosure: Everything that follows may be wrong.

I reckon that, except for a few filters, the important metric is PTS, not the frame #s assigned at a
filter's input node nor its wall-clock arrival time at a filter's input node. For example,
'interleave' performs frame interleaves based on the PTSs of incoming frames -- at least, that's
what I think.

Am I correct?

If so, wouldn't it be helpful if filter documentation included how it generates PTSs?

Filter documentation should include:
1, More than just the names of directives (i.e. "options") -- some do, some don't,
2, Input specifications that include
2.1, The minimum number of output frames,
2.2, The number of output frames per input frame, and
2.3, Indication of the frames that are dropped (if any), for example: "first frame is dropped",
"last 2 frames are dropped", etc., and
3, The mathematical formula employed to calculate output PTSs.

I urge responses from all who are critical -- You know who you are! Perhaps someday we will be
allowed to contribute. There are several of us who are critical. If allowed, we could resolve all
issues for all filters in just a few days.

--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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: Filter documentation -- PTSs

Carl Eugen Hoyos-2
Am Mo., 15. Feb. 2021 um 00:50 Uhr schrieb Mark Filipak (ffmpeg)
<[hidden email]>:

> Perhaps someday we will be allowed to contribute.

This is probably the most insulting comment I have ever seen here.

Carl Eugen
_______________________________________________
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: Filter documentation -- PTSs

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

> …wouldn't it be helpful if filter documentation included how it
> generates PTSs?
> Filter documentation should include:
> …[List of desired items omitted]…


I am in the camp that believes that the measure of adequate FFmpeg
documentation is that it describes what an FFmpeg user needs to know
about the behaviour of that filter, in all respects, without having to
read the source code. By that measure, I believe that FFmpeg's
documentation for almost all filters is inadequate.

The documentation I wrote for the fps filter might be a useful case
study: <http://blog.jdlh.com/en/2020/04/30/ffmpeg-fps-documented/ 
<http://blog.jdlh.com/en/2020/04/30/ffmpeg-fps-documented/>>. (The case
study is not limited to PTSs.)

I think every filter should have documentation to this level of detail.
In addition, I think there should be a comprehensive glossary for terms
FFmpeg documentation uses, including industry standard terms like "PTS"
(meaning, "Presentation Time Stamp"). This would probably mean 10x the
word count compared to the current documentation. It would also lead to
discovering many bugs, i.e. code behaviour that is revealed to be
unreasonable when described in words.


> …I reckon that, except for a few filters, the important metric is PTS,
> not the frame #s assigned at a filter's input node nor its wall-clock
> arrival time at a filter's input node. For example, 'interleave'
> performs frame interleaves based on the PTSs of incoming frames….


I suspect the generalisation, "the important metric is PTS", will not
prove true for all filters. Another metric might be the most important
for some filters. However, I agree that, for most filters, PTS behaviour
will be an important metric that should be documented.


> …There are several of us who are critical. If allowed, we could
> resolve all issues for all filters in just a few days….


I'm not sure what you mean by "critical". Do you mean, "people who are
necessary", or "people who criticise"? And, I don't think the people who
criticise could resolve "all issues for all filters in just a few days".
It would take months to read source code, write draft documentation,
review it, and correct it.  However, I agree that there could be big
improvements in "just a few days". There are so many documentation
sections which so badly need improvement.

Best regards,
     —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
|

"most insulting comment" [was: Re: Filter documentation -- PTSs]

Jim DeLaHunt-2
In reply to this post by Carl Eugen Hoyos-2
On 2021-02-14 15:58, Carl Eugen Hoyos wrote:
> Am Mo., 15. Feb. 2021 um 00:50 Uhr schrieb Mark Filipak (ffmpeg)
> <[hidden email]>:
>
>> Perhaps someday we will be allowed to contribute.
> This is probably the most insulting comment I have ever seen here.
>
> Carl Eugen

Oh, my dear Carl, if you think that is the most insulting comment you
have ever seen here, then you must have missed several of the messages
which pass through this list each month. There have been several
comments recently which are _so_ much more insulting.

I realise the comment may sting. But a comment which reveals a painful
truth is different than an insulting comment. For more on the painful
truth, see for example the thread starting at
<https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/051686.html 
<https://lists.ffmpeg.org/pipermail/ffmpeg-user/2021-February/051686.html>>.

Best regards,
      —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: Filter documentation -- PTSs

Paul B Mahol
In reply to this post by Mark Filipak (ffmpeg)
On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> Disclosure: Everything that follows may be wrong.
>
> I reckon that, except for a few filters, the important metric is PTS, not
> the frame #s assigned at a
> filter's input node nor its wall-clock arrival time at a filter's input
> node. For example,
> 'interleave' performs frame interleaves based on the PTSs of incoming
> frames -- at least, that's
> what I think.
>
> Am I correct?
>
> If so, wouldn't it be helpful if filter documentation included how it
> generates PTSs?
>

PTS are not generated.


>
> Filter documentation should include:
> 1, More than just the names of directives (i.e. "options") -- some do,
> some don't,
> 2, Input specifications that include
> 2.1, The minimum number of output frames,
> 2.2, The number of output frames per input frame, and
> 2.3, Indication of the frames that are dropped (if any), for example:
> "first frame is dropped",
> "last 2 frames are dropped", etc., and
> 3, The mathematical formula employed to calculate output PTSs.
>
> I urge responses from all who are critical -- You know who you are!
> Perhaps someday we will be
> allowed to contribute. There are several of us who are critical. If
> allowed, we could resolve all
> issues for all filters in just a few days.
>
> --
> Any journey, no matter how long, is just a series of small steps.
> "Government is the problem!" -- 1982 and onward.
> "_______ is the enemy of the people!" -- 2016 and onward.
> "You have to fight like hell or you're not going to have a country!" --
> Jan 6, 2021.
> It isn't the distance that's important, it's the direction.
> _______________________________________________
> 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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
On 02/14/2021 07:34 PM, Paul B Mahol wrote:

> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> Disclosure: Everything that follows may be wrong.
>>
>> I reckon that, except for a few filters, the important metric is PTS, not
>> the frame #s assigned at a
>> filter's input node nor its wall-clock arrival time at a filter's input
>> node. For example,
>> 'interleave' performs frame interleaves based on the PTSs of incoming
>> frames -- at least, that's
>> what I think.
>>
>> Am I correct?
>>
>> If so, wouldn't it be helpful if filter documentation included how it
>> generates PTSs?
>>
>
> PTS are not generated.

ffmpeg -i SOURCE -vf telecine TARGET

What are the PTSs of the first 5 frames at the output of the filter?

--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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: Filter documentation -- PTSs

Carl Zwanzig
In reply to this post by Paul B Mahol
On 2/14/2021 4:34 PM, Paul B Mahol wrote:
> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg)<[hidden email]>
> wrote:
>> If so, wouldn't it be helpful if filter documentation included how it
>> generates PTSs?

> PTS are not generated.

-Something- generates the PTS, although maybe not the filter. OTOH if an
element in the pipeline between decode and encode changes the frame-to-frame
timing, I'd expect that the PTS must be altered (which one could call
"recalculated" or "regenerated").

Some handy references, although I'm sure there are others--
https://en.wikipedia.org/wiki/Presentation_timestamp
http://www.bretl.com/mpeghtml/timebuf.HTM

z!
_______________________________________________
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: Filter documentation -- PTSs

Paul B Mahol
In reply to this post by Mark Filipak (ffmpeg)
On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
> > On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
> [hidden email]>
> > wrote:
> >
> >> Disclosure: Everything that follows may be wrong.
> >>
> >> I reckon that, except for a few filters, the important metric is PTS,
> not
> >> the frame #s assigned at a
> >> filter's input node nor its wall-clock arrival time at a filter's input
> >> node. For example,
> >> 'interleave' performs frame interleaves based on the PTSs of incoming
> >> frames -- at least, that's
> >> what I think.
> >>
> >> Am I correct?
> >>
> >> If so, wouldn't it be helpful if filter documentation included how it
> >> generates PTSs?
> >>
> >
> > PTS are not generated.
>
> ffmpeg -i SOURCE -vf telecine TARGET
>
> What are the PTSs of the first 5 frames at the output of the filter?
>
>
Interpolated by very complex formula.


> --
> Any journey, no matter how long, is just a series of small steps.
> "Government is the problem!" -- 1982 and onward.
> "_______ is the enemy of the people!" -- 2016 and onward.
> "You have to fight like hell or you're not going to have a country!" --
> Jan 6, 2021.
> It isn't the distance that's important, it's the direction.
> _______________________________________________
> 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: Filter documentation -- PTSs

FFmpeg-users mailing list
 How does all this interact with files from cameras with very stable timing, such as broadcast and cinema cameras?
Is there not a risk of long-term rounding errors?
P
    On Monday, 15 February 2021, 01:13:37 GMT, Paul B Mahol <[hidden email]> wrote:  
 
 On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
> > On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
> [hidden email]>
> > wrote:
> >
> >> Disclosure: Everything that follows may be wrong.
> >>
> >> I reckon that, except for a few filters, the important metric is PTS,
> not
> >> the frame #s assigned at a
> >> filter's input node nor its wall-clock arrival time at a filter's input
> >> node. For example,
> >> 'interleave' performs frame interleaves based on the PTSs of incoming
> >> frames -- at least, that's
> >> what I think.
> >>
> >> Am I correct?
> >>
> >> If so, wouldn't it be helpful if filter documentation included how it
> >> generates PTSs?
> >>
> >
> > PTS are not generated.
>
> ffmpeg -i SOURCE -vf telecine TARGET
>
> What are the PTSs of the first 5 frames at the output of the filter?
>
>
Interpolated by very complex formula.


> --
> Any journey, no matter how long, is just a series of small steps.
> "Government is the problem!" -- 1982 and onward.
> "_______ is the enemy of the people!" -- 2016 and onward.
> "You have to fight like hell or you're not going to have a country!" --
> Jan 6, 2021.
> It isn't the distance that's important, it's the direction.
> _______________________________________________
> 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".  
_______________________________________________
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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
In reply to this post by Paul B Mahol
On 02/14/2021 08:13 PM, Paul B Mahol wrote:

> On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
>>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
>> [hidden email]>
>>> wrote:
>>>
>>>> Disclosure: Everything that follows may be wrong.
>>>>
>>>> I reckon that, except for a few filters, the important metric is PTS,
>> not
>>>> the frame #s assigned at a
>>>> filter's input node nor its wall-clock arrival time at a filter's input
>>>> node. For example,
>>>> 'interleave' performs frame interleaves based on the PTSs of incoming
>>>> frames -- at least, that's
>>>> what I think.
>>>>
>>>> Am I correct?
>>>>
>>>> If so, wouldn't it be helpful if filter documentation included how it
>>>> generates PTSs?
>>>>
>>>
>>> PTS are not generated.
>>
>> ffmpeg -i SOURCE -vf telecine TARGET
>>
>> What are the PTSs of the first 5 frames at the output of the filter?
>>
>>
> Interpolated by very complex formula.

So, the PTSs are generated.

What is the formula? Certainly it can't be anywhere nearly as complex as the differential equations
and boundary conditions that control air flow through a duct of arbitrary shape or the air flow
across an aircraft wing of arbitrary profile. I guess if I can handle those, I'll be able to handle
the generated PTSs of a periodic series of frames, eh?

--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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: Filter documentation -- PTSs

Paul B Mahol
In reply to this post by FFmpeg-users mailing list
On Mon, Feb 15, 2021 at 2:19 AM Phil Rhodes via ffmpeg-user <
[hidden email]> wrote:

>  How does all this interact with files from cameras with very stable
> timing, such as broadcast and cinema cameras?
> Is there not a risk of long-term rounding errors?
>

PTS and TB (timebase) are used together.


> P
>     On Monday, 15 February 2021, 01:13:37 GMT, Paul B Mahol <
> [hidden email]> wrote:
>
>  On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <[hidden email]
> >
> wrote:
>
> > On 02/14/2021 07:34 PM, Paul B Mahol wrote:
> > > On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
> > [hidden email]>
> > > wrote:
> > >
> > >> Disclosure: Everything that follows may be wrong.
> > >>
> > >> I reckon that, except for a few filters, the important metric is PTS,
> > not
> > >> the frame #s assigned at a
> > >> filter's input node nor its wall-clock arrival time at a filter's
> input
> > >> node. For example,
> > >> 'interleave' performs frame interleaves based on the PTSs of incoming
> > >> frames -- at least, that's
> > >> what I think.
> > >>
> > >> Am I correct?
> > >>
> > >> If so, wouldn't it be helpful if filter documentation included how it
> > >> generates PTSs?
> > >>
> > >
> > > PTS are not generated.
> >
> > ffmpeg -i SOURCE -vf telecine TARGET
> >
> > What are the PTSs of the first 5 frames at the output of the filter?
> >
> >
> Interpolated by very complex formula.
>
>
> > --
> > Any journey, no matter how long, is just a series of small steps.
> > "Government is the problem!" -- 1982 and onward.
> > "_______ is the enemy of the people!" -- 2016 and onward.
> > "You have to fight like hell or you're not going to have a country!" --
> > Jan 6, 2021.
> > It isn't the distance that's important, it's the direction.
> > _______________________________________________
> > 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".
> _______________________________________________
> 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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
In reply to this post by FFmpeg-users mailing list
On 02/14/2021 08:19 PM, Phil Rhodes via ffmpeg-user wrote:
>   How does all this interact with files from cameras with very stable timing, such as broadcast and cinema cameras? ...

What is the antecedent of "this"? We've received no information yet, so how can you refer to "this"?

> Is there not a risk of long-term rounding errors?

Not for CFR I'd imagine. Perhaps that's why some informed folks advise to use solely CFR.

> P
>      On Monday, 15 February 2021, 01:13:37 GMT, Paul B Mahol <[hidden email]> wrote:
>  
>   On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
>>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
>> [hidden email]>
>>> wrote:
>>>
>>>> Disclosure: Everything that follows may be wrong.
>>>>
>>>> I reckon that, except for a few filters, the important metric is PTS,
>> not
>>>> the frame #s assigned at a
>>>> filter's input node nor its wall-clock arrival time at a filter's input
>>>> node. For example,
>>>> 'interleave' performs frame interleaves based on the PTSs of incoming
>>>> frames -- at least, that's
>>>> what I think.
>>>>
>>>> Am I correct?
>>>>
>>>> If so, wouldn't it be helpful if filter documentation included how it
>>>> generates PTSs?
>>>>
>>>
>>> PTS are not generated.
>>
>> ffmpeg -i SOURCE -vf telecine TARGET
>>
>> What are the PTSs of the first 5 frames at the output of the filter?
>>
>>
> Interpolated by very complex formula.
>
>
>> --
>> Any journey, no matter how long, is just a series of small steps.
>> "Government is the problem!" -- 1982 and onward.
>> "_______ is the enemy of the people!" -- 2016 and onward.
>> "You have to fight like hell or you're not going to have a country!" --
>> Jan 6, 2021.
>> It isn't the distance that's important, it's the direction.
>> _______________________________________________
>> 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".
> _______________________________________________
> 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".
>


--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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: Filter documentation -- PTSs

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

> On 02/14/2021 08:13 PM, Paul B Mahol wrote:
> > On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <
> [hidden email]>
> > wrote:
> >
> >> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
> >>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> Disclosure: Everything that follows may be wrong.
> >>>>
> >>>> I reckon that, except for a few filters, the important metric is PTS,
> >> not
> >>>> the frame #s assigned at a
> >>>> filter's input node nor its wall-clock arrival time at a filter's
> input
> >>>> node. For example,
> >>>> 'interleave' performs frame interleaves based on the PTSs of incoming
> >>>> frames -- at least, that's
> >>>> what I think.
> >>>>
> >>>> Am I correct?
> >>>>
> >>>> If so, wouldn't it be helpful if filter documentation included how it
> >>>> generates PTSs?
> >>>>
> >>>
> >>> PTS are not generated.
> >>
> >> ffmpeg -i SOURCE -vf telecine TARGET
> >>
> >> What are the PTSs of the first 5 frames at the output of the filter?
> >>
> >>
> > Interpolated by very complex formula.
>
> So, the PTSs are generated.
>
> What is the formula? Certainly it can't be anywhere nearly as complex as
> the differential equations
> and boundary conditions that control air flow through a duct of arbitrary
> shape or the air flow
> across an aircraft wing of arbitrary profile. I guess if I can handle
> those, I'll be able to handle
> the generated PTSs of a periodic series of frames, eh?
>

You need TB aka timebase too.

TB is rational.
PTS is 64bit integer.


>
> --
> Any journey, no matter how long, is just a series of small steps.
> "Government is the problem!" -- 1982 and onward.
> "_______ is the enemy of the people!" -- 2016 and onward.
> "You have to fight like hell or you're not going to have a country!" --
> Jan 6, 2021.
> It isn't the distance that's important, it's the direction.
> _______________________________________________
> 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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
On 02/14/2021 08:28 PM, Paul B Mahol wrote:

> On Mon, Feb 15, 2021 at 2:23 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> On 02/14/2021 08:13 PM, Paul B Mahol wrote:
>>> On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <
>> [hidden email]>
>>> wrote:
>>>
>>>> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
>>>>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Disclosure: Everything that follows may be wrong.
>>>>>>
>>>>>> I reckon that, except for a few filters, the important metric is PTS,
>>>> not
>>>>>> the frame #s assigned at a
>>>>>> filter's input node nor its wall-clock arrival time at a filter's
>> input
>>>>>> node. For example,
>>>>>> 'interleave' performs frame interleaves based on the PTSs of incoming
>>>>>> frames -- at least, that's
>>>>>> what I think.
>>>>>>
>>>>>> Am I correct?
>>>>>>
>>>>>> If so, wouldn't it be helpful if filter documentation included how it
>>>>>> generates PTSs?
>>>>>>
>>>>>
>>>>> PTS are not generated.
>>>>
>>>> ffmpeg -i SOURCE -vf telecine TARGET
>>>>
>>>> What are the PTSs of the first 5 frames at the output of the filter?
>>>>
>>>>
>>> Interpolated by very complex formula.
>>
>> So, the PTSs are generated.
>>
>> What is the formula? Certainly it can't be anywhere nearly as complex as
>> the differential equations
>> and boundary conditions that control air flow through a duct of arbitrary
>> shape or the air flow
>> across an aircraft wing of arbitrary profile. I guess if I can handle
>> those, I'll be able to handle
>> the generated PTSs of a periodic series of frames, eh?
>>
>
> You need TB aka timebase too.
>
> TB is rational.
> PTS is 64bit integer.

Thank you, Paul. I promise I can handle it. What is the formula?

_______________________________________________
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: Filter documentation -- PTSs

Paul B Mahol
On Mon, Feb 15, 2021 at 2:39 AM Mark Filipak (ffmpeg) <[hidden email]>
wrote:

> On 02/14/2021 08:28 PM, Paul B Mahol wrote:
> > On Mon, Feb 15, 2021 at 2:23 AM Mark Filipak (ffmpeg) <
> [hidden email]>
> > wrote:
> >
> >> On 02/14/2021 08:13 PM, Paul B Mahol wrote:
> >>> On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <
> >> [hidden email]>
> >>> wrote:
> >>>
> >>>> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
> >>>>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
> >>>> [hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> Disclosure: Everything that follows may be wrong.
> >>>>>>
> >>>>>> I reckon that, except for a few filters, the important metric is
> PTS,
> >>>> not
> >>>>>> the frame #s assigned at a
> >>>>>> filter's input node nor its wall-clock arrival time at a filter's
> >> input
> >>>>>> node. For example,
> >>>>>> 'interleave' performs frame interleaves based on the PTSs of
> incoming
> >>>>>> frames -- at least, that's
> >>>>>> what I think.
> >>>>>>
> >>>>>> Am I correct?
> >>>>>>
> >>>>>> If so, wouldn't it be helpful if filter documentation included how
> it
> >>>>>> generates PTSs?
> >>>>>>
> >>>>>
> >>>>> PTS are not generated.
> >>>>
> >>>> ffmpeg -i SOURCE -vf telecine TARGET
> >>>>
> >>>> What are the PTSs of the first 5 frames at the output of the filter?
> >>>>
> >>>>
> >>> Interpolated by very complex formula.
> >>
> >> So, the PTSs are generated.
> >>
> >> What is the formula? Certainly it can't be anywhere nearly as complex as
> >> the differential equations
> >> and boundary conditions that control air flow through a duct of
> arbitrary
> >> shape or the air flow
> >> across an aircraft wing of arbitrary profile. I guess if I can handle
> >> those, I'll be able to handle
> >> the generated PTSs of a periodic series of frames, eh?
> >>
> >
> > You need TB aka timebase too.
> >
> > TB is rational.
> > PTS is 64bit integer.
>
> Thank you, Paul. I promise I can handle it. What is the formula?
>
>
See source code of telecine filter. It is doing all calculations avoiding
floats.
But formula in floats are pretty trivial and straightforward to write.

Note that when you change pts in wrong way like you do, you need to change
timebase too
or you will get many problems out of nowhere.



> _______________________________________________
> 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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
On 02/14/2021 08:44 PM, Paul B Mahol wrote:

> On Mon, Feb 15, 2021 at 2:39 AM Mark Filipak (ffmpeg) <[hidden email]>
> wrote:
>
>> On 02/14/2021 08:28 PM, Paul B Mahol wrote:
>>> On Mon, Feb 15, 2021 at 2:23 AM Mark Filipak (ffmpeg) <
>> [hidden email]>
>>> wrote:
>>>
>>>> On 02/14/2021 08:13 PM, Paul B Mahol wrote:
>>>>> On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg) <
>>>> [hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On 02/14/2021 07:34 PM, Paul B Mahol wrote:
>>>>>>> On Mon, Feb 15, 2021 at 12:50 AM Mark Filipak (ffmpeg) <
>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Disclosure: Everything that follows may be wrong.
>>>>>>>>
>>>>>>>> I reckon that, except for a few filters, the important metric is
>> PTS,
>>>>>> not
>>>>>>>> the frame #s assigned at a
>>>>>>>> filter's input node nor its wall-clock arrival time at a filter's
>>>> input
>>>>>>>> node. For example,
>>>>>>>> 'interleave' performs frame interleaves based on the PTSs of
>> incoming
>>>>>>>> frames -- at least, that's
>>>>>>>> what I think.
>>>>>>>>
>>>>>>>> Am I correct?
>>>>>>>>
>>>>>>>> If so, wouldn't it be helpful if filter documentation included how
>> it
>>>>>>>> generates PTSs?
>>>>>>>>
>>>>>>>
>>>>>>> PTS are not generated.
>>>>>>
>>>>>> ffmpeg -i SOURCE -vf telecine TARGET
>>>>>>
>>>>>> What are the PTSs of the first 5 frames at the output of the filter?
>>>>>>
>>>>>>
>>>>> Interpolated by very complex formula.
>>>>
>>>> So, the PTSs are generated.
>>>>
>>>> What is the formula? Certainly it can't be anywhere nearly as complex as
>>>> the differential equations
>>>> and boundary conditions that control air flow through a duct of
>> arbitrary
>>>> shape or the air flow
>>>> across an aircraft wing of arbitrary profile. I guess if I can handle
>>>> those, I'll be able to handle
>>>> the generated PTSs of a periodic series of frames, eh?
>>>>
>>>
>>> You need TB aka timebase too.
>>>
>>> TB is rational.
>>> PTS is 64bit integer.
>>
>> Thank you, Paul. I promise I can handle it. What is the formula?
>>
>>
> See source code of telecine filter. ...

I can't read 'C'.

>... It is doing all calculations avoiding
> floats.
> But formula in floats are pretty trivial and straightforward to write.

Then my request should be easy for you. What is the formula?

> Note that when you change pts in wrong way like you do, you need to change
> timebase too
> or you will get many problems out of nowhere.

Indeed. I unknowingly make mistakes because I'm ignorant. That costs me hours and days and weeks of
my life.

Look, let's be straight with each other. You developers made the decision that, unlike other video
tools, you will use PTSs & TBs in lieu of frame numbers. That was an excellent decision and I
applaud it, and I applaud you. But if I can't predict and control PTSs & TBs, then I'm disarmed.
Surely you see that, eh?
_______________________________________________
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: Filter documentation -- PTSs

Carl Zwanzig
On 2/14/2021 5:54 PM, Mark Filipak (ffmpeg) wrote:
> On 02/14/2021 08:44 PM, Paul B Mahol wrote:


>> See source code of telecine filter. ...
> I can't read 'C'.

You really ought to learn, it's not that hard to _read_ although the context
and the data names matter a lot. And there are details that may not be so
easy to express in text which then just look like the code.


>> ... It is doing all calculations avoiding
>> floats.
>> But formula in floats are pretty trivial and straightforward to write.
>
> Then my request should be easy for you. What is the formula?

Some of these aren't mere a = b + c formulae, they have decision points in
the calculation which aren't readily expressed in algebra.

You'll see things like this (from vf_telecine.c/filter_frame)

frame->pts = (
      (s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
      av_rescale(outlink->frame_count_in, s->ts_unit.num, s->ts_unit.den);

then you need to know what av_rescale does (libavutils/mathematics.c).

Later,

z!
_______________________________________________
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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
On 02/15/2021 12:35 AM, Carl Zwanzig wrote:

> On 2/14/2021 5:54 PM, Mark Filipak (ffmpeg) wrote:
>> On 02/14/2021 08:44 PM, Paul B Mahol wrote:
>
>
>>> See source code of telecine filter. ...
>> I can't read 'C'.
>
> You really ought to learn, it's not that hard to _read_ although the context and the data names
> matter a lot. And there are details that may not be so easy to express in text which then just look
> like the code.
>
>
>>> ... It is doing all calculations avoiding
>>> floats.
>>> But formula in floats are pretty trivial and straightforward to write.
>>
>> Then my request should be easy for you. What is the formula?
>
> Some of these aren't mere a = b + c formulae, they have decision points in the calculation which
> aren't readily expressed in algebra.
>
> You'll see things like this (from vf_telecine.c/filter_frame)
>

Thanks, Carl,

> frame->pts = (
>       (s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
>       av_rescale(outlink->frame_count_in, s->ts_unit.num, s->ts_unit.den);

Okay. When I see that assignment,

var = (test) ? if_test_true_val : if_test_false_val //this is my favorite way to do a conditional
assignment though I prefer case statements because it's so easy to assure 100% coverage (and thereby
avoid bugs).

I don't know what this: 'frame->pts', means. I have written a ton of assembly code for various
micros and people tell me, "It's easy, Mark. 'frame->pts' is a 'pointer' to memory as in assembly",
but I don't see the analog of a memory address register in it. If 'pts' is a pointer, then how can
'frame' be written through that pointer and where does it get written? It's a mystery to me. Or is
'frame' the pointer and 'pts' the memory location?

I also write complex stuff like 'thisfun(var x=this, var y=that, var z=thatfun(theother))' as a
convenient alternative to
'thisfun(this, that, thatfun(theother))'
  all the time, but I don't get all the 'pointer' references that have similar types of structures.
'rescale()' looks like a function, but how can the arguments to a function be doing writes? If
they're not doing writes, then why do they have variable names: 'outlink' 's' and 's'? And how can
's' be input twice? Wouldn't their simple list order be enough to identify them for the code local
to 'rescale()'? In other words, why wouldn't 'rescale()' be
'rescale(->frame_count_in, ->ts_unit.num, ->ts_unit.den)'?
But then, since a variable name (any variable name) *is* a memory reference already, then why
wouldn't 'rescale()' simply be
'rescale(frame_count_in, ts_unit.num, ts_unit.den)'?

It's my deficiency, but it stops me cold every time I look at 'C' code. My brain just locks up.

> then you need to know what av_rescale does (libavutils/mathematics.c).
>
> Later,
>
> z!
> _______________________________________________
> 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".


--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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: Filter documentation -- PTSs

Chris Angelico
On Mon, Feb 15, 2021 at 5:32 PM Mark Filipak (ffmpeg)
<[hidden email]> wrote:
> > frame->pts = (
> >       (s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
> >       av_rescale(outlink->frame_count_in, s->ts_unit.num, s->ts_unit.den);
>
> I don't know what this: 'frame->pts', means. I have written a ton of assembly code for various
> micros and people tell me, "It's easy, Mark. 'frame->pts' is a 'pointer' to memory as in assembly",
> but I don't see the analog of a memory address register in it. If 'pts' is a pointer, then how can
> 'frame' be written through that pointer and where does it get written? It's a mystery to me. Or is
> 'frame' the pointer and 'pts' the memory location?

'frame' is a pointer to a structure of some sort, and 'pts' is a named
element within that structure. So you might have something like:

struct FrameyThingyWhatsit {
    int foo;
    int bar;
    void *quux;
    int pts;
    const char *flurble;
};

and then 'frame' would be a pointer to an in-memory structure of that
type. When you refer to 'frame->pts', that means 'look at the spot in
memory three words in from where frame points, and assign to that'.

But I think Carl's point was that you can't simply look at an
expression and decode it as algebra. To understand this line of code,
you not only have to interpret the syntax of this exact line, but -
and probably more importantly - you have to understand what the
av_rescale function is doing.

> It's my deficiency, but it stops me cold every time I look at 'C' code. My brain just locks up.

Yeah, well, I generally recommend spending as little time in C as
possible, if you want to be productive :) I like to pick up a library
like ffmpeg, and then write all the surrounding code in a high level
language like Python or Pike. The "heavy lifting" is done by the
library, but I spend 99% of my time working in high level code,
figuring out what I actually want my app to be doing.

ChrisA
_______________________________________________
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: Filter documentation -- PTSs

Mark Filipak (ffmpeg)
On 02/15/2021 01:56 AM, Chris Angelico wrote:

> On Mon, Feb 15, 2021 at 5:32 PM Mark Filipak (ffmpeg)
> <[hidden email]> wrote:
>>> frame->pts = (
>>>        (s->start_time == AV_NOPTS_VALUE) ? 0 : s->start_time) +
>>>        av_rescale(outlink->frame_count_in, s->ts_unit.num, s->ts_unit.den);
>>
>> I don't know what this: 'frame->pts', means. I have written a ton of assembly code for various
>> micros and people tell me, "It's easy, Mark. 'frame->pts' is a 'pointer' to memory as in assembly",
>> but I don't see the analog of a memory address register in it. If 'pts' is a pointer, then how can
>> 'frame' be written through that pointer and where does it get written? It's a mystery to me. Or is
>> 'frame' the pointer and 'pts' the memory location?
>
> 'frame' is a pointer to a structure of some sort, and 'pts' is a named
> element within that structure. So you might have something like:
>
> struct FrameyThingyWhatsit {
>      int foo;
>      int bar;
>      void *quux;
>      int pts;
>      const char *flurble;
> };
>
> and then 'frame' would be a pointer to an in-memory structure of that
> type. When you refer to 'frame->pts', that means 'look at the spot in
> memory three words in from where frame points, and assign to that'.

Well, that makes perfect sense. Thank you, Chris! You've removed most of the mystery. One thing
remains: What links the label "frame" to the structure "FrameyThingyWhatsit"? Is there a linker
directive somewhere, and what would it look like?

Oh, one thing I should clarify. All the folks who tried to explain pointers to me were firmware
writers. Perhaps that explains why they referred to memory, eh? Hahaha... never thought about it
before until you showed me the real codewright's view.

> But I think Carl's point was that you can't simply look at an
> expression and decode it as algebra. To understand this line of code,
> you not only have to interpret the syntax of this exact line, but -
> and probably more importantly - you have to understand what the
> av_rescale function is doing.

Well, I think I know what 'av_rescale()' is doing (at least for the 'minterpolate=fps=48/1.001' &
'telecine' filters). I ran some tests. Look:

24p-original timestamps.txt
     Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9],
23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
frames.frame.0.best_effort_timestamp_time="0:00:00.000000"
frames.frame.479.best_effort_timestamp_time="0:00:19.978000"
ms/frame = 19978/479 = 41.708 = ms/frame(48p-minterpolate48)*2   <<==

48p-minterpolate48 timestamps.txt
     Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9],
47.95 fps, 47.95 tbr, 1k tbn, 47.95 tbc (default)
frames.frame.0.best_effort_timestamp_time="0:00:00.000000"
frames.frame.955.best_effort_timestamp_time="0:00:19.916000"
ms/frame = 19916/955 = 20.854 = ms/frame(24p-original)/2   <<==

60p-minterpolate48,telecine timestamps.txt
     Stream #0:0: Video: hevc (Main), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9],
59.94 fps, 59.94 tbr, 1k tbn, 59.94 tbc (default)
frames.frame.0.best_effort_timestamp_time="0:00:00.000000"
frames.frame.1194.best_effort_timestamp_time="0:00:19.920000"
ms/frame = 19920/1194 = 16.683 = ms/frame(48p-minterpolate48)*4/5   <<==

See? PTS factors of '2' & '4/5'; just what one would expect. Those are the numbers that matter.

I imagine the rest of the code is involved in initialization of certain things that aren't already
defined, and scaling for things that could be represented as floats but are initialized as scaled
integers in order to improve the speed of the pipeline. Do those rationalizations sound reasonable
to you?

So, to wrap up, for the documentation, what would be good is the changes to PTSs for ordinary (or
usual) processing. Numbers like '2' & '4/5'. In the cases above, the numbers are simple, but in
other cases, the numbers are hard to suss out and seem to be inconsistent. And regarding VFR, well,
what would the numbers be? How would they be calculated?

If the VFR numbers can be expressed simply, that would be great. If expressing them requires some
textual explanation, that would still be very helpful no matter how difficult.

All of the foregoing assumes that PTSs are key. Since no one has commented on that part of my OP, I
assume that PTSs *are* key. If so, they should be expressed for each filter. I would help to do that
by running tests, but I would need to know going in that there's a home in the documentation for my
research. Otherwise, I'm not going to spend any more of my lifetime.

That's enough writing. Now it's bedtime (past bedtime). Thanks so much for your insights. You've
really cleared up pointers -- simple!

Mark.

--
Any journey, no matter how long, is just a series of small steps.
"Government is the problem!" -- 1982 and onward.
"_______ is the enemy of the people!" -- 2016 and onward.
"You have to fight like hell or you're not going to have a country!" -- Jan 6, 2021.
It isn't the distance that's important, it's the direction.
_______________________________________________
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".
12