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

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

[softworkz .]

Hello everybody,

[just deleted a whole page of introduction text that was 
essentially pointless]

Getting right to the point, I will give it once another try,  
rework and resubmit an updated version of the subtitle filtering 
patchset, including all improvements and fixes that have been 
made in the meantime.

To avoid unnecessary work, it would be great to get one 
crucial part settled up-front.


New fields on AVFrame for Subtitle Filtering 
============================================

Some of them are used from so many places, that it's a really 
tedious job to change them, hence I'd like to get this cleared-up
before.

Let's go through them:


- enum AVMediaType type;
  This had never been questioned, it should be clear why it's needed


- unsigned num_subtitle_areas;
- AVSubtitleArea **subtitle_areas;
  There were extensive discussions about why the data isn't stored in 
  the video buffers, but eventually there was no more objection


- AVBufferRef *subtitle_header;
  The reason why the ASS header needs to be moved around has been 
  explained and wasn't objected eventually


- int repeat_sub;
  The use case is evident. But I have seen that a number of similar 
  fields have been removed meanwhile and replaced by flags.
  So, the question here would be whether this should also be migrated
  to a flag?


- Time Fields
  This has been the one most discussed topic, but nothing has
  changed in this regard: it requires a separate start and a 
  separate duration field for subtitles.
  There's one improvement I make, which is the addition of a flow_mode
  field. I'll explain the details further down below.

  My preferred way for including the field in the AVFrame struct 
  used to be a sub-struct - simply because it unclutters the list 
  of AVFrame members:

    struct SubtitleTiming
    {
        int64_t start_pts;
        int64_t duration;
        AVSubtitleFlowMode flow_mode;

    } subtitle_timing;


    The same could be done for the other fields:

    struct Subtitles
    {
        unsigned num_subtitle_areas;
        AVSubtitleArea **subtitle_areas;
        AVBufferRef *subtitle_header;

    } subtitles;


    Or all in one:

    struct Subtitles
    {
        unsigned num_subtitle_areas;
        AVSubtitleArea **subtitle_areas;
        AVBufferRef *subtitle_header;

        int64_t start_pts;
        int64_t duration;
        AVSubtitleFlowMode flow_mode;

    } subtitles;



    Of course, they can also be added as flat members, but will 
    require a prefix then, like:

    int64_t subtitle_start_pts;
    int64_t subtitle_duration;
    AVSubtitleFlowMode subtitle_flow_mode;


Please let me know which way you would deem to be most suitable and 
whatever thoughts or questions you might have beyond this.



Subtitle Flow Mode
==================

Please see the list and explanation of flow modes here:
https://github.com/softworkz/SubtitleFilteringDemos/issues/4

This is not something conceptually new. It has always existed, but just
implicitly behind the scenes and you had to know about it in some way
for creating working FFmpeg command lines, because not 
every subtitle decoder, neither every subtitle filter nor every subtitle 
encoder is compatible with each other, even when there's a match in
subtitle type (text/bitmap). Actually, it also needs the flow modes 
to match or be compatible. In the original set, it just failed in those 
cases or deadlocked.

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

- It makes clear what I had continuously failed to explain 

- By giving names to the modes, it will be much easier to understand 
  and talk about

- It allows to provide better feedback to users in case of error, 
  like writing out something like "incompatible flow modes"

- It will be possible to simplify usage: By including this as
  a parameter in filter negotiation, we will be able to perform 
  auto-filter insertions in cases where its reasonable.


Please let me know about your thoughts!

Best regards,
softworkz


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

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

[Lynne]

You don't get to say "oh, there were no more objections, so it was fine" 
or "the use is evident" after the mess that your original patchsets were.

You're still not using the native time fields, nor the packet buffers, 
which is a very hard NAK from me.

On 03/06/2025 23:20, softworkz . wrote:
> Hello everybody,
> 
> [just deleted a whole page of introduction text that was
> essentially pointless]
> 
> Getting right to the point, I will give it once another try,
> rework and resubmit an updated version of the subtitle filtering
> patchset, including all improvements and fixes that have been
> made in the meantime.
> 
> To avoid unnecessary work, it would be great to get one
> crucial part settled up-front.
> 
> 
> New fields on AVFrame for Subtitle Filtering
> ============================================
> 
> Some of them are used from so many places, that it's a really
> tedious job to change them, hence I'd like to get this cleared-up
> before.
> 
> Let's go through them:
> 
> 
> - enum AVMediaType type;
>    This had never been questioned, it should be clear why it's needed
> 
> 
> - unsigned num_subtitle_areas;
> - AVSubtitleArea **subtitle_areas;
>    There were extensive discussions about why the data isn't stored in
>    the video buffers, but eventually there was no more objection
> 
> 
> - AVBufferRef *subtitle_header;
>    The reason why the ASS header needs to be moved around has been
>    explained and wasn't objected eventually
> 
> 
> - int repeat_sub;
>    The use case is evident. But I have seen that a number of similar
>    fields have been removed meanwhile and replaced by flags.
>    So, the question here would be whether this should also be migrated
>    to a flag?
> 
> 
> - Time Fields
>    This has been the one most discussed topic, but nothing has
>    changed in this regard: it requires a separate start and a
>    separate duration field for subtitles.
>    There's one improvement I make, which is the addition of a flow_mode
>    field. I'll explain the details further down below.
> 
>    My preferred way for including the field in the AVFrame struct
>    used to be a sub-struct - simply because it unclutters the list
>    of AVFrame members:
> 
>      struct SubtitleTiming
>      {
>          int64_t start_pts;
>          int64_t duration;
>          AVSubtitleFlowMode flow_mode;
> 
>      } subtitle_timing;
> 
> 
>      The same could be done for the other fields:
> 
>      struct Subtitles
>      {
>          unsigned num_subtitle_areas;
>          AVSubtitleArea **subtitle_areas;
>          AVBufferRef *subtitle_header;
> 
>      } subtitles;
> 
> 
>      Or all in one:
> 
>      struct Subtitles
>      {
>          unsigned num_subtitle_areas;
>          AVSubtitleArea **subtitle_areas;
>          AVBufferRef *subtitle_header;
> 
>          int64_t start_pts;
>          int64_t duration;
>          AVSubtitleFlowMode flow_mode;
> 
>      } subtitles;
> 
> 
> 
>      Of course, they can also be added as flat members, but will
>      require a prefix then, like:
> 
>      int64_t subtitle_start_pts;
>      int64_t subtitle_duration;
>      AVSubtitleFlowMode subtitle_flow_mode;
> 
> 
> Please let me know which way you would deem to be most suitable and
> whatever thoughts or questions you might have beyond this.
> 
> 
> 
> Subtitle Flow Mode
> ==================
> 
> Please see the list and explanation of flow modes here:
> https://github.com/softworkz/SubtitleFilteringDemos/issues/4
> 
> This is not something conceptually new. It has always existed, but just
> implicitly behind the scenes and you had to know about it in some way
> for creating working FFmpeg command lines, because not
> every subtitle decoder, neither every subtitle filter nor every subtitle
> encoder is compatible with each other, even when there's a match in
> subtitle type (text/bitmap). Actually, it also needs the flow modes
> to match or be compatible. In the original set, it just failed in those
> cases or deadlocked.
> 
> 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
> 
> - It makes clear what I had continuously failed to explain
> 
> - By giving names to the modes, it will be much easier to understand
>    and talk about
> 
> - It allows to provide better feedback to users in case of error,
>    like writing out something like "incompatible flow modes"
> 
> - It will be possible to simplify usage: By including this as
>    a parameter in filter negotiation, we will be able to perform
>    auto-filter insertions in cases where its reasonable.
> 
> 
> Please let me know about your thoughts!
> 
> Best regards,
> softworkz
> 
> 
> _______________________________________________
> 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".
_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 377 bytes --]

The first sentence was unnecessary. No need to be this aggressive.

On 6/3/2025 1:00 PM, Lynne wrote:
> You don't get to say "oh, there were no more objections, so it was fine" 
> or "the use is evident" after the mess that your original patchsets were.
> 
> You're still not using the native time fields, nor the packet buffers, 
> which is a very hard NAK from me.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> Sent: Dienstag, 3. Juni 2025 18:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> You don't get to say "oh, there were no more objections, so it was fine"

If you do have an objection, please elaborate:

- what specifically you are objecting
- for which reason you are objecting it
- how you think it should be done instead


> or "the use is evident" 

- Please explain what is unclear and not evident to you 
  about the field named "repeat_sub"



> after the mess that your original patchsets were.

Please elaborate in which way the patchset was "a mess"?


> You're still not using the native time fields, 

Please read the references documentation about AVSubtitleFlowMode.
It provides clarity about the requirement for those timing fields,
just like noted in the text.


> nor the packet buffers,

We can dig up the earlier conversations about it and the conclusions
that were made, then we will see whether I was mistaken or not by
saying that there weren't any remaining objections in this regard.



> which is a very hard NAK from me.

I do not have the impression that this was a serious review
or response, tbh.

Best regards
sw




> On 03/06/2025 23:20, softworkz . wrote:
> > Hello everybody,
> >
> > [just deleted a whole page of introduction text that was
> > essentially pointless]
> >
> > Getting right to the point, I will give it once another try,
> > rework and resubmit an updated version of the subtitle filtering
> > patchset, including all improvements and fixes that have been
> > made in the meantime.
> >
> > To avoid unnecessary work, it would be great to get one
> > crucial part settled up-front.
> >
> >
> > New fields on AVFrame for Subtitle Filtering
> > ============================================
> >
> > Some of them are used from so many places, that it's a really
> > tedious job to change them, hence I'd like to get this cleared-up
> > before.
> >
> > Let's go through them:
> >
> >
> > - enum AVMediaType type;
> >    This had never been questioned, it should be clear why it's needed
> >
> >
> > - unsigned num_subtitle_areas;
> > - AVSubtitleArea **subtitle_areas;
> >    There were extensive discussions about why the data isn't stored in
> >    the video buffers, but eventually there was no more objection
> >
> >
> > - AVBufferRef *subtitle_header;
> >    The reason why the ASS header needs to be moved around has been
> >    explained and wasn't objected eventually
> >
> >
> > - int repeat_sub;
> >    The use case is evident. But I have seen that a number of similar
> >    fields have been removed meanwhile and replaced by flags.
> >    So, the question here would be whether this should also be migrated
> >    to a flag?
> >
> >
> > - Time Fields
> >    This has been the one most discussed topic, but nothing has
> >    changed in this regard: it requires a separate start and a
> >    separate duration field for subtitles.
> >    There's one improvement I make, which is the addition of a flow_mode
> >    field. I'll explain the details further down below.
> >
> >    My preferred way for including the field in the AVFrame struct
> >    used to be a sub-struct - simply because it unclutters the list
> >    of AVFrame members:
> >
> >      struct SubtitleTiming
> >      {
> >          int64_t start_pts;
> >          int64_t duration;
> >          AVSubtitleFlowMode flow_mode;
> >
> >      } subtitle_timing;
> >
> >
> >      The same could be done for the other fields:
> >
> >      struct Subtitles
> >      {
> >          unsigned num_subtitle_areas;
> >          AVSubtitleArea **subtitle_areas;
> >          AVBufferRef *subtitle_header;
> >
> >      } subtitles;
> >
> >
> >      Or all in one:
> >
> >      struct Subtitles
> >      {
> >          unsigned num_subtitle_areas;
> >          AVSubtitleArea **subtitle_areas;
> >          AVBufferRef *subtitle_header;
> >
> >          int64_t start_pts;
> >          int64_t duration;
> >          AVSubtitleFlowMode flow_mode;
> >
> >      } subtitles;
> >
> >
> >
> >      Of course, they can also be added as flat members, but will
> >      require a prefix then, like:
> >
> >      int64_t subtitle_start_pts;
> >      int64_t subtitle_duration;
> >      AVSubtitleFlowMode subtitle_flow_mode;
> >
> >
> > Please let me know which way you would deem to be most suitable and
> > whatever thoughts or questions you might have beyond this.
> >
> >
> >
> > Subtitle Flow Mode
> > ==================
> >
> > Please see the list and explanation of flow modes here:
> > https://github.com/softworkz/SubtitleFilteringDemos/issues/4
> >
> > This is not something conceptually new. It has always existed, but just
> > implicitly behind the scenes and you had to know about it in some way
> > for creating working FFmpeg command lines, because not
> > every subtitle decoder, neither every subtitle filter nor every subtitle
> > encoder is compatible with each other, even when there's a match in
> > subtitle type (text/bitmap). Actually, it also needs the flow modes
> > to match or be compatible. In the original set, it just failed in those
> > cases or deadlocked.
> >
> > 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
> >
> > - It makes clear what I had continuously failed to explain
> >
> > - By giving names to the modes, it will be much easier to understand
> >    and talk about
> >
> > - It allows to provide better feedback to users in case of error,
> >    like writing out something like "incompatible flow modes"
> >
> > - It will be possible to simplify usage: By including this as
> >    a parameter in filter negotiation, we will be able to perform
> >    auto-filter insertions in cases where its reasonable.
> >
> >
> > Please let me know about your thoughts!
> >
> > Best regards,
> > softworkz
> >
> >
> > _______________________________________________
> > 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".
> _______________________________________________
> 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".
_______________________________________________
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".

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

[Devin Heitmueller]

Hi Lynne,

Hope all is well with you.

On Tue, Jun 3, 2025 at 12:00 PM Lynne <dev@lynne.ee> wrote:
> You're still not using the native time fields, nor the packet buffers,
> which is a very hard NAK from me.

I know there's been alot of pushback on the use of the native time
fields, but have you actually read softwork's writeup on why he feels
it's necessary?

https://github.com/softworkz/SubtitleFilteringDemos/issues/1

It's easy to dismiss him or say, "this guy obviously doesn't know what
the hell he's doing", but I think he's got a fair question, and I'm
not confident anyone has proposed anything that actually accommodates
the use case he has raised.  I've seen lots of, "You MUST use the
native time fields", but nobody saying, "Oh given what you're trying
to accomplish here's a better approach..."

Regards,

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Dienstag, 3. Juni 2025 16:21
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up

I am sorry in case this message was somewhat too brief for anybody.

Of course, I will happily explain when something is unclear and provide
references to earlier conversations when there's any doubt about past events.

Thank you
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".

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

[Nicolas George]

James Almer (HE12025-06-03):
> The first sentence was unnecessary. No need to be this aggressive.

“softworks” has been abusing many people in the last week but it is
Lynne that you decide to chide?

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

Lynne (HE12025-06-04):
> You don't get to say "oh, there were no more objections, so it was fine" or
> "the use is evident" after the mess that your original patchsets were.
>
> You're still not using the native time fields, nor the packet buffers, which
> is a very hard NAK from me.

Indeed. And not just that. The whole series had many deep logic flaws
that made it a dead end without a complete rewrite. I explained at the
time, and “softworkz” was almost as rude then than they are now. My
patience if more than exhausted, I will not explain again.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 431 bytes --]

On 6/3/2025 1:40 PM, Nicolas George wrote:
> James Almer (HE12025-06-03):
>> The first sentence was unnecessary. No need to be this aggressive.
> 
> “softworks” has been abusing many people in the last week but it is
> Lynne that you decide to chide?

I missed it if he was aggressive to someone else before. I just saw this 
email and replied accordingly.
In any case, aggression to fight aggression goes nowhere.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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

[Devlist Archive]

Please can we stop keeping score and give everyone a chance to actually get
some work done?  I would love to see more objective discussions on this
topic.  As others have mentioned, let's focus on why specific things are
needed so any objections can be understood and translated into code
modifications that can make a patchset that can actually be merged.  Please
leave personal censure or flaming to other conversations.  Maybe we can
pull up those past explanations and objections so they can be addressed
without having to rehash the past.  Some of those  conversations predate my
archive of the ML so may need to be restated for me to understand.

One subject that derailed a previous attempt I made at discussing
subtitles, captions and general ancillary data is explained here.  The
terminology used on here is not always precise in acknoledging the
differences between data types such as captions data, subtitle frames,
timed text, teletext, etc.  Filtering may also be desirable for non
subtitle ancillary information as referenced.

https://github.com/softworkz/SubtitleFilteringDemos/issues/5

I love the ambition of a filtering framework where subtitle types and
formats can be converted and manipulated, but let's make sure basic data
routing is also allowed by the new infrastructure.

On Tue, Jun 3, 2025 at 9:48 AM James Almer <jamrial@gmail.com> wrote:

> On 6/3/2025 1:40 PM, Nicolas George wrote:
> > James Almer (HE12025-06-03):
> >> The first sentence was unnecessary. No need to be this aggressive.
> >
> > “softworks” has been abusing many people in the last week but it is
> > Lynne that you decide to chide?
>
> I missed it if he was aggressive to someone else before. I just saw this
> email and replied accordingly.
> In any case, aggression to fight aggression goes nowhere.
>
> _______________________________________________
> 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".
>
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Dienstag, 3. Juni 2025 18:44
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Lynne (HE12025-06-04):
> > You don't get to say "oh, there were no more objections, so it was fine" or
> > "the use is evident" after the mess that your original patchsets were.
> >
> > You're still not using the native time fields, nor the packet buffers, which
> > is a very hard NAK from me.
> 
> Indeed. And not just that. The whole series had many deep logic flaws
> that made it a dead end without a complete rewrite. I explained at the
> time, and “softworkz” was almost as rude then than they are now. My
> patience if more than exhausted, I will not explain again.
> 
> Regards,
> 
> --
>   Nicolas George
> _______________________________________________



Given the preceding conversations, it is pretty safe to assume
that these comments are based on personal sentiments rather than 
technical expertise.


Reference:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-June/thread.html
(entire thread)

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

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

[Devlist Archive]

> Given the preceding conversations, it is pretty safe to assume
> that these comments are based on personal sentiments rather than
> technical expertise.

While there may be truth to that, it isn't helpful to discount objections
without a chance to substantiate them.  If the person objecting chooses to
not participate in the conversation then the objection cannot be properly
accommodated.  Any objection that can or should derail progress on a
patchset should be addressed if it has substance that will affect the
codebase.

On Tue, Jun 3, 2025 at 10:07 AM softworkz . <
softworkz-at-hotmail.com@ffmpeg.org> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas
> > George
> > Sent: Dienstag, 3. Juni 2025 18:44
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> >
> > Lynne (HE12025-06-04):
> > > You don't get to say "oh, there were no more objections, so it was
> fine" or
> > > "the use is evident" after the mess that your original patchsets were.
> > >
> > > You're still not using the native time fields, nor the packet buffers,
> which
> > > is a very hard NAK from me.
> >
> > Indeed. And not just that. The whole series had many deep logic flaws
> > that made it a dead end without a complete rewrite. I explained at the
> > time, and “softworkz” was almost as rude then than they are now. My
> > patience if more than exhausted, I will not explain again.
> >
> > Regards,
> >
> > --
> >   Nicolas George
> > _______________________________________________
>
>
>
> Given the preceding conversations, it is pretty safe to assume
> that these comments are based on personal sentiments rather than
> technical expertise.
>
>
> Reference:
>
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-June/thread.html
> (entire thread)
>
> 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".
>
_______________________________________________
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".

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

[Devlist Archive]

Which code branch does the patchset being discussed live in?

Zach

On Tue, Jun 3, 2025 at 10:15 AM Devlist Archive <devlist@rlb.org> wrote:

> > Given the preceding conversations, it is pretty safe to assume
> > that these comments are based on personal sentiments rather than
> > technical expertise.
>
> While there may be truth to that, it isn't helpful to discount objections
> without a chance to substantiate them.  If the person objecting chooses to
> not participate in the conversation then the objection cannot be properly
> accommodated.  Any objection that can or should derail progress on a
> patchset should be addressed if it has substance that will affect the
> codebase.
>
> On Tue, Jun 3, 2025 at 10:07 AM softworkz . <
> softworkz-at-hotmail.com@ffmpeg.org> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Nicolas
>> > George
>> > Sent: Dienstag, 3. Juni 2025 18:44
>> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org
>> >
>> > Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>> >
>> > Lynne (HE12025-06-04):
>> > > You don't get to say "oh, there were no more objections, so it was
>> fine" or
>> > > "the use is evident" after the mess that your original patchsets were.
>> > >
>> > > You're still not using the native time fields, nor the packet
>> buffers, which
>> > > is a very hard NAK from me.
>> >
>> > Indeed. And not just that. The whole series had many deep logic flaws
>> > that made it a dead end without a complete rewrite. I explained at the
>> > time, and “softworkz” was almost as rude then than they are now. My
>> > patience if more than exhausted, I will not explain again.
>> >
>> > Regards,
>> >
>> > --
>> >   Nicolas George
>> > _______________________________________________
>>
>>
>>
>> Given the preceding conversations, it is pretty safe to assume
>> that these comments are based on personal sentiments rather than
>> technical expertise.
>>
>>
>> Reference:
>>
>> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-June/thread.html
>> (entire thread)
>>
>> 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".
>>
>
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> Sent: Dienstag, 3. Juni 2025 18:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> You don't get to say "oh, there were no more objections, so it was fine"
> or "the use is evident" after the mess that your original patchsets were.
> 
> You're still not using the native time fields, nor the packet buffers,
> which is a very hard NAK from me.
> 


After the recent events it is understandable when actions are 
driven by personal sentiments rather than professional judgement.

I'm afraid to see this, but nothing has been reported that wasn't true,

Reference:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-May/344411.html


Regards
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Devlist
> Archive
> Sent: Dienstag, 3. Juni 2025 19:16
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> > Given the preceding conversations, it is pretty safe to assume
> > that these comments are based on personal sentiments rather than
> > technical expertise.
> 
> While there may be truth to that, it isn't helpful to discount objections
> without a chance to substantiate them

This is absolutely correct, but there was no substance. There was no reasoning,
no technical explanation given. I don't even think that you need to know 
anything about software development to recognize that.

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

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

[Nicolas George]

Devlist Archive (HE12025-06-03):
> Please can we stop keeping score and give everyone a chance to actually get
> some work done?

Softworkz has been rude and insulting to me, they have been rude and
insulting to people I respect.

Are you asking me to suck it up and help them?

> One subject that derailed a previous attempt I made at discussing
> subtitles, captions and general ancillary data is explained here.

This is the least of the flaws of this patch series.

> I love the ambition of a filtering framework where subtitle types and
> formats can be converted and manipulated, but let's make sure basic data
> routing is also allowed by the new infrastructure.

This is what I want too. And this is why you do not want softworkz to
work on this feature. This patch series leads libavfilter into a dead
end that cannot evolve for what you want.

> On Tue, Jun 3, 2025 at 9:48 AM James Almer <jamrial@gmail.com> wrote:

Please do not top-post.

-- 
  Nicolas George
_______________________________________________
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".

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

[Hendrik Leppkes]

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

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

[Zach Swena]

On Tue, Jun 3, 2025 at 10:59 AM Nicolas George <george@nsup.org> wrote:

> Softworkz has been rude and insulting to me, they have been rude and
> insulting to people I respect.
>
> Are you asking me to suck it up and help them?

The way I see it, rudeness has been present on all sides of most of the
conflicts I have seen on the ML lately and it is way too easy to reflect
rudeness back so yes I think everyone on here needs to get over it and work
together politely.

> This is what I want too. And this is why you do not want softworkz to
> work on this feature. This patch series leads libavfilter into a dead
> end that cannot evolve for what you want.

This is why I have been trying to ask high level questions.  His old
subtitle filtering patchset would need a lot of rework to bring to the
current codebase so starting over isn't a bad idea.  I don't really care
who works on or makes the commits for the code as long as the resulting
code is clean, makes sense to other developers and accomplishes what
everyone needs.  There are structural changes needed for what I want and it
would be good to find a solution that allows for functionality for
additional processing options also.


> On Tue, Jun 3, 2025 at 9:48 AM James Almer <jamrial@gmail.com> wrote:
Please do not top-post.

I was trying to figure out why you brought this up again, because I didn't
think I was, but realized that Gmail was automatically making every reply a
top post and hiding it from me...  I'll do my best to reply with the right
format.  Plase let me know if any problems persist


On Tue, Jun 3, 2025 at 11:02 AM Hendrik Leppkes <h.leppkes@gmail.com> wrote:
> 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.

How  can we start this new conversation to properly define what work needs
done before we get lost in the weeds again about specific implementations
and libraries?  I think a new public API and cli options/filtergraph
definitions should be considered for handling ancillary data routing in
general between stream types.  What is the best way to start that
conversation?  Are any of the questions proposed by  softworkz in the
beginning of this thread relevant to that conversation yet, or do we need
to establish the required changes in functionality first before discussing
data structures and variable names?

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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Hendrik
> Leppkes
> Sent: Dienstag, 3. Juni 2025 20:02
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> 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.

Hello Hendrik,

thanks a lot for your opinion.

Do you know what I think what the problem is?


Talk is cheap but work is hard!
-------------------------------

I understand very well how you (and some others) are thinking - and 
that's totally plausible and looks good on paper.
But what I can tell you for sure: It will never go to work out 
like that. It might work for some specific cases at best, but you
will never be able to achieve - not even come close to the 
versatility of my work. 


I have an offer to make to FFmpeg, which provides a very wide 
variety of WELL WORKING subtitle filtering scenarios.
It has proven to work over 3 years on hundreds of thousands
machines which are making intensive use of FFmpeg in an 
abundance of different ways, on all platforms you can think 
of and with almost all hw accelerations that FFmpeg supports.


And you want to talk up big and tell me how wrong it is?

I know very well what I'm doing and why I'm doing it that way.
And when you think about it, you should easily come to the 
conclusion that if I really wouldn't know what I'm doing,
then I had agreed long ago already to your suggestions.
But these do not work out, I'm afraid. It's as simple as that.

I also think that everybody knows that nobody else will come 
in the next 10 years and that NG won't accomplish anything 
either, as he's telling to work on this since 10 or 15 years
already and nothing has happened. It's a damn huge amount 
of work, I can tell you, and nobody else will come.


We can talk about and work out details if there's interest.
But I don't have the same amount of time as last time, 
neither enough patience.

I think it's probably best to let the TC make a final
decision right away. Those discussions aren't worth
repeating.

I say you are wrong. You say the same.
But I'm the one who has worked this through to the 
very end. You not. 

Best regards
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Dienstag, 3. Juni 2025 16:21
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up


How many people do remember that Paul actually wanted to merge my patchset?

But somebody held him up. It's documented on the ML.


This leads to an interesting question for all those who are performing their 
show about how bad the patchset would have been:


How could Paul have been so wrong?


Anyway - maybe I should submit it to librempeg instead - under GPL of course...


Best regards
softworkz
_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 507 bytes --]

Hi Zach

On Tue, Jun 03, 2025 at 11:34:17AM -0700, Zach Swena wrote:
[...]

> The way I see it, rudeness has been present on all sides of most of the
> conflicts I have seen on the ML lately and it is way too easy to reflect
> rudeness back so yes I think everyone on here needs to get over it and work
> together politely.

+1

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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

[softworkz .]

Hi,

for the sake of also having given a technical answer:


> 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

Let's go through it once again:


1. AV_SUBTITLE_FLOW_NORMAL

"close to identical" is not the same as identical. A deeper explanation
for the first case is given here: 
https://github.com/softworkz/SubtitleFilteringDemos/issues/1 

For the duration: There is quite a range of functionality built around
AVFrame's duration field. Yet, that code makes the assumption that 
once the duration has elapsed, the next frame will arrive.
This is true for Video and Audio, but not for subtitles.

In case of subtitles, the duration might be 3s (display time), but it
can happen that there doesn't follow any other subtitle frame even for an
hour or more.
The duration of an audio or video frame and the (presentation) duration  
of a subtitle have fundamentally different semantics and there is 
existing functionality that is treating the duration as audio/video 
duration - and that's why we cannot put our subtitle duration into 
that field.
The frame duration must not be set, because we don't know when the 
next frame arrives. But we set the subtitle duration because we 
know how long it should be displayed. There can come another frame,
even before the display duration of the previous has elapsed. Would 
we have set the subtitle duration as the frame duration, then it 
would have been wrong because the subsequent frame came much 
earlier than the frame duration.


2. AV_SUBTITLE_FLOW_KILLPREVIOUS

In this case, subtitle start-time and frame time are equal, but the sub-duration
is infinite (unknown). But setting the duration to infinite when it's 
unknown is subtitle semantic - but not AVFrame semantic. If we would 
set the frame duration to infinite, unexpected things can happen because
it's not meant to be set to infinity.

Also, in this flow mode, an active subtitle event becomes hidden by a 
subsequent "empty" event. Those "reset" events have a duration of 0.
Zero is once again a number with often special meaning and we should 
not put it into the frame duration field.


3. AV_SUBTITLE_FLOW_HEARTBEAT

It's not clear to me how you can conclude that 
"In 3 of your 4 cases, the two sets of fields seem to be close to 
identical with no good reason to be separate"
All 4 fields have very different values in this case.



>>>>>>>>>>> THIS IS IMPORTANT <<<<<<<<<<<


> 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.


Okay, great. We are hitting an essential point here. Just that there's
no plague - this is done by full intention, and here's why:


If we would only ever have subtitle filters handling subtitle frames
in a special subtitle filter-graph, then most of what you are suggesting
would work out indeed. In this case, it would also suffice to use
just the existing frame timing fields (well, in most cases at least).

But what kind of goal is that? I wouldn't have moved even by a millimeter
for this. The primary point which makes this so attractive and interesting
is the ability to interop between different media types, like subtitles 
and video or subtitles and audio, or splitting out closed captions 
from a video stream and many more possible features that don't exist yet.

Subtitles are different to video and audio in multiple points - a primary
one is that subtitles are sparse while audio and video are not.

When you want to enable interaction between subtitles and audio/video,
it wouldn't work out when each side would play by its own rules.
Nothing would go together in that case.
The only way how this can work properly (even more important: generically,
without needing special handling everywhere) - is to have one side 
play by the rules of the other side. Since video and audio filtering 
is long-time implemented and tested, it wouldn't make sense change 
video or audio filtering. Naturally, it needs to go the other way round:


Subtitles need to play by the rules of video and audio with regards to
filtering and all around. That's the way to achieve almost everything 
you can think of. And exactly that's what I've done.

And that's also what FFmpeg users want. Not a single one of them will
ever care about whether there are those 2 extra fields.
And if they would know what range of features those two fields are 
enabling and that there are two or three developers making a big drama
out of it whether these should be there or not, they would be throwing
tomatoes right now.

The result might not be a spotless beauty, but I've also seen so many
much more worse things, and when you consider all the things that this
little spot of imperfection enables, then it's still a very small
sacrifice.

Best regards
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".

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

[Nicolas George]

Zach Swena (HE12025-06-03):
> The way I see it, rudeness has been present on all sides of most of the
> conflicts I have seen on the ML lately and it is way too easy to reflect
> rudeness back so yes I think everyone on here needs to get over it and work
> together politely.

How do you work politely with somebody who says “I am not insulting
people calling them crazy because they are really crazy”?

> This is why I have been trying to ask high level questions.  His old
> subtitle filtering patchset would need a lot of rework to bring to the
> current codebase so starting over isn't a bad idea.  I don't really care
> who works on or makes the commits for the code as long as the resulting
> code is clean, makes sense to other developers and accomplishes what
> everyone needs.  There are structural changes needed for what I want and it
> would be good to find a solution that allows for functionality for
> additional processing options also.

His old filtering patchet was broken beyond repair, and nothing changed.

Just to give an idea of my position on the topic: during one of the
first VDDs, possibly the first one, I co-hosted with Ubitux a
multi-hours brainstorming session on the matter of subtitles in
libavfilter. That is how much I want to keep subtitles out of
libavfilter, and that is how little time I have spent on it anticipating
problems and finding solution.

When I say that softworkz's approach is broken, I know what I am
talking about.

It is broken in three ways.

The first way is the hardest: it does not handle syncing, all the
framesync code plus the complication of subtitles being sparse. It just
feeds everything to libass and takes what comes out of it. It works when
the subtitles arrive neatly before the video frames. It just does not
work for such a simple use case as shifting the subtitles a few seconds
forward.

softworkz has refused to even test that case.

But softworkz could not even test that case, because, second flaw, the
easiest to fix: he neglected to implement all the utility filters, the
filters that operate not on the frame payload but on timestamps, side
data, other technical properties. All these filters are needed for
subtitles too. softworkz patch series do not include them, and he
refuses to implement them.

It is a little harder than it looks, because implementing these filters
by copy-pasting a third copy would not be acceptable, it must be done
by factoring the existing duplicated code. But it being a little harder
is not an excuse not to work at it.

Third flaw: no negotiation. Negotiation is a core concept of
libavfilter: have a RGB stream and a YUV-only filter? lavfi inserts the
scale filter, and it inserts it at the right place. With softworkz's
implementation: have text subtitles, expect bitmap ones, it fails
instead of inserting the rasterizer at the right place.

This series only works in the simplest of test cases. It does not handle
even one of the most obvious use cases, adjusting timing. It cannot even
be called a proof of concept.

If we want to move libavfilter fowrward properly, there are preparatory
things that need to happen. Not sexy things that will let you put your
name on a “killer feature”, which seems to be all softworkz wants, not
things that will cause randos on Twitter swoon “ffmpeg is so good!”, but
things that are necessary to do things properly.

These things are some of the things I criticized about softworkz's patch
series: refactoring the negotiation code and then the utility filters.

The issue with this is that the negotiation code is extremely fragile
and has barely any test coverage at all.

Therefore, the very first thing that needs to happen on libavfilter is
to add test coverage on the negotiation system.

That is not hard work. That is not glorious work either, in fact it is
extremely boring, which is why I never completed it.

But it needs to happen.

Just for the record, I asked softworkz, I told him: for your patch
series to move forward, we need to add testing, will you help? No help
came.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Diederick C. Niehorster]

On Wed, Jun 4, 2025, 09:13 Nicolas George <george@nsup.org> wrote:

>
> These things are some of the things I criticized about softworkz's patch
> series: refactoring the negotiation code and then the utility filters.
>
> The issue with this is that the negotiation code is extremely fragile
> and has barely any test coverage at all.
>
> Therefore, the very first thing that needs to happen on libavfilter is
> to add test coverage on the negotiation system.
>
> That is not hard work. That is not glorious work either, in fact it is
> extremely boring, which is why I never completed it.
>
> But it needs to happen.
>
> Just for the record, I asked softworkz, I told him: for your patch
> series to move forward, we need to add testing, will you help? No help
> came.
>

This sounds like something that STF funding would be good for?

Cheers,
Dee

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

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

[Nicolas George]

Diederick C. Niehorster (HE12025-06-04):
> This sounds like something that STF funding would be good for?

I had that kind of idea too, which is why I sent the mail I just sent in
a new thread.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

softworkz . (HE12025-06-03):
> How many people do remember that Paul actually wanted to merge my patchset?
> 
> But somebody held him up. It's documented on the ML.

I prevented Paul from pushing quite a few half-assed patches over the
years. More often than not, after a mandatory bullheaded period he would
resubmit the patches with the changes I demanded in — a lot of them
along the lines “you copypasted that code, you need to refactor it
instead”, on occasion acknowledging that my advice made the code better.

Your mandatory bullheaded period is going on two years.

> Anyway - maybe I should submit it to librempeg instead - under GPL of course...

Yes, do that please.

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

softworkz . (HE12025-06-03):
> Talk is cheap but work is hard!

Which is why after authoring a patch series that can only handle toy use
cases you are more ready to talk it into the project than work at making
it acceptable.

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

Hendrik Leppkes (HE12025-06-03):
> In fact, this is the main problem that plagued this patchset from the
> start.

Not the main one, only the one that people who are not familiar with the
current state of libavfilter will notice immediately.

But still, I agree that softworkz's attitude on this is just as bad as
on the rest and hints at an inability to work in a team project where he
has to work at things.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Rémi Denis-Courmont]

Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan kesäaika softworkz . a 
écrit :
> Given the preceding conversations, it is pretty safe to assume
> that these comments are based on personal sentiments rather than 
> technical expertise.

I won't deny the fact that several people have raised non-technical objections 
against you and your work... but you have been dismissive of actual technical 
objections. And to start with, you set a pretty bad mood in one of your first 
email this year, with your choice of words against the community.

Also a few days ago, you literally challenged everybody on this list to 
provide technical arguments against your patches, all the while preemptively 
dismissing any such argument... and then you feigned surprise that there were 
not a lot of answers.

I cannot condone ad-hominem attacks but you can't expect volunteer reviewers 
to keep their cool and (re)state their technical objections in-depth in such 
circumstances.

-- 
德尼-库尔蒙‧雷米
Tapio's place new town, former Finnish Republic of Uusimaa



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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Rémi Denis-
> Courmont
> Sent: Mittwoch, 4. Juni 2025 17:49
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan kesäaika softworkz . a
> écrit :
> > Given the preceding conversations, it is pretty safe to assume
> > that these comments are based on personal sentiments rather than
> > technical expertise.
> 
> I won't deny the fact that several people have raised non-technical objections
> against you and your work... but you have been dismissive of actual technical
> objections. And to start with, you set a pretty bad mood in one of your first
> email this year, with your choice of words against the community.
> 
> Also a few days ago, you literally challenged everybody on this list to
> provide technical arguments against your patches, all the while preemptively
> dismissing any such argument... and then you feigned surprise that there were
> not a lot of answers.
> 
> I cannot condone ad-hominem attacks but you can't expect volunteer reviewers
> to keep their cool and (re)state their technical objections in-depth in such
> circumstances.

Hello Remy,

whom did I attack other than NG?

And then I didn't see much technical responses either. Also, given that
I haven't even posted a patchset, but merely a question about field
additions to AVFrame.


Thanks
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 09:14
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Zach Swena (HE12025-06-03):
> > The way I see it, rudeness has been present on all sides of most of the
> > conflicts I have seen on the ML lately and it is way too easy to reflect
> > rudeness back so yes I think everyone on here needs to get over it and work
> > together politely.
> 
> How do you work politely with somebody who says “I am not insulting
> people calling them crazy because they are really crazy”?
> 
> > This is why I have been trying to ask high level questions.  His old
> > subtitle filtering patchset would need a lot of rework to bring to the
> > current codebase so starting over isn't a bad idea.  I don't really care
> > who works on or makes the commits for the code as long as the resulting
> > code is clean, makes sense to other developers and accomplishes what
> > everyone needs.  There are structural changes needed for what I want and it
> > would be good to find a solution that allows for functionality for
> > additional processing options also.
> 
> His old filtering patchet was broken beyond repair, and nothing changed.
> 
> Just to give an idea of my position on the topic: during one of the
> first VDDs, possibly the first one, I co-hosted with Ubitux a
> multi-hours brainstorming session on the matter of subtitles in
> libavfilter. That is how much I want to keep subtitles out of
> libavfilter, and that is how little time I have spent on it anticipating
> problems and finding solution.
> 
> When I say that softworkz's approach is broken, I know what I am
> talking about.
> 
> It is broken in three ways.
> 
> The first way is the hardest: it does not handle syncing, all the
> framesync code plus the complication of subtitles being sparse. It just
> feeds everything to libass and takes what comes out of it. It works when
> the subtitles arrive neatly before the video frames. It just does not
> work for such a simple use case as shifting the subtitles a few seconds
> forward.
> 
> softworkz has refused to even test that case.

I'd like to kind as you to provide such a case which my patchset 
doesn't handle. To make it easy, I could provide you a compiled 
binary for your convenience.


> But softworkz could not even test that case, because, second flaw, the
> easiest to fix: he neglected to implement all the utility filters, the
> filters that operate not on the frame payload but on timestamps, side
> data, other technical properties. All these filters are needed for
> subtitles too. softworkz patch series do not include them, and he
> refuses to implement them.

Which filters are you talking about specifically?

 
> It is a little harder than it looks, because implementing these filters
> by copy-pasting a third copy would not be acceptable, it must be done
> by factoring the existing duplicated code. But it being a little harder
> is not an excuse not to work at it.

I have no avoidance attitude towards hard work. Please let
me know which filters are you talking about.


> Third flaw: no negotiation. Negotiation is a core concept of
> libavfilter: have a RGB stream and a YUV-only filter? lavfi inserts the
> scale filter, and it inserts it at the right place. With softworkz's
> implementation: have text subtitles, expect bitmap ones, it fails
> instead of inserting the rasterizer at the right place.

Negotiation is supported and it is something different from auto-
insertion. For example, auto-insertion is happening to replicate 
the sub2video mechanism. Those command lines work just like before.

At one point I had said that I think it might be better when people
insert text2graphicsub filter manually, but auto-insertion is easily
doable, and I can add that with ease.



> This series only works in the simplest of test cases. It does not handle
> even one of the most obvious use cases, adjusting timing. It cannot even
> be called a proof of concept.

It has proven to work for a wide range of cases. Please provide a specific
example that should work but doesn't, then we can talk about it.


> The issue with this is that the negotiation code is extremely fragile
> and has barely any test coverage at all.

I had asked you many times about providing specific examples, but you 
never did. 

Please do that and we can talk about it.


Thanks
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".

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

[Nicolas George]

softworkz . (HE12025-06-04):
> whom did I attack other than NG?

A lot of people:

# Also, I cannot consider people as trustworthy while they are going crazy.

https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/344274.html

And this is just the one I remembered accurately enough to find it in a
few moments; there were other similar instances.

Anyway, the fact that I am the one who know libavfilter best and
therefore noticed the flaws in your old patch series is not an excuse
for you to attack me.

-- 
  Nicolas George
_______________________________________________
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".

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

[Nicolas George]

softworkz . (HE12025-06-04):
> I'd like to kind as you

This ask of me being kind to you after you shamelessly admitted to
attacking me is so outrageous that it can count as an extra insult all
by itself.

If you genuinely want to make your patch better, you can do the work
yourself with what I posted this time and more importantly with what I
posted three years ago and you refused to consider.

Of course, if all you wanted to do was drown my objections in your
verbal diarrhea and have inattentive people think you replied
relevantly, it will not work for you.

-- 
  Nicolas George
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:26
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > whom did I attack other than NG?
> 
> A lot of people:
> 
> # Also, I cannot consider people as trustworthy while they are going crazy.
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2025-May/344274.html
> 
> And this is just the one I remembered accurately enough to find it in a
> few moments; there were other similar instances.
> 
> Anyway, the fact that I am the one who know libavfilter best and
> therefore noticed the flaws in your old patch series is not an excuse
> for you to attack me.
> 
> --
>   Nicolas George
> _______________________________________________

I'm afraid to see that you are having language issues again.

"Going crazy" is something very different from calling somebody to
be crazy.

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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:30
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > I'd like to kind as you
> 
> This ask of me being kind to you after you shamelessly admitted to
> attacking me is so outrageous that it can count as an extra insult all
> by itself.

Again, a language issue. This is not asking you to be kind, it means
that I am kind in asking you for it.


> If you genuinely want to make your patch better, you can do the work
> yourself with what I posted this time and more importantly with what I
> posted three years ago and you refused to consider.
> 
> Of course, if all you wanted to do was drown my objections in your
> verbal diarrhea and have inattentive people think you replied
> relevantly, it will not work for you.

Again, please provide specific examples which do not work, to prove
your claims.

Thank you
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".

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

[Nicolas George]

softworkz . (HE12025-06-04):
> Again, please provide specific examples which do not work, to prove
> your claims.

I did. You are again trying to deflect.

-- 
  Nicolas George
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:35
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > Again, please provide specific examples which do not work, to prove
> > your claims.
> 
> I did. You are again trying to deflect.
> 
> --
>   Nicolas George
> _______________________________________________


No you didn't. You are claiming that certain things don't work.

Please provide specific examples which demonstrate your claim.
And I don't mean in words but in command lines and sample files.

Also please answer which utility filters I would have "refused to implement".


Thanks
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".

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

[Nicolas George]

softworkz . (HE12025-06-04):
> Please provide specific examples which demonstrate your claim.

If you are not able to derive them from what I posted these last few
days, then you do not have what it takes to write anything non trivial
for FFmpeg anyway.

But even if you are no able, I did post more details last time. Make the
effort for search for it or do not, it is all the same to me.

> And I don't mean in words but in command lines and sample files.

You do not get to make demands. It is your crappy patch that you want to
get in.

Oh, what happened to submitting to librempeg instead?

-- 
  Nicolas George
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:45
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > Please provide specific examples which demonstrate your claim.
> 
> If you are not able to derive them from what I posted these last few
> days, then you do not have what it takes to write anything non trivial
> for FFmpeg anyway.
> 
> But even if you are no able, I did post more details last time. Make the
> effort for search for it or do not, it is all the same to me.
> 
> > And I don't mean in words but in command lines and sample files.
> 
> You do not get to make demands. It is your crappy patch that you want to
> get in.

Those kinds of texts don't get us anywhere.


Please provide specific example which demonstrate your claims.

If you aren't able to do that, then I cannot consider any of those to
be valid.

Also please answer which utility filters I would have "refused to implement".

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

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

[Nicolas George]

softworkz . (HE12025-06-04):
> Those kinds of texts don't get us anywhere.

I confirm. If you want to get somewhere, get to work.

> Please provide specific example which demonstrate your claims.

Do the work yourself.

-- 
  Nicolas George
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 19:57
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > Those kinds of texts don't get us anywhere.
> 
> I confirm. If you want to get somewhere, get to work.
> 
> > Please provide specific example which demonstrate your claims.
> 
> Do the work yourself.


If you want to make any claims it is up to you to provide a specific
example scenario which doesn't work.
So far, you have just written some text that sound like there would
be any substance, but this alone is not sufficient to make an objection
It is up to you to provide specific examples for those claims and if 
you are unable to do so, there is no other conclusion than that
your claims are not valid.

Also, I have been asking 3 times about your claim that I would have 
refused to implement important utility filters and you weren't able 
to name those filters.

This should make it very clear to everybody that this claims isn't
worth a penny.

I'm not saying that there aren't any scenarios which it cannot handle,
but it all has to start by naming them, understanding them, and 
evaluating their importance.
This is also relevant for any other readers who follow this discussion.
It must be clear and understandable for everybody what is working and
what might not be working and how relevant those cases are which are 
not working and how easily or not they can be made working.

You are the objector. 

You are making claims. 

Provide specific examples to illustrate your claims.


Otherwise, your claims can only be considered invalid.


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

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

[Nicolas George]

softworkz . (HE12025-06-04):
> You are the objector. 

You are the one proposing these changes. Proving them valid is your
responsibility.

-- 
  Nicolas George
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Mittwoch, 4. Juni 2025 20:13
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> softworkz . (HE12025-06-04):
> > You are the objector.
> 
> You are the one proposing these changes. Proving them valid is your
> responsibility.

LOL - absolutely not!

When you want to make any objections, it is up It is on you to make them
clear and specific. Otherwise an objection cannot be considered valid.



And for the 4th time: which filters?

It seems that this objection of yours is clearly invalidated already.

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

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

[softworkz .]

Objections Summary
==================


Here's a summary of objections made so far:


Lynne
-----

- Not using picture buffers for subtitle data
  It's not impossible, just doesn't make much sense
  I said there wasn't anybody against it anymore in 2022.
  We can dig up previous conversations, or we can just let
  the TC decide about it


Lynne & Hendrik
---------------

- Claimed that AVFrame's timing fields would be sufficient
  They can take my $1000 challenge to prove it


Nicolas George
--------------

Just a lot of text, but refuses to get specific, even after
multiple requests.

Valid objections: Zero


That's pretty scarce, given the count of messages.

Best regards
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Rémi Denis-
> Courmont
> Sent: Mittwoch, 4. Juni 2025 17:49
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Le tiistaina 3. kesäkuuta 2025, 20.07.18 Itä-Euroopan kesäaika softworkz . a
> écrit :
> > Given the preceding conversations, it is pretty safe to assume
> > that these comments are based on personal sentiments rather than
> > technical expertise.
> 
> I won't deny the fact that several people have raised non-technical objections
> against you and your work... but you have been dismissive of actual technical
> objections. 

My first response to Hendrik was admittedly a bit overdriven, but I have 
followed-up with a detailed technical response shortly after.

As of now, I think I have addressed all specific objections that were made.
If you think that I would have missed any, please point at them.


> And to start with, you set a pretty bad mood in one of your first
> email this year, with your choice of words against the community.

Would you be able to let me know which one you are referring to? If there was 
one that you still have in memory, then it must be something severe and
I would like to clear it up in (the likely) case it was unintended by
myself.


> Also a few days ago, you literally challenged everybody on this list to
> provide technical arguments against your patches, all the while preemptively
> dismissing any such argument... 

It wasn't preemptively dismissing any arguments, but when I claim that almost
nobody has actually looked at the patchset, then it's just natural that 
there's no point to answer for anybody where this is true.


> I cannot condone ad-hominem attacks 

I'm not aware that I've attacked anybody else than NG, but in case I did,
I am truly sorry about it. I don't want to attack anybody other than NG.

Thanks
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1810 bytes --]

Hi Nicolas

On Wed, Jun 04, 2025 at 09:13:44AM +0200, Nicolas George wrote:
> Zach Swena (HE12025-06-03):
[...]
>
> > This is why I have been trying to ask high level questions.  His old
> > subtitle filtering patchset would need a lot of rework to bring to the
> > current codebase so starting over isn't a bad idea.  I don't really care
> > who works on or makes the commits for the code as long as the resulting
> > code is clean, makes sense to other developers and accomplishes what
> > everyone needs.  There are structural changes needed for what I want and it
> > would be good to find a solution that allows for functionality for
> > additional processing options also.
> 
> His old filtering patchet was broken beyond repair, and nothing changed.
> 
> Just to give an idea of my position on the topic: during one of the
> first VDDs, possibly the first one, I co-hosted with Ubitux a
> multi-hours brainstorming session on the matter of subtitles in
> libavfilter. That is how much I want to keep subtitles out of
> libavfilter, and that is how little time I have spent on it anticipating
> problems and finding solution.
> 
> When I say that softworkz's approach is broken, I know what I am
> talking about.
> 
> It is broken in three ways.

Is it possible to create 3 testcases that one can just copy and paste to the
command line to see these 3 problems ?

If its possible, it would clearly show the problems and avoid a never
ending disagreement

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Mittwoch, 4. Juni 2025 22:42
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Hi Nicolas
> 
> On Wed, Jun 04, 2025 at 09:13:44AM +0200, Nicolas George wrote:
> > Zach Swena (HE12025-06-03):
> [...]
> >
> > > This is why I have been trying to ask high level questions.  His old
> > > subtitle filtering patchset would need a lot of rework to bring to the
> > > current codebase so starting over isn't a bad idea.  I don't really care
> > > who works on or makes the commits for the code as long as the resulting
> > > code is clean, makes sense to other developers and accomplishes what
> > > everyone needs.  There are structural changes needed for what I want and
> it
> > > would be good to find a solution that allows for functionality for
> > > additional processing options also.
> >
> > His old filtering patchet was broken beyond repair, and nothing changed.
> >
> > Just to give an idea of my position on the topic: during one of the
> > first VDDs, possibly the first one, I co-hosted with Ubitux a
> > multi-hours brainstorming session on the matter of subtitles in
> > libavfilter. That is how much I want to keep subtitles out of
> > libavfilter, and that is how little time I have spent on it anticipating
> > problems and finding solution.
> >
> > When I say that softworkz's approach is broken, I know what I am
> > talking about.
> >
> > It is broken in three ways.
> 
> Is it possible to create 3 testcases that one can just copy and paste to the
> command line to see these 3 problems ?
> 
> If its possible, it would clearly show the problems and avoid a never
> ending disagreement
> 
> thx
> 
> [...]
> 
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB


Hi Michael,


He won't do that because he can't. At best, he will come up with a 
non-implemented feature.

All the crucial utility filters are implemented already:

sbuffersink, sbuffersrc, strim, snull

(here's no ssetpts yet, but that's just a missing feature and not crucial)



Also, this behavior is a pattern he has repeatedly used in the past 
already: He talked about "flaws" all the time and never got really 
specific when asked for it.

He played in the same way as today: like "when you don't know which
flaws I mentioned, then you are not suitable to do the task" etc.

Most ridiculously, after I had nailed it down to a point where it
was clear that he couldn't name any, he changed his statement to say
he "could find flaws if he would do a full review"

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-July/299284.html


And here he had invented a reason against my sf patchset in 2022:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298407.html

He would have something important to submit and because of that,
my patchset cannot be merged.

He has never submitted this, what he had presented as a blocking 
reason.


The truth is that what he does here is just about producing a 
lot of steam, making it _sound_ like something profound while 
it is just hot air without substance.

In the past, I made the mistake that I tried to respond at a 
technical level, but at the end, nobody was able to understand
who is right and who is wrong.

Talking about specific cases and examples is the way to quickly
reveal for every other reader that there's no substance behind
his claims.

Thanks
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Mittwoch, 4. Juni 2025 20:35
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Objections Summary
> ==================
> 
> 
> Here's a summary of objections made so far:
> 
> 
> Lynne
> -----
> 
> - Not using picture buffers for subtitle data
>   It's not impossible, just doesn't make much sense
>   I said there wasn't anybody against it anymore in 2022.
>   We can dig up previous conversations, or we can just let
>   the TC decide about it


Here's the thread and specifically the message about the reasonings in 
this regard:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300740.html



> Lynne & Hendrik
> ---------------
> 
> - Claimed that AVFrame's timing fields would be sufficient
>   They can take my $1000 challenge to prove it

Here, Hendrik had asked for an explanation for the extra time fields:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-October/303282.html

My reply:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-October/303285.html

And I had asked later whether it's clarified for him:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-October/303371.html

==> No response

------------


In this conversation, I had stated that no unaddressed objections were 
remaining:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300593.html

I had also said (about the timing fields):

> I had explained the reasons and in conversation on IRC, Lynne was
> no longer insisting on this AFAIR.

I still have the log of those conversations. It's just a lot of text
to go through.
But if Lynne wants to insist that it was any different, then I can
post the full IRC log somewhere.


-----------------------------------

Anton said he would review it:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300729.html

I posted the explanation he was asking for in a reply.

He never responded. 
I sent 4 or 5 reminders over the subsequent weeks and he didn't respond.

-------------

There were more messages where it was talked about whether any objections
would be remaining and there weren't any responses.

That's the evidence for why I said there were no more objections.


Best regards
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".

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

[Nicolas George]

Michael Niedermayer (HE12025-06-04):
> Is it possible to create 3 testcases that one can just copy and paste to the
> command line to see these 3 problems ?

Absolutely. I made sure to give all the necessary information all in one
place. Turning my words into command lines is a very easy task.

Now, if you expect me to do it, think again.

I will not spend efforts into helping somebody who repeatedly insulted
me and others doing something suicidal only an idiot would do.

> If its possible, it would clearly show the problems and avoid a never
> ending disagreement

The never ending disagreement is there because softworkz wants that
there is a never ending disagreement, the alternative being either
abandoning this broken patch series or having to work at things that are
obviously still beyond his skills.

If softworkz had any pride as a developer and any trust in his own code,
he would have made a point of checking these issues days ago.

The fact that he prefers spending hours writing verbal diarrhea to this
mailing-list over spending minutes testing what I pointed him to test
tells you all you need to know about his attitude.

Regards,

-- 
  Nicolas George
_______________________________________________
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".

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

[Devin Heitmueller]

On Fri, Jun 6, 2025 at 10:32 AM Nicolas George <george@nsup.org> wrote:
> The fact that he prefers spending hours writing verbal diarrhea to this
> mailing-list over spending minutes testing what I pointed him to test
> tells you all you need to know about his attitude.

Respectfully, you just spent six paragraphs lamenting how bad
softworks patches are, when you could have proven your point with a
single command line (which would have demonstrated your concerns
definitively).

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
_______________________________________________
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".

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Freitag, 6. Juni 2025 16:33
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> Michael Niedermayer (HE12025-06-04):
> > Is it possible to create 3 testcases that one can just copy and
> paste to the
> > command line to see these 3 problems ?
> 
> Absolutely. I made sure to give all the necessary information all in
> one
> place. Turning my words into command lines is a very easy task.
> 
> Now, if you expect me to do it, think again.
> 
> I will not spend efforts into helping somebody who repeatedly
> insulted
> me and others doing something suicidal only an idiot would do.
> 
> > If its possible, it would clearly show the problems and avoid a
> never
> > ending disagreement
> 
> The never ending disagreement is there because softworkz wants that
> there is a never ending disagreement, the alternative being either
> abandoning this broken patch series or having to work at things that
> are
> obviously still beyond his skills.
> 
> If softworkz had any pride as a developer and any trust in his own
> code,
> he would have made a point of checking these issues days ago.
> 
> The fact that he prefers spending hours writing verbal diarrhea to
> this
> mailing-list over spending minutes testing what I pointed him to test
> tells you all you need to know about his attitude.
> 
> Regards,
> 
> --
>   Nicolas George
> _______________________________________________


Oh, that's a great message, I don't even need to write a response,
because you are just discrediting yourself with those kinds of 
messages. 

softworkz








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

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

[softworkz .]

It's MythBusters Day!
=====================


Today: Busting the Lies of Nicolas George



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> 
> [...]
> 
> When I say that softworkz's approach is broken, I know what I am
> talking about.

Oh wow, that sounds impressive - but does he really..?

Let's see how much of his infamous, often claimed, never detailed
and never ever proven myths will hold up true after a fact-check.


> It is broken in three ways.
> The first way is the hardest: it does not handle syncing, 

It does handle syncing perfectly via framesync wherever it's
required. (example right below)


> It just
> feeds everything to libass and takes what comes out of it.


Wrong. Two examples:


video > [sub_cc] > textsubs > [overlaytextsubs] > video

video > [graphicsub_ocr] > textsubs > [overlaytextsubs] > video


What's specific to those examples is that in both cases, (closed
captions and OCR for bitmap subs), the text events DO NOT
come all at once, but continuously, which is the nature of 
those cases and contradicts the false claim that NG tried
to place.


==> "broken in three ways #1" => Busted


> softworkz has refused to even test that case.

Really? 

I have not only tested that case - I have tested dozens of cases,
and not just that. I even have a cross-platform automated test
system which is testing dozens of different filtergraphs for 
subtitle filtering, including hardware accelerated filtering.

The two videos here are showing 66 (!!) different filtergraph setups
which are all working successfully:

https://github.com/softworkz/SubtitleFilteringDemos/tree/master/TestRun1


==> "broken in three ways #1.1" => Busted




> easiest to fix: he neglected to implement all the utility filters,
> the
> filters that operate not on the frame payload but on timestamps, side
> data, other technical properties. All these filters are needed for
> subtitles too. softworkz patch series do not include them, and he
> refuses to implement them.

After asking him 5 times to name the filters he is referring to,
he wasn't able to do so.
And nobody can say that stating the names of the filters would be 
asked too much.


==> "broken in three ways #2" => Busted



> Third flaw: no negotiation. Negotiation is a core concept of
> libavfilter: have a RGB stream and a YUV-only filter? lavfi inserts
> the
> scale filter, and it inserts it at the right place. With softworkz's
> implementation: have text subtitles, expect bitmap ones, it fails
> instead of inserting the rasterizer at the right place.

Negotiation is properly implemented.
Not auto-inserting a text-to-bitmap subs filter is intentional,
but very easy to change - in the same way as filters are already
auto-inserted to replicate the sub2video hack from somebody, which 
is an old half-broken feature in FFmpeg.

There's proof already that auto-insertion is working,
just not for that case where it is intentionally not done.


==> "broken in three ways #3" => Busted




> This series only works in the simplest of test cases. 

That's a good laugh after viewing evidence showing 66 different 
working cases, which is still just a fraction. 

Everybody can run these tests oneself, I can give instructions,
takes about 30 minutes to set up, works on Windows, Linux and 
most of its derivates, Android and Mac.


==> "broken in three ways #3.5" => Bonus-Bust



Best regards,
softworkz

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

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

[Kieran Kunhya via ffmpeg-devel]

On Sat, Jun 7, 2025 at 5:20 PM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
>
>
> It's MythBusters Day!
> =====================
>
>
> Today: Busting the Lies of Nicolas George

Can you stop spamming this list with your rants and get a blog or something?

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

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

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Kieran Kunhya via ffmpeg-devel
> Sent: Samstag, 7. Juni 2025 19:25
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Cc: Kieran Kunhya <kieran618@googlemail.com>
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
> 
> On Sat, Jun 7, 2025 at 5:20 PM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> >
> >
> > It's MythBusters Day!
> > =====================
> >
> >
> > Today: Busting the Lies of Nicolas George
> 
> Can you stop spamming this list with your rants and get a blog or
> something?
> 
> Kieran
> _______________________________________________


It might be a fancy presentation, but it is a profound, concise 
and correct response to the false claims that have been made.

I truly wish that there wouldn't be such messages to respond to.
You can trace all those conversations back to the origin, to see
that I'm not the one starting them.

Admittedly, I had sent too many messages last week, for which 
I'm sorry about, but would you have left that message unresponded?

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-June/344600.html
 

Best regards
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".

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

[Nicolas George]

Devin Heitmueller (HE12025-06-06):
> Respectfully, you just spent six paragraphs lamenting how bad
> softworks patches are, when you could have proven your point with a
> single command line (which would have demonstrated your concerns
> definitively).

I do not need to prove my knowledge of libavfilter.

Patch reviewer asking patch submitter to run some more tests or a
benchmark is a completely standard part of the review process; the patch
reviewer is not expected to do the work, although they can help if the
patch submitter asks nicely. We are in this mess only because softworkz
refuses to comply to this perfectly normal request.

-- 
  Nicolas George
_______________________________________________
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".