(2015-01-02, 02:55)Stereodude Wrote: That's not exactly correct. Consumer electronics gear uses YCbCr 16-235. If you send YCbCr it has to be 16-235. That's the format. CE devices don't use RGB 16-235. RGB is supposed to be 0-255. RGB 16-235 is like a redhead stepchild of video formats. It shouldn't be used, and certainly shouldn't be the default.

(2015-01-01, 22:09)Matt Devo Wrote:

(2015-01-01, 21:33)Veronica Wrote: in kodi OE5.0 you need to uncheck the whole "VAAPI hardware acceleration" option, not only the "prefer VAAPI" one. But OE 5.0 was supposed to have the freeze bug fix (confused).

100% incorrect. VAAPI acceleration and prefer VAAPI renderer should both be checked/enabled. The default/OOTB settings are correct for OE 5.0.0 (stable)

---

(2015-01-01, 19:05)asleulv Wrote: Thanks. Was able to install OE5.0 and added the recommended adjustments to the settings. However I'm still struggling with videos freezing while subtitles and audio continuing. Was hoping this issue would disappear after the update.

Is this the dreaded Intel bug? If so the workaround in the wiki isn't working for me.

1) there is no dreaded intel bug anymore, it is fixed

2) complaining of playback issues without logs is useless

3) this thread is for setup/install related issues involving my EZ setup script. Playback issues belong in the Linux support forum (or OpenELEC forums, if it's OS-related).

(2015-01-02, 11:30)fritsch Wrote:

Code:

mkdir 3.18
cd 3.18
wget http://es.archive.ubuntu.com/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.140_all.deb
sudo dpkg -i *linux-firmware*deb

wget https://dl.dropboxusercontent.com/u/55728161/linux-headers-3.18.1-ickle75%2B_3.18.1-ickle75%2B-10.00.Custom_amd64.deb https://dl.dropboxusercontent.com/u/55728161/linux-image-3.18.1-ickle75%2B_3.18.1-ickle75%2B-10.00.Custom_amd64.deb

sudo dpkg -i *3.18.1*ickle*deb

(2015-01-02, 16:35)movie78 Wrote: Did Anyone using the Standalone boot Chromebox upgrade from OpenElec 4.2.1 to 5.0?

If you did,how did you do it?

Thanks!

(2015-01-02, 12:13)noggin Wrote: Not going to get into a big argument about this, but as a former Broadcast R&D engineer, 16-235 level RGB is also standard in broadcast use, and 4:4:4:4 video which can be RGBK or YCrCbK remains in the 16-235 space whether it is 8 or 10 bit in most broadcast configurations. (There are, of course, now alternative sampling schemes to allow Log capture etc.) You use 16-235 in both RGB and YCrCb to ensure you don't clip <16 and >235 content in your YCrCb (or RGB) source.

Annex 1 Part 2 of the ITU 601 spec (which is the SD broadcast video bible) confirms that 16-235 level space is to be used for RGB digital video, with black levels for both RGB and YCrCb at 8bit digital 16 : http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.601-7-201103-I!!PDF-E.pdf
Part 6 of the ITU 709 spec (which is the HD broadcast video bible) confirms that the same levels are used in both RGB and YCrCb video, with black at 8 bit digital 16. http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.pdf

HDMI for consumer video complies with ITU 601/709 levels, and as such, whether RGB or YCrCb is used 16-235 level space is what you would expect. Just as RGB over HD-SDI is 16-235 level space, so it is over HDMI.

As supplied every HDTV I've ever owned has expected RGB 4:4:4 to be 16-235 by default, as well as 4:2:2 and 4:4:4 YCrCb - for good reason. It's the standard used for video. If it is the default for HDTVs then it makes sense for it to be the default for HDTV resolutions output by Intel GPUs. Otherwise default usage cases would end up with clipped blacks and whites.

You don't use 0-255 in broadcast video (whether you are using YCrCb or RGB representation - and both are used internally in broadcast gear) as you lose sub-black and super-white to ensure that signals that originated in the analogue domain and which may have over/under-shoot on sharp transitions aren't clipped and lost in conversion. This is to avoid ringing, which can occur if you clip overshoot/undershoot content and then resample or filter (such as convert from 1280x720 to 1920x1080). Analogue connectivity is still used in lots of situations for HD production believe it or not, as one of the two dominant camera cabling systems (Triax) is used with analogue connectivity in most (though not all) use cases. It isn't just an issue with archive content (though that is also a very valid reason for not clipping <16 and >235 and is why re-scaling RGB to 0-255 is not routinely used for video)

0-255 RGB is a PC spec (effectively inherited from DVI), 16-235 RGB or YCrCb is the broadcast video spec, and it is the default HDMI level space on consumer gear.

(2015-01-02, 21:14)nickr Wrote:

(2015-01-02, 16:35)movie78 Wrote: Did Anyone using the Standalone boot Chromebox upgrade from OpenElec 4.2.1 to 5.0?

If you did,how did you do it?

Thanks!

Read the 5.0 announcement and backup as suggested, heed all warnings.

Download the 5.0 tar file to your pc.

Transfer it via scp or smb to your chromebox, into the .update folder.

Reboot.

Enjoy.

(2015-01-02, 22:56)movie78 Wrote: Link please.

Thanks!

(2015-01-02, 23:24)Matt Devo Wrote:

(2015-01-02, 22:56)movie78 Wrote: Link please.

Thanks!

srsly? www.openelec.tv

BTW, there will be no support here for issues with 5.0.0 if upgraded from 4.2.1. If you upgrade and things don't work, backup/export etc and do a clean install (or a hard reset).

(2015-01-02, 23:27)movie78 Wrote: I taught there was a different link for the Chromebox release.

Thanks!

(2015-01-02, 23:32)johnnyboy79 Wrote: Tried following everything in the setup and got to step 5. Flashed the custom firmware and when it reboots I do not get an option to boot from USB. It immediately says booting from hard disk... and never goes any further? Any advise or am I totally hosed here?