[FFmpeg-user] Filter documentation -- PTSs

[Chris Angelico]

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

"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, 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.

(It's not necessarily going to be the sum of the sizes of the
preceding elements, due to alignment requirements and padding. But if
there's any complexities to it, it's the compiler's job to know about
them. As the programmer, you just use the name of the member, and
it'll figure out the details.)

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

Heh maybe. I mainly work in high level languages, preferring to dip
into C only when necessary (such as when implementing an interpreter
for an HLL!); but I've also taught data structures and algorithms
using a combination of JavaScript and, I kid you not, a deck of cards
on a desk. With a webcam mounted vertically on a hacked-up lamp arm.
But if you've ever tried to comprehend quicksort by reading through a
highly optimized C implementation, you'll appreciate the WAY easier
explanation that doesn't look at memory at all :)

(Seriously, quicksort is actually a very simple algorithm. It's just
that it becomes almost completely opaque when you look at an in-place
implementation.)

> > 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 :)

> 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?

Yeah, they definitely sound plausible, but I haven't looked at the code.

> 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!
>

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