• 1
  • 55
  • 56
  • 57(current)
  • 58
  • 59
  • 168
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)
Latest release updated with build #0822b
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.
(2015-08-23, 00:26)popcornmix Wrote:
(2015-08-22, 21:25)polo_joe Wrote: What are the current hevc limits on rpi 2? resolution, bitrate

With these builds I think 1280x720 @ 1Mbit/s should always be safe.
Depending on encoding options 1280x720 at a few Mbit/s may work.
With overclock and the right encoding options you might get low bitrate 1080p.

Is someone working on further hevc improvement? Or is the limit reached.
(2015-08-21, 21:12)doveman2 Wrote:
(2015-08-21, 17:21)L-S-D Wrote: aspect ratio information is present in SI tables of the TS and in the video sequence header of the encoded video stream, so maybe Kodi relies on the one and your STB on the other and ITV4 only sets one of them correctly?

It's my TV's built-in tuner I'm using, not a STB. If my TV (and I imagine 99% of other TVs, or else people would be rather unhappy) correctly detects 4:3 programmes and Kodi doesn't, I'd venture to suggest that Kodi is looking in the wrong place for the information (maybe technically one of the right places but not in the one that everyone else has agreed to use).

I've made a few short recordings of different channels and on none of them does Kodi detect 4:3 (or at least it doesn't switch the view mode to Normal, which is what I've set for 4:3). Even The Simpsons on Ch4+1 didn't this time, when I thought it did before but it was on Ch4 before, so maybe there's a difference between the two channels.

For the first two recordings I captured the transition between the adverts (16:9) and the programme (4:3) which on my TV auto-switches between the two modes but did nothing on Kodi. Touched by an Angel seems to be in some strange format, as on Normal it has black space above and below (this is with the TV in 4:3 mode) and I have to switch it to Original to expand vertically, which sets the Zoom to 1.09. When I play the other recordings, they all use Stretch 16:9 for both the adverts and the programme but when I play Touched by an Angel again it auto-changes back to Original, which I'm not sure how it's managing as the default is set to Stretch 16:9 and "Display 4:3 videos as" is set to Normal.

ITV3+1 - On the Buses: https://drive.google.com/file/d/0B1fDI89...sp=sharing

Ch4 - The Simpsons: https://drive.google.com/file/d/0B1fDI89...sp=sharing

True Entertainment - Touched by an Angel: https://drive.google.com/file/d/0B1fDI89...sp=sharing

Yesterday - Secrets of War: https://drive.google.com/file/d/0B1fDI89...sp=sharing

All your samples play fine on Kodi Master on Linux x64, VLC and WMP. So it seems this is really a problem of the current RPi build. Doveman2s samples should make reproducing the error quite easy. Is there anything else we could help devs with?
FYI: Leopold has released version 4.17.0 of his OpenELEC Dev Update add-on - please make sure you update to this version if you use this add-on to download new builds.

A recent commit on OpenELEC master (PR:4285) has meant that previous versions of the Dev Update add-on might install RPi builds on RPi2 resulting in a non-booting system, or repeatedly suggest that a non-existant new build is available (even when you're running the latest available build). It's also possible the add-on may drop the tar file into /storage/.kodi/temp instead of the .update folder.

See issue #24 for details.

I'll continue reverting PR:4285 up to and including 29 August/#0829 so that versions of the Dev Update add-on prior to 4.17.0 will continue to work, and should give everyone sufficient time to upgrade their installed add-on. From 30 August/#0830 all pre-4.17.0 Dev Update bets will be off... Smile
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.
(2015-08-23, 07:06)polo_joe Wrote: Is someone working on further hevc improvement? Or is the limit reached.

There is additional work scheduled but the guy who can do it is busy on another project, but there will be further improvements in the future.
(2015-08-21, 06:19)illiac4 Wrote: In this sample file subtitles are shown on wrong side of the screen (left in the middle and not at the bottom) (you have to enable it if they are not shown). I know that in older versions it was playing fine but can not say when.
Using omx player.
File (size 13mb): http://bite-in.com/debug/24Kitchen-HD.ts

Popcornmix:did you maybe get a chance to look into this bug?
I installed 0822b this morning. I put on live TV (mythpvr and HDHomerun) using DVDPlayer and I noticed the image didn't look as smooth as it should. I brought up the OSD and it looks to be skipping 10fps or so. The feed was 720p. I played a 720p recording and it did the same thing. I switched back to OMX and it looks fine. The OSD doesn't seem to show if it's skipping or dropping frames, but the video looks like it should.

I will do some more testing later with 1080i and SD TV channels to see if I can provide more information. I have to go right now though.
Experience: It's what you get when you were expecting something else.
I didn't realised hevc encoding is problematic even for RP2 until I started watching a movie yesterday encoded in720p hevc, feels a bit dissapointed as I was under impression that it should have worked fluidly on this hardware.

I gotta say video qualty for a given size is just insane, hopefully things can get for a better in a future.
(2015-08-21, 06:19)illiac4 Wrote: In this sample file subtitles are shown on wrong side of the screen (left in the middle and not at the bottom) (you have to enable it if they are not shown). I know that in older versions it was playing fine but can not say when.
Using omx player.
File (size 13mb): http://bite-in.com/debug/24Kitchen-HD.ts

I can see the problem but it's no pi specific. It behaves the same with a master build on x86/linux. Might be worth reporting here:
http://forum.kodi.tv/showthread.php?tid=236232
(2015-08-23, 16:31)banesi Wrote: I didn't realised hevc encoding is problematic even for RP2 until I started watching a movie yesterday encoded in720p hevc, feels a bit dissapointed as I was under impression that it should have worked fluidly on this hardware.

I gotta say video qualty for a given size is just insane, hopefully things can get for a better in a future.

On the contrary, I've had little problem running 720p hevc on a slightly overclocked rpi2.
New OpenELEC Jarvis build #0823: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.1.6 #1 Sun Aug 23 22:34:38 BST 2015 armv6l GNU/Linux

# vcgencmd version
Aug 23 2015 19:27:51
Copyright (c) 2012 Broadcom
version 41b1f861989dc4d1bbe19a52361a248ae57ee82b (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150823223350-#0823-gc06668c [Build #0823]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (c06668c5, changelog) and tip of XBMC master (183b2138, changelog) with the following modifications: Build Highlights:
  1. New firmware, with what looks like an advanced deinterlace optimisation
  2. Seek fix (presumably this issue)
  3. Fix DVD subtitles (PR:7878)
  4. Update openssh-7.1p1
Build Details:
  1. Firmware (Aug 23):
    • firmware: di_adv: Only acquire ush once per file not per frame
  2. OpenELEC:
    • kodi: add Isengard backports (5ffa1818)
    • openssh: update to openssh-7.1p1 (91c934d4)
    • mesa: update to mesa-10.6.5 (44b07022)
    • linux: enable net.ipv4.tcp_no_metrics_save (c06668c5)
  3. XBMC:
    • [gui] fix CGUIDialogSelect::GetSelectedItem not returning the selected item (PR:7868, 1 commit, 2 files changed)
  4. newclock4:
    • New commits in this build:
      • [omxplayer] Flush EOS message from queue to avoid it turning up after a seek (4faad781)
  5. Additional commits/pull requests/changes not yet merged upstream:
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.
@Leopold - are you still experiencing libnfs-related crashes with recent builds, or have they stopped now?
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.
@illiac4 try the latest build with your misplaced subs file.
@doveman2 test if your seeking hang is fixed.
(2015-08-23, 14:43)afremont Wrote: I installed 0822b this morning. I put on live TV (mythpvr and HDHomerun) using DVDPlayer and I noticed the image didn't look as smooth as it should. I brought up the OSD and it looks to be skipping 10fps or so. The feed was 720p. I played a 720p recording and it did the same thing. I switched back to OMX and it looks fine. The OSD doesn't seem to show if it's skipping or dropping frames, but the video looks like it should.

I will do some more testing later with 1080i and SD TV channels to see if I can provide more information. I have to go right now though.

To add to this, it seems to only apply to 720p for some reason. The skip count is incrementing 20 times per second and the audio gets way ahead of the video in a hurry.

Here is a screenshot. Check out that audio error percentage on the S line. Every so often it resyncs and then gets progressively worse:
http://imgur.com/ma8tcSq

EDIT: I downloaded 0823 and it does the same thing.
Experience: It's what you get when you were expecting something else.
@popcornmix

Have you had a look at the test file I provided earlier and the debug logs and such from Milhouse? I am still experiencing the same crashes.
  • 1
  • 55
  • 56
  • 57(current)
  • 58
  • 59
  • 168

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 16.0)10