[FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prepare AVFrame for subtitle handling

[Hendrik Leppkes]

On Mon, Dec 6, 2021 at 1:24 AM Soft Works <softworkz at hotmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Hendrik
> > Leppkes
> > Sent: Monday, December 6, 2021 12:37 AM
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v20 02/20] avutil/frame: Prepare AVFrame
> > for subtitle handling
> >
> > On Mon, Dec 6, 2021 at 12:23 AM Soft Works <softworkz at hotmail.com> wrote:
> > >
> > > It can only work like that.
> > >
> >
> > You literally designed subtitle filtering. You defined how it works.
> > All your explanations come down to some fancy form of "because I made
> > it required".
> >
> > All I'm hearing is that some internal mechanisms in avfilter need it.
> > Why is it a public field in one of the most key structures in our
> > entire codebase? You understand this concern, right? Any public field
> > should first (and only) answer the question, what information does
> > this convey to the user? Does the user need this information? I'm not
> > seeing any of that in your explanations. All I'm seeing is internal
> > avfilter workings - cemented in public API.
> >
> > You are not integrating into an existing infrastructure, you are
> > literally trying to add the whole thing, so you can change it to not
> > need this redundant field.
> >
> > - Hendrik
>
> OK, maybe this is better to understand. Very simple burn-down:
>
> I send a subtitle frame into a filtergraph.
>
> pts = 10
> subtitle_pts = 10
>
> Now I need to re-send a duplicate of that frame into the graph
> (=> heartbeat - to keep the graph flowing)
>
> Now, it's not possible (by lavf design, not mine) to send another frame
> without increasing the pts of the frame. So we send it like this:
>
> pts = 11
> subtitle_pts = 10
>
> The pts needs to be increased. But the start-display time of the
> subtitle event must not be changed - it's still the same frame like
> before, just a duplicate.
>

You just keep re-iterating that avfilter internals need it. And I'll
just keep saying that avfilter internals shall not define public API
design. I have not heard anything that justifies yet another field
that has no benefit to the external public API - to the contrary even,
a user would assume pts is pts, and he would be wrong.

- Hendrik