•   
  • 1
  • 273
  • 274
  • 275
  • 276(current)
  • 277
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi Part 2
There's quite a bit of info in each new build post that milhouse makes. Is the "Build Highlights" in the posts the changelog as such? So I can just skim through that to see what's changed?
It's not the complete changelog, but the 'highlights' as the title says. So yes, that's the reason it's there.
quick question regarding DVDPlayer and DTS. I've read that when using DVDPlayer to play video file with DTS performace drops? Or at least CPU usage goes sky high. Is that true?
DVDPLayer has more demands in terms of CPU and GPU memory. But it is capable of playing DTS tracks on a PI (at least it works fine on my overclocked pi).
GPU memory could be set to 192 if you are experiencing problems.
(2014-04-15, 11:02)ijsbeer79 Wrote: DVDPLayer has more demands in terms of CPU and GPU memory. But it is capable of playing DTS tracks on a PI (at least it works fine on my overclocked pi).
GPU memory could be set to 192 if you are experiencing problems.

1080p works as well?
Software DTS decoding with 1080p is to slow with dvdplayer here; 100% CPU and lots of stutter. It runs fine for me with passthrough you need a DTS capable reciever though. It think its normal ie. no optimizations yet? I'm running 1100/500/500/ +6 with force_turbo=1.

On another matter software DTS-MA and Dolby-HD plays fine with omxplayer. Official beta 5 can't handle it. Also 1080p.
(2014-04-11, 11:31)tomer953 Wrote:
(2014-04-10, 11:53)MilhouseVH Wrote: @tomer953: Can you confirm the same behaviour with OpenELEC 4 Beta 5?

Yes.
Same Problem...
Remote not responding untill i "activated" xbmcwith iphone app

Still same problem
Tv remote stop working with hdmi-cec after few minutes on other source.
Iphone app working fine - someone after moving arrows with the iphobe app the remote is work again, and sometimes not and restart needed.

Also airplay from youtube is only video and no sound (wierd)

3.9.5 official
Phenomenal™ Skin • ForumWebsiteGitHub
(2014-04-15, 11:41)tuxen Wrote: Software DTS decoding with 1080p is to slow with dvdplayer here to 100% CPU and lots of stutter. It runs fine for me with passthrough you need a DTS capable reciever though. It think its normal ie. no optimizations yet? I'm even running 1100/500/500/ +6 with force_turbo=1.

On another matter software DTS-MA and Dolby-HD plays fine with omxplayer. Official beta 5 can't handle it. Also 1080p.

I've got DTS capable receiver, so this is not a problem. On the other hand, it is an old one without HDMI input, so I have to use USB DAC to get the optical audio out. And as I understand it adds additional load.
I will test it today after work, if it does not work without a stuttering, I may have to think about HiFiBerry Digi, apparently I2S interface has less overhead than USB.
Is MilhouseVH part of the OpenELEC team? Are these builds nightlies that eventually become the official OpenELEC betas?
No I'm not part of any team. These builds have patches that may eventually (hopefully) be accepted "upstream" in XBMC, and before that may also be cherry-picked by OpenELEC in official betas. OpenELEC master (not Beta 5, but should be in Beta 6 or whatever comes next) includes a subset of the newclock3 patches in the gotham-rbp-backports patch, this currently has 63 of the approx 90 newclock3 patches.

And about the "Build Highlights" - this is just what I consider to be the most noteworthy changes in that particular build. If you want the full list of changes in each build, click on the "changelog" links for XBMC and OpenELEC.
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.
Thanks. Would you clarify what newclock3 is? Are they the patches you've prepared for your ongoing builds?
(2014-04-14, 22:50)host505 Wrote:
(2014-04-14, 17:26)host505 Wrote: I just noticed that on 3D, the aspect ratio switching doesn't affect the actual video at all, only the masking (the black bars). Video is stretched to 16:9 by default and this does not change at any setting, it just adds black bars on some settings (stretch 16:9, stretch 4:3... all actually exept zoom) covering part of the video.
That's why 16:9 videos look ok.

OK tried a 3D Top/Bottom 2.35:1 video, no stretching here, movie looks normal, but, aspect ratio changing has the same behaviour. No actual effect on the video itself, just the letterbox bars appear depending the ar mode, covering part of the video.

Tested the same files with 411b and all look proper (aspect-ratio-wise). Again aspect ratio switching doesn't affect actual video but only the masking, I assume this is how it is supposed to work on 3D?

So, I guess this is the cause:
Quote:[omxplayer] Fix for 3d video in mono mode. The test for no aspect wasn't correct, causing large black bars
The link to the newclock3 patches is present in each release post. They're a collection of bug-fix/performance patches mostly from popcornmix who works at the Raspberry Pi Foundation/Broadcom. The name newclock3 isn't particularly descriptive but just refers to the name of the repository branch popcornmix uses to group all these patches together.
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.
(2014-04-15, 14:01)host505 Wrote: Tested the same files with 411b and all look proper (aspect-ratio-wise). Again aspect ratio switching doesn't affect actual video but only the masking, I assume this is how it is supposed to work on 3D?

The Pi firmware only allows a single display rectangle to be specified. This allows any zoom mode on a mono image, but only limited zoom modes on stereoscopic.
To handle this when in stereoscopic modes, we disable any custom zoom settings.
This works fine for 16:9 square pixel videos on a 16:9 display (which my collection of 20+ 3D videos all are).
But when this is not true it's hard to handle this correctly.

Last night I bit the bullet, and tried to solve this properly. Basically allowing two zoom rectangles to be specified to firmware.
This should allow all custom zoom modes with 3d contents, including things like viewing SBS video in TAB mode.

I've carefully gone through all the zoom modes on different 3D content using xbmc on windows as a reference and making sure it all matches.
It's looking promising, so hopefully can be pushed out later today.

(I'm still not convinced that all zoom modes possible are sensible. Zooming in to remove black bars for example will change the eye separation and so the depth effect.
But, I think we should match behaviour of xbmc on other platforms).
Nice popcornmix.
What I found odd is all 2.35:1 stereoscopic videos I have is encoded with the black bars to make it look correct, so maybe its a general problem with players based on the same code.

Hmm.. If updating addons manually and there is more than one update and I choose update all, XBMC crashes. Updating them one by one works fine. Anybody else encountered this?
  •   
  • 1
  • 273
  • 274
  • 275
  • 276(current)
  • 277
  •   
  Thread Closed
 
Thread Rating:
  • 23 Vote(s) - 4.48 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 24.4823