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

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Saturday, July 2, 2022 10:40 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Cc: Michael Niedermayer <michael@niedermayer.cc>; Andriy Gelman
> <andriy.gelman@gmail.com>; Andreas Rheinhardt
> <andreas.rheinhardt@outlook.com>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022
> 
> On Sat, Jul 2, 2022 at 10:32 PM Soft Works <softworkz@hotmail.com>
> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Nicolas George
> > > Sent: Saturday, July 2, 2022 9:36 PM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Cc: Michael Niedermayer <michael@niedermayer.cc>; Andriy Gelman
> > > <andriy.gelman@gmail.com>; Andreas Rheinhardt
> > > <andreas.rheinhardt@outlook.com>
> > > Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering
> 2022
> > >
> > > Soft Works (12022-07-02):
> > > > This can easily be done AFTER my patchset has been merged.
> > >
> > > With exponentially more work. Out of question.
> >
> > Previously it would have been about like:
> >
> > - Merging audio filter code with the video filter code
> >   (for the filters in question)
> >
> > Now it will be
> >
> > - Merging audio and subtitle filter code with the video filter code
> >   (for the same filters)
> >
> > TBH, I can't see any exponent here. I think "double work" would be
> > closer to the truth and realistically it will be much less than
> that
> > because the work for merging audio and subtitle code is very
> similar,
> > so when you have merged audio code in a filter, merging the
> subtitle
> > part will be very analogous, so in total it would be less than
> > double.
> >
> > And when we look at the required amount of work in total, that
> > calculation would only be valid when you would consider the value
> > of MY work that I've already done as zero.
> >
> > I even think that it's a better approach overall to do the
> deduplication
> > afterwards, because now - with the subtitle filtering patchset -
> the
> > specific requirements for subtitle filtering are visible on the
> table
> > and that way, the deduplication can already provision for those
> > specific requirements whereas focusing on audio/video only, might
> have
> > led to do changes that wouldn't accommodate for the needs of
> subtitle
> > filtering.
> >
> > I am convinced that doing deduplication afterwards is a better
> order
> > for getting this done. I'm also convinced that my patchset is
> pretty
> > solid in the way it does handle subtitles, and I'm further
> convinced
> > that you know that very well. During all the process I have watched
> > very closely, and in several cases where others had objections
> about
> > things I had done, you kept quiet, presumably because you were the
> only
> > other one to know why it had to be done that way. Also, you never
> > named any specific detail that would be wrong, and I'm sure you
> would
> > have done if there had been any significant one.
> > My impression is that your primary reason for objection is that my
> > patchset interferes with your plans and visions you probably had in
> > mind for quite a while and I'm very sorry about that.
> > But in the end, my patchset doesn't stand in opposition to your
> plans,
> > it just requires a bit of adaption regarding the order of doing the
> work.
> > Neither do I stand in opposition to your plans. I respect the
> technical
> > architecture of libavfilter, especially regarding its simplicity
> and
> > effectivity compared to other filtering frameworks (like
> DirectShow)
> > and my interest in Ffmpeg filtering is not limited to subtitles.
> > We don't need to be friends, but when you would manage to act and
> > communicate in a friendly way, you might gain somebody to help with
> > and support your plans in the future and you would also do a favor
> > to all readers of the ML by not having them read through despicable
> > conversations.
> >
> 
> AFAIK only NIcolas is for this merge of different types of filters
> into
> single filter,
> and filter type negotiation.
> 
> Both ideas are very bad. And Nicolas is (still) not (yet) FFmpeg
> dictator.

I think it makes sense for certain filters like buffer source, buffer
sink, null sink, trim, showinfo, copy, delay, repeat, etc.

Yet there is no point in making this a pre-condition for subtitle 
filtering, it's out of scope.

sw



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".