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

[Paul B Mahol]

On Sat, Jul 2, 2022 at 10:32 PM Soft Works <softworkz at hotmail.com> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Nicolas George
> > Sent: Saturday, July 2, 2022 9:36 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Cc: Michael Niedermayer <michael at niedermayer.cc>; Andriy Gelman
> > <andriy.gelman at gmail.com>; Andreas Rheinhardt
> > <andreas.rheinhardt at 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.


> Best regards,
> softworkz
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>