[FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Friday, August 26, 2022 10:47 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
> 
> Quoting Soft Works (2022-08-25 00:19:33)
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Jean-Baptiste Kempf
> > > Sent: Monday, August 22, 2022 4:39 PM
> > > To: ffmpeg-devel at ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering
> 2022
> > >
> > > On Mon, 22 Aug 2022, at 14:18, Anton Khirnov wrote:
> > > > Almost exactly identical objections to the basic aspects of the
> API
> > > were
> > > > raised independently by me, Lynne, and Hendrik.
> > > > IIUC Soft Works still refuses to address them (though it's not
> so
> > > easy
> > > > to tell in a 200-email thread).
> > >
> > > OK. I lost the lists of objections, then.
> > >
> > > --
> > > Jean-Baptiste Kempf -  President
> >
> >
> > Could everybody who still has any objection PLEASE name it with
> reasoning
> > and explain in which way it should be resolved?
> 
> Most of the main objections are mentioned in [1]. As far as I can
> tell, none of them were adequately addressed.

Hi Anton,

thanks a lot for your reply.

In fact, all of these were addressed long ago.
http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-December/288894.html

That message you referenced is about 4 issues:


1. "Milliseconds?"

I have changed fields to int64_t values in AV_TIME_BASE,
please see below.


2. "There's no reason why this cannot be handled using the buffer
    and data fields"

I had explained the reasons and in conversation on IRC, Lynne was
no longer insisting on this AFAIR.


3. "I'm not going to accept a field which is instantly deprecated."

I have reworked this and there is no longer a field that is 
instantly deprecated.


3. "As we've discussed multiple times, please merge this into
   the regular frame PTS field. We already have _2_ necessary
   stard/end fields."

I have addressed this as well already. There are no longer 3 
but only 2 fields remaining (int64_t in AV_TIME_BASE): 

AVFrame.subtitle_timing.start_pts
AVFrame.subtitle_timing.duration



> Frankly, you write too many words. A good argument about something
> like
> this should fit in a paragraph. Maybe followed by some extended
> explanations and clarifications, but the core of it should be quite
> short and right at the top, not buried under heaps of introductory
> remarks and examples. And if you cannot boil down your argument to a
> few words then maybe it's not a very strong one.

It's a complicated matter and after I had seen that the situation 
wasn't understood, I started to get more into detail.

I will try to write less text in the future.


> Or maybe people just got tired of repeating the same objections to
> the
> same patches being submitted again and again.

Or maybe people didn't realize that the objections were addressed
already?

> You are the author of this set, it is _your_ job to keep track of
> what has and has not been addressed

I do that, and the count of unaddressed objections that I'm aware
of is zero.

That's why I'm asking whether anybody would still have an objection
or might not see her/his objection being addressed adequately.


Thanks again,
softworkz


PS: the one thing that was under discussion on IRC was about why
the subtitle start_pts cannot be the same as the AVFrame pts
and that was the point I was explaining in so much detail.