Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up

From: Hendrik Leppkes <h.leppkes@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
Date: Tue, 3 Jun 2025 20:02:08 +0200
Message-ID: <CA+anqdwVei3k-cxhhOhBi+u+1neij1aTviTXDJTA4iz3iKE0rw@mail.gmail.com> (raw)
In-Reply-To: <DM8P223MB0365BD8492EA1137948089E5BA6DA@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>

On Tue, Jun 3, 2025 at 4:21 PM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
>
> Making it explicit now in the form of the AVSubtitleFlowMode enum
> provides a number of benefits:
>
> - It finally provides an understandable explanation for why those two
>   extra timing fields are needed
>

You say that, but I don't see that at all. In 3 of your 4 cases, the
two sets of fields seem to be close to identical with no good reason
to be separate, and the 4th case is an implementation detail that is
being forced into the API.

In fact, this is the main problem that plagued this patchset from the
start. The newly introduced public API is designed around
ffmpeg.c/lavfi implementation details, rather than cleanly
representing subtitle data and then adjusting the implementation to
actually support it.
And this is the reason it never found acceptance. And this has
seemingly not changed. All that changed is trying to explain it away.

For a clean API in the future, we should start with a clean and clear
definition of public API, and not use it to solve
implementation-specific solutions in lavfi that should rather get
solved in lavfi itself, and not in the user-facing API.
And this is exactly what I've also tried to explain from day one that
this patchset showed up on the ML.

- Hendrik
_______________________________________________
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".