(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?

(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.

(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.

(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

(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.

(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.

(2017-05-23, 22:38)Vimes Wrote:

(2017-05-23, 21:46)popcornmix Wrote:

(2017-05-23, 20:56)Vimes Wrote: I have found that build 314 works fine but from build 315 on it fails.

Build 315....

http://forum.kodi.tv/showthread.php?tid=298461&pid=2549210#pid2549210

Yes there are a couple of bug reports:
https://github.com/Pulse-Eight/libcec/issues/342
https://github.com/Pulse-Eight/libcec/issues/343

and this commit is under suspicion:
https://github.com/Pulse-Eight/libcec/commit/67d444dd944192a31ab07637a4b57d27c890ede4

Perhaps Milhouse can try reverting that commit to confirm it is to blame.
If so you can add your voice to the libcec issues.

If Milhouse would feel that is appropriate then I could test and report accordingly.

Thanks for the links

(2017-05-24, 20:58)Milhouse Wrote:

(2017-05-23, 22:38)Vimes Wrote:

(2017-05-23, 21:46)popcornmix Wrote: Yes there are a couple of bug reports:
https://github.com/Pulse-Eight/libcec/issues/342
https://github.com/Pulse-Eight/libcec/issues/343

and this commit is under suspicion:
https://github.com/Pulse-Eight/libcec/commit/67d444dd944192a31ab07637a4b57d27c890ede4

Perhaps Milhouse can try reverting that commit to confirm it is to blame.
If so you can add your voice to the libcec issues.

If Milhouse would feel that is appropriate then I could test and report accordingly.

Thanks for the links

Can you test build #0523y: RPi2

It's similar to #0523, but with the following commits reverted:

https://github.com/Pulse-Eight/libcec/commit/d1a708b9401cc20efd44f8549edffc972e4786b0
https://github.com/Pulse-Eight/libcec/commit/67d444dd944192a31ab07637a4b57d27c890ede4

(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....?

(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.

• 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
  

1. Incorrect release code - should have been #0524 but I probably won't have time to do one tonight anyway so...
   
2. Enable mesa GLES support for Generic/RPi/RPi2 (nothing to see here, testing only)
   
3. Bump Samba 4.6.4
   

1. 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)
     
2. 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)
     
3. inputstream.adaptive:
   • [depends][windows] expat: build from source (6a183982)
     
   • [DASH]Don't normalize seg::range_begin at timelined templates (used to fill placeholders) (fe73f2db)
     
   • Merge branch 'master' of https://github.com/peak3d/inputstream.adaptive (c7721b63)
     
   • [SmoothStream] Fix tempate handling after cleanup (5f455dff)
     
   • Merge branch 'master' of https://github.com/peak3d/inputstream.adaptive (f1f5539d)
     
4. 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)
     
5. kernel 4.11.y:
   • New commits in this build:
     • [ARM64] enable drivers for GPIO expander and vcio (8cedda2b)
       

(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...