2014-04-15, 07:05
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?
(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
(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.
(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.
Quote:[omxplayer] Fix for 3d video in mono mode. The test for no aspect wasn't correct, causing large black bars
(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?