[FFmpeg-devel] [PATCH 4/9] avfilter/overlay_subs: Add overlay_subs filter

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Thursday, 19 August 2021 10:28
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/9] avfilter/overlay_subs: Add
> overlay_subs filter
> 
> Soft Works (12021-08-19):
> > The primary problem I have is that the regular overlay filter just
> > enforces an overlay format that matches the primary input video format:
> >
> > e.g.: when the primary video is yuv420p, it requests yuva420p for
> > the overlay input which causes a format filter to be inserted
> automatically.
> >
> > That's not possible in this case because we have subtitle frames as
> > input. Ideally, there wouldn't happen any format conversion up-front.
> > Neither for the main video, nor for the overlay rects.
> > What I mean is, that only the pixels of the overlay area would be touched,
> > like for example: convert yuv to rgb, blend with rgba overlay, convert
> > back rgb to yuv.
> >
> > Does that make sense?
> 
> Yes and no. Yes it makes sense in itself.
> 
> But no, it does not make sense as an excuse to duplicate hundreds of
> lines of code. If you want this special filter, you have to find a way
> of sharing the code.

I forgot to add [RFC PATCH]. I'm clearly not intending to have those
duplicate (and even unused) lines to be committed.

It's just at a point where I'm wondering whether the idea that I have 
described above (touching only relevant regions) could be implemented
easily or whether there might already exist something similar.

> But I can say immediately that, after a quick glance, I do not like your
> patch series at all, for a very simple reason: it is all over the place.

Remove the new filters and it's quickly getting more compact.


> One of the key features of the sub2video hack was that it was entirely
> contained: a few dozens lines of code in ffmpeg.c clearly identified.
> Once proper support for subtitles in libavfilter is added, removing the
> sub2video hack will be very easy.
> 
> As far as I can see, your proposal does not have that feature. Quite the
> opposite: it takes the place in libavfilter that proper subtitles
> support would take. As such, it makes it harder to implement subtitles
> properly.
> If you want to help on this, consider helping implementing real
> subtitles support in libavfilter.

Where is my proposed code for libavfilter different from "proper"
subtitles support?

I think at the libavfilter side, this is pretty how it will have
to be for "proper" implementation.
(anyway, it can't be much wrong as it is done just analog to audio and 
video)

I think that the area that is remaining in a somewhat "dirty" state 
is the heartbeat mechanism, which I have kept from sub2video.
As mentioned, I didn't want to make a step too big and rather keep 
things working and compatible.

softworkz