Media Open Source Projects: Looking for Volunteers

This page lists open source projects related to the Media subsystem that are in need of volunteers.

Each project has a short description and an indication of the difficulty and guesstimated time in days (assume around 7-8 hours per day). The time is just an indication. The reality might differ wildly from my guesstimate, especially once it gets beyond 5 days.

Projects marked 'Easy' are suitable for those with little experience with C and kernel development. Projects marked 'Medium' require C experience and at least some knowledge about kernel driver development. Projects marked 'Hard' require a solid amount of kernel development experience and ideally at least some knowledge about media subsystem development.

If you are interested in one of these projects, then please contact the linux-media mailinglist.

• V4L2: vimc: Add HDMI emulation support. The vimc (Virtual Media Controller) driver supports sensors, but it does not have a sub-device driver for HDMI receivers. It would be nice to have this for prototyping purposes. Difficulty: medium. Time: 10 days.

• V4L2: vimc: Add S-Video emulation support. The vimc (Virtual Media Controller) driver supports sensors, but it does not have a sub-device driver for S-Video receivers. It would be nice to have this for prototyping purposes. Difficulty: medium. Time: 10 days.

• V4L2: vimc: Add frame rate control. The vimc (Virtual Media Controller) driver support different frame resolutions, but it does not support different frame rates. Add support for this. Difficulty: Easy/Medium. Time: 5 days.

• V4L2: vimc: Add support for cropping/composing. The vimc (Virtual Media Controller) driver does not have any support for the cropping and composing API (aka selection API). Add support for this. Difficulty: Medium. Time: 10-15 days.

• V4L2: vimc: Optimize pipeline (In Progress). Only generate the video data at one point by calculating the final format based on the full pipeline configuration. Difficulty: Medium-Hard. Time: 15-20 days.

• V4L2 Documentation: the Extended Controls documentation should be split up into sub-sections, one for each class of controls. Difficulty: Easy. Time: 1 day.

• V4L2 Documentation: re-organize the Selection API documentation. It's messy and the information is spread over too many pages. Difficulty: Easy/Medium. Time: 2-4 days.

• V4L2: vim2m: add support for the _MPLANE API (i.e. multiplanar or one buffer per plane). This is similar to what the vivid driver offers. Difficulty: Medium. Time: 5 days.

• V4L2: vivid: proper implementation of connect and disconnect emulation of HDMI input: events related to that are not implemented by vivid. In order to do proper prototyping using vivid these events should be added. Difficulty: Medium. Time: 3-5 days. In progress.

• V4L2: vivid: improve loopback support (depends on the previous vivid project). Currently an HDMI input can be connected to an HDMI output, and ditto for S-Video, provided both are in the same vivid instance. It would make a nice addition to allow an HDMI/S-Video input to be connected to a HDMI/S-Video output from any vivid instance. This would improve the vivid prototyping capabilities. Difficulty: Medium. Time: 10 days.

• V4L2: vivid: add software defined radio output emulation support. Currently only SDR input is emulated. I started working on this a long time ago, but never finished it. As part of this work the current SDR implementation needs to be converted to a proper kthread implementation as was done for video. Some knowledge of SDR (i.e. how software defined radio works) is a nice-to-have. Difficulty: Medium. Time: 10 days.

• V4L2: vivid: improve timestamping (In Progress). When buffers are processed they get a timestamp. In real hardware this typically happens in an interrupt, thus providing pretty precise timestamps. In vivid this happens in a thread, making the timestamps very jittery. Properly calculate the timestamps based on the framerate so this is more like real hardware. Difficulty: Easy. Time: 2-3 days.

• V4L2: vivid: add emulation for metadata capture such as an histogram. Metadata capture is fairly new and emulation for this was never added to vivid. Metadata output has also appeared in kernel 5.0, so it makes sense for this project to add emulation support for both capture and output at the same time. Difficulty: Medium/Hard. Time: capture only: 10-15 days. Add another 5 days for metadata output support.

• V4L2: vivid: add v4l-touch emulation. It will be very similar to regular video capture, but we would need a new test pattern for this, something that emulates touchpads. Difficulty: Medium (I think). Time: 5-10 days.

• V4L2: vicodec: add stateless codec support (Reserved as Outreachy Project). Currently vicodec only has a stateful codec (i.e. the codec remembers the full state), but we want to have a stateless variant as well (both the frame and the state is passed at the same time using the upcoming Request API framework). Difficulty: Medium/Hard. Time: 15 (?) days.

• V4L2: uvc: convert to use the control framework. This is almost the last driver left that does not use the control framework (v4l2-ctrls.h) for control handling. It would be really nice to do this, but due to special requirements of UVC w.r.t. controls this isn't easy to do in a sane way. Difficulty: Hard. Time: several weeks.

• CEC: cec-compliance: write new compliance tests. Requires a Raspberry Pi and a TV with CEC support. The v4l-utils repository contains the cec-compliance utility that is used to test CEC. The CEC commands are divided into groups called 'Features' where each 'Feature' deals with specific CEC functionality (e.g. starting a recording, programming timers, TV tuning, etc.). Some features are tested in-depth, others only have limited test coverage. Extending test coverage would be very nice. Different people can improve test support for different features, so this can be done in parallel. Difficulty: Easy/Medium (depends on the feature). Time: variable (again very much dependent on the feature).

• DVB: virtual driver and dvb-compliance: write a virtual driver and a DVB compliance tool in order to check Digital TV core.