Build/provide mpv package with vdpau acceleration

[ThomasKaiser]

Disclaimer: I've not the slightest idea about desktop/GUI/video issues but fear that questions regarding this will come soon in the forum.

Are we able to build/provide a mpv package built like this for A10/A20/H3?

[igorpecovnik]

video playing is working with stock mpv ... but there are some issues. sound is not synced and what else?

[ThomasKaiser]

No idea, i've not even tried it yet. But since @WereCatf already provided Mali acceleration I thought maybe he is already preparing something is this area.

I've really no clues regarding video stuff but just thought it would/might be nice to be able to add 'use the included mpv package on our desktop images to enjoy HW accelerated video where possible' to the user documentation in advance instead of answering the question multiple times in the forum :)

[igorpecovnik]

That's true. I was already thinking to provide two icons on the desktop:

1. Play video
2. Test 3D acceleration

Both things works out of the box on A20 (H3 video not yet), but we need to add mpv to the desktop package base. That far is where I am willing to go. Don't want to play with further optimizations - if someone take it from here, yes I'll support and include.

[WereCatf]

I just happened to play with video a little yesterday, compiled the latest libvdpau-sunxi from their git - repo and such and while playing H/W-accelerated H.264 seemed to work otherwise fine I didn't test with audio. Couldn't test HEVC, mpv always insisted on using software-decoding for that and it resulted in corrupted display -- would probably require recompiling mpv and possibly some patching to get it to play HEVC with H/W-decoding.

I can test in a few hours if I'm seeing out-of-sync audio with latest libvdpau-sunxi, but if I am I wouldn't know what to do about it and as such I wouldn't be able to fix it. It'll take some more hours to try and see if I can get HEVC-decoding to work.

[igorpecovnik]

No need to rush ... video / desktop is not our primary goal but if it can work good, why not prepare it.

[WereCatf]

Tbh, Jernej is also having troubles with his OpenElec - build using libvdpau-sunxi, so I wouldn't expect this stuff to work well for a while longer.

[WereCatf]

Yeah, no idea what to do about the timing-issues for now other than wait for them to patch libvdpau-sunxi up some more.

[ThomasKaiser]

@WereCatf what you're currently trying out is exactly what Jernej now suggests? isn't it? The confused video NOOB is asking ;)

[WereCatf]

@ThomasKaiser Um, yes and no: the Armbian - images already pack libvdpau-sunxi, so he's not talking about anything new per se. The version used by Armbian - images is just quite old and I, instead, compiled the latest stuff from github -- I'm still getting timing - issues, so using newer libs didn't fix that. (I can still submit a commit for Armbian that builds newer libs, if you guys want that; I just haven't seen the point, because it's not quite useable anyways until someone figures out how to fix the timing - stuff.)

Background: CedarX is binary-only, Allwinner-specific stuff and software has to be specifically designed to support that, whereas vdpau is used by e.g. NVIDIA's drivers on x86 and is thus much more widely supported. Most Linux video-players support vdpau already, so obviously it makes more sense to just ignore CedarX and use vdpau.

This applies only to playback, though: vdpau can't be used for encoding. CedarX supports encoding, too, but there's nothing out there that uses it, as far as I can tell.

[ThomasKaiser]

Thx for the explanation. If it doesn't matter I've no opinion on that (and also no knowledge whether this vdpau stuff already works identical on A20 and on H3?)

[WereCatf]

@ThomasKaiser It should work just the same on A20, except on the H3 it also supports HEVC. I don't own an A20, though, so I have no idea how well or how badly it works.

[ThomasKaiser]

If there aren't real improvements in bundling a newer version we could skip this. IIRC anyone (you?) wanted to repackage the desktop stuff so that we can also ship the whole thing as debs and do not have to rebuild it everytime we create a desktop build?

And Igor wanted to bundle a mpv package linked to the desktop, right? But we're not in a hurry at all so better think twice about that and do it right :)

[WereCatf]

Xfwm4, the window-manager we install by default, uses software-compositing by default -- try playing some H.264 - video with mpv using vdpau and you'll see mpv doesn't use much CPU, but X is using ~66% CPU! Then, disable compositing with "xfconf-query -c xfwm4 -p /general/use_compositing -t bool -s false" and try it again: you'll notice X's CPU-usage has dropped to ~14%.

That is quite significant, especially on such a low-performance device. Using kwin_gles allows for utilizing eGL/GLESv2 for hardware-accelerated compositing and drops CPU-usage by a very large amount, both when playing video and in general, but it carries a lot of dependencies with it.

[WereCatf]

Are there any plans to move the desktop to use Ubuntu 16.04 instead of 14.04 once it's released? Building mpv is quite a mess and finding out which commits work and which ones don't work on Debian Wheezy and Ubuntu 14.04 is, well, a lot of work, whereas on 16.04 there is a reasonably recent build of mpv already in the repos and we could just simply install it in the desktop - images. This would leave the other distros out, though.

Also, I have a crappy script at https://dl.dropboxusercontent.com/u/11811685/compile.tar.bz2 that builds fbturbo, libvdpau, sunxi-mali and friends into debs. I have not tested whether the script works under 14.04 or Wheezy, I've only run it under Jessie. I have also not yet tested whether the debs work under Wheezy or Ubuntu 14.04, but they should. The script, on the first run, builds all the debs, but on subsequent runs it only checks if there are new commits to the libraries/fbturbo and builds new debs only if new commits were found. Feel free to modify it, I'm not going to be uploading more debs to github as this is definitely not the right place for that stuff.

Oh, and the script doesn't do cross-compiling. You have to run it on real hardware or under qemu.

[igorpecovnik]

Thanks for update, I'll check and test the script asap ... Ubuntu 16.04 is planned.

[WereCatf]

Here ( https://dl.dropboxusercontent.com/u/11811685/mpv_0.16.0_armhf.deb ) is latest git-build of mpv that is capable of using vdpau for decoding of HEVC, too. I am pretty sure it'll only work on Jessie or newer distros, like e.g. Ubuntu 16.04, due to many of the dependencies being terribly out-of-date on Wheezy and Ubuntu 14.04. I just tested it on my OPi PC running Jessie and H/W-decoding of both H.264 and non-10-bit HEVC works beautifully -- 10-bit HEVC is not supported by hardware.

Grab files http://jell.yfish.us/ and use mpv --vo=vdpau --hwdec=vdpau --hwdec-codecs=all [filename] if you wish to test.

[ThomasKaiser]

Great efforts! Hmm... what about the following (if it complicates our build process not too much)? We use the H3 platform for testing 16.04 since currently no OPi user really expects 100% stable images and they know that we need their feedback for the whole situation to improve.

So we add Xenial now and on sun8i switch already to it. This might allow to ship with this mpv package included in the desktop image (and a link on the desktop to mpv) to collect feedback from OPi users the next few weeks and then when 16.04 will be released switch on all other platforms to it without any hassles (same with u-boot, we can then skip the special behaviour for sun8i and update to 2016.03 for all platforms?).

Disclaimer: I'm still not 100% familiar with our build process so maybe I underestimate the whole idea totally.

[WereCatf]

@ThomasKaiser There are no armhf-binaries built in Xenial - repos yet, I assume they'll build those only for final release. I just tried this a few days ago and would've submitted a commit otherwise. So no, moving to 16.04 already now isn't going to work, unless you want to build everything manually!

[ThomasKaiser]

@WereCatf WTF? Ok, I played around with Xenial the last few days but that's arm64 (and there are some packages missing or not adopted already to arm64). But what about https://launchpad.net/ubuntu/xenial/armhf then?

[WereCatf]

@ThomasKaiser Well, I dunno. Maybe I did something wrong or maybe the packages weren't there when I tried it? If you can build Armbian based on arm-binaries by all means, submit a commit. If we're going to be moving to 16.04 anyways we may as well test it out already.

[WereCatf]

By the way, vdpau works with VLC, too, from 2.2.0 onwards. Decoding HEVC didn't work, I'm just trying to find out if newer builds of VLC support using vdpau for HEVC.

[zador-blood-stained]

@WereCatf http://ports.ubuntu.com/dists/xenial/main/binary-armhf/ http://ports.ubuntu.com is used for older armhf debootstrap too AFAIK.

[ThomasKaiser]

Attention! NOOB question: How does http://apt.armbian.com/dists/xenial/ get populated? Is this a manual step or can this be automated too?

[zador-blood-stained]

Attention! NOOB question: How does http://apt.armbian.com/dists/xenial/ gets populated? Is this a manual step or can this be automated too?

repo-update.sh & addtorepo() in general.sh?

[igorpecovnik]

repo-update.sh & addtorepo() in general.sh?

yes. only extra "script" is rsync to the server

[ThomasKaiser]

Ok, the last one puzzled me a bit. So it's some sort of chicken&egg problem? Unless the packages are already rsynced the build will fail with

Failed to fetch http://apt.armbian.com/dists/xenial/main/binary-armhf/Packages

when trying to add Xenial?

[igorpecovnik]

Directory / distro xenial does not exists on server yet. It will once packages will be added ... probably it's possible to initialize empty one.

[WereCatf]

I am preparing a commit that will install updated debs, including mpv, and setting defaults for mpv so that it'll use VDPAU for decoding if possible. That should make it quite plug-and-play for end-users.

Alas, do I submit the debs with the commit or do you want to host them somewhere else? If so I'll post a link to a zip-file and then you'll have to tell me where you're hosting them or if you're adding them to Armbian-repos so they can be installed simply with apt-get -- your decision. And one of the problems with playing video is that xfwm4 in our images uses compositing by default and that eats a helluva lot of CPU -- should we disable compositing by default on sunxi so as to enable a bit smoother playback, or just stick with it and let users disable it if they wish?

[ThomasKaiser]

IMO we should disable it. The average user of desktop images won't touch defaults.

[WereCatf]

@ThomasKaiser Personally I lean towards that myself, too, but I wanted to ask your opinions. Users could, theoretically, expect to see pretty transparency-effects and stuff like they see on the other boards and be a bit taken aback to find out sunxi-boards lack those (by default, that is), but on the other hand, good performance is more useful and I would imagine that's important to a larger group of people than compositing.

[ThomasKaiser]

@WereCatf I just played around with Armbian 5.05 Ubuntu Trusty desktop and trying to use the GUI is close to impossible (at least for me who is lacking patience). The SD card currently used is a bit slow especially regarding IOPS and maybe that's also responsible for the mess. I already searched around how to disable stuff and am not even able to disable the screensaver that starts to eat one CPU core after a while (so clearly I'm the wrong person to judge about Linux with GUI ;) )

So in my very personal opinion everything that speeds up the desktop experience might be worth a try even if transparency-effects are affected.

[WereCatf]

@ThomasKaiser Play around with https://dl.dropboxusercontent.com/u/11811685/Armbian_5.05_Orangepih3_Debian_jessie_3.4.110_desktop.zip instead, much more fun -- includes all the stuff I mentioned above, including VDPAU-support for HEVC, mpv that uses VDPAU by default, compositing disabled by default and working 3D, too. Decoding of HEVC doesn't work with VLC using VDPAU, though -- I couldn't make it work. I think VLC just doesn't support that yet.

[WereCatf]

@igorpecovnik is busy somewhere else, so I'll just leave these links here for him: https://dl.dropboxusercontent.com/u/11811685/compile.zip has updated the script that builds those debs, there were a bunch of bugs in the earlier one. https://dl.dropboxusercontent.com/u/11811685/debs.zip has already-built debs for now.

[igorpecovnik]

https://github.com/igorpecovnik/lib/pull/215

[ThomasKaiser]

BTW: @WereCatf this mpv stuff on Debian with the new default settings works way better than before. But am I'm the only one not being able to shutdown / reboot / suspend the board from an unprivileged user account in the GUI ('sudo reboot' in an xterm works of course)? There seems to be something different between Trusty and Jessie in this area?

[WereCatf]

I dunno, I haven't tried using the shutdown/reboot/suspend - stuff from the menu. It's certainly nothing I have changed. I did notice that for a normal user it said "Command not found" when trying to issue "poweroff" from CLI, so it's either a path-issue or permission-issue. Or maybe even both?

You could try seeing where "poweroff" is located, adjusting the user's path to include the location and seeing if things work better. And maybe report back here about your findings.

[ThomasKaiser]

(Googling and) Installing gksu package solved the problem partially (so we should add it for the desktop builds). The shutdown GUI link in the upper right corner is available and working but suspend is still greyed out (a bit sad, that was also one very nice feature but maybe it's good to promote it later when we switched the meaning of the leds on sun8i so we use green for power and switch to red before the boards starts to suspend to RAM)

[ThomasKaiser]

Update: the 'Shutdown' menu item doesn't work (GUI disappears and gets back after some time, since I left the room I thought 'reboot? strange'). But clicking on 'Log out' showed then 3 choices: Logout, reboot and shutdown. Reboot worked and now the systems seems somewhat broken (can't login through SSH, not able to start local programs, one CPU core busy doing $something according to RPi-Monitor). Trying to shutdown/reboot ends up with

After a forced power cycle now everything's back to normal. Hmm... needs a bit more testing.

[ThomasKaiser]

BTW: http://linux-sunxi.org/User:Rellla/Armbian

[WereCatf]

The two patches from https://github.com/rellla/lib/commit/622a9b075661f95a8bdd457b652c5fb5b0f41ce3 may be worth adding to Armbian. They do apply cleanly and the kernel compiles fine with them, but since I don't have any A20-hardware I cannot test any further than that. They do not apply to the H3-kernel, though, only sun7i.

I won't be making a commit to apply those to Armbian, someone with the hardware should see if anything breaks or not -- I doubt anything does break, but, you know, better safe than sorry.

[ThomasKaiser]

I would suspect he will send a PR later. And I already thought about how to deal with the situation (different legacy kernel configs for desktop and 'server' builds? Trying to provide up-to-date mpv packages on apt.armbian.com?)

But no idea. Let's wait and see :)

[WereCatf]

Might as well add pcsx-rearmed to the list of stuff to build, then. Neither Ubuntu or Debian provide pcsx-rearmed in their repos, they use pcsx-reloaded, but pcsx-rearmed performs a whole lot better on ARM-devices. I built a temporary version of it just for testing and it actually works impressively well, all things considered.

Personally, I have no interest in using my OPi as a desktop, as a media-player or for playing games on or such, but a lot of people do seem to like such stuff and including stuff like this in the repos might make Armbian more appealing for them.

[igorpecovnik]

Youtube playing is no more with this version ... do we need some special compilation procedure?

[WereCatf]

Youtube-playing?

[ThomasKaiser]

Just tested it with a desktop Jessie image I built 2 days ago and with 'Linux version 3.4.110-sun8i (root@armbian) (gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-1) ) #2 SMP PREEMPT Mon Mar 21 18:44:33 CET 2016' youtube still works

[WereCatf]

I hadn't even realized you could use mpv for Youtube. Well, I don't know. As far as I know the version I built was compiled with pretty much everything possible enabled, but it is entirely possible that something is missing. On the other hand, it's also possible they've changed something on Google's ending, I really don't know.

[ThomasKaiser]

@igorpecovnik what are you talking about? Playing youtube videos in Iceweasel (that's what I tested -- not related to mpv at all ;) ) or something else?

[igorpecovnik]

mpv --vo=vdpau --hwdec=vdpau --framedrop=vo --hwdec-codecs=all https://www.youtube.com/watch?v=sqqvQRHScgY

This used to work. The error is: [ytdl_hook] youtube-dl failed, trying to play URL directly ... [ffmpeg] tls: The TLS connection was non-properly terminated. Failed to recognize file format.

Which might lead to: https://github.com/mpv-player/mpv/issues/1291

[WereCatf]

Oh, I think the mpv I provided doesn't have lua enabled

[zador-blood-stained]

youtube-dl is an external program, so even if LUA was enabled in mpv, there is nothing for mpv to launch.