• 1
  • 6
  • 7
  • 8(current)
  • 9
  • 10
  • 89
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2
(2015-04-16, 20:13)Patrics83 Wrote: With #0406+ builds I have noticed that the reported FPS in kodi system summary goes down to ~7 when idle and 30-40 when scrolling the menu and while playing a movie it's low again around 1-9fps.
#0405 sits at 30fps when idle and when playing the same movie at 25fps.

Lower fps reported is correct. It no longer counts frames that were skipped when nothing had changed:
https://github.com/xbmc/xbmc/pull/6872
Ok, that makes sense.

I will make a sample now.
For info, I build libvpx and enable it in ffmpeg ( --disable-decoder=vp9 --enable-libvpx ) instead of built-in vp9 decoder, it's a little faster but not enough to play vp9 files at 720p or 1080p. Sad
New OpenELEC Isengard build #0416: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.0.0 #1 Thu Apr 16 21:04:02 BST 2015 armv6l GNU/Linux

# vcgencmd version
Apr 11 2015 17:37:07
Copyright (c) 2012 Broadcom
version 311b05fb4e33655a083a6f65b645e6a14e322803 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150416210232-#0416-gacf36ec [Build #0416]

# vcdbg log msg 2>&1 | grep DTOK
001541.787: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (acf36ec4, changelog) and tip of XBMC master (84ee4bcd, changelog) with the following modifications: Build Highlights:
  1. Several newclock4 omxplayer commits merged
  2. dcadec: add support for DTS-CD
Build Details:
  1. XBMC:
    • [depends] Update libmicrohttpd to SVN 35533 (PR:6892, 2 commits, 3 files changed)
    • Quell warnings and fix include paths (PR:6915, 10 commits, 10 files changed)
    • [pvr] expose timer epg info for listitem labels (PR:6962, 1 commit, 3 files changed)
    • [OMXAudio] Make stereoupmix and fixed behave more like dvdplayer (PR:6954, 1 commit, 1 file changed)
    • [omximage] Increase timeout - this is sometimes hit (PR:6959, 1 commit, 1 file changed)
    • [rbp] Add Pi 2 specific settings defaults (PR:6958, 1 commit, 3 files changed)
    • [UX] improve some strings used in settings (PR:6890, 11 commits, 2 files changed)
    • [omxplayer] Handle failures from EmptyThisBuffer and FillThisBuffer (PR:6957, 1 commit, 5 files changed)
    • [improvement] Include MusicVideos when creating playlists (PR:6606, 1 commit, 3 files changed)
    • [rbp] Disable analogue output of sink when passthrough is enabled (PR:6955, 1 commit, 4 files changed)
  2. dcadec:
    • Refactor packet buffer reallocation. (159e9e83)
    • Replace magic constants with error codes. (5c5205db)
    • Define and use alignment macro. (77ee8820)
    • Add frame syncing and bitstream conversion APIs. (84b77a1b)
  3. pvr.wmc:
    • [pvr] pvr.wmc version 0.5.3 (PR:4, 4 commits, 15 files changed)
  4. newclock4:
    • New commits in this build:
      • [mmalcodec] Return mmal buffers explicitly (7163a266)
      • [mmalcodec] Handle resolution change from callback (d48fb099)
    • Commits no longer in build:
      • [omximage] Increase timeout - this is sometimes hit (8761620a)
      • [rbp] Add Pi 2 specific settings defaults (3c28e7c5)
      • [omxplayer] Handle failures from EmptyThisBuffer and FillThisBuffer (97e656c7)
      • [OMXAudio] Make stereoupmix and fixed behave more like dvdplayer (1a70af6c)
      • [omximage] Increase timeout on encode (095851db)
      • [rbp] Disable analogue output of sync when passthrough is enabled (fc692413)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
During video playback - omxplayer - GUI is very slow.

Affected (Pi2) builds are: #0414, #0415 and #0416.

Build #0413 is fine.

Attached #0414 log:
http://pastebin.com/icFWLhWf
@slack3r - this is by intention and there is a setting for it (limit GUI updates when playing video).
(2015-04-17, 10:26)da-anda Wrote: @slack3r - this is by intention and there is a setting for it (limit GUI updates when playing video).

Thank you da-anda, but I think something is broken:
only setting 'GUI updates limit' to "unlimited" solves the issue.
(2015-04-17, 07:37)slack3r Wrote: During video playback - omxplayer - GUI is very slow.

Affected (Pi2) builds are: #0414, #0415 and #0416.

Build #0413 is fine.

What do you do with GUI when video is playing? Just OSD interaction, or are you backgrounding video and then browsing through menus?
(2015-04-16, 22:13)fab67 Wrote: For info, I build libvpx and enable it in ffmpeg ( --disable-decoder=vp9 --enable-libvpx ) instead of built-in vp9 decoder, it's a little faster but not enough to play vp9 files at 720p or 1080p. Sad

Does it make use of all cores?
Any view on how much faster it is? E.g. if you play an SD file what is the percentage CPU with default ffmpeg and libvpx?
(2015-04-17, 12:49)popcornmix Wrote:
(2015-04-17, 07:37)slack3r Wrote: During video playback - omxplayer - GUI is very slow.

Affected (Pi2) builds are: #0414, #0415 and #0416.

Build #0413 is fine.

What do you do with GUI when video is playing? Just OSD interaction, or are you backgrounding video and then browsing through menus?


I mean backgrounding video and browsing through menus: it is very, very slow. Try jumping at home screen and browse items.
(2015-04-17, 13:11)slack3r Wrote: I mean backgrounding video and browsing through menus: it is very, very slow. Try jumping at home screen and browse items.

To be honest I've never wanted to do this. Is this something you regularly do, or are you just stress testing.
The intention with the recent update is that the GUI runs at 10fps and video at full rate. The gui shouldn't be slower, it should just update less often so may look less smooth.
Possibly something else is going wrong - I'll need to test this.

Obviously there are some cases where rendering the GUI at full rate, and rendering video at full rate are not both possible
(e.g. 1080i video deinterlaced to 60fps running in PVR preview/channel window), and we need to decide whether smooth video or smooth UI is preferable.
(2015-04-17, 13:23)popcornmix Wrote:
(2015-04-17, 13:11)slack3r Wrote: I mean backgrounding video and browsing through menus: it is very, very slow. Try jumping at home screen and browse items.

To be honest I've never wanted to do this. Is this something you regularly do, or are you just stress testing.
The intention with the recent update is that the GUI runs at 10fps and video at full rate. The gui shouldn't be slower, it should just update less often so may look less smooth.
Possibly something else is going wrong - I'll need to test this.

Obviously there are some cases where rendering the GUI at full rate, and rendering video at full rate are not both possible
(e.g. 1080i video deinterlaced to 60fps running in PVR preview/channel window), and we need to decide whether smooth video or smooth UI is preferable.

I do this to check hardware temperature, for example. I know, it's not essential for normal usage, but with last three builds GUI seems running at 1-2 frames per second.
For me, the 0416 build is one of the best I've seen on my RPi2 for video playback. I'm only using dvdplayer and have disabled omxplayer. Everything just worked quite well... Skipping back and forth by large and small amounts, deinterlacing 1080i60, playing back 1080p60. I'm totally fine with the GUI updates being a second priority when video is playing.
(2015-04-17, 15:02)zaphod24 Wrote: For me, the 0416 build is one of the best I've seen on my RPi2 for video playback. I'm only using dvdplayer and have disabled omxplayer. Everything just worked quite well... Skipping back and forth by large and small amounts, deinterlacing 1080i60, playing back 1080p60. I'm totally fine with the GUI updates being a second priority when video is playing.

Thanks for reporting. Please continue to report when things improve in builds as well as when things get worse.

I don't typically use PVR/live tv/deinterlace, but from time to time I test files using the IPTV PVR addon (which behaves somewhat like real PVR) and may make changes that appear to improve its behaviour. However I'm never very sure if the changes help real PVR use, and so if no one comments on the change, I may drop it as not having a proven benefit.
I use the rp1 with LiveTV and HD channels (1080i 50) and the channels mini OSD ('c' key) is painfully slow. It doesn't matter if I change the GUI updates limit to 10, 25 or unlimited.
  • 1
  • 6
  • 7
  • 8(current)
  • 9
  • 10
  • 89

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 214