March 2026 - whitebox-dev - ml.whitebox.aero

Re: Setting resetting on its own?
by Xavier Antoviaque 10 Mar '26

10 Mar '26

Unfortunately we need to be able to include others in discussions we hold on the mailing-list, and have their emails appear on the mailing-list. So discarding those emails isn't going to work for us. :/ If you are worried about spam, we had those posts going through the moderation queue, and we were filtering out the few spams by hand. Could you consider allowing at least that option, if not the approval by default? If this isn't possible, we will unfortunately need to cancel our plan and migrate. :/ Which would be huge pain, especially without advance warning - maybe you could give us time to migrate before enforcing this option? -- Xavier Whitebox.aero <https://whitebox.aero/> On Tue, Mar 10, 2026, at 12:24, MailmanLists Support wrote: > --------- Original message ------------------ > Received: 2026-03-10 08:52 UTC > From: Xavier Antoviaque <xavier(a)whitebox.aero> > For: Mailmanlists Support <support(a)mailmanlists.net> > Subject: RE: Setting resetting on its own? > >> Hi, >> >> I am experiencing issues with one of the settings on our mailing list (dev(a)ml.whitebox.aero) hosted on your services. When I try to set this setting to anything else, it just reverts to "Discard": >> This is very disruptive for us, as we have threads that include non-members, and their emails are silently discarded - which is problematic and very confusing to everyone. Could you fix that? We need anyone to be able to write on the mailing-list, preferrably accepting them immediately rather than going through the moderation queue, which can take time to be processed. >> >> -- >> Xavier >> Whitebox.aero <https://whitebox.aero/> >> > > Hi Xavier, > > Users must be subscribed to a list (be a member) for their posts to be > accepted. Posts from non-members are discarded. > > The default for members is their posts are accepted without moderation. > > It is a recently added policy on all lists. It's purpose is to assist > in reducing the number of unwanted emails that members receive. > Complaints of unwanted email lead to the server getting blacklisted. > > See: FAQ What settings are enforced on all lists? - > https://mailmanlists.net/en/faq/07 > > Regards, > > Mark > > MailmanLists Support > support(a)mailmanlists.net > Tel: +61 2 7255 9924 > Sydney, Australia (UTC +10:00)

1 0

Setting resetting on its own?
by Xavier Antoviaque 10 Mar '26

10 Mar '26

Hi, I am experiencing issues with one of the settings on our mailing list (dev(a)ml.whitebox.aero) hosted on your services. When I try to set this setting to anything else, it just reverts to "Discard": This is very disruptive for us, as we have threads that include non-members, and their emails are silently discarded - which is problematic and very confusing to everyone. Could you fix that? We need anyone to be able to write on the mailing-list, preferrably accepting them immediately rather than going through the moderation queue, which can take time to be processed. -- Xavier Whitebox.aero <https://whitebox.aero/>

1 0

[update] 2026-03-09
by milos＠whitebox.aero 09 Mar '26

09 Mar '26

R2D2's *beep boop*, #525 - https://gitlab.com/whitebox-aero/whitebox/-/work_items/525 Ready for review, M.2 vendor agnostic Tried doing a Vulkan helloworld on the OPi but I've had issues getting it up, details in the Vulkan-related thread

1 0

Re: FFmpeg v360 Vulkan filter development
by milos＠whitebox.aero 09 Mar '26

09 Mar '26

Hey Lynne, Your emails should go through instantly now. I've tried running that filter, but I couldn't get it working, neither as part of our current pipeline, nor standalone (using only the filter from your sample). Pasted my results here: https://gitlab.com/whitebox-aero/whitebox/-/snippets/5967510 I see that Vulkan has had considerable driver improvements in kernel 6.13, and we're currently running on 6.1 - would upgrading be a requirement to running this (whether Vulkan, or the latest FFmpeg version in some way)? I'll try to get up to speed with the driver replacements later this week to verify that as well. @Xavier @Avinash Does any of this ring any bells, have you maybe tried using Vulkan on OPi before? It seems there's also Armbian for Orange Pi 5 Plus, but they ship it with 6.1 and 6.11, so I guess that wouldn't really bring benefits here On 6. 3. 2026. 16:43, milos(a)whitebox.aero wrote: > Hey, I did receive it on my email, so I assume the ML also got it, but > I think it requires approval to be posted on there. I don't have > access to that, so when Xavier comes around he'll do it. I've sent him > an email. I could technically just reply to your email here, but I > think that'd open a new thread. > > Also thank you for the test instructions! I'll run them over the > weekend and let you know how it went > > On 6. 3. 2026. 14:51, Lynne wrote: >> Was my reply received? I don't see it on the ML. >> >> On 06/03/2026 13:28, Lynne wrote: >>> Hi all, >>> >>> Certainly, a Vulkan version would likely speed the pipeline up. GPUs >>> are good at interpolating, and very large amount of the time spent >>> on the CPU version of the filter is spent doing that. >>> >>> Would you be able to test whether Vulkan is setup correctly? Try >>> adding: >>> `hwupload,avgblur_vulkan=planes=0,hwdownload,format=yuv420p` >>> after the v360 filter. The output should not change, and the >>> slowdown shouldn't be too significant. >>> You need to use current git master of FFmpeg, not any release branch. >>> >>> I highly suggest using the panfrost Vulkan drivers from Mesa, rather >>> than some outdated vendor-provided inactively developed drivers. >>> They support RK3588, but you'll need to look into how to enable them >>> (they require using the mainline kernel panfrost module, rather than >>> mali). >>> >>> The previous work done by Paul isn't really helpful, as we're >>> currently rewriting all the Vulkan codecs and filters to >>> compile-time SPIR-V in order to eliminate dependencies on large >>> external libraries, and to speed up the code with offline >>> optimizations. >>> I'd be interested in being contracted to write a modern Vulkan >>> filter with enough capabilities for your particular use-case, if you >>> agree. >>> >>> On 06/03/2026 12:37, milos(a)whitebox.aero wrote: >>>> Hey Lynne, >>>> >>>> Adding our conversation from IRC: >>>> >>>>> <libmilos-so> Hello Lynne, I'm Milos, contributor to https:// >>>>> whitebox.aero . We're looking for a FFmpeg developer for >>>>> assistance with filter development, and Paul B Mahol gave us your >>>>> contact as an expert in Vulkan development. We are building an >>>>> SBC-based device which needs to run the v360 filter on it, however >>>>> the CPU filter's performance is starting to be our bottleneck, and >>>>> we're looking to explore a GPU-based approach to it. Paul started >>>>> working on `v360_{opencl,vulkan}` filters a while back, but it >>>>> wasn't finished, and the `libavfilter` has changed since, >>>>> requiring more development to get them working. Here's a link to >>>>> the mailing list's previous discussion: >>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2024- June/330229.html >>>>> >>>>> >>>>> <libmilos-so> Our use case is to convert dual-fisheye videos to >>>>> equirectangular in real time, we're basically only doing this for >>>>> now: `v360=dfisheye:e:ih_fov=193:iv_fov=193` >>>>> >>>>> <libmilos-so> Currently we are running it for a single video feed, >>>>> but we're close to hitting resource limits. As we'd like to extend >>>>> to multiple videos, we think that GPU-based acceleration would >>>>> provide us the performance improvement we need. Considering your >>>>> FFmpeg expertise, we were wondering if you'd be interested for >>>>> contracting to help us get this implemented for our use case? >>>>> Our mailing list is at https://ml.whitebox.aero, and if that'd be >>>>> alright with you, I'd like to copy the contents of this >>>>> conversation to the mailing list later. If you're interested in >>>>> the contractual work, it'd be great if we could then continue the >>>>> conversation on the mailing list to keep the team in the loop >>>>> >>>>> <libmilos-so> Thanks! >>>>> >>>>> <Lynne> sure, I'd be happy to help >>>>> >>>>> <libmilos-so> Thanks! Could you give me your email address and >>>>> I'll cc you on the thread? >>>>> >>>>> <Lynne> the filter which paul wrote years ago needs quite a bit of >>>>> work, since currently we're rewriting all vulkan filters to >>>>> compile- time spir-v generation >>>>> >>>>> <Lynne> sure, [redacted] >>>>> >>>> For context, we are taking H.264/H.265 dual-fisheye videos from >>>> Insta360 cameras, both from live feeds, and when recorded from file >>>> recordings, and processing them using FFmpeg to produce >>>> equirectangular videos which would then be suitable for playback in >>>> browsers. We are currently using Pannellum player for this, given >>>> our current equirectangular format. If there are more efficient >>>> options on the backend side to achieve the same effect, we're open >>>> to exploring those as well, although frontend clients would also be >>>> phones and tablets, so no heavy operations should take place on them. >>>> >>>> We are currently developing on RK3588 (on Orange Pi 5 Plus), which >>>> by the documentation supports OpenCL 2.2 and Vulkan 1.2. It has >>>> H.264 and H.265 hardware encoders and decoders, which we've tried >>>> using, but v360 filter ended up being the biggest bottleneck. >>>> >>>> Here's one example of how we're currently using this filter: >>>> >>>>> return [ >>>>> "ffmpeg",# Decoder settings "-fflags","+genpts+discardcorrupt", >>>>> "-flags","low_delay", >>>>> >>>>> "-f","h264", >>>>> "-i","pipe:0",# input from stdin "-r","30", >>>>> >>>>> # Filter settings "-filter_complex", >>>>> f"[0:v]scale=1440:720,v360=dfisheye:e:ih_fov=193:iv_fov=193[out]", >>>>> "-map","[out]", >>>>> >>>>> # Encoder settings "-c:v","libx264", >>>>> "-preset","ultrafast", >>>>> "-tune","zerolatency", >>>>> "-pix_fmt","yuv420p", >>>>> "-profile:v","main", >>>>> "-level","3.1", >>>>> >>>>> # Bitrate settings # This ensures that keyframes are pushed >>>>> frequently enough to keep the # streaming latency low "-g","30",# >>>>> keyframe interval "-keyint_min","30",# minimum keyframe interval >>>>> "- sc_threshold","0",# disable scene change detection >>>>> "-muxpreload","0", >>>>> "-muxdelay","0", >>>>> >>>>> "-f","flv",# output format "-rtmp_live","live", >>>>> >>>>> # e.g.: rtmp://srs-dev/live/livestream output_target, >>>>> ] >>>> >>>> By my understanding, we likely need a GPU-based v360 filter as a >>>> drop- in replacement for the standard CPU-based v360. I think that >>>> the GPU- based filters would also require >>>> `hwupload`/`hwdownload`(?), but I don't have experience with it. >>>> Personally I'm new to FFmpeg, so feel free to correct me if >>>> something sounds off. >>>> >>>> The code would ideally be released under a copyleft license, I'll >>>> let Xavier pitch in on this. >>>> >>>> Does this sound like a proper approach to it and something that'd >>>> be interesting for you to work on? >>>> >>>> Thanks! >>>> >>> >>

1 0

[update] 2026-03-06~08
by milos＠whitebox.aero 09 Mar '26

09 Mar '26

Heya, !224 - https://gitlab.com/whitebox-aero/whitebox/-/merge_requests/224 Merged #479 - https://gitlab.com/whitebox-aero/whitebox/-/work_items/479 Ready for review #525 - https://gitlab.com/whitebox-aero/whitebox/-/work_items/525 Almost done with a possible fix, investigation details in ticket I've reached out to Lynne, conversation is in another thread. Need to run some tests to verify Vulkan works as intended on Orange Pi and will then get back with info

1 0

[update] 2026-02-05
by milos＠whitebox.aero 06 Mar '26

06 Mar '26

Heya, #503 - https://gitlab.com/whitebox-aero/whitebox/-/issues/503 Post-review: reworked implementation of model inheritance and reference, refactored kernel API usages across all plugins

1 0

FFmpeg v360 Vulkan filter development
by milos＠whitebox.aero 06 Mar '26

06 Mar '26

Hey Lynne, Adding our conversation from IRC: > <libmilos-so> Hello Lynne, I'm Milos, contributor to > https://whitebox.aero . We're looking for a FFmpeg developer for > assistance with filter development, and Paul B Mahol gave us your > contact as an expert in Vulkan development. We are building an > SBC-based device which needs to run the v360 filter on it, however the > CPU filter's performance is starting to be our bottleneck, and we're > looking to explore a GPU-based approach to it. Paul started working on > `v360_{opencl,vulkan}` filters a while back, but it wasn't finished, > and the `libavfilter` has changed since, requiring more development to > get them working. Here's a link to the mailing list's previous > discussion: > https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/330229.html > > > <libmilos-so> Our use case is to convert dual-fisheye videos to > equirectangular in real time, we're basically only doing this for now: > `v360=dfisheye:e:ih_fov=193:iv_fov=193` > > <libmilos-so> Currently we are running it for a single video feed, but > we're close to hitting resource limits. As we'd like to extend to > multiple videos, we think that GPU-based acceleration would provide us > the performance improvement we need. Considering your FFmpeg > expertise, we were wondering if you'd be interested for contracting to > help us get this implemented for our use case? > Our mailing list is at https://ml.whitebox.aero, and if that'd be > alright with you, I'd like to copy the contents of this conversation > to the mailing list later. If you're interested in the contractual > work, it'd be great if we could then continue the conversation on the > mailing list to keep the team in the loop > > <libmilos-so> Thanks! > > <Lynne> sure, I'd be happy to help > > <libmilos-so> Thanks! Could you give me your email address and I'll cc > you on the thread? > > <Lynne> the filter which paul wrote years ago needs quite a bit of > work, since currently we're rewriting all vulkan filters to > compile-time spir-v generation > > <Lynne> sure, [redacted] > For context, we are taking H.264/H.265 dual-fisheye videos from Insta360 cameras, both from live feeds, and when recorded from file recordings, and processing them using FFmpeg to produce equirectangular videos which would then be suitable for playback in browsers. We are currently using Pannellum player for this, given our current equirectangular format. If there are more efficient options on the backend side to achieve the same effect, we're open to exploring those as well, although frontend clients would also be phones and tablets, so no heavy operations should take place on them. We are currently developing on RK3588 (on Orange Pi 5 Plus), which by the documentation supports OpenCL 2.2 and Vulkan 1.2. It has H.264 and H.265 hardware encoders and decoders, which we've tried using, but v360 filter ended up being the biggest bottleneck. Here's one example of how we're currently using this filter: > return [ > "ffmpeg",# Decoder settings "-fflags","+genpts+discardcorrupt", > "-flags","low_delay", > > "-f","h264", > "-i","pipe:0",# input from stdin "-r","30", > > # Filter settings "-filter_complex", > f"[0:v]scale=1440:720,v360=dfisheye:e:ih_fov=193:iv_fov=193[out]", > "-map","[out]", > > # Encoder settings "-c:v","libx264", > "-preset","ultrafast", > "-tune","zerolatency", > "-pix_fmt","yuv420p", > "-profile:v","main", > "-level","3.1", > > # Bitrate settings # This ensures that keyframes are pushed frequently > enough to keep the # streaming latency low "-g","30",# keyframe interval "-keyint_min","30",# minimum keyframe interval "-sc_threshold","0",# disable scene change detection "-muxpreload","0", > "-muxdelay","0", > > "-f","flv",# output format "-rtmp_live","live", > > # e.g.: rtmp://srs-dev/live/livestream output_target, > ] By my understanding, we likely need a GPU-based v360 filter as a drop-in replacement for the standard CPU-based v360. I think that the GPU-based filters would also require `hwupload`/`hwdownload`(?), but I don't have experience with it. Personally I'm new to FFmpeg, so feel free to correct me if something sounds off. The code would ideally be released under a copyleft license, I'll let Xavier pitch in on this. Does this sound like a proper approach to it and something that'd be interesting for you to work on? Thanks!

1 0

[update] 2026-03-04
by milos＠whitebox.aero 05 Mar '26

05 Mar '26

Heya, #503 - https://gitlab.com/whitebox-aero/whitebox/-/issues/503 Investigated possible solutions to review comments, pushing updates today

1 0

Fwd: Your meeting recap - Sprint planning & retro - Whitebox
by Xavier Antoviaque 04 Mar '26

04 Mar '26

> <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> > Xavier Antoviaque > > (antoviaque(a)gmail.com) > invited Fireflies to your meeting > > To record and take notes > > > Sprint planning & retro - Whitebox > > Mar 3rd at 4:00 PM CET > > > View meeting recap <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> > > > In this meeting > > 31+ Questions were asked > 12+ Action items detected > 21+ Dates & times discussed > Discussed in this meeting > Django model inheritance <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> Alpha 3 planning <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> playback synchronization <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> +3 more <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> > > See more insights <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> > > Meeting Overview > • Routing and URL Parameters: Postponed complex routing for plugins until after Alpha 3 to maintain focus on the current release. > > • Playback Sync Issues: UI imprecision causes perceived video offsets; detailed fixes deferred to Alpha 4 to prevent scope expansion. > > • Network Security Enhancements: Proposing default-deny policies at Ed Snow network level to increase security against accidental exposure. > > • IP Management Automation: Improved VM IP assignment stability with custom scripts, enhancing reliability for GitLab CI deployments. > > • Django Model Complexity: Introduced dynamic model patterns; balancing functionality with developer onboarding needs remains a priority. > > • Library Maintenance Assurance: Django import-export library confirmed well-maintained; adoption planned cautiously to mitigate integration risks. > > View complete meeting notes <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJN19WTBGDK…> > <https://app.fireflies.ai/agents?utm_content=voice-agents&utm_campaign=meeti…> > Supercharge your > meetings with AI Assistant > > Record > > Just invite Fireflies secure Notetaker to your meetings for seamless recording. > > Transcribe > > Easily transcribe your live meetings or media files that you can upload. > > Summarize > > Instantly get meeting overview, outline, bullet-point notes, action items and more. > > Analyze > > Understand your meetings better with conversation intelligence. > > Smart Search > > Search across meetings or transcript, action items, and other important highlights. > > Collaborate > > Comment or mark specific parts in meetings to quickly collaborate with teammates. > > Get AI meeting assistant <https://app.fireflies.ai/login?utm_content=features_cta&utm_campaign=meetin…> > > > How Fireflies works > > Sign up and invite fred(a)fireflies.ai > > Fireflies.ai Notetaker joins > the meeting > > Captures and transcribes > the meeting > > Sign up for free <https://app.fireflies.ai/login?utm_content=how_fireflies_works&utm_campaign…> > Learn more <https://fireflies.ai/?utm_content=how_fireflies_works&utm_campaign=meeting-…> > > > > > Meeting notes taken on behalf of antoviaque(a)gmail.com > > To stop receiving email notifications like this, click here to unsubscribe. <https://api.firefliesapp.com/notifications/unsubscribe> > > DATA SECURITY & POLICY <https://guide.fireflies.ai/hc/en-us/articles/360020097537-Policy-on-Keeping…> > > > Fireflies.ai • 5424 Sunol Blvd , Ste 10-531 Pleasanton, CA 94566 > > Privacy Policy <https://fireflies.ai/privacy_policy.pdf> • Terms of Service <https://fireflies.ai/terms-of-service.pdf> > > -- Xavier Whitebox.aero <https://whitebox.aero/>

1 0

ffmpeg's v360 hardware filters
by Milos 03 Mar '26

03 Mar '26

Hey, I've asked Paul about the `v360` hardware-accelerated FFmpeg filters, thread below. He referred me to Lynne @ #ffmpeg-devel on Libera, to ask about the possible Vulkan implementation. I'll get in touch soon and update ============ Forwarded message ============ From: Paul B Mahol < mailto:onemda@gmail.com > To: "Milos"< mailto:milos@whitebox.aero > Cc: "xavier"< mailto:xavier@whitebox.aero > Date: Sat, 24 Jan 2026 13:51:52 +0100 Subject: Re: ffmpeg's v360 hardware filters ============ Forwarded message ============ Hi, I have had only half-finished but working OpenCL filter version of v360 for ffmpeg/libavfilter. I need to recheck if I still have source code of vf_v360_opencl.c and related files/changes still somewhere. The Vulkan version never was really functional like OpenCL version is, and if you want Vulkan version better contact Vulkan expert(s) at FFmpeg. At least over IRC channel, #ffmpeg-devel on libera IRC servers, by IRC nick name Lynne. I'm not working on Vulkan stack so I do not have all necessary skills for very optimal filter implementation, moved to do other stuff instead. The old Vulkan WIP patch was here, which was then tested on old integrated Intel GPU: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265057.html But Vulkan API is changing and FFmpeg related support code too, so it needs more work, and more other transforms needs to be implemented for other projections in v360 vulkan filter... Regards On Sat, Jan 24, 2026 at 12:07 PM Milos < mailto:milos@whitebox.aero > wrote: Hello Paul, I'm working on a project utilizing the ffmpeg's v360 filter and we're looking into ways to accelerate it. We found your messages on ffmpeg-devel's mailing list: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/330229.html , and I was wondering if you'd be willing to share the patches for us to try them out. You can check the project out here: https://docs.whitebox.aero If that's alright, we'd like to try them out, and, considering your ffmpeg expertise, potentially contract you for some help getting it running / merged upstream if you'd be willing to help. Looking forward to hearing from you. Thanks! Milos

3 3