• 1
  • 240
  • 241
  • 242(current)
  • 243
  • 244
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2014-03-20, 22:52)MrNice Wrote: With full screen I can see the cursor going from left to right. It freeze and sound drops.

Cursor?
When in full screen mode you should see just the visualisation and no GUI elements.
Is anyone of you using the hyperion ambilight plugin withnthese builds? everythin was fine with an early march build 02.03. or so...in the latest builds, hyperion IS working after start, but stops working after few minutes of watching video. any1 here maybe got a clue what might be causing the issue?
(2014-03-20, 22:52)MrNice Wrote: @ 606u
You can download test files here
go to Multi-Channel Examples (WAVE_FORMAT_EXTENSIBLE)
To check channel position
files are 3 and 9 Mo

(2014-03-20, 22:00)popcornmix Wrote:
(2014-03-20, 21:54)MrNice Wrote: Gotham build: #0320b
Both have drops every few seconds

Do the drops go away when running full screen (tab on keyboard)?

Not at all
With full screen I can see the cursor going from left to right. It freeze and sound drops.
Both of multichannel files linked by you plays fine with correct channel mapping. However, due to lack of audio upon start the 1st thing I usually hear is the end of word "center".

BTW where do you store multi-channel files you have drops with? Right now I'm testing with 24-192-2.0 and 24-96-5.1 FLACs from 2L high-res samples and they play perfectly from the SD-card. Writing myself a note to compare CPU utilization with FLAC vs ALAC and locally stored files (SD/USB) vs NFS vs Samba; getting late today, will try to do this tomorrow.
(2014-03-20, 23:19)popcornmix Wrote:
(2014-03-20, 22:52)MrNice Wrote: With full screen I can see the cursor going from left to right. It freeze and sound drops.

Cursor?
When in full screen mode you should see just the visualisation and no GUI elements.

With remote, I play the file then go left to "view options" sliding window then down to "full screen"

Quote:BTW where do you store multi-channel files you have drops with? Right now I'm testing with 24-192-2.0 and 24-96-5.1 FLACs from 2L high-res samples and they play perfectly from the SD-card. Writing myself a note to compare CPU utilization with FLAC vs ALAC and locally stored files (SD/USB) vs NFS vs Samba; getting late today, will try to do this tomorrow.
Files are in a USB case SATA 2.5 HDD
Config, video/audio player:
3T HDD <USB> Odroid N2+ / CoreElec <HDMI> Denon AVR-2313 <HDMI> LG TV 55UF860V
                                          <nfs wired> Linksys WRT32X router <USB> 4T HDD
I have found a way to fix the overscan issue that I was having by adjusting the video settings for the offending channels and selecting zoom amount 1.01. It is all good now.
It seems the Pi is still clipping my black levels, despite setting
hdmi_pixel_encoding=2
in config.txt, which is meant to be RGB Full (0-255). I'm testing with a black clipping pattern showing levels 0-25 and when I play it from a USB stick on my TV, if I increase the brightness the lower bars will show up as grey rather than black but via the RPi, it doesn't change which bars are visible at all. Is there another setting in XBMC which would cause this?

I've also found that with my TV (Panasonic X60B plasma) that playing the pattern via the RPi and setting the brightness to +2 - +4 shows noise/snow (dithering?) all over the picture but playing it via the TV's USB port this doesn't happen. I also see this noise on the XBMC menu background.

EDIT: Another thing I've noticed is that the thumbnails in Videos - Files look like they've had the brightness boosted, so that they look very different to how they do when played. I took these screenshots in the list and with the videos playing to show the difference.

Image

Image

Image

Image
(2014-03-20, 23:19)FattyMcDirty Wrote: Is anyone of you using the hyperion ambilight plugin withnthese builds? everythin was fine with an early march build 02.03. or so...in the latest builds, hyperion IS working after start, but stops working after few minutes of watching video. any1 here maybe got a clue what might be causing the issue?
I am, haven't noticed any issues so far. Have you tried updating Hyperion?
(2014-03-21, 12:38)doveman2 Wrote: It seems the Pi is still clipping my black levels, despite setting
hdmi_pixel_encoding=2
in config.txt, which is meant to be RGB Full (0-255). I'm testing with a black clipping pattern showing levels 0-25 and when I play it from a USB stick on my TV, if I increase the brightness the lower bars will show up as grey rather than black but via the RPi, it doesn't change which bars are visible at all. Is there another setting in XBMC which would cause this?

I've also found that with my TV (Panasonic X60B plasma) that playing the pattern via the RPi and setting the brightness to +2 - +4 shows noise/snow (dithering?) all over the picture but playing it via the TV's USB port this doesn't happen. I also see this noise on the XBMC menu background.

EDIT: Another thing I've noticed is that the thumbnails in Videos - Files look like they've had the brightness boosted, so that they look very different to how they do when played. I took these screenshots in the list and with the videos playing to show the difference.

I think the x60 doesn't support full RGB range. So you should remove hdmi_pixel_encoding=2 and choose from the xbmc settings limited color range [settings/system/video output - enable use limited color range (16-235)].
I'd also suggest setting contrast and brightness at 50 on xbmc and whatever calibration you do do it from tv's menu.
(Panasonic UT30 plasma owner here, everything is good with the above).
(2014-03-21, 15:24)host505 Wrote:
(2014-03-21, 12:38)doveman2 Wrote: It seems the Pi is still clipping my black levels, despite setting
hdmi_pixel_encoding=2
in config.txt, which is meant to be RGB Full (0-255). I'm testing with a black clipping pattern showing levels 0-25 and when I play it from a USB stick on my TV, if I increase the brightness the lower bars will show up as grey rather than black but via the RPi, it doesn't change which bars are visible at all. Is there another setting in XBMC which would cause this?

I've also found that with my TV (Panasonic X60B plasma) that playing the pattern via the RPi and setting the brightness to +2 - +4 shows noise/snow (dithering?) all over the picture but playing it via the TV's USB port this doesn't happen. I also see this noise on the XBMC menu background.

EDIT: Another thing I've noticed is that the thumbnails in Videos - Files look like they've had the brightness boosted, so that they look very different to how they do when played. I took these screenshots in the list and with the videos playing to show the difference.

I think the x60 doesn't support full RGB range. So you should remove hdmi_pixel_encoding=2 and choose from the xbmc settings limited color range [settings/system/video output - enable use limited color range (16-235)].
I'd also suggest setting contrast and brightness at 50 on xbmc and whatever calibration you do do it from tv's menu.
(Panasonic UT30 plasma owner here, everything is good with the above).

Yeah it does, it has the option to set it to Auto, Full or Normal. Auto correctly sets it to the same as Full and Normal is clearly wrong as all the bars from 17-25 are completely black.

Nonetheless I tried removing the hdmi_pixel_encoding setting. After that, I had to manually set the TV RGB mode to Normal as it was still Auto setting it to Full. With the limited range output with the default pixel_encoding settings, obviously that doesn't output anything below 16, so increasing the brightness doesn't make the bars below 16 visible but it should when using hdmi_pixel_encoding=2, which is obviously changing the outputted range but it seems that something further down the chain is cutting off everything below 16.

I haven't even seen any contrast and brightness settings in XBMC, where are those? I also don't see any "enable use limited color range" setting under Settings/System/Video Output.
Delete the hdmi_pixel_encoding=2 line as there already is a setting in xbmc (in Settings/System/Video Output - you need to enable expert mode to see it). Set the tv's setting to full and disable "use limited color range (16-235)" in xbmc.
(2014-03-21, 16:15)host505 Wrote: Delete the hdmi_pixel_encoding=2 line as there already is a setting in xbmc (in Settings/System/Video Output - you need to enable expert mode to see it). Set the tv's setting to full and disable "use limited color range (16-235)" in xbmc.

As I say, I don't see that option and I am in Expert mode (tried switching to Confluence just in case it wasn't visible using xTV-SAF as well).

Anyway, if I delete the config.txt setting then surely the RPi will be set at a low level to output limited range RGB, so I don't see how changing the XBMC could allow full range RGB to be outputted, unless that changes the same hardware setting that the config.txt line does and if that's the case, then surely if I disable the line and enable the setting I'd end up in the same place?
Really sorry for the confusion, I guess I mixed up my pi and my pc setups. You're right there isn't a range option on pi.
So if there is hdmi_pixel_encoding=2 in config.txt and tv is set to full there's something going on, from the pictures it appears that the full range setting is only applied on video playback and not the interface. I don't have a full-range capable tv to test though.
No worries.

It doesn't seem like the full range is being used for video playback though, as if it was I'd be able to see the bars below 16 when I increase the TV brightness, as I can when playing the files via my TV's USB port. What seems to be happening is that the output is being limited, so perhaps that full range setting that is available on the PC is hidden and defaulted to off on the Pi.
(2014-03-21, 18:28)doveman2 Wrote: It doesn't seem like the full range is being used for video playback though, as if it was I'd be able to see the bars below 16 when I increase the TV brightness, as I can when playing the files via my TV's USB port. What seems to be happening is that the output is being limited, so perhaps that full range setting that is available on the PC is hidden and defaulted to off on the Pi.

By default video files are limited range and shouldn't encode levels below 16.
You need a flag in the file (like video_full_range_flag for h264) to be able to encode these levels. Does your file have this set?

If you force a DMT mode (with hdmi_group=2) you will get full range by default. CEA modes will get limited range by default.
The full/limited range flag is correctly output by the Pi (in the AV infoframe), and the display should act on that (without requiring setting in menus on display or using hdmi_pixel_encoding on pi)
In our testing, many TV's only support limited range in CEA modes (which you are probably using at 1080p) and only full range in DMT modes (they are manditory, supporting full range with CEA and limited range with DMT is optional).

But I think all this talk is based on a misunderstanding. Full range does not give you more or better colours.
Assuming all parts are the system (the video file flags, the video player, the HDMI settings and the display) agree on whether they are using full or limited then the picture displayed on the display will be identical.

We have done a lot of testing of feeding encoded bars test files through the system, and using a hdmi capture card to confirm that the levels are correct in the full and limited range modes.
That is the only way to confirm that the Pi is outputting the correct signals. We did find in this testing that some TV's do clamp levels below 16, even when we are signalling full range.
That sounds right, also the test paterns above that doveman2 is running are just to adjust brightness/contrast (assuming all the parts agree on the color range as you said popcornmix) and do not indicate whether limited/full color range is used.
  • 1
  • 240
  • 241
  • 242(current)
  • 243
  • 244
  • 277

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