[fritsch]

Code:

mkdir 3.18
cd 3.18
wget https://bugs.launchpad.net/ubuntu/+source/linux-firmware/1.140/+build/6640596/+files/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

[noggin]

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.

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/...!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/...!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.

[asleulv]

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)

---

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

1) Ok, that's good to hear.

2) I agree. So I uploaded my log file after reproducing the error.

3) I did post my problem in the Linux forums and was told to try this thread

Here is the thread with my log file and problem describtion: http://forum.kodi.tv/showthread.php?tid=213314

[movie78]

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!

[wackid]

My update didn't work also. I installed by ez script. That worked. Look like to me the file from Openelec is corrupted or something.

[jtadeia]

I've upgraded to OpenELEC 5.0
Wifi connection is always dropping, it connects sometimes for 1 minute, then goes back again to "State:failure"

Is this happening to anyone else?

Thanks

[rodalpho]

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

I'm personally going to wait for Ubuntu rather than installing a custom kernel from a dropbox link (it came from you so I'm sure it's fine, but still just not comfortable), but thanks for the instructions.

[kenz]

Just curious do you think this could be used to run XBMC with out the dual boot?

http://www.itworld.com/article/2864156/r...ebook.html

[nickr]

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.

[Stereodude]

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/...!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/...!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.

I didn't say RGB 16-235 wasn't a standard. I said it wasn't used by Consumer Electronics (CE) equipment. CE devices send out YCrCb (16-235) for HDMI video. If they support anything else it's not the default and you have to go tinkering around in menus to change it.

My experience is very different from yours. All the HDTV's I've used treat RGB 0-255 as the normal case, and RGB 16-235 as the odd case (if they even support RGB 16-235). This is because CE devices send out YCrCb and when the TVs see a RGB signal they assume they are being fed by a computer which sends out 0-255. Further, digital displays natively are almost all RGB. Internally, after all their processing, they send RGB 0-255 to the DACs/TCONs/drivers (unless they're >8bit displays). Expanding RGB 16-235 to RGB 0-255 somewhere downstream of the color space conversion is a great way to get banding/posterization. Converting YCrCb (16-235) directly to RGB 0-255 gives better visual results than converting YCrCb (16-235) to RGB 16-235 and having your display turn it into RGB 0-255 due to the floating point math used in the color space conversion and the way the floating point values can be mapped to any target level range or bit depth. You get no such luxury converting RGB 16-235 to RGB 0-255.

Since the Chromebox is a computer and OpenELEC does not default to YCrCb playing back videos in their native color space and chroma format I stand by my contention that it should output RGB 0-255 by default for the best video quality, not RGB 16-235.

[movie78]

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.

Link please.

Thanks!

[Matt Devo]

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

[movie78]

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

I taught there was a different link for the Chromebox release.

Thanks!

[johnnyboy79]

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?

[Matt Devo]

I taught there was a different link for the Chromebox release.

Thanks!

there hasn't been a custom release since 4.1.3 beta. The ChromeBox uses the standard Generic x86_64 OpenELEC release, as per the wiki

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?

my advice would be to read the wiki and employ the suggestions listed there for your exact situation