Release v1.4.0

This release is a significant update to v1.3.1 as, leveraging the hard work by the RPF's 6by9 and others on the rpi-4.19.y kernel, use of the Pi's camera module, and the Pi's hardware video codecs are now both supported! [1]

If you would like to upgrade an existing, older version of this image to v1.4.0 (rather than just downloading and using the latest v1.4.0 image directly), please see below.

Changes in this release (see main project page for further details):

• Kernel migrated to rpi-4.19.y (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226). As just noted, this represents a significant upgrade, as a number of features (such as v4l2 m2m codec support) are only available in 4.19, and will not (aiui) be backported to 4.14. The boot firmware was also updated to sys-boot/rpi3-64bit-firmware-1.20190213, and the userland libraries to media-libs/raspberrypi-userland-1.20190114.

• Thanks to advice and patches from the RPF's 6by9, added a version of ffmpeg that can both access the Pi's v4l2 camera (via /dev/video0) and access the Pi's hardware video codec capabilities, via v4l2 m2m (memory-to-memory) interfaces at /dev/video{10,11,12}. The h264_v4l2m2m, mpeg4_v4l2m2m, and (if you have purchased a license key) mpeg2_v4l2m2m codecs all currently work from 64-bit userland. (Note, I have primarily tested decoding, as that is relevant for video playback, but these endpoints should support hw-based encoding too (for h264 and mpeg4, anyhow).)

• Added (via USE flag on media-plugins/gst-plugins-meta) the necessary additional gstreamer library, to allow it to also access the v4l2 m2m endpoints (media-plugins/gst-plugins-v4l2-1.14.4).

• Added the pi-ffcam app, a trivial [2] 'live viewer' for the Pi camera module v1/v2 (available under the Multimedia menu). This streams an h264-encoded live video feed from the camera, decodes it using h264_v4l2m2m (i.e., a hardware codec, just for fun ^-^), and then displays the output in an SDL desktop window. It is built on ffmpeg / ffplay. Note that due to buffering, the stream has around a 1s lag. (Also note that you wouldn't build a 'real' live view app like this of course; it's main purpose is to provide confidence that the various interfaces are working.)

• The media-tv/v4l-utils package is also included; this provides an app (Applications→Multimedia→V4L2 test Utility) that may also be used (inter alia) to live-view the camera (although I have found its GL output to be unreliable).

• Added the pi-ffplay app, a trivial [2] video player that can utilize the Pi's built-in hardware codecs just described, for h264, mpeg4, and - if you have purchased the license - mpeg2. It may also be found under the Multimedia menu. The app prompts for a video to play, attempts to probe its video stream type, and plays it, forcing (where possible) an appropriate v4l2 m2m hardware codec (stream decode only; actual blit of the rendered bitmaps to the window is still via the regular pipeline). This uses the standard ffplay underneath, so consult its manpage for details (double-click to toggle full screen etc.) If the video contains an audio track, this will be played also. Unfortunately, the other bundled video playback apps (VLC, Kodi, and SMPlayer) do not yet leverage the m2m codec paths by default - at least, not in the versions currently provided. If you know how to make them do this (either by preference file, USE flag or patching) please let me know! It is a similar case (at the moment) for the bundled Firefox and Chromium browsers (the latter can use v4l2 m2m, but only in an ozone context right now). That's a shame - files like http://jell.yfish.us/media/jellyfish-50-mbps-hd-h264.mkv (1920x1080 50Mbps) choke the RPi3 (even B+) under software rendering, but display relatively smoothly when using the v4l2 m2m codecs (you can easily try for yourself, just download the file and try playing it with e.g. VLC or SMPlayer (the latter does the better job), then try again with ff-play). But as making the connection (particularly where ffmpeg or gstreamer are used 'under the hood') is a relatively straightforward matter, these facilities will hopefully be added in relatively short order.

• The default GPU memory setting in /boot/config.txt has been increased, to 128 MiB from the prior (de minimis) 16 MiB. Per 6by9 and my own empirical tests, this should be sufficient to permit both camera and v4l2 m2m codec use simultaneously, for most use cases. The camera interface has also been selected by default (start_x=1). NB: if you do not need to use the codecs (or camera) please feel free to revert these settings (memory being a precious resource on the RPi3!).

• The pyconfig_gen application has been updated; it now allows setting of gpu_mem, and selection of the camera interface (start_x=1).

• Although I have elected to stay with fkms in this release, for regular RPi3 users, 'true' kms (vc4-kms-v3d) should prove an entirely viable option now (and this can easily be selected via the pyconfig_gen application); I have one system that has been running this for weeks now, and it seems very usable (and exhibits maybe 5-10% more GL bandwidth relative to an fkms system, when compared on a like-for-like, no-display-manager-compositing basis). Please note that under vc4-kms-v3d, window manager compositing should be turned off to prevent periodic 'stalling' of the GUI, and so I have modified the existing rpi3-safecompositor service to do this automatically. For avoidance of doubt, fkms - the shipped default - is unaffected.

  NB: Pi-Top users should definitely stick with fkms - sound output via the built-in speaker does not work when using kms.

• Various minor ebuild tidy-ups.

• All packages brought up-to-date against the Gentoo tree, as of 19 February 2019 (which means e.g., www-client/firefox-65.0.1, www-client/chromium-72.0.3626.96-r1, app-office/libreoffice-6.1.5.2 etc. are bundled; a full list of installed packages may be found here).

Upgrading from an Earlier Release of the Image

Users downloading this v1.4.0 image directly can of course omit the instructions below; as all settings have been correctly set up for you already.

Users on earlier releases who wish to manually upgrade should follow the manual upgrade instructions to 1.3.1 below; the final step genup therein will actually bring you to a baseline v1.4.0 now.

You can easily check your current version at any time, by issuing:

demouser@pi64 ~ $ eix rpi3-64bit-meta

Once upgraded, be sure that you merge all configuration file updates; in particular, this release contains changes to /boot/config.txt (supplied by the sys-boot/rpi3-boot-config package) which must be accepted to use the RPi3's hardware video codecs, and (optional) camera module. To do so, issue:

demouser@pi64 ~ $ sudo dispatch-conf

and follow the prompts (if you haven't modified this particular file yourself, the changes will already have happened, but if you have changed it, dispatch-conf will ask you what to do - for further guidance, please see my notes here).

Notes

[1] There's still no 64-bit userland MMAL just yet, but things are getting closer; in any event, hardware video codec access is one of the big reasons people wanted MMAL ported to 64-bit in the first place, so getting access to this facility via the v4l2 m2m endpoints instead will obviate the need for it, in many cases ^-^

[2] Once ffmpeg has the necessary v4l2 m2m codec support built in (which the version on the image has) then exploiting these features from the command line is trivial - see for example the example CLI 'recipes' in this project's open wiki.