Project Description

I have had a hobby project of running Raspberry Pi to record video when detecting motion, mostly catching rabbits and such on the yard.

I'm using the upstream's default offering Raspbian (or nowadays called also Raspberry Pi OS) together with motion software, but there have been a few problems which would be interesting to see if can be get to working better using openSUSE.

Motivations to seek alternatives include:

  • Raspbian buster (based on Debian 10) is stable, but the ffmpeg included is too old to support the hardware accelerated h.264 encoding. Software encoding speed is okayish with my RPi Zero 2 and RPi 3 Model A+, but still limiting.
  • Raspbian bullseye (based on Debian 11) would be fresh, but the migration from MMAL to libcamera causes problems at minimum due to v4l compatibility layer seeming unstable - and libcamera, regardless of some of its merits, causes incompatibilities and is unusable for the motion software.
  • If libcamera is in general stable eg in openSUSE (I have not checked yet whether openSUSE has migrated), other motion detection software could be considered as well - in the past there have been even interesting hacks utilizing the hardware encoder and reading its motion vectors to get essentially 0% CPU motion detection!
  • My RPi Zero 2 installation seems a bit unstable for unknown reasons (the other installation is has 1y+ uptime), making a good candidate to replace the software.

Goal for this Hackweek

The goal is to prepare an alternate boot environment using the same hardware but different software. Initially the idea would be to use openSUSE Leap 15.4, for which there is a repository offering ffmpeg 4.4 which is recent enough. At least first goal would be to setup the same motion software with the same config as currently, if possible, but if openSUSE already uses libcamera then a different approach will be needed.

Ultimately, the goal is to learn about Raspberry Pi, video interfaces and motion detection on openSUSE.

Resources

If you want to try to setup something similar, whether migrating or simply wanting to setup motion detection video recording, we could work together by exchanging experiences or ideas of what software to use.

https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications

https://github.com/Motion-Project/motion/

https://github.com/raspberrypi/rpi-imager

http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSELeap15.4/Essentials/aarch64/

http://billw2.github.io/pikrellcam/pikrellcam.html

Looking for hackers with the skills:

raspberrypi videoprocessing motiondetection opensuse

This project is part of:

Hack Week 21

Activity

  • over 2 years ago: clin liked this project.
  • over 2 years ago: ptesarik liked this project.
  • over 2 years ago: mbrugger liked this project.
  • over 2 years ago: tjyrinki_suse added keyword "opensuse" to this project.
  • over 2 years ago: tjyrinki_suse added keyword "raspberrypi" to this project.
  • over 2 years ago: tjyrinki_suse added keyword "videoprocessing" to this project.
  • over 2 years ago: tjyrinki_suse added keyword "motiondetection" to this project.
  • over 2 years ago: tjyrinki_suse liked this project.
  • over 2 years ago: tjyrinki_suse started this project.
  • over 2 years ago: tjyrinki_suse originated this project.

  • Comments

    • tjyrinki_suse
      over 2 years ago by tjyrinki_suse | Reply

      Finished the main hack week tasks, although there are always more things to be done.

      Blogged at https://timojyrinki.gitlab.io/hugo/post/2022-07-01-leap-on-rpi-zero2/ (also planet.o.o)

    Similar Projects

    YQPkg - Bringing the Single Package Selection Back to Life by shundhammer

    tl;dr

    Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.

    See section "Result" at the bottom for the current status after the hack week.

    Current Status

    See the development status issue at the GitHub repo.

    tl;dr: It's usable now with all the key features.

    It does real package installation / removal / update with reasonable user feedback.

    The Past and the Present

    We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.

    You can search packages based on name, description, "requires" or "provides" level, and many more things.

    The Future

    YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.

    Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?

    For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.

    But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.

    The Idea

    YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.

    For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.

    For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.

    Preparatory Work: Initializing the Package Subsystem

    To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?

    Yes, it is: That part is already working:

    https://github.com/yast/yast-ycp-ui-bindings/pull/71


    Update Haskell ecosystem in Tumbleweed to GHC-9.10.x by psimons

    Description

    We are currently at GHC-9.8.x, which a bit old. So I'd like to take a shot at the latest version of the compiler, GHC-9.10.x. This is gonna be interesting because the new version requires major updates to all kinds of libraries and base packages, which typically means patching lots of packages to make them build again.

    Goals

    Have working builds of GHC-9.10.x and the required Haskell packages in 'devel:languages:haskell` so that we can compile:

    • git-annex
    • pandoc
    • xmonad
    • cabal-install

    Resources

    • https://build.opensuse.org/project/show/devel:languages:haskell/
    • https://github.com/opensuse-haskell/configuration/
    • #discuss-haskell
    • https://www.twitch.tv/peti343


    Create openSUSE images for Arm/RISC-V boards by avicenzi

    Project Description

    Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.

    Goal for this Hackweek

    Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.

    Consider generic EFI images where possible, as some boards can hold a bootloader.

    Document in the openSUSE Wiki how to flash and use the image for a given board.

    Boards that I have around and there are no images:

    • Rock 3B
    • Nano PC T3 Plus
    • Lichee RV D1
    • StartFive VisionFive (has some image needs testing)

    Hack Week 22

    Hack Week 21

    Resources


    Enlightenment in Leap 16 by simotek

    Description

    Get the Enlightenment stack + X11 building and running on the Leap 16 codebase.

    Goals

    • Get enlightenment / terminology compiling for Leap 16
    • Test that they are running correctly in a Virtual Machine.

    Resources


    Digital art wallpapers for openSUSE Leap and Tumbleweed by lkocman

    Description

    We've enrolled set of new wallpapers to both Leap 16 and Tumbleweed as part of https://news.opensuse.org/2024/10/26/leap-tw-get-makeovers/

    We've previewed digital art wallpapers which were not part of the initial drop. I'd like to spend time on hackweek to finialize my current Taipei (mountains) and Mauritius digital art wallpapers.

    Goals

    Finalize existing two digital art wallpapers for Leap and Tumbleweed https://github.com/openSUSE/branding/issues/155 Make them available as part of leap16 dir in https://github.com/openSUSE/wallpapers and update (This makes is available to Tumbleweed users as well). Update https://build.opensuse.org/package/show/X11:common:Factory/wallpapers-openSUSE-extra && Leap:16.0 && Factory.

    Resources

    https://github.com/openSUSE/branding/issues/155 The mauritius draft can be found in https://github.com/lkocman/geo-wallpapers