The Bugfree Blog ;-)

Sunday, March 4, 2018

Raspberry has a huge community that creates a considerable amount of material in a large number of projects. A relevant support for Yocto cannot therefore be missing for it. Months ago I started to work on using Yocto to create images for the Raspberry Pi. Unfortunately I had to stop for a few months to work on other projects, so the result could not be published immediately: the project is based on Pyro while current Yocto release is Rocko. The concept is however similar.

I created a test image for the Raspberry Pi 3 board, using the best compilation flags I found available, and added a recipe for POT to include hardware acceleration in Qt. The result is good: just invoke qmlscene on a little QML code and you have a hardware accelerated OpenGL scene rendering video with Qt API (QML) in your Yocto image.

and you should see your video in the QML scene right away with the command:

qmlscene -platform eglfs main.qml

Optimization

I wanted to also create an image fully optimized for the Raspberry Pi 3 board, which is a Cortex-A53 armv8-a architecture which includes crc and new A64, A32, and T32 instructions to Advanced SIMD that accelerate Advanced Encryption Standard (AES) encryption and decryption, and the Secure Hash Algorithm (SHA) functions SHA-1, SHA-224, and SHA-256. Still I wanted a fully 32-bit system as hardware libraries are only supported for this bitness. To do this I had to apply a few patches to the Yocto repos. I uploaded every patch to these forks:

Tuesday, January 2, 2018

This was a good test for my cross toolchain with gcc 6.3.0 I uploaded some days ago: the new Qt 5.10.0 built with -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard, including POT for video acceleration on Raspbian Stretch. The build includes most Qt modules plus Qt WebKit (the modernized QtWebKit from Konstantin Tokarev, version 5.212, https://github.com/annulen/webkit) plus QtWebEngine 5.9.1, a bit patched to build here. I didn't test browsers much, you'll have to work on those yourself if you need them.

By using the Qt build and the cross toolchain you can build your own applications.

Friday, November 24, 2017

Raspbian Stretch is out for Raspberry Pi. I needed a cross toolchain with the same exact version used to build the system so I built my own. As I had my script ready, I also tried to build one for Mac OS and it seems to work for the moment. I tested these cross toolchains for my projects and seemed to be able to build everything that I tried: Qt libs, apps, omxplayer, ffmpeg etc...

NOTE: The Mac OS version requires some packages to be installed from macports.NOTE: The toolchain is built to crossbuild for armv7-a. I could also build for armv8 but not sure if it also works for armv6.

Saturday, June 3, 2017

This post is mostly for myself :-) This was very simple years ago; actually it was automatic. Now, I have no idea why, but shared directories are not automatically mounted anymore. By searching online it is incredibly difficult to find a proper answer: I tried a million answers but none was working properly. The only one that worked is simply the shortest and the one I never remember for some reason (and also difficult to find) :-):

vmhgfs-fuse /mount/dir

this is how I do it, and it works for me. No idea why the other techniques are not.

Sunday, March 19, 2017

At the moment I still don't want to test custom firmwares or 64 bit arch builds, but I started to test a couple of new features: a new compiler from Linaro (the one provided by the foundation keeps giving me headaches), version 4.9.4 instead of 4.8, and optimised compiler flags for the Rapsberry Pi 3, which is an armv8.
In this build, Qt, ffmpeg and POT are all built with 4.9.4 Linaro toolchain and optimised compiler flags for Pi3. This will only work on Pi3.
You won't probably see much difference in GPU intensive apps, but it is a step on the road of optimisation!

Saturday, January 28, 2017

A few months back I decided to try to implement hardware decoding in WebKit. Unfortunately this task is always pretty long and complex for many reasons. I found the time to draft an implementation for WebKit1, which is pretty useless as WebKit1 in Qt is only used outside QML and JS is executed in the main thread. Unfortunately I never found the time to implement this in WebKit2, which runs in QML and is suitable for more fluid UIs. This was the result:

This is how YouTube was running with this implementation:

Now Qt has deprecated QtWebKit and is working heavily on QtWebEngine, which is built on Chromium, so I wanted to try this road. Unfortunately these kind of things always claim a lot of time, and I don't typically have that much, but I was able to start and get something done already.

Writing a complete solution in Chromium to decode and render video takes much time, so I thought of a shortcut: creating a custom VDA (Video Decode Accelerator) that loads the POT library and reusing its entire codebase to implement decode and rendering with little modifications. This proved to be possible and now I get something on the screen.

So, to summarise: a little patch to Chromium is needed to create a VDA that dynamically loads POT library into memory and uses it with a common interface. Data and calls are translated to POT structures and are sent to POT, which then processes the buffers properly. The result of the decode operation is then sent back to the VDA through the same interface and textures are then sent to Chromium for rendering.

Still many problems remain open, there is much to be done yet as you can see from the video, but something is drawn. Have a look at the demo:

Tuesday, December 27, 2016

A new version of Qt is out and some interesting changes are being developed. Interesting work was done on WebEngine. This package contains an experimental build of Qt 5.8.0-rc1 with the POT driver to provide hardware acceleration to video decoding and rendering. POT was updated to build on the new plugin architecture of Qt and includes ffmpeg 3.2.2. For info on the content of the package refer to this article. The youtube player still runs on WebKit 1 and so is still hardly useful.