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 (In Progress): improve logging and 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 (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: 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: improve loopback support. In Progress. 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. This has been done for video/VBI capture, but should be rolled out for other devices as well. Difficulty: Easy. Time: 2-3 days.

• V4L2: vivid: add v4l-touch emulation. In Progress. 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: vivid: the error injection control that tests wrap-around sequence counter and wrap-around timestamps appears to be broken. Fix this. Difficulty: Easy/Medium. Time: 3 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 or a Pulse Eight USB CEC dongle 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).

• CEC: the vivid driver emulates CEC, but it is not a precise emulation. In particular it will not correctly emulate errors like Arbitration Lost. The right approach is likely to emulate the CEC bus at the low level and use the cec-pin framework to implement the emulated CEC adapters. Difficulty: Medium/Hard. Time: 1-2 weeks.

• DVB: virtual driver and dvb-compliance: write a virtual driver and 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.

• saa7146, bttv, cx18, tm6000, zr364xx: convert these drivers to use the videobuf2 (vb2) framework for their streaming I/O implementation. These drivers either implement their own streaming I/O ioctls, or use the old videobuf framework. All these drivers should be converted to the new and much better vb2 framework, allowing us to eventually ditch the old videobuf framework. This project requires access to hardware supported by the driver you are converting. Difficulty: Medium. Time: 1-2 weeks per driver (quite possible more for the bttv driver).