01:04 <jbennett1> Hey, wondering if any of the core devs would be interested in coming on FLOSS Weekly. Who should I get in touch with?

01:09 <BtbN> best ask over in -devel or on the ML. Not everyone is in here.

01:11 <jbennett1> Copy that

01:57 <Deihmos> I previously used this command /usr/bin/ffmpeg -hide_banner -loglevel error -fflags +discardcorrupt -i pipe:0 -c copy -f mpegts pipe:1 but since the system updated to version 7.1-3 it no longer works.

02:12 <Deihmos> nevermind

14:19 <^Neo> Looking at udp.c, I'm a bit confused about its support for IGMPv3 joining of ssm multicast traffic. Passing in sources via the address line looks like the proper setsocketopts are called, but ffmpeg.c doesn't seem to by default handle data if there are multiple sources sending mpegts traffic to the same multicast group... this article (https://flussonic.com/doc/standby-mode-of-multicast-pusher/) suggests that an application needs to have a configured timeout

14:19 <^Neo> and then join source groups based on the presence of multicast traffic from that source

15:17 <DeHackEd> I'm using igmpv3... we just use udp://232.1.2.3:4567?sources=10.1.1.5 and it works

15:18 <DeHackEd> typically the switch does the filtering, but if you were to run multiple instances it could get jumbled. udp.c does have a filter to confirm the packets it receives are on the allow list for that particular input

15:22 <^Neo> Right, it works for a single source perfectly, but `sources` can have multiple unicast IP's listed, and the idea that I was hoping would work is that there's an ordered mechanism where if source A is down it'd start getting source B, but to me, that's not how any sort of application works. Really you'd have to follow what the website I linked states and have some sort of timeout that you would join source A, and when the application stops seeing packets from

15:22 <^Neo> source A, switch to source B by performing a multicast SSM join with source B's address.

15:23 <^Neo> > source A is down it'd start getting _data_ from source B _automatically

15:24 <DeHackEd> that's not how it's implemented, no. you could implement it yourself with 2 instances of the udp thing, each on a different source

15:25 <DeHackEd> honestly I'm not sure how multiple sources are intended to be applied in ffmpeg

15:25 <^Neo> oh I've tested it, it just gets mashed together to something undecodable

15:25 <^Neo> well, not really undecodable, but just corrupted

15:26 <^Neo> but yeah, I think it's a fundamental misunderstanding of how IGMPv3 is supposed to work on my part

15:29 <^Neo> IGMPv3 switches will do the filtering based on the source unicast IP but if there are multiple IP's listed, it's not like there's a redundancy layer there, it's just going to forward everything downstream, which to me is a bit of a limitation with the technology I guess? if I'm using the same multicast group IP for 2 senders, hoping that with IGMPv3 I'll be able to seamless pull from 1 or the other depending on upstream availability, it seems like that sort

15:29 <^Neo> of logic is more application/business logic based

15:29 <^Neo> I was just hoping "the network" would figure it out :)

15:36 <DeHackEd> my point is, it works, but the only situation I can imagine using it is with only 1 IP in the sources list.

15:39 <^Neo> Yeah I agree