[FFmpeg-devel] STF RaptorQ

[FFmpeg-devel] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

Hello,

I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.

It's adding an obscure FEC protocol to FFmpeg, which is not going to be
implemented well without an event loop anyway.

I do not think it's a suitable STF project.

Regards,
Kieran Kunhya
_______________________________________________
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] STF RaptorQ

[Devin Heitmueller]

On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
> I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> maintenance of FFmpeg.
>
> It's adding an obscure FEC protocol to FFmpeg, which is not going to be
> implemented well without an event loop anyway.
>
> I do not think it's a suitable STF project.

I see the task on the TRAC page for STF 2025, and while intellectually
interesting to a nerd like me who does lots of work with reliable
protocols, I'm not confident this particular protocol makes much sense
to work on, especially for 24,000 EUR.

I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
so it's not clear what the use cases are if the goal is
interoperability.  If somebody really wants to be paid to work on
reliable transport protocols, the time would be better spent improving
the RIST or SRT integration, which is where most of the industry is
putting their energy.

I agree with Kieran that this seems to largely be outside the STF
objectives (i.e. sustainability for open source projects).

Devin

(1) https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2025

-- 
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] STF RaptorQ

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1223 bytes --]

On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> Hello,
> 
> I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> maintenance of FFmpeg.

It isn't -- it's research.
> It's adding an obscure FEC protocol to FFmpeg, which is not going to be
> implemented well without an event loop anyway.

You're mixing up FEC implementation details that don't matter for a library.
It works much like a decoder - you put N blocks of Y bytes data in, and 
you get X blocks of Z byes out.
> I do not think it's a suitable STF project.
STF is not maintenance-only from what I understand, but also for 
innovation, in this case, research.

I have no strong opinions on including this into STF. It's just work I'm 
interested in doing, which is currently obscure, but that's because it's 
still young and recently standardized. It will likely be used in future 
multimedia work, or so I'd like to think.

I'd like to ask for you to judge this without prejudice, however. When 
we spoke on IRC, you had (and still have, in the case of the event loop 
point), inaccurate understanding of the algorithm, and resorted to 
asking very technical questions about a recent algorithm to AI chatbots.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] STF RaptorQ

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1626 bytes --]

On 23/05/2025 08:55, Devin Heitmueller wrote:
> On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> <ffmpeg-devel@ffmpeg.org> wrote:
>> I wanted to put on the record that adding RaptorQ to FFmpeg isn't
>> maintenance of FFmpeg.
>>
>> It's adding an obscure FEC protocol to FFmpeg, which is not going to be
>> implemented well without an event loop anyway.
>>
>> I do not think it's a suitable STF project.
> 
> I see the task on the TRAC page for STF 2025, and while intellectually
> interesting to a nerd like me who does lots of work with reliable
> protocols, I'm not confident this particular protocol makes much sense
> to work on, especially for 24,000 EUR.

It's not a protocol.

> I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> so it's not clear what the use cases are if the goal is
> interoperability.  If somebody really wants to be paid to work on
> reliable transport protocols, the time would be better spent improving
> the RIST or SRT integration, which is where most of the industry is
> putting their energy.

Again, it's not a protocol. It's an FEC algorithm. No current mainstream 
protocol specifies using it. It will take decades, at least, and it 
definitely cannot fit into existing protocols.

Custom closed-source video transmission protocols are using it.
But, I do believe it's the future for open-source protocols too.
> I agree with Kieran that this seems to largely be outside the STF
> objectives (i.e. sustainability for open source projects).Like I mentioned, I believe the STF is not maintenance-only, or so I gather.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 04:44 Lynne, <dev@lynne.ee> wrote:

> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
> > It's adding an obscure FEC protocol to FFmpeg, which is not going to be
> > implemented well without an event loop anyway.
>
> You're mixing up FEC implementation details that don't matter for a
> library.
> It works much like a decoder - you put N blocks of Y bytes data in, and
> you get X blocks of Z byes out.
> > I do not think it's a suitable STF project.
> STF is not maintenance-only from what I understand, but also for
> innovation, in this case, research.
>

I point you to the previous thread on FEC where I explained that's a flawed
design as it causes bursting in a practical protocol.

You've basically answered the question that your implementation will be
theoretical and not usable in a real protocol.

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 04:44 Lynne, <dev@lynne.ee> wrote:

> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
>

STF isn't for "fun things I want to work on"

I appreciate the way the 2024 organisers ran STF was not exactly stellar
but that doesn't mean you can just jump on the bandwagon in 2025.

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] STF RaptorQ

[Michael Niedermayer]

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

Hi

On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> <ffmpeg-devel@ffmpeg.org> wrote:
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.

i agree adding RaptorQ itself is probably not maintenance


> >
> > It's adding an obscure FEC protocol to FFmpeg,

tornado and raptor codes are not obscure.
and FFmpeg supports hundreads of much more obscure things


[...]

> I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> so it's not clear what the use cases are if the goal is
> interoperability.

its IMHO for communication between tools that on both sides
use our software

If no commercial gear uses a reliable FEC system all teh better
for us


> If somebody really wants to be paid to work on
> reliable transport protocols, the time would be better spent improving
> the RIST or SRT integration, which is where most of the industry is
> putting their energy.

FEC is supperior to ARQ
for ARQ, each receiver needs to request the lost packet
while for FEC the sender just needs to know or guess how many packets
where lost.
1. FEC is lower latency
2. FEC does not suffer from "oops the retrasmit was lost too"
3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0
   with ARQ you need to send 3 individual packets with FEC you CAN broadcast
   the same 1 packet to all 3 receivers to recover them.

Also FEC is VERY widely used, just not where you are looking.
from compact disks, to phone networks to inter planetary communication
since over 50 years its the standard, voyager in 1970 used FEC already.


> 
> I agree with Kieran that this seems to largely be outside the STF
> objectives (i.e. sustainability for open source projects).

A new implementation of RIST, SRT, Raptor and so on may fall outside
but redesigning the protocol layer in FFmpeg would perfectly fit inside
"sustainability for open source projects"
When you want A and B and both are connected, you ask for the funding
to be for the side that fits inside the guidelines
So this STF project could be changed to center on maintaince of the
protocol layer instead of a RaptorQ/SRT/RIST implementation i think.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- 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] STF RaptorQ

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1452 bytes --]

On 23/05/2025 15:50, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, 23 May 2025, 04:44 Lynne, <dev@lynne.ee> wrote:
> 
>> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
>>> Hello,
>>>
>>> I wanted to put on the record that adding RaptorQ to FFmpeg isn't
>>> maintenance of FFmpeg.
>>
>> It isn't -- it's research.
>>> It's adding an obscure FEC protocol to FFmpeg, which is not going to be
>>> implemented well without an event loop anyway.
>>
>> You're mixing up FEC implementation details that don't matter for a
>> library.
>> It works much like a decoder - you put N blocks of Y bytes data in, and
>> you get X blocks of Z byes out.
>>> I do not think it's a suitable STF project.
>> STF is not maintenance-only from what I understand, but also for
>> innovation, in this case, research.
>>
> 
> I point you to the previous thread on FEC where I explained that's a flawed
> design as it causes bursting in a practical protocol.
> 
> You've basically answered the question that your implementation will be
> theoretical and not usable in a real protocol.

Pretty much all implementations share the same underlying API, to the 
point where the protocol almost specifies how a public API would look like.
It isn't a flawed design either, it works differently, so you simply use 
it differently.

I've removed the proposal from the list.
You should consider reading the spec, along with the Raptor spec.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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] STF RaptorQ

[Michael Niedermayer]

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

On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote:
> Hi
[...]
> > I agree with Kieran that this seems to largely be outside the STF
> > objectives (i.e. sustainability for open source projects).
> 
> A new implementation of RIST, SRT, Raptor and so on may fall outside
> but redesigning the protocol layer in FFmpeg would perfectly fit inside
> "sustainability for open source projects"
> When you want A and B and both are connected, you ask for the funding
> to be for the side that fits inside the guidelines
> So this STF project could be changed to center on maintaince of the
> protocol layer instead of a RaptorQ/SRT/RIST implementation i think.

Theres also the human element, where people are not machienes that can
be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring

Some people enjoy working on "cool" things, dont tell them to work on
boring things please. Its bad for them, and likely bad for the results.

If you find RIST/SRT important, you should work on it, or fund someone
to do it or to submit a project idea to STF/GsoC/... and work on it
with their funding ...

Also IMO if you have someone who wants to do a project that moves FFmpeg
forward, be supportive of the effort and try to find a way to make it happen
be that inside or outside STF.
Arguing against efforts to move to teh cutting edge of technology
will do only one thing and thats havig competitors take the space
and FFmpeg fall behind

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data

[-- 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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 10:58 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote:
> > Hi
> [...]
> > > I agree with Kieran that this seems to largely be outside the STF
> > > objectives (i.e. sustainability for open source projects).
> >
> > A new implementation of RIST, SRT, Raptor and so on may fall outside
> > but redesigning the protocol layer in FFmpeg would perfectly fit inside
> > "sustainability for open source projects"
> > When you want A and B and both are connected, you ask for the funding
> > to be for the side that fits inside the guidelines
> > So this STF project could be changed to center on maintaince of the
> > protocol layer instead of a RaptorQ/SRT/RIST implementation i think.
>
> Theres also the human element, where people are not machienes that can
> be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring
>
> Some people enjoy working on "cool" things, dont tell them to work on
> boring things please. Its bad for them, and likely bad for the results.
>

They can work on cool things outside of STF.

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 10:45 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi
>
> On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > <ffmpeg-devel@ffmpeg.org> wrote:
> > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > maintenance of FFmpeg.
>
> i agree adding RaptorQ itself is probably not maintenance
>
>
> > >
> > > It's adding an obscure FEC protocol to FFmpeg,
>
> tornado and raptor codes are not obscure.
> and FFmpeg supports hundreads of much more obscure things
>
>
> [...]
>
> > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > so it's not clear what the use cases are if the goal is
> > interoperability.
>
> its IMHO for communication between tools that on both sides
> use our software
>
> If no commercial gear uses a reliable FEC system all teh better
> for us
>

But Lynne is insisting it's not a protocol. The work would just be the low
level RaptorQ algorithm.

UDP based retransmit/FEC protocols are essentially impossible to develop
well without an event loop / timers.

You can look at libsrt and librist of examples of how trying to reinvent an
event loop in threads and creating lots of bugs in the process as each lib
struggles to synchronise a complex state machine between threads.

Adding event loop support to FFmpeg would be a great STF project.

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] STF RaptorQ

[Michael Niedermayer]

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

Hi Kieran

On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> I appreciate the way the 2024 organisers ran STF was not exactly stellar

It seems every mail you post is an attack on FFmpeg or the FFmpeg Team
And its alot of different people you target. And often people who
have done good and valuable work

Seriously, I could easily talk negatively about you in every mail i
write too but i dont, i try to be polite and positive.

As an example i could have instead replied with a tone matching yours:
(below is a (true) example of communication in the same tone as yours
 that i avoid)

"I appreciated the stellar service you provided by providing and
 hosting a trac server for FFmpeg. It had only one broken cpu core.
 You only once decided to use the FFmpeg server to test some random
 audio hardware.

 Its sad that our users need reliable service"

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 12:33 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every mail you post is an attack on FFmpeg or the FFmpeg Team
> And its alot of different people you target. And often people who
> have done good and valuable work
>

STF was you and Thilo. Thilo doesn't exactly have the best reputation in
this project.

Seriously, I could easily talk negatively about you in every mail i
> write too but i dont, i try to be polite and positive.
>
> As an example i could have instead replied with a tone matching yours:
> (below is a (true) example of communication in the same tone as yours
>  that i avoid)
>
> "I appreciated the stellar service you provided by providing and
>  hosting a trac server for FFmpeg. It had only one broken cpu core.
>  You only once decided to use the FFmpeg server to test some random
>  audio hardware.
>
>  Its sad that our users need reliable service"
>

You seem to forget that you contacted me in a panic because your hosting
was gone. And I went into the office on a Saturday in my own time and found
the first server I could find and immediately set it up for you. You are
very much welcome for this.

You really are doing an amazing job of antagonising people to leave the
project. Let's list them:

Paul
Anton
Derek
Vittorio

The two biggest contributors of the last decade gone because of you and
both explicitly saying that.

Who will be next! Tune into the next episode of Michael antagonising people
who don't agree with him!

Regards,
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] STF RaptorQ

[Devin Heitmueller]

Hello Lynne,

On Thu, May 22, 2025 at 11:48 PM Lynne <dev@lynne.ee> wrote:
> > I see the task on the TRAC page for STF 2025, and while intellectually
> > interesting to a nerd like me who does lots of work with reliable
> > protocols, I'm not confident this particular protocol makes much sense
> > to work on, especially for 24,000 EUR.
>
> It's not a protocol.

Yes, I am aware of the difference between an algorithm and a protocol,
thanks.  My (perhaps incorrect) assumption was that you also intended
to implement the RaptorQ over RTP protocol spec (RFC 6682), since
algorithms themselves aren't very useful without some form of working
implementation.  If your intent is to implement just the algorithm
without any protocol that demonstrates it, then my concerns are even
greater regarding whether this is a good use of STF funds.

> > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > so it's not clear what the use cases are if the goal is
> > interoperability.  If somebody really wants to be paid to work on
> > reliable transport protocols, the time would be better spent improving
> > the RIST or SRT integration, which is where most of the industry is
> > putting their energy.
>
> Again, it's not a protocol. It's an FEC algorithm. No current mainstream
> protocol specifies using it. It will take decades, at least, and it
> definitely cannot fit into existing protocols.
>
> Custom closed-source video transmission protocols are using it.
> But, I do believe it's the future for open-source protocols too.
> > I agree with Kieran that this seems to largely be outside the STF
> > objectives (i.e. sustainability for open source projects).Like I mentioned, I believe the STF is not maintenance-only, or so I gather.

Yeah, I suspect much of this comes down to a discussion on what STF
expects/requires funds to be used for.

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] STF RaptorQ

[Michael Niedermayer]

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

Hi Kieran

On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, 23 May 2025, 12:33 Michael Niedermayer, <michael@niedermayer.cc>
> wrote:
> 
> > Hi Kieran
> >
> > On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> > wrote:
> > [...]
> > > I appreciate the way the 2024 organisers ran STF was not exactly stellar
> >
> > It seems every mail you post is an attack on FFmpeg or the FFmpeg Team
> > And its alot of different people you target. And often people who
> > have done good and valuable work
> >
> 
> STF was you and Thilo.

There where several more people working on STF.
If you want to spread defamation against me and thilo, at least exclude
the other people


> Thilo doesn't exactly have the best reputation in
> this project.

There was a systematic defamation campaign against thilo (and me)
The people doing that, themselfs even publically called it
"this may be slander"
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-November/336263.html

Thilo as a result of all this stoped posting to ffmpeg-devel and also no
longer works at fflabs.

[...]

--
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.

[-- 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] STF RaptorQ

[Devin Heitmueller]

Hello Michael,

On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
> On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > <ffmpeg-devel@ffmpeg.org> wrote:
> > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > maintenance of FFmpeg.
>
> i agree adding RaptorQ itself is probably not maintenance

Ok, so that much everybody seems to agree on.  Great.

> > > It's adding an obscure FEC protocol to FFmpeg,
>
> tornado and raptor codes are not obscure.
> and FFmpeg supports hundreads of much more obscure things

Sure, no disagreement there.  While I've personally never used any of
the codecs that support video games from the 1990's, I don't really
have any problem with them being in ffmpeg.  That said, in my opinion,
I doubt STF would really think it's a good use of their funds to add
support for new codecs for such games.

> > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > so it's not clear what the use cases are if the goal is
> > interoperability.
>
> its IMHO for communication between tools that on both sides
> use our software
>
> If no commercial gear uses a reliable FEC system all teh better
> for us

Wow, that's quite a leap to suggest that because there aren't open
standards using RaptorQ that there isn't commercial video transmission
gear out there that doesn't do a good job with FEC.

> > If somebody really wants to be paid to work on
> > reliable transport protocols, the time would be better spent improving
> > the RIST or SRT integration, which is where most of the industry is
> > putting their energy.
>
> FEC is supperior to ARQ
> for ARQ, each receiver needs to request the lost packet
> while for FEC the sender just needs to know or guess how many packets
> where lost.
> 1. FEC is lower latency
> 2. FEC does not suffer from "oops the retrasmit was lost too"
> 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0
>    with ARQ you need to send 3 individual packets with FEC you CAN broadcast
>    the same 1 packet to all 3 receivers to recover them.

This is largely an academic discussion that I could argue either side
of, depending on the intended use case.  There are tradeoffs to both
approaches, and which one is most appropriate depends on how it's
being used.

> Also FEC is VERY widely used, just not where you are looking.
> from compact disks, to phone networks to inter planetary communication
> since over 50 years its the standard, voyager in 1970 used FEC already.

Please tell me that you're not seriously trying to explain to me that
FEC is widely used and has been around for decades to solve lots of
real-world problems.  It would be difficult for me to not read that
with a very condescending tone.

> > I agree with Kieran that this seems to largely be outside the STF
> > objectives (i.e. sustainability for open source projects).
>
> A new implementation of RIST, SRT, Raptor and so on may fall outside
> but redesigning the protocol layer in FFmpeg would perfectly fit inside
> "sustainability for open source projects"
> When you want A and B and both are connected, you ask for the funding
> to be for the side that fits inside the guidelines
> So this STF project could be changed to center on maintaince of the
> protocol layer instead of a RaptorQ/SRT/RIST implementation i think.

I'm certainly not suggesting anybody implement a new version of RIST
or SRT (and on a personal note I give Kieran an enormous amount of
credit for building his own SRT implementation).  But yeah, I think
most people who have looked closely at the ffmpeg protocol layer
acknowledge it could be improved, and that seems like the thing that
someone could easily convince STF of.

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] STF RaptorQ

[Devin Heitmueller]

On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
> Theres also the human element, where people are not machienes that can
> be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring
>
> Some people enjoy working on "cool" things, dont tell them to work on
> boring things please. Its bad for them, and likely bad for the results.
>
> If you find RIST/SRT important, you should work on it, or fund someone
> to do it or to submit a project idea to STF/GsoC/... and work on it
> with their funding ...
>
> Also IMO if you have someone who wants to do a project that moves FFmpeg
> forward, be supportive of the effort and try to find a way to make it happen
> be that inside or outside STF.
> Arguing against efforts to move to teh cutting edge of technology
> will do only one thing and thats havig competitors take the space
> and FFmpeg fall behind

To be clear, I have no desire to discourage developers from working on
anything that interests them.  I've spoken to Lynne about her txproto
work, and while I can't offer any guidance due to the NDA with my
employer, I admire her initiative and really hope that research turns
into something useful.

This discussion though really started about what the scope of work is
that can be funded by STF.  My understanding is that STF intends for
the funds to be used for maintenance and work that contributes toward
project sustainability.  At least for me personally, I am not
confident I could argue that the RaptorQ work proposed falls within
that definition.

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, May 23, 2025 at 12:33 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every mail you post is an attack on FFmpeg or the FFmpeg Team
> And its alot of different people you target. And often people who
> have done good and valuable work
>
> Seriously, I could easily talk negatively about you in every mail i
> write too but i dont, i try to be polite and positive.
>
> As an example i could have instead replied with a tone matching yours:
> (below is a (true) example of communication in the same tone as yours
>  that i avoid)
>
> "I appreciated the stellar service you provided by providing and
>  hosting a trac server for FFmpeg. It had only one broken cpu core.
>  You only once decided to use the FFmpeg server to test some random
>  audio hardware.
>
>  Its sad that our users need reliable service"

Since you decided to slander me I looked at the logs.
I travelled two hours each way to the office on Saturday July 4th 2015
and stayed until 8pm on your request setting up a server as an
emergency.

This server was in the same room as two FFmpeg committers and a third
works for the same company remotely. These three contributors are
known physically to the community and have met the community many
times.
Many other FFmpeg developers also visited our office. This is in
contrast to the current hosting situation where nobody has visited,
nobody knows who has access.

I have no record of us ever testing an audio device in it. If we did
it was a real emergency.

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
<devin.heitmueller@ltnglobal.com> wrote:
>
> Hello Michael,
>
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > <ffmpeg-devel@ffmpeg.org> wrote:
> > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > > maintenance of FFmpeg.
> >
> > i agree adding RaptorQ itself is probably not maintenance
>
> Ok, so that much everybody seems to agree on.  Great.
>
> > > > It's adding an obscure FEC protocol to FFmpeg,
> >
> > tornado and raptor codes are not obscure.
> > and FFmpeg supports hundreads of much more obscure things
>
> Sure, no disagreement there.  While I've personally never used any of
> the codecs that support video games from the 1990's, I don't really
> have any problem with them being in ffmpeg.  That said, in my opinion,
> I doubt STF would really think it's a good use of their funds to add
> support for new codecs for such games.
>
> > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > > so it's not clear what the use cases are if the goal is
> > > interoperability.
> >
> > its IMHO for communication between tools that on both sides
> > use our software
> >
> > If no commercial gear uses a reliable FEC system all teh better
> > for us
>
> Wow, that's quite a leap to suggest that because there aren't open
> standards using RaptorQ that there isn't commercial video transmission
> gear out there that doesn't do a good job with FEC.
>
> > > If somebody really wants to be paid to work on
> > > reliable transport protocols, the time would be better spent improving
> > > the RIST or SRT integration, which is where most of the industry is
> > > putting their energy.
> >
> > FEC is supperior to ARQ
> > for ARQ, each receiver needs to request the lost packet
> > while for FEC the sender just needs to know or guess how many packets
> > where lost.
> > 1. FEC is lower latency
> > 2. FEC does not suffer from "oops the retrasmit was lost too"
> > 3. if you have 3 receivers one lost packet 5 one packet 8 and one packet 0
> >    with ARQ you need to send 3 individual packets with FEC you CAN broadcast
> >    the same 1 packet to all 3 receivers to recover them.
>
> This is largely an academic discussion that I could argue either side
> of, depending on the intended use case.  There are tradeoffs to both
> approaches, and which one is most appropriate depends on how it's
> being used.
>
> > Also FEC is VERY widely used, just not where you are looking.
> > from compact disks, to phone networks to inter planetary communication
> > since over 50 years its the standard, voyager in 1970 used FEC already.
>
> Please tell me that you're not seriously trying to explain to me that
> FEC is widely used and has been around for decades to solve lots of
> real-world problems.  It would be difficult for me to not read that
> with a very condescending tone.

Michael doesn't understand the difference between block FEC and packet
FEC so he's not being condescending.

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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya <kieran618@googlemail.com> wrote:
>
> On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> <devin.heitmueller@ltnglobal.com> wrote:
> >
> > Hello Michael,
> >
> > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > > <ffmpeg-devel@ffmpeg.org> wrote:
> > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > > > maintenance of FFmpeg.
> > >
> > > i agree adding RaptorQ itself is probably not maintenance
> >
> > Ok, so that much everybody seems to agree on.  Great.
> >
> > > > > It's adding an obscure FEC protocol to FFmpeg,
> > >
> > > tornado and raptor codes are not obscure.
> > > and FFmpeg supports hundreads of much more obscure things
> >
> > Sure, no disagreement there.  While I've personally never used any of
> > the codecs that support video games from the 1990's, I don't really
> > have any problem with them being in ffmpeg.  That said, in my opinion,
> > I doubt STF would really think it's a good use of their funds to add
> > support for new codecs for such games.
> >
> > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > > > so it's not clear what the use cases are if the goal is
> > > > interoperability.
> > >
> > > its IMHO for communication between tools that on both sides
> > > use our software
> > >
> > > If no commercial gear uses a reliable FEC system all teh better
> > > for us
> >
> > Wow, that's quite a leap to suggest that because there aren't open
> > standards using RaptorQ that there isn't commercial video transmission
> > gear out there that doesn't do a good job with FEC.
> >
> > > > If somebody really wants to be paid to work on
> > > > reliable transport protocols, the time would be better spent improving
> > > > the RIST or SRT integration, which is where most of the industry is
> > > > putting their energy.
> > >
> > > FEC is supperior to ARQ
> > > for ARQ, each receiver needs to request the lost packet
> > > while for FEC the sender just needs to know or guess how many packets
> > > where lost.
> > > 1. FEC is lower latency

This isn't true. You need a large FEC matrix to handle burst packet
loss and you have to buffer for the duration of this matrix.
At low bitrates this duration can be really long. (100 packets at
1mbit/s is already roughly a second).

Regards,
Kieran Kunhya
_______________________________________________
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] STF RaptorQ

[Michael Niedermayer]

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

Hi Devin

On Fri, May 23, 2025 at 10:57:37AM -0400, Devin Heitmueller wrote:
> On Fri, May 23, 2025 at 5:58 AM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > Theres also the human element, where people are not machienes that can
> > be placed and told things arbitrary. RaptorQ is "cool", ARQ is boring
> >
> > Some people enjoy working on "cool" things, dont tell them to work on
> > boring things please. Its bad for them, and likely bad for the results.
> >
> > If you find RIST/SRT important, you should work on it, or fund someone
> > to do it or to submit a project idea to STF/GsoC/... and work on it
> > with their funding ...
> >
> > Also IMO if you have someone who wants to do a project that moves FFmpeg
> > forward, be supportive of the effort and try to find a way to make it happen
> > be that inside or outside STF.
> > Arguing against efforts to move to teh cutting edge of technology
> > will do only one thing and thats havig competitors take the space
> > and FFmpeg fall behind
> 
> To be clear, I have no desire to discourage developers from working on
> anything that interests them.  I've spoken to Lynne about her txproto
> work, and while I can't offer any guidance due to the NDA with my
> employer, I admire her initiative and really hope that research turns
> into something useful.
> 
> This discussion though really started about what the scope of work is
> that can be funded by STF.  My understanding is that STF intends for
> the funds to be used for maintenance and work that contributes toward
> project sustainability.  At least for me personally, I am not
> confident I could argue that the RaptorQ work proposed falls within
> that definition.

yes, as it was proposed on the wiki and as i remember STF, i agree.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle

[-- 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] STF RaptorQ

[Michael Niedermayer]

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

Hi Devin

On Fri, May 23, 2025 at 10:50:32AM -0400, Devin Heitmueller wrote:
> Hello Michael,
> 
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > <ffmpeg-devel@ffmpeg.org> wrote:
> > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > > maintenance of FFmpeg.
> >
> > i agree adding RaptorQ itself is probably not maintenance
> 
> Ok, so that much everybody seems to agree on.  Great.
> 
> > > > It's adding an obscure FEC protocol to FFmpeg,
> >
> > tornado and raptor codes are not obscure.
> > and FFmpeg supports hundreads of much more obscure things
> 
> Sure, no disagreement there.  While I've personally never used any of
> the codecs that support video games from the 1990's, I don't really
> have any problem with them being in ffmpeg.  That said, in my opinion,
> I doubt STF would really think it's a good use of their funds to add
> support for new codecs for such games.

yes, of course


[...]

> > > I agree with Kieran that this seems to largely be outside the STF
> > > objectives (i.e. sustainability for open source projects).
> >
> > A new implementation of RIST, SRT, Raptor and so on may fall outside
> > but redesigning the protocol layer in FFmpeg would perfectly fit inside
> > "sustainability for open source projects"
> > When you want A and B and both are connected, you ask for the funding
> > to be for the side that fits inside the guidelines
> > So this STF project could be changed to center on maintaince of the
> > protocol layer instead of a RaptorQ/SRT/RIST implementation i think.
> 
> I'm certainly not suggesting anybody implement a new version of RIST
> or SRT (and on a personal note I give Kieran an enormous amount of
> credit for building his own SRT implementation).  But yeah, I think
> most people who have looked closely at the ffmpeg protocol layer
> acknowledge it could be improved, and that seems like the thing that
> someone could easily convince STF of.

So if i understand you correctly, we seem to agree here

If someone wants to do a protocol layer improvment project in FFmpeg STF
you agree with me that this would fall within STF.

we would just need someone who wants to do that.

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

[-- 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] STF RaptorQ

[Tristan Matthews via ffmpeg-devel]

Hi,

<snip>
> 
> 
> But Lynne is insisting it's not a protocol. The work would just be the low
> level RaptorQ algorithm.
> 
> UDP based retransmit/FEC protocols are essentially impossible to develop
> well without an event loop / timers.
> 
> You can look at libsrt and librist of examples of how trying to reinvent an
> event loop in threads and creating lots of bugs in the process as each lib
> struggles to synchronise a complex state machine between threads.
> 
> Adding event loop support to FFmpeg would be a great STF project.

I just wanted to drop a giant +1 that event loop support in FFmpeg would be a big win (and unblock a lot of other improvements for e.g. FFmpeg's network stack IMO) and should seriously be considered for an STF project if someone has the wherewithal. It's obviously a pretty large undertaking.

Best,
Tristan
_______________________________________________
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] STF RaptorQ

[Michael Niedermayer]

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

Hi Kieran

On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya <kieran618@googlemail.com> wrote:
> >
> > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> > <devin.heitmueller@ltnglobal.com> wrote:
> > >
> > > Hello Michael,
> > >
> > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > > > <ffmpeg-devel@ffmpeg.org> wrote:
> > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > > > > maintenance of FFmpeg.
> > > >
> > > > i agree adding RaptorQ itself is probably not maintenance
> > >
> > > Ok, so that much everybody seems to agree on.  Great.
> > >
> > > > > > It's adding an obscure FEC protocol to FFmpeg,
> > > >
> > > > tornado and raptor codes are not obscure.
> > > > and FFmpeg supports hundreads of much more obscure things
> > >
> > > Sure, no disagreement there.  While I've personally never used any of
> > > the codecs that support video games from the 1990's, I don't really
> > > have any problem with them being in ffmpeg.  That said, in my opinion,
> > > I doubt STF would really think it's a good use of their funds to add
> > > support for new codecs for such games.
> > >
> > > > > I'm not sure I've seen any commercial gear that does RaptorQ for FEC,
> > > > > so it's not clear what the use cases are if the goal is
> > > > > interoperability.
> > > >
> > > > its IMHO for communication between tools that on both sides
> > > > use our software
> > > >
> > > > If no commercial gear uses a reliable FEC system all teh better
> > > > for us
> > >
> > > Wow, that's quite a leap to suggest that because there aren't open
> > > standards using RaptorQ that there isn't commercial video transmission
> > > gear out there that doesn't do a good job with FEC.
> > >
> > > > > If somebody really wants to be paid to work on
> > > > > reliable transport protocols, the time would be better spent improving
> > > > > the RIST or SRT integration, which is where most of the industry is
> > > > > putting their energy.
> > > >
> > > > FEC is supperior to ARQ
> > > > for ARQ, each receiver needs to request the lost packet
> > > > while for FEC the sender just needs to know or guess how many packets
> > > > where lost.
> > > > 1. FEC is lower latency
> 
> This isn't true. You need a large FEC matrix to handle burst packet
> loss and you have to buffer for the duration of this matrix.
> At low bitrates this duration can be really long. (100 packets at
> 1mbit/s is already roughly a second).

Even with this constructed example, FEC is lower latency than no FEC

lets take your 1mbit/sec and your 100packets a second, that makes 10kbit per packet

with retransmission we will request a retransmission once we reasonably know a packet
is lost, but we will not be sure because sometimes a packet is just late or out of order
so we at the very least will have to wait for the next packet to come in but in reality maybe
we wait an extra one to conserve bandwidth and not request a reatransmit of every out of
order packet.
We will also end up asking for packets that we actually do receive later,
these will waste bandwidth

with FEC lets say we have 1 extra parity packet every 20 packets, but you can
pick other numbers
now we do the same, we ask for a retransmission at the same time as before.
BUT and thats the crucial difference we dont need to ask for a specific packet
we just ask for how many we are currently missing

Lets pick actual random numbers:

Packets 1, 3, 2, 4, 5, 8, 6, 9, 10
ARQ:       R2          R6R7         (you can make this burst arbitrary long)
FEC:       R1          R2

Now the differnce are multiple
First the parity packet send for R1 will not just include packets up to 3 but instead up to the
point the sender has them at the time it sends the parity packet so this packet may include
packet 6 or 7.
Similarly when the receiver requests 2 parity packets seeing 8 without 6 and 7 by the time
the receiver receives the first parity packet it will have received packet 6 and not
need to wait for the 2nd one
again there is a CLEAR advantage over ARQ in lower latency
and we have NOT even used the 1/20 parity we get by default

you can make teh burst as long as you want, theres an advanatge for FEC
* If a packet is received after its retransmission is requested
* If any transmitted by default parity packets cover the range
* If any previous requested parity happens to cover any part of the burst

Now i dont expect that iam the first to suggest this system above, but
maybe i am.

Also above is just what i came up with in 15min, i expect if some
mathematicans think about this they will find more ways to reduce
latency with FEC.

Giving one an extra optional tool cant make the optimal solution worse,
it can make it better though.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable

[-- 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] STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Fri, 23 May 2025, 21:35 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi Kieran
>
> On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya <kieran618@googlemail.com>
> wrote:
> > >
> > > On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
> > > <devin.heitmueller@ltnglobal.com> wrote:
> > > >
> > > > Hello Michael,
> > > >
> > > > On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> > > > <michael@niedermayer.cc> wrote:
> > > > > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > > > > <ffmpeg-devel@ffmpeg.org> wrote:
> > > > > > > I wanted to put on the record that adding RaptorQ to FFmpeg
> isn't
> > > > > > > maintenance of FFmpeg.
> > > > >
> > > > > i agree adding RaptorQ itself is probably not maintenance
> > > >
> > > > Ok, so that much everybody seems to agree on.  Great.
> > > >
> > > > > > > It's adding an obscure FEC protocol to FFmpeg,
> > > > >
> > > > > tornado and raptor codes are not obscure.
> > > > > and FFmpeg supports hundreads of much more obscure things
> > > >
> > > > Sure, no disagreement there.  While I've personally never used any of
> > > > the codecs that support video games from the 1990's, I don't really
> > > > have any problem with them being in ffmpeg.  That said, in my
> opinion,
> > > > I doubt STF would really think it's a good use of their funds to add
> > > > support for new codecs for such games.
> > > >
> > > > > > I'm not sure I've seen any commercial gear that does RaptorQ for
> FEC,
> > > > > > so it's not clear what the use cases are if the goal is
> > > > > > interoperability.
> > > > >
> > > > > its IMHO for communication between tools that on both sides
> > > > > use our software
> > > > >
> > > > > If no commercial gear uses a reliable FEC system all teh better
> > > > > for us
> > > >
> > > > Wow, that's quite a leap to suggest that because there aren't open
> > > > standards using RaptorQ that there isn't commercial video
> transmission
> > > > gear out there that doesn't do a good job with FEC.
> > > >
> > > > > > If somebody really wants to be paid to work on
> > > > > > reliable transport protocols, the time would be better spent
> improving
> > > > > > the RIST or SRT integration, which is where most of the industry
> is
> > > > > > putting their energy.
> > > > >
> > > > > FEC is supperior to ARQ
> > > > > for ARQ, each receiver needs to request the lost packet
> > > > > while for FEC the sender just needs to know or guess how many
> packets
> > > > > where lost.
> > > > > 1. FEC is lower latency
> >
> > This isn't true. You need a large FEC matrix to handle burst packet
> > loss and you have to buffer for the duration of this matrix.
> > At low bitrates this duration can be really long. (100 packets at
> > 1mbit/s is already roughly a second).
>
> Even with this constructed example, FEC is lower latency than no FEC
>
> lets take your 1mbit/sec and your 100packets a second, that makes 10kbit
> per packet
>
> with retransmission we will request a retransmission once we reasonably
> know a packet
> is lost, but we will not be sure because sometimes a packet is just late
> or out of order
> so we at the very least will have to wait for the next packet to come in
> but in reality maybe
> we wait an extra one to conserve bandwidth and not request a reatransmit
> of every out of
> order packet.
> We will also end up asking for packets that we actually do receive later,
> these will waste bandwidth
>
> with FEC lets say we have 1 extra parity packet every 20 packets, but you
> can
> pick other numbers
> now we do the same, we ask for a retransmission at the same time as before.
> BUT and thats the crucial difference we dont need to ask for a specific
> packet
> we just ask for how many we are currently missing
>
> Lets pick actual random numbers:
>
> Packets 1, 3, 2, 4, 5, 8, 6, 9, 10
> ARQ:       R2          R6R7         (you can make this burst arbitrary
> long)
> FEC:       R1          R2
>
> Now the differnce are multiple
> First the parity packet send for R1 will not just include packets up to 3
> but instead up to the
> point the sender has them at the time it sends the parity packet so this
> packet may include
> packet 6 or 7.
> Similarly when the receiver requests 2 parity packets seeing 8 without 6
> and 7 by the time
> the receiver receives the first parity packet it will have received packet
> 6 and not
> need to wait for the 2nd one
> again there is a CLEAR advantage over ARQ in lower latency
> and we have NOT even used the 1/20 parity we get by default
>
> you can make teh burst as long as you want, theres an advanatge for FEC
> * If a packet is received after its retransmission is requested
> * If any transmitted by default parity packets cover the range
> * If any previous requested parity happens to cover any part of the burst
>
> Now i dont expect that iam the first to suggest this system above, but
> maybe i am.
>
> Also above is just what i came up with in 15min, i expect if some
> mathematicans think about this they will find more ways to reduce
> latency with FEC.
>
> Giving one an extra optional tool cant make the optimal solution worse,
> it can make it better though.
>
> thx
>

Your diagram makes no sense and in protocols such as RaptorQ and other FEC
like XOR it's a unidirectional channel. You don't request FEC packets in
any of these protocols. There is a (potentially dynamic) percentage of FEC
packets sent for the actual data..

Let's use your toy example of one parity packet after 20 data packets. The
receiver has to wait 20 packets to be sure an FEC packet has been
transmitted, adding latency. If the content is VBR it's even worse as you
need out of band signalling to signal the worst case latency to avoid
bursting.

If the RTT is low then it might be quicker to just retransmit and it saves
bandwidth as you don't have overhead.

For long RTT links like London to Sydney unidirectional FEC might be a
better tradeoff.

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

[FFmpeg-devel] Previous trac server hosting Was: STF RaptorQ

[Michael Niedermayer]

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

Hi

On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> > As an example i could have instead replied with a tone matching yours:
> > (below is a (true) example of communication in the same tone as yours
> >  that i avoid)
> >
> > "I appreciated the stellar service you provided by providing and
> >  hosting a trac server for FFmpeg. It had only one broken cpu core.
> >  You only once decided to use the FFmpeg server to test some random
> >  audio hardware.
> >
> >  Its sad that our users need reliable service"
> >
> 
> You seem to forget that you contacted me in a panic because your hosting
> was gone. And I went into the office on a Saturday in my own time and found
> the first server I could find and immediately set it up for you. You are
> very much welcome for this.

Its long ago, if we look at the logs, we can see how the whole team worked
together with no problems and then votes are started on people and fail and
you shut the server down.
This log is sadly a bit lengthy, i tried to cut away uninterresting things
but its still long.

When it all started in 2015

Jul 04 15:39:34 *       kierank (sid5955@gateway/web/irccloud.com/x-jxtnzgbwhhjmsyes) has joined ##ffmpeg-admin
Jul 04 15:39:43 <kierank>       I have a box with 2x 750GB drives
Jul 04 15:39:49 <kierank>       and 250mbit/s internet
Jul 04 15:40:58 <michaelni>     hi kierank maybe we could move trac there and or secondary nameserver i dont know if anyone is working on trac rescue
Jul 04 15:41:18 <michaelni>     if you know trac, ive no idea what you know
Jul 04 15:41:43 <kierank>       I can try migrating trac


First surprise, secure login:

Jul 04 21:00:50 <kierank>       217.138.67.134 - username: ffmpeg password: ffmpegpassw0rd
Jul 04 21:00:52 <kierank>       you can login


Later we learn more about the machiene:

Jul 06 23:49:53 <kierank>       that server has some oddities like
Jul 06 23:49:54 <kierank>       CPU 4 on socket 0 has large number of corrected cache errors in Level-2 Generic
Jul 06 23:49:54 <kierank>       System operating correctly
Jul 06 23:51:42 <beastd>        ah
Jul 06 23:53:17 <michaelni>     kierank, can you replace faulty hw ?
Jul 06 23:53:45 <kierank>       yes there are 4 machines which I think are identical
Jul 06 23:54:07 <michaelni>     rcombs, and others will that ipv6 mail stuff not cause problems without reverse dns, or do we have reverse dns ?
Jul 06 23:55:07 <kierank>       there are also a ton of uniprocessor machines there
Jul 06 23:55:50 <michaelni>     kierank, please replace that faulty cpu if you can easily, i dont think this is urgent but its better to replace if you can easily
Jul 06 23:55:58 <kierank>       it's not easily replaceable
Jul 06 23:56:06 <michaelni>     :(
Jul 06 23:56:26 <kierank>       I'm not sure if I could just pull the disks out of one and stick it in another machine
Jul 06 23:56:28 <kierank>       because of the raid
Jul 06 23:56:51 <kierank>       the OS seems to have disabled the faulty cores


ECC RAM vs backups for db ?

Jul 07 01:00:51 <kierank>       Error Correction Type: None
Jul 07 01:00:52 <kierank>       apparently not
Jul 07 01:01:28 <kierank>       hence why it should get backed up


"tons of other boxes" there ...

Jul 31 17:33:57 <TimNich>       If we could get a better box at your loc, that would be good wouldn’t it?
Jul 31 17:34:46 <kierank>       yes, there are tons of other boxes, just haven't had time to see what's on them yet


replacing a disk: "doesn't boot at all now"

Feb 20 15:36:58 <kierank>       I found a spare hdd
Feb 20 16:07:15 <kierank>       so looks like /dev/sda has failed
Feb 20 16:07:26 <kierank>       need to figure out how to remove it from the raid array and add /dev/sdb
Feb 20 16:20:55 <kierank>       ok going to take trac down
Feb 20 16:33:21 <kierank>       back up but using the bad disk still
Feb 20 16:33:53 <michaelni>     what went wrong ?
Feb 20 16:34:17 <michaelni>     or it was intended to still use the old ?
Feb 20 16:37:09 <kierank>       it wasn't happy with the new
Feb 20 16:37:19 <kierank>       and now it wants to raid resync
Feb 20 16:37:22 <kierank>       which is going really slow
Feb 20 16:42:39 <michaelni>     why didnt it accept it? do you have another disk ?
Feb 20 16:43:11 <kierank>       I have to let it raid resync now
Feb 20 16:43:31 <kierank>       I think there was some stuff on that disk which confused it
Feb 20 16:43:35 <kierank>       so I am wiping the new disk
Feb 20 16:43:43 <michaelni>     ahh, ok
Feb 20 16:43:53 <kierank>       the raid resync will take a day or so
Feb 20 16:43:56 <kierank>       it's about 1x in
Feb 20 16:43:58 <kierank>       1%
Feb 20 16:45:21 <kierank>       trac is hanging which I don't like
Feb 20 16:45:56 <michaelni>     :(
Feb 20 16:48:48 <kierank>       seems up but slow
Feb 20 16:50:15 <kierank>       basically got to wait for the existing raid to sort itself out
Feb 20 16:50:19 <kierank>       and hopefully not cause any damage
Feb 20 16:50:30 <kierank>       and then I can swap /dev/sda for /dev/sdc
Feb 20 16:50:34 <kierank>       and see if that works
Feb 20 16:50:41 <kierank>       otherwise i'll swap /dev/sdac
Feb 20 16:50:51 <kierank>       otherwise i'll swap /dev/sdb for /dev/sda
Feb 20 16:50:54 <kierank>       and put /dev/sdc in /dev/sdb
Feb 20 18:04:40 *       Disconnected (Input/output error).
**** ENDING LOGGING AT Sat Feb 20 18:04:40 2016

**** BEGIN LOGGING AT Sat Feb 20 18:05:17 2016

Feb 20 18:05:17 *       Now talking on ##ffmpeg-admin
Feb 20 18:07:07 <michaelni>     kierank, just be carefull you dont overwrite the good disk from an empty one
Feb 20 18:07:47 <kierank>       I'm hoping the raid controller will do the right thing
Feb 20 18:07:49 <kierank>       but not fully sure
...
Feb 21 15:09:15 <kierank>       don't know but I can put a new disk in
Feb 21 15:09:21 <kierank>       "new"
Feb 21 15:10:23 <michaelni>     if putting a "new" disk in + sync fixes it it would be easier than a full reinstall i guess
Feb 21 15:10:51 <kierank>       ok I will try
Feb 21 15:15:10 <kierank>       well it doesn't want to rebuild to the new drive
Feb 21 15:15:48 <michaelni>     what does it say to what command ?
Feb 21 15:18:04 <kierank>       root@ffmpeg1:~# dmraid -s
Feb 21 15:18:04 <kierank>       ERROR: isw: wrong number of devices in RAID set "isw_ciaehhaddg_RAID1" [1/2] on /dev/sdb
Feb 21 15:18:04 <kierank>       ERROR: isw: wrong number of devices in RAID set "isw_dageddcdde_Volume0" [1/2] on /dev/sda
Feb 21 15:18:04 <kierank>       *** Group superset isw_ciaehhaddg
Feb 21 15:18:04 <kierank>       --> *Inconsistent* Subset
Feb 21 15:18:04 <kierank>       name   : isw_ciaehhaddg_RAID1
Feb 21 15:18:04 <kierank>       size   : 1465143296
Feb 21 15:18:05 <kierank>       stride : 128
Feb 21 15:18:05 <kierank>       type   : mirror
Feb 21 15:18:06 <kierank>       status : inconsistent
Feb 21 15:18:06 <kierank>       subsets: 0
Feb 21 15:18:07 <kierank>       devs   : 1
Feb 21 15:18:07 <kierank>       spares : 0
Feb 21 15:18:08 <kierank>       *** Group superset isw_dageddcdde
Feb 21 15:18:40 <kierank>       this machine uses ubuntu "fakeraid"
Feb 21 15:21:09 <michaelni>     ill try to research that a bit, you can also ask root@ffmpeg.org someone like raz or arpi should know what to do
Feb 21 15:22:31 <kierank>       should be rebuilding now onto new disk
Feb 21 15:32:23 <kierank>       game over
Feb 21 15:32:24 <kierank>       doesn't boot at all now


wait for admins or just wipe and reinstall

Feb 21 15:43:18 <michaelni>     i mailed the log to root, maybe one of them has an idea
Feb 21 15:44:46 <kierank>       I am reinstalling
Feb 21 15:44:51 <kierank>       it's too late


Secure login #2

Feb 21 16:14:28 <kierank>       ok you can login to uk trac
Feb 21 16:14:31 <kierank>       username: ffmpeg
Feb 21 16:14:36 <kierank>       password: ffmpegPassw0rd
Feb 21 16:14:56 <kierank>       michaelni: ^
...
Feb 21 16:31:18 <michaelni>     also its safer to just add my key to authorized_keys than using pw
Feb 21 16:31:26 <michaelni>     ssh-rsa ...


what 250mbit/sec really means

May 18 01:14:52 <kierank>       I may have to ratelimit connectivity on my FFmpeg machine soon
...
May 24 20:21:44 <kierank>       traffic shaping on my machine to 5mbit/s up and down for now
...


ending hosting after a vote doesnt go as planned:

So 12 Jun 2016 22:58:37 CEST Paul B Mahol <onemda@gmail.com> [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos

**** BEGIN LOGGING AT Mon Jun 13 05:54:31 2016
Jun 13 12:24:21 <kierank>       I am considering taking fftrac-gb offline
Jun 13 13:01:36 <kierank>       permanently
Jun 13 13:25:44 <michaelni>     kierank, why ?
Jun 13 13:25:58 <michaelni>     we use the machine
Jun 13 13:27:31 <kierank>       ffmpeg is a sinking ship
Jun 13 13:35:46 <michaelni>     kierank, whats the matter all of a sudden ?
Jun 13 13:36:04 <kierank>       look at ffmpeg, the community is falling apart
Jun 13 13:36:34 <michaelni>     taking the server offline is not going to help the situation
Jun 13 13:36:55 <michaelni>     everyone overreacts already
Jun 13 13:36:57 <kierank>       i've told you for 9 months now to let vlc host us
...
Jun 13 13:48:39 <kierank>       nobody voted for me to host
Jun 13 13:50:25 <michaelni>     no, you generously offered it, we needed to move and it seemed a good choice to accept, noone objected AFAIK and time was rather short
Jun 13 14:03:59 <michaelni>     also i think you know derek well, is there something that can be done to get him to return?
Jun 13 14:05:38 <michaelni>     that 4month vote was very unwise as peope will not support it due to harshness
Jun 13 14:17:57 <michaelni>     kierank, ^ (do you have an idea how we can get derek back?)
Jun 15 21:25:25 <kierank>       my server is going down
Jun 15 21:25:27 <kierank>       bye
Jun 15 21:25:44 <kierank>       can't really support the insanity of this project atm
Jun 15 21:36:02 <michaelni>     kierank, please explain
Jun 15 21:37:30 *       kierank (sid5955@gateway/web/irccloud.com/x-alaucxykftiixsxj) has left ##ffmpeg-admin




-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope

[-- 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] Previous trac server hosting Was: STF RaptorQ

[Kieran Kunhya via ffmpeg-devel]

On Sat, 24 May 2025, 17:39 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi
>
> On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > > As an example i could have instead replied with a tone matching yours:
> > > (below is a (true) example of communication in the same tone as yours
> > >  that i avoid)
> > >
> > > "I appreciated the stellar service you provided by providing and
> > >  hosting a trac server for FFmpeg. It had only one broken cpu core.
> > >  You only once decided to use the FFmpeg server to test some random
> > >  audio hardware.
> > >
> > >  Its sad that our users need reliable service"
> > >
> >
> > You seem to forget that you contacted me in a panic because your hosting
> > was gone. And I went into the office on a Saturday in my own time and
> found
> > the first server I could find and immediately set it up for you. You are
> > very much welcome for this.
>
> Its long ago, if we look at the logs, we can see how the whole team worked
> together with no problems and then votes are started on people and fail and
> you shut the server down.
> This log is sadly a bit lengthy, i tried to cut away uninterresting things
> but its still long.
>
> When it all started in 2015
>
> Jul 04 15:39:34 *       kierank (sid5955@gateway/web/
> irccloud.com/x-jxtnzgbwhhjmsyes) has joined ##ffmpeg-admin
> Jul 04 15:39:43 <kierank>       I have a box with 2x 750GB drives
> Jul 04 15:39:49 <kierank>       and 250mbit/s internet
> Jul 04 15:40:58 <michaelni>     hi kierank maybe we could move trac there
> and or secondary nameserver i dont know if anyone is working on trac rescue
> Jul 04 15:41:18 <michaelni>     if you know trac, ive no idea what you know
> Jul 04 15:41:43 <kierank>       I can try migrating trac
>
>
> First surprise, secure login:
>
> Jul 04 21:00:50 <kierank>       217.138.67.134 - username: ffmpeg
> password: ffmpegpassw0rd
> Jul 04 21:00:52 <kierank>       you can login
>
>
> Later we learn more about the machiene:
>
> Jul 06 23:49:53 <kierank>       that server has some oddities like
> Jul 06 23:49:54 <kierank>       CPU 4 on socket 0 has large number of
> corrected cache errors in Level-2 Generic
> Jul 06 23:49:54 <kierank>       System operating correctly
> Jul 06 23:51:42 <beastd>        ah
> Jul 06 23:53:17 <michaelni>     kierank, can you replace faulty hw ?
> Jul 06 23:53:45 <kierank>       yes there are 4 machines which I think are
> identical
> Jul 06 23:54:07 <michaelni>     rcombs, and others will that ipv6 mail
> stuff not cause problems without reverse dns, or do we have reverse dns ?
> Jul 06 23:55:07 <kierank>       there are also a ton of uniprocessor
> machines there
> Jul 06 23:55:50 <michaelni>     kierank, please replace that faulty cpu if
> you can easily, i dont think this is urgent but its better to replace if
> you can easily
> Jul 06 23:55:58 <kierank>       it's not easily replaceable
> Jul 06 23:56:06 <michaelni>     :(
> Jul 06 23:56:26 <kierank>       I'm not sure if I could just pull the
> disks out of one and stick it in another machine
> Jul 06 23:56:28 <kierank>       because of the raid
> Jul 06 23:56:51 <kierank>       the OS seems to have disabled the faulty
> cores
>
>
> ECC RAM vs backups for db ?
>
> Jul 07 01:00:51 <kierank>       Error Correction Type: None
> Jul 07 01:00:52 <kierank>       apparently not
> Jul 07 01:01:28 <kierank>       hence why it should get backed up
>
>
> "tons of other boxes" there ...
>
> Jul 31 17:33:57 <TimNich>       If we could get a better box at your loc,
> that would be good wouldn’t it?
> Jul 31 17:34:46 <kierank>       yes, there are tons of other boxes, just
> haven't had time to see what's on them yet
>
>
> replacing a disk: "doesn't boot at all now"
>
> Feb 20 15:36:58 <kierank>       I found a spare hdd
> Feb 20 16:07:15 <kierank>       so looks like /dev/sda has failed
> Feb 20 16:07:26 <kierank>       need to figure out how to remove it from
> the raid array and add /dev/sdb
> Feb 20 16:20:55 <kierank>       ok going to take trac down
> Feb 20 16:33:21 <kierank>       back up but using the bad disk still
> Feb 20 16:33:53 <michaelni>     what went wrong ?
> Feb 20 16:34:17 <michaelni>     or it was intended to still use the old ?
> Feb 20 16:37:09 <kierank>       it wasn't happy with the new
> Feb 20 16:37:19 <kierank>       and now it wants to raid resync
> Feb 20 16:37:22 <kierank>       which is going really slow
> Feb 20 16:42:39 <michaelni>     why didnt it accept it? do you have
> another disk ?
> Feb 20 16:43:11 <kierank>       I have to let it raid resync now
> Feb 20 16:43:31 <kierank>       I think there was some stuff on that disk
> which confused it
> Feb 20 16:43:35 <kierank>       so I am wiping the new disk
> Feb 20 16:43:43 <michaelni>     ahh, ok
> Feb 20 16:43:53 <kierank>       the raid resync will take a day or so
> Feb 20 16:43:56 <kierank>       it's about 1x in
> Feb 20 16:43:58 <kierank>       1%
> Feb 20 16:45:21 <kierank>       trac is hanging which I don't like
> Feb 20 16:45:56 <michaelni>     :(
> Feb 20 16:48:48 <kierank>       seems up but slow
> Feb 20 16:50:15 <kierank>       basically got to wait for the existing
> raid to sort itself out
> Feb 20 16:50:19 <kierank>       and hopefully not cause any damage
> Feb 20 16:50:30 <kierank>       and then I can swap /dev/sda for /dev/sdc
> Feb 20 16:50:34 <kierank>       and see if that works
> Feb 20 16:50:41 <kierank>       otherwise i'll swap /dev/sdac
> Feb 20 16:50:51 <kierank>       otherwise i'll swap /dev/sdb for /dev/sda
> Feb 20 16:50:54 <kierank>       and put /dev/sdc in /dev/sdb
> Feb 20 18:04:40 *       Disconnected (Input/output error).
> **** ENDING LOGGING AT Sat Feb 20 18:04:40 2016
>
> **** BEGIN LOGGING AT Sat Feb 20 18:05:17 2016
>
> Feb 20 18:05:17 *       Now talking on ##ffmpeg-admin
> Feb 20 18:07:07 <michaelni>     kierank, just be carefull you dont
> overwrite the good disk from an empty one
> Feb 20 18:07:47 <kierank>       I'm hoping the raid controller will do the
> right thing
> Feb 20 18:07:49 <kierank>       but not fully sure
> ...
> Feb 21 15:09:15 <kierank>       don't know but I can put a new disk in
> Feb 21 15:09:21 <kierank>       "new"
> Feb 21 15:10:23 <michaelni>     if putting a "new" disk in + sync fixes it
> it would be easier than a full reinstall i guess
> Feb 21 15:10:51 <kierank>       ok I will try
> Feb 21 15:15:10 <kierank>       well it doesn't want to rebuild to the new
> drive
> Feb 21 15:15:48 <michaelni>     what does it say to what command ?
> Feb 21 15:18:04 <kierank>       root@ffmpeg1:~# dmraid -s
> Feb 21 15:18:04 <kierank>       ERROR: isw: wrong number of devices in
> RAID set "isw_ciaehhaddg_RAID1" [1/2] on /dev/sdb
> Feb 21 15:18:04 <kierank>       ERROR: isw: wrong number of devices in
> RAID set "isw_dageddcdde_Volume0" [1/2] on /dev/sda
> Feb 21 15:18:04 <kierank>       *** Group superset isw_ciaehhaddg
> Feb 21 15:18:04 <kierank>       --> *Inconsistent* Subset
> Feb 21 15:18:04 <kierank>       name   : isw_ciaehhaddg_RAID1
> Feb 21 15:18:04 <kierank>       size   : 1465143296
> Feb 21 15:18:05 <kierank>       stride : 128
> Feb 21 15:18:05 <kierank>       type   : mirror
> Feb 21 15:18:06 <kierank>       status : inconsistent
> Feb 21 15:18:06 <kierank>       subsets: 0
> Feb 21 15:18:07 <kierank>       devs   : 1
> Feb 21 15:18:07 <kierank>       spares : 0
> Feb 21 15:18:08 <kierank>       *** Group superset isw_dageddcdde
> Feb 21 15:18:40 <kierank>       this machine uses ubuntu "fakeraid"
> Feb 21 15:21:09 <michaelni>     ill try to research that a bit, you can
> also ask root@ffmpeg.org someone like raz or arpi should know what to do
> Feb 21 15:22:31 <kierank>       should be rebuilding now onto new disk
> Feb 21 15:32:23 <kierank>       game over
> Feb 21 15:32:24 <kierank>       doesn't boot at all now
>
>
> wait for admins or just wipe and reinstall
>
> Feb 21 15:43:18 <michaelni>     i mailed the log to root, maybe one of
> them has an idea
> Feb 21 15:44:46 <kierank>       I am reinstalling
> Feb 21 15:44:51 <kierank>       it's too late
>
>
> Secure login #2
>
> Feb 21 16:14:28 <kierank>       ok you can login to uk trac
> Feb 21 16:14:31 <kierank>       username: ffmpeg
> Feb 21 16:14:36 <kierank>       password: ffmpegPassw0rd
> Feb 21 16:14:56 <kierank>       michaelni: ^
> ...
> Feb 21 16:31:18 <michaelni>     also its safer to just add my key to
> authorized_keys than using pw
> Feb 21 16:31:26 <michaelni>     ssh-rsa ...
>
>
> what 250mbit/sec really means
>
> May 18 01:14:52 <kierank>       I may have to ratelimit connectivity on my
> FFmpeg machine soon
> ...
> May 24 20:21:44 <kierank>       traffic shaping on my machine to 5mbit/s
> up and down for now
>

The server was moved away at this time. It was doing purely backups.

...
>
>
> ending hosting after a vote doesnt go as planned:
>
> So 12 Jun 2016 22:58:37 CEST Paul B Mahol <onemda@gmail.com>
> [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos
>
> **** BEGIN LOGGING AT Mon Jun 13 05:54:31 2016
> Jun 13 12:24:21 <kierank>       I am considering taking fftrac-gb offline
> Jun 13 13:01:36 <kierank>       permanently
> Jun 13 13:25:44 <michaelni>     kierank, why ?
> Jun 13 13:25:58 <michaelni>     we use the machine
> Jun 13 13:27:31 <kierank>       ffmpeg is a sinking ship
> Jun 13 13:35:46 <michaelni>     kierank, whats the matter all of a sudden ?
> Jun 13 13:36:04 <kierank>       look at ffmpeg, the community is falling
> apart
> Jun 13 13:36:34 <michaelni>     taking the server offline is not going to
> help the situation
> Jun 13 13:36:55 <michaelni>     everyone overreacts already
> Jun 13 13:36:57 <kierank>       i've told you for 9 months now to let vlc
> host us
> ...
> Jun 13 13:48:39 <kierank>       nobody voted for me to host
> Jun 13 13:50:25 <michaelni>     no, you generously offered it, we needed
> to move and it seemed a good choice to accept, noone objected AFAIK and
> time was rather short
> Jun 13 14:03:59 <michaelni>     also i think you know derek well, is there
> something that can be done to get him to return?
> Jun 13 14:05:38 <michaelni>     that 4month vote was very unwise as peope
> will not support it due to harshness
> Jun 13 14:17:57 <michaelni>     kierank, ^ (do you have an idea how we can
> get derek back?)
> Jun 15 21:25:25 <kierank>       my server is going down
> Jun 15 21:25:27 <kierank>       bye
> Jun 15 21:25:44 <kierank>       can't really support the insanity of this
> project atm
> Jun 15 21:36:02 <michaelni>     kierank, please explain
> Jun 15 21:37:30 *       kierank (sid5955@gateway/web/
> irccloud.com/x-alaucxykftiixsxj) has left ##ffmpeg-admin
>

You had already moved trac from this server at the time.

I helped you in an emergency in my own spare time on a Saturday. I found
the first server I could to get trac back.

It's truly incredible getting lectured from you on being a sysadmin.

Adding cc as quotes are being taken out of context here when I helped the
project in my own spare time on a Saturday in an emergency.

I will quote Anton here:

"
Behold, the favorite excuse of every tin-pot dictator ever.

So boiling down your verbal vomit, I get

    Yes, your democracy IS just pretend and I - the person who

    * tries very very hard to avoid as much human contact as possible
    * oversaw one of the most toxic FOSS communities for close
      to 25 years
    * through heavy-handed authoritarianism directly caused one of the
      most notorious forks in FOSS history

    really do know better than everyone else how to run a community.


To that I say:
* you are delusional, as you are the source or enabler of all the
  toxicity
* Libav had NONE of these problems (not saying it was perfect - it did
  have other problems, but not these)
* there is no hope for this project as long as you continue to hold the
  reins and I've wasted enough of my life on it.
"

He is absolutely spot on.

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] Previous trac server hosting Was: STF RaptorQ

[Baptiste Coudurier]

Hi

> On May 24, 2025, at 10:48 AM, Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> On Sat, 24 May 2025, 17:39 Michael Niedermayer, <michael@niedermayer.cc <mailto:michael@niedermayer.cc>>
> wrote:
> 
>> Hi
>> 
>> On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel
>> wrote:
>> [...]
>>>> As an example i could have instead replied with a tone matching yours:
>>>> (below is a (true) example of communication in the same tone as yours
>>>> that i avoid)
>>>> 
>>>> "I appreciated the stellar service you provided by providing and
>>>> hosting a trac server for FFmpeg. It had only one broken cpu core.
>>>> You only once decided to use the FFmpeg server to test some random
>>>> audio hardware.
>>>> 
>>>> Its sad that our users need reliable service"
>>>> 
>>> 
>>> You seem to forget that you contacted me in a panic because your hosting
>>> was gone. And I went into the office on a Saturday in my own time and
>> found
>>> the first server I could find and immediately set it up for you. You are
>>> very much welcome for this.
>> 
> 

[…]

> You had already moved trac from this server at the time.
> 
> I helped you in an emergency in my own spare time on a Saturday. I found
> the first server I could to get trac back.
> 
> It's truly incredible getting lectured from you on being a sysadmin.
> 
> Adding cc as quotes are being taken out of context here when I helped the
> project in my own spare time on a Saturday in an emergency.
> 
> I will quote Anton here:
> 
> "
> Behold, the favorite excuse of every tin-pot dictator ever.
> 
> So boiling down your verbal vomit, I get
> 
>    Yes, your democracy IS just pretend and I - the person who
> 
>    * tries very very hard to avoid as much human contact as possible
>    * oversaw one of the most toxic FOSS communities for close
>      to 25 years
>    * through heavy-handed authoritarianism directly caused one of the
>      most notorious forks in FOSS history
> 
>    really do know better than everyone else how to run a community.
> 
> 
> To that I say:
> * you are delusional, as you are the source or enabler of all the
>  toxicity
> * Libav had NONE of these problems (not saying it was perfect - it did
>  have other problems, but not these)
> * there is no hope for this project as long as you continue to hold the
>  reins and I've wasted enough of my life on it.
> "
> 
> He is absolutely spot on.

May I ask why you came back and are you still around the project ?

Libav failed, that’s a fact. Please stop bringing that subject into conversations.

In the last few months that I’ve on the ML, I feel that yourself have introduced a lot of toxicity as well.

— 
Baptiste Coudurier





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