[FFmpeg-devel] [PATCH v5 00/12] Subtitle Filtering

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Wednesday, 15 September 2021 11:21
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v5 00/12] Subtitle Filtering
> 
> On Wed, Sep 15, 2021 at 9:39 AM Soft Works <softworkz at hotmail.com>
> wrote:
> >
> > In my upcoming patchset, I have added a new struct AVSubtitleArea
> > which is similar to AVSubtitleRect with the difference that
> >
> > - It's not AVSubtitleRect (which can be deprecated then)
> > - It uses refcounted buffers for the image data
> >
> > AVFrame gets an array of AVSubtitleArea structs. The image data
> > is attached to AVSubtitleArea (data, buf, linesize).
> >
> > I'm not sure whether it would make sense to store the image data in
> > buf/data of AVFrame like
> >
> > AVSubtitleArea[0] <=> buf[0], buf[1]
> > AVSubtitleArea[1] <=> buf[2], buf[3]
> >
> 
> I suppose the main problem is that there can be more areas then we
> have buf entries?
> There is just one small wrinkle, there is an expectation in various
> areas of the code that an empty frame has buf[0] zero, and conversely
> a filled one does not.

You made re-think this and there are quite a number of places that
do that buf[0] checking. Replacing those checks with an API method
might make sense, but I think it's beyond the scope of this patchset.

The context above was about whether storing bitmap buffers in
individual rects or inside the buffers of AVFrame. 
We need to be aware though, that storing the buffers in AVFrame
wouldn't help with the checks for frame->buf[0], because:

- For text subtitles, the texts are not stored in buffers
- Subtitle frames that do not contain any rects at all are 
  still valid

For those reasons I resorted to adding a simple 1-byte buffer to
subtitle frames in buf[0]. This allows to remain compatible with all 
existing frame handling logic.
The meaning of buf[0]=!0 is the same as for other frames: "has data"
as it will only get set on calling av_frame_get_buffer2.

Kind regards,
softworkz