How is H265 performing now?
What formats seem to be working? e.g. 8bit 1080p @ 25, 30, 50, 60 fps?
anyone willing to post a clip onto you tube?
(2017-05-24, 11:48)fsman1967 Wrote: [ -> ]How is H265 performing now?
What formats seem to be working? e.g. 8bit 1080p @ 25, 30, 50, 60 fps?
I'm finding all my movies/tvshows at 8-bit 1080p24 play fine without overclock and with fairly low arm cpu.
25 and 30fps are much less common. I'd imagine no problems with 25, but 30 may require overclocking.
We will never do 1080p at 50 or 60fps without dedicated hardware.
My 720p50 samples do play fine.
(2017-05-24, 13:38)popcornmix Wrote: [ -> ] (2017-05-24, 11:48)fsman1967 Wrote: [ -> ]How is H265 performing now?
What formats seem to be working? e.g. 8bit 1080p @ 25, 30, 50, 60 fps?
I'm finding all my movies/tvshows at 8-bit 1080p24 play fine without overclock and with fairly low arm cpu.
25 and 30fps are much less common. I'd imagine no problems with 25, but 30 may require overclocking.
We will never do 1080p at 50 or 60fps without dedicated hardware.
My 720p50 samples do play fine.
Good to konw.
I would have thought that only at 1080p and above would h265 really make a big difference in verse h264.
I think I read that 720p not much difference of 264 vs 265.
Great work btw. I am actually thinking o f replacing my Rpi2 for a Rpi3 just on the basis of your work on h665
(2017-05-24, 14:06)fsman1967 Wrote: [ -> ]I would have thought that only at 1080p and above would h265 really make a big difference in verse h264.
I think I read that 720p not much difference of 264 vs 265.
I don't believe that is true.
HEVC is getting around 50% saving in bitrate for same quality across UHD, 1080, 720p and 480p in paper linked from
here.
One issue currently is the H.264 encoders are much more mature than HEVC.
It may be easier to produce a good encode from a H.264 encoder as options are well understood.
(2017-05-24, 14:06)fsman1967 Wrote: [ -> ] (2017-05-24, 13:38)popcornmix Wrote: [ -> ] (2017-05-24, 11:48)fsman1967 Wrote: [ -> ]How is H265 performing now?
What formats seem to be working? e.g. 8bit 1080p @ 25, 30, 50, 60 fps?
I'm finding all my movies/tvshows at 8-bit 1080p24 play fine without overclock and with fairly low arm cpu.
25 and 30fps are much less common. I'd imagine no problems with 25, but 30 may require overclocking.
We will never do 1080p at 50 or 60fps without dedicated hardware.
My 720p50 samples do play fine.
Good to konw.
I would have thought that only at 1080p and above would h265 really make a big difference in verse h264.
I think I read that 720p not much difference of 264 vs 265.
Great work btw. I am actually thinking o f replacing my Rpi2 for a Rpi3 just on the basis of your work on h665
To back up what Popcornmix has said, I am using test files generated using HandBrake.
I use a 4K original that I re sample down to lower resolutions, it has a lot of movement and high detail.
At 1280x720 (720p) @ 31Hz full screen plays perfectly at almost any quality setting, Handbrake recommend using 20 to 18 quality, (for some reason the lower the number the higher the quality) I've generated files using 12 quality which still play perfectly, which is a 125MB file for a 2 minute clip. This is true for both a Pi2 and a Pi3.
For 1920x1080 (1080p) HandBrake recommends a quality factor of 23 to 20, again lower is higher quality.
The 1920x1080 @ 31Hz full screen will also play perfectly on both a Pi2 and Pi3 but using slightly less quality than the 1280x720 sample.
On a Pi2 I can get to a quality factor of 24, I use 25 to compress my videos anyway, so that works just great. File size for this is 46MB for a 2 minute clip.
On a Pi3 I can get down to a quality factor of 15, so way better than HandBrake recommends. File size for this is 156MB for the same 2 minute clip.
So if you don't want or need perfect quality, a Pi2 will actually do the job.
Both my Pis are slightly over clocked and have a good heat sink, no fan.
Hope this helps.
Kevin.
(2017-05-24, 16:47)bleep42 Wrote: [ -> ] (2017-05-24, 14:06)fsman1967 Wrote: [ -> ] (2017-05-24, 13:38)popcornmix Wrote: [ -> ]I'm finding all my movies/tvshows at 8-bit 1080p24 play fine without overclock and with fairly low arm cpu.
25 and 30fps are much less common. I'd imagine no problems with 25, but 30 may require overclocking.
We will never do 1080p at 50 or 60fps without dedicated hardware.
My 720p50 samples do play fine.
Good to konw.
I would have thought that only at 1080p and above would h265 really make a big difference in verse h264.
I think I read that 720p not much difference of 264 vs 265.
Great work btw. I am actually thinking o f replacing my Rpi2 for a Rpi3 just on the basis of your work on h665
To back up what Popcornmix has said, I am using test files generated using HandBrake.
I use a 4K original that I re sample down to lower resolutions, it has a lot of movement and high detail.
At 1280x720 (720p) @ 31Hz full screen plays perfectly at almost any quality setting, Handbrake recommend using 20 to 18 quality, (for some reason the lower the number the higher the quality) I've generated files using 12 quality which still play perfectly, which is a 125MB file for a 2 minute clip. This is true for both a Pi2 and a Pi3.
For 1920x1080 (1080p) HandBrake recommends a quality factor of 23 to 20, again lower is higher quality.
The 1920x1080 @ 31Hz full screen will also play perfectly on both a Pi2 and Pi3 but using slightly less quality than the 1280x720 sample.
On a Pi2 I can get to a quality factor of 24, which is what I already use to compress my videos anyway, so that's great. File size for this is 46MB for a 2 minute clip.
On a Pi3 I can get down to a quality factor of 18, so way better than HandBrake recommends. File size for this is 104MB for the same 2 minute clip.
So if you don't want or need perfect quality, a Pi2 will actually do the job.
Both my Pis are slightly over clocked and have a good heat sink, no fan.
Hope this helps.
Kevin.
Wow - very detailed. Many thanks. I thought the RPI2 wouldn't handle it, especially as the RPI3 have a higher clocked GPU vs. the PI2.
(2017-05-24, 17:01)fsman1967 Wrote: [ -> ]Wow - very detailed. Many thanks. I thought the RPI2 wouldn't handle it, especially as the RPI3 have a higher clocked GPU vs. the PI2.
Actually the firmware is able to request a clock boost in various scenarios.
HEVC is one where core_freq=400 and v3d_freq=300 is requested on both Pi2 and Pi3.
(if you have manually specified a higher overclock you will get the higher overclock).
The Pi3 does have a higher arm frequency and double width NEON so it can handle harder HEVC files.
(2017-05-24, 23:18)Vimes Wrote: [ -> ]I have just got home and tested it now and I can happily confirm that it works a treat. The Pi3 was fully powered off with the TV on standby. Then the power was applied to the Pi3 and when it started to power up the TV switched on then switched to the correct HDMI input of the PI3.
Great work and most appreciated 
What will this mean now, in terms of those reverted commits....?
Please report it to @
opdenkamp on the Pulse-Eight github in either of those existing bug reports. It really needs fixing upstream, as reverting those commits doesn't really fix the issue.
(2017-05-24, 23:34)Milhouse Wrote: [ -> ] (2017-05-24, 23:18)Vimes Wrote: [ -> ]I have just got home and tested it now and I can happily confirm that it works a treat. The Pi3 was fully powered off with the TV on standby. Then the power was applied to the Pi3 and when it started to power up the TV switched on then switched to the correct HDMI input of the PI3.
Great work and most appreciated
What will this mean now, in terms of those reverted commits....?
Please report it to @opdenkamp on the Pulse-Eight github in either of those existing bug reports. It really needs fixing upstream, as reverting those commits doesn't really fix the issue.
Will do and thanks again.
Reported....
https://github.com/Pulse-Eight/libcec/co...27c890ede4
hopefully that might help, although I did notice that it had already been reported 28 days ago, with no comment. The person making those commits has not been active this month.
New LibreELEC.tv Leia build #0525:
RPi /
RPi2
(Supercedes previous build)
Code:
# uname -a
Linux rpi512 4.11.2 #1 Thu May 25 02:25:31 BST 2017 armv6l GNU/Linux
# vcgencmd version
May 15 2017 17:01:07
Copyright (c) 2012 Broadcom
version 9469ea3706e34c4de62f38a5008f69a429b4b43e (clean) (release)
# lsb_release
LibreELEC (Milhouse) - Version: devel-20170525022341-#0525-g856d624 [Build #0525]
# Kodi version
(18.0-ALPHA1 Git:61e98fd). Platform: Linux ARM 32-bit
Based on tip of
LibreELEC.tv master (856d6246,
changelog) and tip of
XBMC master (1a38948a,
changelog) with the following modifications:
- Includes newclock5 patches
- Excludes the LibreELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.11.y
- Includes latest bcm2835-driver master (b9dbf8cf, ahead +5)
- Includes latest kodi-platform master (36fb4937)
- Includes latest libcec master (3953f8dc, ahead +12)
- Includes latest libnfs master (eee1b4f7, ahead +94)
- Includes latest p8-platform master (2d90f986)
- Includes latest addons: inputstream.adaptive (f1f5539d, +3), inputstream.rtmp (d93d32d4), peripheral.joystick (f49fa337, +5), pvr.argustv (b281e04f), pvr.demo (ffee02b8), pvr.dvblink (6d42eae1), pvr.dvbviewer (3f05af60), pvr.filmon (300c595e), pvr.hdhomerun (9073b99b), pvr.hts (7f998e0f), pvr.iptvsimple (dbf6011e), pvr.mediaportal.tvserver (07d73f3a), pvr.mythtv (f2da22ca), pvr.nextpvr (239dbef3), pvr.njoy (4785afd2), pvr.octonet (3494c4c4, +6), pvr.pctv (f61e2541), pvr.stalker (151e3d3f), pvr.vbox (df9efea4), pvr.vdr.vnsi (40dc17d0), pvr.vuplus (83a729ea), pvr.wmc (93cebfc7), vfs.rar (4ce78b0f)
- Include [env] compare: kodi18a1 latest updates
- Include [env] compare: linux: update to linux-4.11.2
- Include [env] patch: Bump included addon versions to prevent online updates
- Include [env] patch: Add experimental splash video for RPi
- Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
- Include [env] patch: Add kodi binary addons (pvr, adsp, inputstream, vfs, other)
- Include [env] PR:1469: samba: update to samba-4.6.4
- Include [env] PR:1635: firmware: install wifi firmware from linux-firmware, cleanup wlan-firmware
- Include [pkg] PR:67: Revert "Revert "change smbd and nmbd location"" (service.libreelec.settings)
- Include [pkg] PR:12034: KODI: Update NEON support
- Include [pkg] PR:12110: smbclient: cleanup smbclient configuration
Build Highlights:
- Incorrect release code - should have been #0524 but I probably won't have time to do one tonight anyway so...
- Enable mesa GLES support for Generic/RPi/RPi2 (nothing to see here, testing only)
- Bump Samba 4.6.4
Build Details:
- LibreELEC.tv:
- linux: enable fq_codel for all projects (PR:713, 2 commits, 9 files changed)
- Enable mesa GLES support for Generic/RPi/RPi2 (PR:1395, 9 commits, 8 files changed)
- XBMC:
- [osx/windowing] - fix regression after removing deprecated video mode enumeration API (PR:12152, 2 commits, 1 file changed)
- [fix] gcc 4.8 doesn’t correctly implement std::regex (PR:12154, 1 commit, 4 files changed)
- allow using VAAPI with OpenGLES (PR:12113, 7 commits, 12 files changed)
- inputstream.adaptive:
- peripheral.joystick:
- Minor fixes and improvements (PR:104, 3 commits, 2 files changed)
- [xinput] Add motors to built-in button map (PR:103, 1 commit, 2 files changed)
- Preserve underscores in file name (PR:102, 1 commit, 1 file changed)
- kernel 4.11.y:
- New commits in this build:
- [ARM64] enable drivers for GPIO expander and vcio (8cedda2b)
In build #0525 does not work the multimedia keys (stop, play, pause, rec etc.).
Pansonic TX-50EXW784 - remote control.
From build to build, the one works the other no function...
(2017-05-25, 17:42)Aux_ Wrote: [ -> ]In build #0525 does not work the multimedia keys (stop, play, pause, rec etc.).
Pansonic TX-50EXW784 - remote control.
From build to build, the one works the other no function...
Have you tried this:
http://forum.kodi.tv/showthread.php?tid=...pid1367645
I have a Panasonic and find those buttons occasionally stop working.
Unplugging from main all CEC devices (e.g. TV) may also help.