Jump to content

Banana Pi: Mainline kernel with hw video acceleration / decoding


oxymoron

Recommended Posts

I'm running a dockerized VDR server on the BPi, still on bananian. Every time I installed armbian, I had to discover that video playback on remote devices started to stutter.

 

Without knowing about the details, my guess is that this is owed to the fact that the mainline kernel build does not feature hw video decoding. (Though I'm not sure whether bananian had it actually.) Unfortunately I cannot use the legacy kernel build, as docker is not supported on that platform.

 

Is there any chance to kind of enable hw video acceleration on the mainline build? I saw some posts here and there in the forum on that topic, but none seemed really having solved it definite or reliably.

 

greets

Link to comment
Share on other sites

26 minutes ago, oxymoron said:

had to discover that video playback on remote devices started to stutter.


This is kind of weird. And this works fine on Bananian? Which kernel? Provide all possible data from both systems, the one which works and the one which doesn't.

 

26 minutes ago, oxymoron said:

Is there any chance to kind of enable hw video acceleration on the mainline build?


This problem has nothing to do with video acceleration and it's anyway not developed for mainline yet.

Link to comment
Share on other sites

Thanks for your reply. This is my current bananian kernel

root@tv ~ # uname -a   
Linux tv.lan 4.4.66-bananian #2 SMP Sat May 6 19:26:50 UTC 2017 armv7l GNU/Linux

Please let me know what other information might be helpful.

Afterwards I'll setup the server on current armbian to check whether stuttering still occurs. I have to admit that the last time I tried it was maybe half a year ago.

root@tv ~ # lsmod
Module                  Size  Used by
xt_nat                  1567  15 
xt_tcpudp               2077  29 
veth                    4218  0 
ipt_MASQUERADE          1019  10 
nf_nat_masquerade_ipv4     1817  1 ipt_MASQUERADE
nf_conntrack_netlink    23591  0 
nfnetlink               4905  2 nf_conntrack_netlink
iptable_nat             1469  3 
nf_conntrack_ipv4       6793  4 
nf_defrag_ipv4          1300  1 nf_conntrack_ipv4
nf_nat_ipv4             4480  1 iptable_nat
xt_addrtype             2619  2 
iptable_filter          1281  1 
ip_tables              11125  2 iptable_filter,iptable_nat
xt_conntrack            2911  3 
x_tables               11316  7 ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,xt_nat,iptable_filter,xt_addrtype
nf_nat                 11031  3 nf_nat_ipv4,xt_nat,nf_nat_masquerade_ipv4
nf_conntrack           70409  6 nf_nat,nf_nat_ipv4,xt_conntrack,nf_nat_masquerade_ipv4,nf_conntrack_netlink,nf_conntrack_ipv4
br_netfilter           12383  0 
overlay                27626  6 
ts2020                  5544  2 
sun4i_codec             8300  3 
snd_soc_core          116192  1 sun4i_codec
dvb_usb_dvbsky          7562  14 
ftdi_sio               30425  1 
snd_pcm_dmaengine       3007  1 snd_soc_core
snd_pcm                70170  2 snd_soc_core,snd_pcm_dmaengine
m88ds3103              10884  3 dvb_usb_dvbsky
snd_timer              18216  1 snd_pcm
usbserial              19325  3 ftdi_sio
snd                    42273  3 snd_soc_core,snd_timer,snd_pcm
soundcore                858  1 snd
evdev                  11204  0 
sun4i_ts                3798  0 
nvmem_sunxi_sid         2359  0 
nvmem_core              7651  1 nvmem_sunxi_sid
cpufreq_dt              4010  0 
sun4i_ss               15042  0 
thermal_sys            51713  2 cpufreq_dt,sun4i_ts
uio_pdrv_genirq         2972  0 
uio                     6976  1 uio_pdrv_genirq
root@tv ~ # docker -v
Docker version 17.09.1-ce, build 19e2cf6

 

Link to comment
Share on other sites

10 hours ago, oxymoron said:

Afterwards I'll setup the server on current armbian to check whether stuttering still occurs. I have to admit that the last time I tried it was maybe half a year ago.


Well, it could be some temporal setback. The kernel used in Armbian is more advanced, modern and I haven't heard of such problems. Check most recent one and then we could look into it if the problems are still present.

Link to comment
Share on other sites

On 12/15/2017 at 8:51 AM, Bernie_O said:

How do you access the videos? SMB? DLNA?

 

I'm using the Bananapi as a TV backend server to watch satellite tv. In my case, I'm viewing the tv stream from other devices with Kodi via the VNSI plugin.

I'll install the latest armbian now.

Link to comment
Share on other sites

I've installed armbian now and unfortunately TV streaming playback on remote devices stutters. That applies for SD as well as for HDTV, which stutters more.

root@bananapi:~# uname -a
Linux bananapi 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l GNU/Linux

As far as the logging on the bananapi tv server shows (attached/below), there seems not much going on on the CPU side, but obviously on network i/o (varying traffic is owed to switching between SDTV and HTDV).5a355e5be1b1c_Screenshotfrom2017-12-1618-53-42.thumb.png.5642dbae5efa85161bd652dd17912c39.png

Link to comment
Share on other sites

Strange. What you have on: 

 

ifconfig

Try changing CPU governor. I know it's probably unrelated but ...

edit /etc/defalt/cpufrequtils and change to performance

restart service

service cpufrequtils restart


 

 

Link to comment
Share on other sites

I changed to performance, stuttering is gone. Which is a real relief, as I would be able to migrate to armbian now. Is this a reasonable long-term solution, not sure about the effects of 'performance'? Btw. I just checked, bananian uses ondemand governor.

 

Presumably not relevant anymore, but this here is on ifconfig

root@tv:~# ifconfig
---snip---
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.28.97  netmask 255.255.255.0  broadcast 192.168.28.255
        inet6 fe80::4d:6ff:fe40:90e1  prefixlen 64  scopeid 0x20<link>
        ether 02:4d:06:40:90:e1  txqueuelen 1000  (Ethernet)
        RX packets 648141  bytes 43022905 (41.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1217295  bytes 1679524870 (1.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 50  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 11040  bytes 21360182 (20.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11040  bytes 21360182 (20.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

 

Link to comment
Share on other sites

3 minutes ago, oxymoron said:

I changed to performance, stuttering is gone. Which is a real relief, as I would be able to migrate to armbian now. Is this a reasonable long-term solution, not sure about the effects of 'performance'? Btw. I just checked, bananian uses ondemand governor.


There is some small science behind those governors and it's possible to fine tune it further but IMHO not really necessary in this use case. 

I am glad trick worked! 

Link to comment
Share on other sites

This is really weird, after some days it starting stuttering again. And the stuttering stays persistently, for days now. I have no clue why, I haven't been doing  anything on that machine - no package upgrades have been performed during that time, the workload on the machine is the same (i.e. same containers running on it), the only thing that happened was that the docker images have been rebuilt, but that can't be related really. Is there anything else I could try?

Link to comment
Share on other sites

I can confirm this behavior!

 

With an old installation of bananian with tvheadend

Linux bananapi 3.4.108-bananian #2 SMP PREEMPT Thu Aug 13 06:08:25 UTC 2015 armv7l GNU/Linux

everything works like a charm on several clients.

 

But with a new installation of armbian (latest updates installed) I can see the same "stuttering" on clients as mentioned above.

Linux bananapi 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l GNU/Linux

 

Link to comment
Share on other sites

I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382

 

Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html

 

I think that most promising workaround can be found in LE PR mentioned at the beginning.

 

Let me know if this is what you're after.

Link to comment
Share on other sites

Jernej,

 

I think that's it.

 

I am using a technotrend tt-connect s2-4600 on usb. As described here: Some get artifacts when watching livetv...

 

But I don't understand what I shoud do when using mainline-kernel >4.8! Did you mean this? Patching and recompiling kernel is a little bit too much for me...

Link to comment
Share on other sites

I managed to switch and try kernel 4.14.15 (via armbian-config > nightlies), 4.15.0-rc9 (via armbian config > switch kernel, after having switched to nightlies), and if I remember correctly also 4.14.0 (installed via apt-get). The process was a bit brittle, I lost USB HDD support in the one or other installation approach (e.g. I think nand-sata-install and kernel switch before apt-get upgrade and the system would not boot from USB anymore, not sure whether this makes sense), anyway it worked out at the end.

 

Indeed I'm using USB receivers - DVBSky 960.

 

As far as I can tell, 4.14.x did not make any difference to 4.13, heavy artefacts quite regularly. But 4.15 looks really good, only a few artefacts very infrequently, which is not perfect but definitely good enough. Thanks a lot for your effort!

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines