From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] STF RaptorQ Date: Fri, 23 May 2025 11:45:14 +0200 Message-ID: <20250523094514.GW29660@pb2> (raw) In-Reply-To: <CAHGibzGhTePabJygyVHmHwMSwKzVoEg5QrizDwye1q21BJBRtA@mail.gmail.com> [-- 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".
next prev parent reply other threads:[~2025-05-23 9:45 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-05-22 23:42 Kieran Kunhya via ffmpeg-devel 2025-05-22 23:55 ` Devin Heitmueller 2025-05-23 3:48 ` Lynne 2025-05-23 14:37 ` Devin Heitmueller 2025-05-23 9:45 ` Michael Niedermayer [this message] 2025-05-23 9:58 ` Michael Niedermayer 2025-05-23 11:25 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 14:57 ` Devin Heitmueller 2025-05-23 15:59 ` Michael Niedermayer 2025-05-23 11:32 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 16:24 ` Tristan Matthews via ffmpeg-devel 2025-05-23 14:50 ` Devin Heitmueller 2025-05-23 15:00 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 15:45 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 20:35 ` Michael Niedermayer 2025-05-23 21:45 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 16:04 ` Michael Niedermayer 2025-05-23 3:44 ` Lynne 2025-05-23 6:50 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 9:53 ` Lynne 2025-05-23 7:51 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 11:33 ` Michael Niedermayer 2025-05-23 12:13 ` Kieran Kunhya via ffmpeg-devel 2025-05-23 14:43 ` Michael Niedermayer 2025-05-24 16:39 ` [FFmpeg-devel] Previous trac server hosting Was: " Michael Niedermayer 2025-05-24 17:48 ` Kieran Kunhya via ffmpeg-devel 2025-06-02 4:29 ` Baptiste Coudurier 2025-05-23 14:58 ` [FFmpeg-devel] " Kieran Kunhya via ffmpeg-devel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20250523094514.GW29660@pb2 \ --to=michael@niedermayer.cc \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git