[FFmpeg-user] Filter documentation -- PTSs

[Chris Angelico]

On Tue, Feb 16, 2021 at 8:29 AM Mark Filipak (ffmpeg)
<markfilipak at bog.us> wrote:
>
> On 02/15/2021 06:38 AM, Chris Angelico wrote:
> > On Mon, Feb 15, 2021 at 9:21 PM Mark Filipak (ffmpeg)
> > <markfilipak at bog.us> wrote:
> >> On 02/15/2021 01:56 AM, Chris Angelico wrote:
> >>> On Mon, Feb 15, 2021 at 5:32 PM Mark Filipak (ffmpeg)
> >>> <markfilipak at bog.us> 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. ...
> >>>
> >>> struct FrameyThingyWhatsit {
> >>>       int foo;
> >>>       int bar;
> >>>       void *quux;
> >>>       int pts;
> >>>       const char *flurble;
> >>> };
> >
> > "frame" is a variable, declared to be a pointer to a
> > FrameyThingyWhatsit, and assigned to something. It might be something
> > like this:
> >
> > struct FrameyThingyWhatsit *frame;
> >
> > frame = malloc(sizeof(FrameyThingyWhatsit));
> >
> > That'll allocate enough memory for the entire structure, and then
> > "frame" is a pointer to the start of that structure. Just like with
> > arrays ...
>
> "Thunk"!   ...The sound of pieces falling in place.
>
> So this:
>
> struct FrameyThingyWhatsit {...int pts;...}   ...a 'C' structure referenced by
> 'FrameyThingyWhatsit->pts'
>
> is equivalent to this:
>
> FrameyThingyWhatsit = [...pts,...]   ...an array referenced by 'FrameyThingyWhatsit[3]' (except that
> mixed datatypes in arrays are verboten)
>
> or maybe better analogy, to this:
>
> FrameyThingyWhatsit = {...pts,...}   ...an object referenced by 'FrameyThingyWhatsit.pts'
>
> >... you hang onto a pointer to the base of it, and then you index
> > into it; the compiler knows the layout of the structure, so when you
> > say "frame->pts", it knows exactly how many bytes above the base of
> > the structure to find that member.
>
> Ah, so there can be
> struct thisframe {...int pts;...}
> struct thatframe {...int pts;...}
> struct otherframe {...int pts;...}
> referenced by 'thisframe->pts', 'thatframe->pts', and 'otherframe->pts', and the 3 'pts's are
> independent of one another, sort of like 3 namespaces.
>
> I think I have it right, or do I?

Yes. The "pts" in each case has no meaning on its own, and the
compiler understands it specifically by knowing the type of the
variable that you're looking at.

(Other languages work differently, but this is C's way of doing things.)

> >>> 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:
> >
> > Uhh..... cool. This is the part where I'm the one who has no clue
> > what's going on, so I'm just going to do the whole "smile and nod"
> > thing, and trust that you know what's going on :)
>
> Well, here's the thing: At times PTSs are perfect [1], or sometimes they're bollixed but the video
> nonetheless plays properly [2], or sometimes it doesn't play properly [3].
> [1] 60/1.001fps example: MPV shows "FPS: 59.940 (specified) 59.940 (estimated)"
> [2] 60/1.001fps example: MPV shows "FPS: 60.025 (specified) 59.940 (estimated)"
> [3] 60/1.001fps example: MPV shows "FPS: 59.940 (specified) ...wanders... (estimated)"
>
> That playback behavior is the 1st clue I got that PTSs are key. Why are there MPV differences
> remains a mystery -- I assume that it indicates that the PTSs are (may be) correct but the video's
> metadata is wrong. Of course, my inference may be wrong -- ffmpeg investigation is like reading a
> murder mystery.

Ahh, yep, gotcha.

> > Glad I could help! You're on your own for the next part, but if I've
> > been of any value at all, that's awesome. All the best!
> >
> > ChrisA
>
> You did well, Chris, and you did good. Thanks so much. I feel I know what 'C' structures are and how
> the '->' operator works -- before you, I didn't even know that '"struct "+label+"{ "+type+" "+var"
> }"' and 'label+"->"+var"' were related. The bottom line is this: A struct is the 'C'-way to
> instantiate an object -- Yes, I'm aware of C++. It's sort of a 'C' language architecture hack, isn't
> it?
>

In object-oriented languages, an object has methods (functions, code)
as well as data members, but C just has the members, the pure data.
But yes, it's basically the C way to do this.

ChrisA