View source for 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.

* Patchwork: add access controls to the tool.

* 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. 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: re-organize the [https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-g-selection.html 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. Also clean up the code, it is using old constructs that are no longer needed. Difficulty: Medium. Time: 8 days.

* V4L2: vivid: improve loopback support. 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. In Progess.

* V4L2: vivid: add software defined radio output emulation support. Currently only SDR input is emulated. I [https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=sdrout 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. 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: Medium. Time: 5 days.

* cec-compliance/follower: add tests for the new SET_AUDIO_VOLUME_LEVEL message. Difficulty: Easy/Medium (depends on your CEC knowledge). Time: 2-3 days.

* DVB: dvb-compliance: write a DVB compliance tool in order to check Digital TV core.

* qvidcap: proper socket implementation. If qvidcap is called with the -p option, then it listens to a socket waiting for a connection. This is implemented using low-level system calls instead of proper Qt classes, and this causes the main event loop to be stalled while listening. The whole networking code should be replaced by proper Qt classes. Difficulty: Medium. Time: 1 week.

* qv4l2: reuse the qvidcap OpenGL code for showing video frames. The two applications really should use the same backend for that. Difficulty: Medium (depends on your Qt experience as well). Time: 1-2 weeks.

* qv4l2: support Ctrl+V shortcut in the capture window to start/stop capturing. This is currently only available in the main Test Bench windows. Difficulty: Easy. Time: 4-8 hours.

* v4l2-compliance: the linux kernel supports several stateless hardware decoders (hantro, cedrus). However, it is difficult to test these decoders since the v4l2-compliance utility is not capable of parsing an H.264 bytestream and fill in the required metadata for use with the stateless decoder API. It would be nice to have a parser for H.264 (and others as well) that can be used by v4l2-compliance (possibly v4l2-ctl as well) to test these decoders. Difficulty: Medium-Hard. This requires a Rockchip or Allwinner-based board that the hantro/cedrus drivers support. Time: 4-6 weeks (just for H.264).

* v4l2-compliance/v4l2-ctl: support JPEG decoders: this requires that these utilities can compress the output of the test pattern generator to a JPEG format. Difficulty: Medium. Time: 1 week.