- whitebox-dev - ml.whitebox.aero

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

Fwd: Meeting notes & video: Maps MR - Steps to merge & customization demo by Quinn
by Xavier Antoviaque 03 Mar '26

03 Mar '26

Forwarding to you Quinn as I don't think you are on the mailing-list - FYI. Also note that Avinash is going through an emergency medical operation, so he hasn't been able to look into your MR as planned this week. He should hopefully be back on his feet next week! And in any case I'll make sure we complete the next steps on the MR decided last week. And we can also move forward with discussing and scheduling the list of improvements you would suggest to the developer experience, as soon as you are ready to post the ticket listing them. -- Xavier Whitebox.aero <https://whitebox.aero/> On Mon, Mar 2, 2026, at 14:27, Xavier Antoviaque wrote: > Video for the demo on how to customize map styling by Quinn available at: https://www.youtube.com/watch?v=olQofyT-oqA > > > On Tue, Feb 24, 2026, at 17:47, Zoom wrote: <https://zoom.com> >> >> Meeting assets for Maps MR - Steps to merge & customization demo by Quinn are ready! >> >> Recording >> <https://us02web.zoom.us/launch/csd?origin=https%3A%2F%2Fus02web.zoom.us%2Fr…> >> Duration: 00:10:12 >> Shareable link: https://us02web.zoom.us/rec/share/gqF2FJ6bEx1HQfFMcTajyFgj7S1El1AfN5sRM3bza… >> Watch recording <https://us02web.zoom.us/launch/csd?origin=https%3A%2F%2Fus02web.zoom.us%2Fr…> Share <https://us02web.zoom.us/launch/csd?origin=https%3A%2F%2Fus02web.zoom.us%2Fr…> >> Cloud recordings will be deleted automatically after they have been stored for 90 days. >> >> >> Meeting summary >> >> >> >> Quick recap >> >> The team met to review Quinn's work on map implementation and styling, which included demonstrating how to use MapLibre and Protomaps for rendering vector maps and customizing styles through JSON files. Avinash and Milos confirmed that the map implementation looked good and was ready for merging, though they noted some remaining work on plugin changes and routing. The team agreed to merge Quinn's work to a feature branch before integrating it into the main repository, with Avinash taking the lead on coordinating the merge process. Quinn also shared his experience with developer onboarding and offered to create a ticket with suggestions for improvements to the documentation and contribution process. >> >> Next steps >> >> • Qing: Double check what's left in the current merge request, close any remaining issues, and update the target branch to a feature branch for further collaboration. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Avinash: Handle creation and coordination of the feature branch, and work with Qing to merge the plugin and related changes into the feature branch. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Avinash: Take on the remaining plugin changes, including investigating and implementing a solution for the proxy/hostname issue, starting in the coming sprint. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Qing: Update the README with instructions on how the GeoJSON files for country borders were generated. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Qing: Open a ticket listing suggestions for improving developer onboarding and documentation, based on recent experience, and discuss with the team in the ticket. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Team (Avinash/Miloш): Review and approve the merge request(s) in the next few days after Qing's final checks. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> • Qing: (Optional, if needed) Provide support or feedback to Avinash/Miloш on any remaining scripting bugs or improvements found during further work. <https://us02tasks.zoom.us?meetingId=vEGFdsaaTZm5o9mFH3tHHQ%3D%3D&stepId=575…> >> Summary >> >> Merge Request Review and Setup >> >> The team discussed the status of a merge request review, with Quinn demonstrating the setup and testing of a new machine for map data processing. Xavier encouraged the team to review any outstanding issues from the merge request before dividing the remaining work between Avinash and Miloš. Quinn also offered to show the team how to customize the theme and styling of the maps, though this portion of the meeting was not recorded. >> >> Map Plugin Merge Discussion >> >> The team discussed merging a map plugin and associated changes. Avinash reviewed the demo and found it mostly complete, with only minor issues to address in the coming sprint. Qing and Miloš agreed to merge the plugin first, followed by the main changes. They discussed the need to document routing and hostname configurations. Avinash and Qing also reviewed the country border data and agreed to update the README with instructions for generating GeoJSON files. >> >> Map Styling and Code Merging >> >> The team discussed merging code to a feature branch to keep the master branch clean, with Avinash and Miloš taking on the remaining work. Qing demonstrated how to use Maputnik to style maps, including changing colors, adjusting contour lines, and modifying elevation data. They agreed to have a follow-up workshop on map styling, which Xavier offered to record. >> >> Protomaps Map Rendering System Demo >> >> Quinn demonstrated a new map rendering system using Protomaps and MapLibra, which allows for flexible styling and dynamic style changes. Miloš asked questions about the system's functionality, including how it handles data and styles, and Quinn explained the components and their interactions. Xavier suggested improving developer onboarding for contributing to Whitebox, and Quinn agreed to review documentation and provide suggestions. They decided to create a ticket to discuss developer experience improvements. >> >> >> >> AI can make mistakes. Review for accuracy. >> >> Please rate the accuracy of this summary. feedback good <https://us02web.zoom.us/meeting/summary/feedback?meetingId=vEGFdsaaTZm5o9mF…> feedback bad <https://us02web.zoom.us/meeting/summary/feedback?meetingId=vEGFdsaaTZm5o9mF…> >> Edit summary <https://us02web.zoom.us/launch/csd?origin=https%3A%2F%2Fus02web.zoom.us%2Fu…> >> >> Thank you, >> Zoom Support Team >> https://support.zoom.us >> LinkedIn <https://www.linkedin.com/company/zoom/> >> X <https://twitter.com/zoom> >> Instagram <https://instagram.com/zoom> >> Facebook <https://www.facebook.com/zoom> >> YouTube <https://www.youtube.com/@Zoom> >> Blog <https://blog.zoom.us/> >> Zoom.com <https://zoom.com> 55 Almaden Blvd >> San Jose, CA 95113 <https://www.google.com/maps/place/55+Almaden+Blvd,+San+Jose,+CA+95113/@37.3…> >> +1.888.799.9666 <tel:1-888-799-9666> >> >> © 2026 Zoom Communications, Inc. >> >

1 0

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

03 Mar '26

Hi, #499 - https://gitlab.com/whitebox-aero/whitebox/-/issues/499 Ready for review, and also for preview :D #479 - https://gitlab.com/whitebox-aero/whitebox/-/issues/479 Started working on this

1 0

Alpha2 - Retro recap
by Xavier Antoviaque 02 Mar '26

02 Mar '26

*_Alpha2 Sprint_* Based on the retro discussion from last Tuesday <https://app.fireflies.ai/view/Sprint-planning-retro-Whitebox::01KJ30GX4P8PY…> _What went well:_ • Planning, allowed to know where we stood, and adapt to deliver on time (even though it was a rush) • Whitebox *became a product* during alpha2, the streaming in particular is a useful new function that works • Software reliable to complete & record a flight despite issues & bugs (eg switch from tablet to phone) • *Almost* all the tickets done on time for the flight _To improve:_ • Milos not to try to complete many tickets at once • We need to finish future releases without a rush or having to cut stuff • In particular, we need to have the release candidate to test earlier => 1 ticket for testing the release candidate 2 weeks before the release itself, to have time to fix issues before the flight _LLM summary:_ Positive outcomes from Alpha 2 planning and platform development (48:53) • Avinash praised the detailed planning that enhanced focus and efficiency, calling it a personal breakthrough. • Miloш noted how White Box evolved from a toy to a useful product, motivating the team with real-world interest from flight schools. • Xavier emphasized the platform’s emerging reliability, with successful streaming on mobile despite rough edges. • The team acknowledged that most issues were manageable without huge refactors, validating the architecture’s soundness. Recognition of milestone delivery and schedule adherence (55:56) • Xavier highlighted that most Alpha 2 tickets were completed on time, a notable improvement over previous cycles. • Avinash shared that Alpha 3 planning intentionally schedules heavier refactoring tasks early to avoid last-minute rushes. • The team agreed this approach helps maintain steady progress and reduces end-of-cycle pressure. Identified workflow improvements for Alpha 3 (57:23) • Miloш recognized the need to avoid juggling too many tickets simultaneously and return to isolated, focused commits. • Xavier encouraged embracing small, continuous workflow improvements for sustained progress. • Miloш felt this change would bring peace and better compatibility with Alpha 3’s planned work style. Testing timeline improvements and release candidate strategy (58:38) • Xavier stressed the need to have a stable release candidate ready two sprints before flight tests for early validation. • Miloш agreed that earlier testing would reduce anxiety and improve issue detection but noted differing workflows. • Xavier requested a ticket to formalize early testing and emphasized preparing a useful, stable version for meaningful feedback. • The team concurred that the last two sprints should focus on polishing and testing, minimizing new feature development. -- Xavier Whitebox.aero <https://whitebox.aero/>

1 0