Bug 376893

Summary: Bad performance of kaffeine when watching HD channels compared to VLC and other players
Product: [Applications] kaffeine Reporter: yulinux
Component: generalAssignee: Mauro Carvalho Chehab <mchehab>
Status: RESOLVED NOT A BUG    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: kaffeine --debug using libVLC with args: -v
kaffeine --debug using libVLC with args: -vv
vlc -vv

Description yulinux 2017-02-24 17:59:02 UTC
Created attachment 104205 [details]
kaffeine --debug using libVLC with args: -v

Hello,
I watch DVB-T2 HD channels in H.265 but the video stutters. This problem does not appear in VLC, SMPlayer or the Gnome Video player. I can record a movie in kaffeine, and watch it without stuttering with VLC at the same time. So it is not that the computer is not fast enough to handle it.
If I play the record with kaffeine, all 4 cores are almost at 100% and the complete system (and the cursor) becomes a sluggish. (The sluggish cursor is a known bug/disadvantage of using wayland under heavy load.)

If I play the file in any other player, the video and the system is completely fine, although the 4 cores are at ~ 80 %.

I have no graphics acceleration via VDPAU for video decoding of H.265. I have an AMD RS880 chip, that supports VDPAU, but not for the 'newer' H.265. 

I tried many possibilities of libvlc parameters, but did not get it to work like in VLC. I was even unsure if those parameters had any effect, partly. The attached logs show kaffeine --debug with libvlc -v and -vv, as well as a working vlc -vv for comparison.

Some parameters of my system: Fedora 25, but with vanilla linux 4.10, x86_64. I use Gnome 3 under wayland. kaffeine from today's GIT.

Any ideas? 
Thanks in advance.
Comment 1 yulinux 2017-02-24 18:13:29 UTC
Created attachment 104206 [details]
kaffeine --debug using libVLC with args: -vv
Comment 2 yulinux 2017-02-24 18:14:35 UTC
Created attachment 104207 [details]
vlc -vv
Comment 3 Mauro Carvalho Chehab 2017-07-09 23:14:59 UTC
Could you try again against Kaffeine -git? There were some bad performance issues related to EPG handled that got fixed a few versions ago, and we just fixed some CPU performance issues while sending data to libVLC.
Comment 4 yulinux 2017-07-12 19:32:51 UTC
I just freshly installed the new Fedora 26 and compiled kaffeine from git. In my case there is no difference between git and the last version, but it is pretty smooth most of the time now. This has nothing to do with changes of kaffeine, though.

The problem was the VDPAU package, that should actually accelerate the video processing. Because after installing the package mesa-vdpau-drivers and enable it via "$ export VDPAU_DRIVER=r600" (known bug in fedora, see e.g. [1]), it starts stuttering. After removing the package it works okay again. Although all 4 cores are at ~100%. 
Maybe also other changes of the new system are relevant.

So it seems not to be a problem of kaffeine alone, but more like a problem of VDPAU. Or the use of VDPAU of libVLC when the used codec is not supported. VDPAU on my GPU does not support H.265. But as VDPAU development seems not very active any more and my hardware is also relatively "old", probably it's not worth to investigate further.

Thanks!


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1305699
Comment 5 Mauro Carvalho Chehab 2017-07-13 13:45:00 UTC
(In reply to yulinux from comment #4)
> I just freshly installed the new Fedora 26 and compiled kaffeine from git.
> In my case there is no difference between git and the last version, but it
> is pretty smooth most of the time now. This has nothing to do with changes
> of kaffeine, though.
> 
> The problem was the VDPAU package, that should actually accelerate the video
> processing. Because after installing the package mesa-vdpau-drivers and
> enable it via "$ export VDPAU_DRIVER=r600" (known bug in fedora, see e.g.
> [1]), it starts stuttering. After removing the package it works okay again.
> Although all 4 cores are at ~100%. 
> Maybe also other changes of the new system are relevant.
> 
> So it seems not to be a problem of kaffeine alone, but more like a problem
> of VDPAU. Or the use of VDPAU of libVLC when the used codec is not
> supported. VDPAU on my GPU does not support H.265.

Yeah, HEVC support is restricted to a few GPUs.

> But as VDPAU development
> seems not very active any more and my hardware is also relatively "old",
> probably it's not worth to investigate further.
> 
> Thanks!
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1305699

Thanks for testing and providing the above information. I added a
summary of the above at README.md, with will hopefully help others
that may have troubles setting vdpau:

https://commits.kde.org/kaffeine/a16fdee4de0f007874cd9aff3fbe93731e8473f9

README.md: Add an extra section about vdpau settings

Properly setting vdpau may reduce CPU usage on Kaffeine.
So, add a chapter describing how to do it in order to
workaround for a few known issues.
Comment 6 Mauro Carvalho Chehab 2017-07-13 14:18:55 UTC
(In reply to Mauro Carvalho Chehab from comment #5)
> (In reply to yulinux from comment #4)
> > I just freshly installed the new Fedora 26 and compiled kaffeine from git.
> > In my case there is no difference between git and the last version, but it
> > is pretty smooth most of the time now. This has nothing to do with changes
> > of kaffeine, though.
> > 
> > The problem was the VDPAU package, that should actually accelerate the video
> > processing. Because after installing the package mesa-vdpau-drivers and
> > enable it via "$ export VDPAU_DRIVER=r600" (known bug in fedora, see e.g.
> > [1]), it starts stuttering. After removing the package it works okay again.
> > Although all 4 cores are at ~100%. 
> > Maybe also other changes of the new system are relevant.

I did some tests here with Intel driver. Using va-gl driver, on an H.264 HD channel, it is using ~100% cpu total:

top - 14:15:20 up 22 min,  4 users,  load average: 1,13, 0,82, 0,54
Tasks: 221 total,   1 running, 220 sleeping,   0 stopped,   0 zombie
%Cpu0  : 26,5 us,  0,7 sy,  0,0 ni, 71,2 id,  1,0 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu1  : 25,9 us,  1,0 sy,  0,0 ni, 70,8 id,  1,3 wa,  0,0 hi,  1,0 si,  0,0 st
%Cpu2  : 28,8 us,  0,7 sy,  0,0 ni, 68,6 id,  1,3 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu3  : 21,5 us,  0,0 sy,  0,0 ni, 77,4 id,  0,3 wa,  0,0 hi,  0,7 si,  0,0 st
KiB Mem : 16313332 total, 12070956 free,   925672 used,  3316704 buff/cache
KiB Swap: 31731708 total, 31731708 free,        0 used. 14800628 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                   
 7689 mchehab   20   0 3514688 300020  96892 S 104,0  1,8   0:13.23 kaffeine                                                                                                                  

If I force, instead, to not use vdpau, by passing an invalid driver name to VDPAU_DRIVER, e. g.:

export VDPAU_DRIVER=none

Top shows a CPU load of ~85% and a lower load average:

top - 14:16:17 up 23 min,  4 users,  load average: 1,09, 0,88, 0,58
Tasks: 222 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
%Cpu0  : 20,9 us,  0,3 sy,  0,0 ni, 78,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
%Cpu1  : 30,7 us,  1,3 sy,  0,0 ni, 67,6 id,  0,0 wa,  0,0 hi,  0,3 si,  0,0 st
%Cpu2  : 19,8 us,  0,3 sy,  0,0 ni, 79,2 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
%Cpu3  : 19,3 us,  0,0 sy,  0,0 ni, 80,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem : 16313332 total, 12170628 free,   891132 used,  3251572 buff/cache
KiB Swap: 31731708 total, 31731708 free,        0 used. 14900388 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                                                   
 7716 mchehab   20   0 3330868 264148  95664 S  88,0  1,6   0:09.00 kaffeine