This is an experimental build of POT 5.1.0 including support for remote streaming. I tested it for HTTP/HTTPS with YouTube but it should work with other protocols supported by ffmpeg as well.
In case someone is interested in testing it please let me know. This is a build for Pi2 on Qt 5.6.0-beta1. To quickly test you can use POCPlayer:
Download PiOmxTextures 5.2.0 for Raspbian Jessie Pi2 here (extraction code is: cd4f).
Please file bug reports in case of issues and have fun! Bye ;-)
NOTE: If you need to test the samples please keep in mind that Qt 5.6.0 seems to have changed the order of the params to provide to qmlscene: the qml file must appear at the end.
This is a experimental build of POT 5.1.0 running on Qt 5.6.0-beta1 built for Raspbian Jessie for armv7 (Raspberry Pi 2). Do not use in production. The package includes:
Qt 5.6.0-beta1 optimised for armv7.
QtConnectivity including BLE support.
QtWebKit including both WebKit 1 and WebKit 2. Video decoding is implemented in WebKit with gstreamer (won't even do 720p properly).
QtWebEngine with unaccelerated video decoding using ffmpeg.
QtFtp.
valgrind-3.12.0.SVN: using it on PiOmxTextures requires to disable libarmmem.so in /etc/ld.so.preload. Also the default valgrind in Raspbian was not working for me.
POT 5.1.0 for accelerated playback in Qt.
No accelerated video playback is implemented in QtWebKit nor QtWebEngine in this build. CSS animations instead are properly accelerated when OpenGL rendering is used.
Download PiOmxTextures 5.1.0 for Raspbian Jessie Pi2 here (extraction code is: 508d).
This is the first attempt at playing YouTube videos using POT and QtWebKit on Raspberry Pi 2 (Raspbian Jessie). I tried two ways: one is from the YouTube website and one is using the iframe YouTube API. What you'll see in the video is done using the old WebKit 1 in QtWebKit with the OpenGL paint engine. This is good if you need to place a YouTube video in your application. Unfortunately this is still very experimental and cannot be placed in QML applications. Much more work is needed for that.
Unfortunately what you'll see in the demo is just HD quality (720p). YouTube doesn't seem to be willing to let my Pi have the 1080p version for some reason.
There are a few solutions to get a browser with good performance on Raspberry Pi 2, but I wanted to test solutions that provide this to a Qt app on OpenGL without X11. The two main options I know are the "old" QtWebKit and the new QtWebEngine. I know that there are a couple of ways to use QtWebKit, one is with the first implementation, WebKit 1, the other is through WebKit 2. Also, it is possible to use WebKit 1 using the regular software raster paint engine and the OpenGL paint engine, which is the one I used in the previous article to implement the HTML5 video feature.
I therefore wanted to have a look at the performance of the animations (I'm not talking about WebGL here), so here it is; the video shows three samples (thanks to the authors!) run on each of these alternatives: WebKit 1 on raster, WebKit 1 on OpenGL, WebKit 2 and then QtWebEngine.
As you can see WebKit 1 on raster is completely unusable and WebKit 1 on OpenGL is clearly better, but still not very good. Also you can see how the pointer moves: the main thread is too busy and user interaction is difficult. WebKit 2 and QtWebEngine solve this issue and improve performance.
I tried to do this a few months ago actually, but I got lost in the huge amount of code and architecture variants of WebKit. Now I convinced myself it would be too interesting to see it working. I don't have much spare time, so I wanted to start with the path of least-resistance and then, depending on the time available, continue climbing. This activity is very time consuming, so I do not know where I'll get.
This is however the first stage: using POT to implement 1080p hardware accelerated zero-copy video playback in the Qt port of WebKit1. No QML here. Of no use, but it somehow works. I read there are far better results out there, but I learned much by doing this, and I had fun :-)
Of course, as you can see, there is much much work being done in the UI thread. JavaScript is mostly run in the main thread, making the framerate pretty bad on heavy websites. That is why WebKit2 is there after all :-)