Media Open Source Projects: Looking for Volunteers: Difference between revisions

From LinuxTVWiki
Jump to navigation Jump to search
No edit summary
No edit summary
 
(46 intermediate revisions by 2 users not shown)
Line 6: Line 6:


If you are interested in one of these projects, then please contact the linux-media mailinglist.
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 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.
Line 15: Line 17:
* 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: 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: the [https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/extended-controls.html 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 [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 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. Difficulty: Medium. Time: 5 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: 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: 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.


* 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: 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.
⚫
* 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.

* 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.
* 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: Easy. Time: 2-3 days.


* 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.
* 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. Note that metadata output will probably appear in the near future as well, so it makes sense for this project to wait until support for that has been upstreamed and add emulation support for both 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.
* 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: vicodec: add stateless codec support. 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-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.
* CEC: cec-compliance: write new compliance tests. Requires a Raspberry Pi and a TV with [https://en.wikipedia.org/wiki/Consumer_Electronics_Control CEC] support. The [https://git.linuxtv.org/v4l-utils.git/ 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).

Latest revision as of 07:27, 8 October 2024

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 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: 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. 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.
Retrieved from "https://www.linuxtv.org/wiki/index.php?title=Media_Open_Source_Projects:_Looking_for_Volunteers&oldid=36753"