Explore Projects

<p>The goal of this project is to contribute to the development of the rav1e AV1 video encoder, through work on rate-distortion optimization (RDO) in areas of the encoder where it is not yet (fully) implemented, such as contribution to missing prediction modes or improvements to rate estimation methods, depending on the project state and immediate needs at the start of the project period.</p>

<p>With VLC’s version 3.0, a major feature is the renderer API.This api makes it possible to create modules such as the new chromecast module that allows a user to cast arbitrary media to a chromecast enabled device. There is a clear use-case for the same functionality for the AirPlay and ROAP protocols.</p>

The project aims to enhance VLC by introducing support for WebAssembly (Wasm) plugins, paving the way for a potential replacement of the current Lua scripting functionality in the future. This endeavour involves the development of a Wasm Plugin Manager within VLC, allowing for the utilisation of plugins written in various languages that support Wasm compilation. By introducing this feature, VLC users will have the flexibility to create plugins in their preferred programming languages, streamlining the plugin development process and expanding VLC's capabilities. While the Lua scripting system will remain in place for now, this project lays the groundwork for a potential transition to Wasm-based plugins in the future, offering users even more options for customization and extension of VLC's functionality.

Radio-Browser is a community-driven database that provides as many internet radio and TV stations as possible for end-users to quickly lookup. Per https://www.radio-browser.info/users, there are plenty of apps using these API services. By implementing this project into the VLC player, users can easily find and listen to online radio on the VLC player. Inspired by https://wiki.videolan.org/SoC_2024/#Radio-Browser_integation.

<p>project involve adding new transformations to spirv-fuzz tools to improve their support for compute shaders</p>

<p>The objective of this project would be to write Vulkan Apps that demonstrate some part/combination of the Vulkan API that is not already covered by the Sascha-Willems Demos, the Khronos Samples, the Google Test Apps or the Imagination demos.</p>

This proposal aims to improve the developer experience of using VLC in Unity. Right now, developers have to write extra boilerplate code and use raw strings just to play a video and configure settings instead of using standard Unity tools. I plan to change this manual setup into a simple plug and play experience. To achieve this, I will integrate standard Unity features like the Package Manager and ScriptableObjects for visual menus. I will also add useful features like video preloading, a playlist API, unified logging, and better demo scenes. Overall, this proposal aims to make the plugin much easier to use and reduce setup errors, which will encourage more developers to choose VLC for their projects.

In this GSoC project, I worked on developing a multimedia processing system, focusing on commercial detection and replacement using deep learning. I have developed a real-time, efficient solution that enhances media consumption experiences by seamlessly integrating custom audio streams during commercial breaks.

The goal of this project is to improve the tooling surrounding embedded machine learning on the BeagleBone Black(BBB)/Bela to aid its community in experimenting with machine learning applications for their projects. The specific developer tools chosen for this project are an inference benchmarking tool as well as a perf-based profiler developed for the BBB/Bela platform.

<p>This project aims at the development of a hardware mixer block in the HDMI2USB firmware which can implement mixing of the two input pixel stream as per the mask information. This suitable mask can be varied dynamically to create fading and wipe effects using the hardware block at a given pixel rate.</p>

<p>While the BeagleBone family has a large number of pins available on their P8/P9 headers, projects requiring a large amount of GPIO I/O may still be infeasible due to pinmux conflicts with other interfaces (SPI, UARTs, etc.). The newer PocketBeagle platform is even more restricted in the number of available GPIOs for interfacing. In addition, bi-directional bus communication using GPIOs is infeasible, as each GPIO is configured for either input or output. This project will combine your hardware and software skills to address these limitations by creating a shift register-based hardware design that will allow serial streams of data going in/out of the PocketBeagle or BeagleBone family GPIOs to be mapped into a bi-directional communications bus</p>

The objective is to enhance the Beagle-Tester framework for BeagleBoard devices by adding mikroBUS support and updating it for mainline kernel testing. This project aims to develop an automated regression test suite for Linux kernel on BeagleBoard hardware, enabling continuous validation within the OpenBeagle CI server. The approach includes developing comprehensive test cases for interfaces such as PWM, ADC, UART, I2C, SPI, and GPIO, integrating automated power cycling capabilities for test farms, building a web interface for real-time monitoring of test results, and optimizing the framework for seamless Buildroot deployment. Key deliverables include an enhanced Beagle-Tester with mikroBUS support, an automated regression testing framework for kernel updates, a GitLab CI pipeline for weekly testing, a modular test farm design with power cycling capabilities, a web-based monitoring interface, and comprehensive documentation with tutorials.

The Greybus module for Zephyr currently exists as an out-of-tree component, making maintenance, testing, and contributions difficult. This project aims to upstream Greybus as an official Zephyr module, improving maintainability, accessibility, and seamless integration within the Zephyr RTOS ecosystem. By upstreaming Greybus, BeagleConnect and other Greybus-enabled platforms will gain native support in Zephyr, removing the need for custom patches or kernel modifications. Originally developed by Google as part of Project Ara, Greybus is a lightweight, high-speed protocol designed for efficient, low-power communication across diverse hardware interfaces. While initially intended for modular smartphones, Greybus has since expanded into IoT and industrial applications, particularly in wireless sensor networks. This project will focus on cleaning up and refactoring the existing Greybus module, revamping its testing infrastructure, and ensuring compatibility with Zephyr’s CI/CD workflows. The successful completion of this work will enable seamless hardware-software interaction, making Greybus more accessible for embedded systems development within Zephyr.

Current SoCs frequently feature heterogeneous remote processor units in asymmetric multiprocessing (AMP) setups, which may be running several Linux or other real-time OS instances. One such SoC is TDA4VM, with heterogeneous multicore support it can run multiple operating systems simultaneously. TDA4VM has Dual 64-bit Arm® Cortex®-A72 microprocessor subsystem at up to 2.0 GHz, Six Arm® Cortex®-R5F MCUs at up to 1.0 GHz, Two C66x floating point DSP, up to 1.35 GHz, 40 GFLOPS, 160 GOPS and 3D GPU PowerVR® Rogue 8XE GE8430, up to 750 MHz, 96 GFLOPS, 6 Gpix/sec. Zephyr is a small real-time operating system for connected, resource-constrained and embedded devices supporting multiple architectures. Zephyr allows for easy handling of multiple configuration options, APIs and external components, and is well suited to structured application development. Another benefit of Zephyr is that it targets some very serious protocol and standard implementations, being e.g. the first open source RTOS to introduce TSN support – by way of Antmicro’s contribution. The rising popularity of TSN in automotive and aerospace applications, and just about everywhere else, could be a very important reason to start using Zephyr in your TSN-capable product. The goal of the project is to add Zephyr RTOS support to run on Cortex R5 processor core loaded from A72 core running Linux through remoteproc and add few peripheral support (Interrupts, Gpio, UART, Timers) for TDA4VM. The Cortex R5 processor cores are built to provide deeply embedded real-time and safety-critical systems. Adding Zephyr RTOS support for R5 cores in TDA4VM will be very helpful for the Users.. Programming Languages: Assembly Programming, C.

<p>Volcano's scheduler has no presence in the dashboard today. Three critical operator workflows are missing:&nbsp;</p><p><br></p><p>(1) Configuration — the entire scheduling policy (6 actions, 22 plugins, per-plugin toggles and arguments) lives in a raw Kubernetes ConfigMap edited only via `kubectl`, with no validation or UI;&nbsp;</p><p>(2) Observability — Volcano exposes rich Prometheus metrics (scheduling latency, preemption counts, unschedulable job/task counts) that the dashboard never queries, leaving operators dependent on a separate Grafana stack;&nbsp;</p><p>(3) Logs — debugging scheduling issues requires `kubectl logs` against pods in `volcano-system`; the dashboard has no log viewing capability at all. This project adds a `/scheduler` section with three tabs: a Config tab that reads and writes the `volcano-scheduler-configmap` as a structured form, a Metrics tab that proxies and visualizes the scheduler's Prometheus `/metrics` endpoint, and a Logs tab that streams live logs from any Volcano system component (`volcano-scheduler`, `volcano-controller-manager`, `volcano-webhook-manager`, `volcano-agent`) — all backed by new tRPC procedures using the existing `CoreV1Api` client in `packages/trpc/server/utils/k8s.ts`.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>Config tab: draggable action pipeline editor, plugin tier editor with per-plugin `enabled` toggles and typed argument fields, live YAML diff preview, and a Save button that patches the ConfigMap via `CoreV1Api.patchNamespacedConfigMap`.</li><li>Metrics tab: stat cards for unschedulable jobs/tasks and total preemptions; line chart for e2e and per-plugin scheduling latency; bar chart for per-action latency — all from a new `getMetrics` tRPC procedure querying the scheduler's `/metrics` endpoint.</li><li>Logs tab: component selector dropdown (`scheduler`, `controller-manager`, `webhook-manager`, `agent`), `tailLines` control, keyword filter/highlight, and real-time log streaming via `CoreV1Api.readNamespacedPodLog` with a Server-Sent Events or polling transport.</li><li>Updated RBAC in `deployment/volcano-dashboard.yaml` for ConfigMap `get`/`update` and Pod logs in `volcano-system`.</li><li>Tests and user-facing documentation.</li></ul>

<p>This project aims to create a tool that allows anyone to become a market gardener, given some space. As a first step, a user will merely sign up and enter the amount of space that they want to use. The system will then trigger tasks the user has to do to farm on his space efficiently. Those tasks are triggered by simple rules and may depend on weather events, dates, and later also other triggers. Thus, anyone can be a market gardener, and this tool will be beneficial and easy to use.</p>

<p>coala is a linting and code fixing tool with support for many languages. Having a configuration file is essential to make full use of coala. Having a standardised configuration format like TOML helps. coala currently has an INI style configuration. Also, INI style configuration has certain limitations when it comes to custom sub-level parsing. The LineParser and ConfParser becomes complex and error-prone. This project will allow developers to quickly implement new features and will allow users to write configuration files in a format that they are already familiar with.</p> <p>This project would focus on :</p> <ol> <li>Allowing the user to create configuration files in TOML</li> <li>Providing coala with the functionality to create TOML configuration files from sections</li> <li>Creating a tool to convert .coafile to TOML configuration file</li> <li>Allowing coala-quickstart to generate configuration files in TOML as well.</li> <li>Creation of TOMLLintBear and a repository of good configuration files to allow users to easily bootstrap their projects.</li> </ol>

<p>Currently, the coala Online module lacks support for all the bears. Bears with non-optional settings are ignored. The first goal of this project is to have a powerful online module that provides backend and frontend interface to be able to do code analysis with any given bear. The project focusses on enhancing coala-html by introducing results and bear search and filtering on basis of parameters. The next thing where the project will help us is that it will provide an effective bear search mechanism on coala.io and make projects.coala.io configurable and extensible.</p>

<p>Programming the PRU is a uphill task for a beginner, since it involves several steps, writing the firmware for the PRU, writing a loader program. This can be a easy task for a experienced developer, but it keeps many creative developers away. So, I propose to implement a REPL based control of the PRU, hiding all the low level things behind the REPL and providing a clean interface to uses PRU. This can be achieved by implementing a PRU firmware which only runs some specific user defined commands delivered by RPMSG, executes and then sends a appropriate response. This can be achieved by offloading major task like lexing, parsing to the linux core, and through RPMSG only certain set of commands will be run, the high level code will be converted to these set of commands, on the linux machine itself.</p>

<h4>GitMate for all!</h4> <p>This time with user configurable plugins!</p> <h3>About the product</h3> <p><strong>GitHub</strong>, <strong>GitLab</strong> and <strong>BitBucket</strong> support webhooks for common events like opening/closing/commenting on Merge Requests, creating Issues, etc. These webhooks could be configured for automated response using their own API's for comments, tests/integrations, etc. <strong>GitMate</strong> merely acts as a tunnel for these events and responds accordingly. The interface for these API's is held by its wrapper library, IGitt.</p> <h3>Aim of the project</h3> <p>This project is aimed at extending the support for <strong>GitMate</strong> to <strong>GitLab</strong> and <strong>BitBucket</strong> repositories. This adds up to unified and automated code analysis and maintenance on the big three code hosting platforms.</p> <h3>Implementation</h3> <p>This project consists of implementing <strong>GitLab</strong> and <strong>BitBucket</strong> interfaces in <strong>IGitt</strong>, following the already implemented <strong>GitHub</strong>'s convention, while simultaneously creating webhook responders and tasks for the same on <strong>gitmate-2</strong>.</p> <p>Extending plugins is quite easy on <strong>gitmate-2</strong> following <code>gitmate_testplugin</code> as an example, thanks to its plugin-based architecture.</p>

<p>The aim of the project is to create easy-to-use APIs for the hardware on the BB Blue. This would consist of developing/improving kernel drivers for the on-board devices and then re-implementing the Strawson APIs to use these kernel drivers. These APIs will then be used by real-time applications which can be run on BB Blue. In the later phase of the project, support for BB Blue will be added in Ardupilot and ROS will be ported to BB Blue using these APIs.</p>

<p>The goal of project meta-review is to track emoji responses to review comments. These responses would be collected, processed and displayed. This project builds a meta-review system on the community site and gh-board to display score ranking statistics and meta-reviews in need, respectively, and encourage people to do meta-review.</p>

<p>Goal of this project is to use coala's json output format, convert it to various test result formats and then integrate these test format reports to various tools like CricleCI, Appveyor, Jenkins and Phabricator. Result format inconsistencies has been a problem for a long time but the benefit of converting the static analysis results into a test result format can provide tight integration with various systems. This project also aims to provide our upstream linters with some of these test formats using the Result Reporter Tool library and help developers in extending this project to other formats and uses in the future.</p>