Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1
  • 138
  • 139
  • 140(current)
  • 141
  • 142
  • 553
Linux ChromeBox Kodi E-Z Setup Script (LibreELEC/Linux+Kodi) [2017/02/21]
I've had good results with H264 2160/24p content VAAPI accelerated on the Chromebox feeding a Sony UHD set via HDMI. Worked pretty well. No hope of HEVC stuff playing though.
Reply
Bought a Chromebox for $100 yesterday to setup for a friend or perhaps I'll keep it for 2nd room . At this price its really attractive and I think the prices will drop soon.

How does Chromwbox compare to Fire Tv w.r.t native hw decoding without transcoding on the server? Do both of them support all the formats?
Reply
Chromebox > FTV Smile. Latter doesn't support VC-1.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
My HT
Reply
AIUI Chromebox does a MUCH better job with interlaced H264 and MPEG2 than Fire TV (or any Android solution) YADIF 2x in main OpenElec builds, and hopefully if the Intel GPU driver bug gets fixed we'll have reliable hardware MA and MC deinterlacing as well (The experimental builds are great on the Chromebox, but the Intel GPU bug means you get hangs)

This is really important if you watch live or recorded TV or interlaced DVD/Blu-ray (as I do)
Reply
Hi, I just got a chromebox today's showed up early. I'm not sure what I'm doing wrong, I booted to developer mode. When I do ctrl-alt-f2 I see the black command screen flicker then goes to where it's asking for my login in on the chrome os.. Please help would like to do a stand alone openelec install.

Thanks
Reply
(2014-11-29, 17:23)noggin Wrote: You are right, it would be good if there were an optional, "Match resolution" as well as "Match Framerate" option. It could be quite complex to implement though - as so much video has non-standard resolutions (where black bars have been cropped for instance). However you could do a bit of an "educated guess" system - and let people check box at what resolution they wanted XBMC to stop scaling?

You could have different settings for "SD" (i.e. content with a horizontal resolution of 1024 or lower?), "720p" (i.e. content with horizontal resolution >1024 but <=1280), "1080" (i.e. content with a horizontal resolution >1280 but <=1920), "Above HD" (i.e. content with a horizontal resolution >1920)? Then you could have "Output at" options for these four genres (So you could chose to output "SD" as 1080p, "720p" as 720p, "1080" as 1080p but "Above HD" as 2160p?)

I know in researching this the XBMC developers have extolled the difficulties of implementing such a system too due to abnormal video sizes, but as you point out, all it really needs is some good forethought put into what to do with what. Have separate settings for SD/480p, 720, 1920 and 4K that can be enabled or disabled (so if you don't enable SD/480p and 720 they're merely scaled to the first enabled one, 1920), do your matching based on vertical or horizontal resolution (to cover things like 1440x1080p or 1920x800p), and after selecting a resolution, match the refresh rate.

About the trickiest part in my mind is dealing with non-square PAR, so you'd probably have to calculate the "effective resolution" first.

Frankly, I'd be happy with a crude patch that just allowed for "whatever's stock" and "UHD/2160" modes.
Reply
(2014-11-30, 01:59)Sunflux Wrote:
(2014-11-29, 17:23)noggin Wrote: You are right, it would be good if there were an optional, "Match resolution" as well as "Match Framerate" option. It could be quite complex to implement though - as so much video has non-standard resolutions (where black bars have been cropped for instance). However you could do a bit of an "educated guess" system - and let people check box at what resolution they wanted XBMC to stop scaling?

You could have different settings for "SD" (i.e. content with a horizontal resolution of 1024 or lower?), "720p" (i.e. content with horizontal resolution >1024 but <=1280), "1080" (i.e. content with a horizontal resolution >1280 but <=1920), "Above HD" (i.e. content with a horizontal resolution >1920)? Then you could have "Output at" options for these four genres (So you could chose to output "SD" as 1080p, "720p" as 720p, "1080" as 1080p but "Above HD" as 2160p?)

I know in researching this the XBMC developers have extolled the difficulties of implementing such a system too due to abnormal video sizes, but as you point out, all it really needs is some good forethought put into what to do with what. Have separate settings for SD/480p, 720, 1920 and 4K that can be enabled or disabled (so if you don't enable SD/480p and 720 they're merely scaled to the first enabled one, 1920), do your matching based on vertical or horizontal resolution (to cover things like 1440x1080p or 1920x800p), and after selecting a resolution, match the refresh rate.

About the trickiest part in my mind is dealing with non-square PAR, so you'd probably have to calculate the "effective resolution" first.

Frankly, I'd be happy with a crude patch that just allowed for "whatever's stock" and "UHD/2160" modes.

Yes - it isn't perfectly straightforward but with some intelligent rules based on horizontal and vertical resolutions AFTER PAR has been taken into account (i.e. equivalent square pixel resolution) you can cope with most things with a couple of rules.

You'd need to cope with 1080p stuff that is very cropped to cinemascope and could have less than 720 lines - but as it has a horizontal size >1280 you could separate it from 720p. Another possibility is a 1440x1080 16:9 non-square HD source that contained a 4:3 pillbox picture so was cropped to 1080x1080 4:3 non-square, and thus had a horizontal size <1280 but as it has a vertical size >720 you can still separate it from 720p content.

SD is probably the hardest to handle - as you have 576i/p and 480i/p outputs to cope with and some interaction between resolution and frame rate to consider. To be honest I'd probably leave content <720p to be upscaled permanently (but that's a personal choice).

I'd prefer to avoid the crude patch - as it would be great to solve the "double scaling" of 720/50p content issue whilst still being able to play 1080p content at full resolution (and without having to change output formats in settings between files)
Reply
(2014-11-30, 02:15)noggin Wrote: Yes - it isn't perfectly straightforward but with some intelligent rules based on horizontal and vertical resolutions AFTER PAR has been taken into account (i.e. equivalent square pixel resolution) you can cope with most things with a couple of rules.

You'd need to cope with 1080p stuff that is very cropped to cinemascope and could have less than 720 lines - but as it has a horizontal size >1280 you could separate it from 720p. Another possibility is a 1440x1080 16:9 non-square HD source that contained a 4:3 pillbox picture so was cropped to 1080x1080 4:3 non-square, and thus had a horizontal size <1280 but as it has a vertical size >720 you can still separate it from 720p content.

SD is probably the hardest to handle - as you have 576i/p and 480i/p outputs to cope with and some interaction between resolution and frame rate to consider. To be honest I'd probably leave content <720p to be upscaled permanently (but that's a personal choice).

I'd prefer to avoid the crude patch - as it would be great to solve the "double scaling" of 720/50p content issue whilst still being able to play 1080p content at full resolution (and without having to change output formats in settings between files)

Yeah, I do agree it's probably okay to resample anything <720p up to 720p. Would eliminate a lot of hassle in dealing with a myriad of NTSC/PAL formats. It would definitely be nice to avoid unneeded resampling of 720p -> 1080p and 720p/1080p -> 2160p, though. The problem is, I don't think this is going to be a dev priority until a bunch of them get 4K televisions of their own and realize how crap the current operation is. :-)
Reply
(2014-11-30, 03:16)Sunflux Wrote:
(2014-11-30, 02:15)noggin Wrote: Yes - it isn't perfectly straightforward but with some intelligent rules based on horizontal and vertical resolutions AFTER PAR has been taken into account (i.e. equivalent square pixel resolution) you can cope with most things with a couple of rules.

You'd need to cope with 1080p stuff that is very cropped to cinemascope and could have less than 720 lines - but as it has a horizontal size >1280 you could separate it from 720p. Another possibility is a 1440x1080 16:9 non-square HD source that contained a 4:3 pillbox picture so was cropped to 1080x1080 4:3 non-square, and thus had a horizontal size <1280 but as it has a vertical size >720 you can still separate it from 720p content.

SD is probably the hardest to handle - as you have 576i/p and 480i/p outputs to cope with and some interaction between resolution and frame rate to consider. To be honest I'd probably leave content <720p to be upscaled permanently (but that's a personal choice).

I'd prefer to avoid the crude patch - as it would be great to solve the "double scaling" of 720/50p content issue whilst still being able to play 1080p content at full resolution (and without having to change output formats in settings between files)

Yeah, I do agree it's probably okay to resample anything <720p up to 720p. Would eliminate a lot of hassle in dealing with a myriad of NTSC/PAL formats. It would definitely be nice to avoid unneeded resampling of 720p -> 1080p and 720p/1080p -> 2160p, though. The problem is, I don't think this is going to be a dev priority until a bunch of them get 4K televisions of their own and realize how crap the current operation is. :-)

Yeah - to be honest I think we have slightly different usage cases. Whilst we remain in the arena where we don't have 2160/50p and 2160/60p output we can't output everything at 2160p and scale everything once in XBMC/Kodi

I'd go with :

SD -> 1080p (Allows 50/60i to 50/60p 2x deinterlace), 720p would probably also be OK (but suspect that will depend on how good the XBMC scaling is)
720p -> 720p (Allows 50/60p and leaves all the scaling to the TV as XBMC could only scale to 1080p and still output 50p/60p, as scaling to 2160p would mean 25p/30p output and halve the frame rate on native 50/60p content)
1080i/p -> 1080p (Again allows 50/60i and 50/60p content to be output at full frame rate)
2160p -> 2160p
Reply
(2014-11-30, 03:24)noggin Wrote: SD -> 1080p (Allows 50/60i to 50/60p 2x deinterlace), 720p would probably also be OK (but suspect that will depend on how good the XBMC scaling is)
720p -> 720p (Allows 50/60p and leaves all the scaling to the TV as XBMC could only scale to 1080p and still output 50p/60p, as scaling to 2160p would mean 25p/30p output and halve the frame rate on native 50/60p content)
1080i/p -> 1080p (Again allows 50/60i and 50/60p content to be output at full frame rate)
2160p -> 2160p

I'd be fine with that, but I could also see a FROM -> TO table being configurable (even if by text file). Honestly, our needs depend on what we watch... I'm in Canada, so the vast majority of what I'm watching is 23.976p material. Surprisingly little 29.97, I almost never have interlaced to deal with, rarely any 59.94/60p (and it's usually 720p), and only occasionally have 25/50p content.

But, I have a TON of 720p and 1080p material and I'd like to leave it at that... even if I want the interface to be 4k, and even if I'd like to be able to play the occasional 4k video too.
Reply
(2014-11-30, 01:37)LilSnoop40 Wrote: Hi, I just got a chromebox today's showed up early. I'm not sure what I'm doing wrong, I booted to developer mode. When I do ctrl-alt-f2 I see the black command screen flicker then goes to where it's asking for my login in on the chrome os.. Please help would like to do a stand alone openelec install.

Thanks

as per the wiki instructions / first post of this thread, login with the user 'chronos' then type the two commands to download and run the script
Reply
I ordered a Fire TV stick for $20. I'm assuming the included remote will work fine with OpenElec on Chromebox since its just a regular HID device? It's a barebones remote and doesn't have too many buttons but I'm guessing its probably enough for XBMC? Would like to hear any thoughts on this vs getting one of the other suggested remotes like MCE or PS3.
Reply
@MrCrispy

Don't need a keyboard then?

Rii I28 keyboard does not work to get in the command prompt menu. But normal use ok.
Logitech K830 does work.
Reply
(2014-11-30, 05:41)MrCrispy Wrote: I ordered a Fire TV stick for $20. I'm assuming the included remote will work fine with OpenElec on Chromebox since its just a regular HID device? It's a barebones remote and doesn't have too many buttons but I'm guessing its probably enough for XBMC? Would like to hear any thoughts on this vs getting one of the other suggested remotes like MCE or PS3.

it should pair just fine; there are keymaps available on these forums for the remote already I believe. whether it's adequate for you really depends on your use cases. I'd try it and see, then pick up something else if it's not functional enough.
Reply
Well I got my ASUS chromebox yesterday and installed Openelec on it to stand alone boot. It must boot to Openelec in 5 seconds. Must say its the smoothest running box I have ever used for XBMC. I have used RPI's and Amazon fire tv's and now this. I just ordered two more that will be here on Tuesday. Highly recommended.

Love it
Reply
  • 1
  • 138
  • 139
  • 140(current)
  • 141
  • 142
  • 553

Logout Mark Read Team Forum Stats Members Help
ChromeBox Kodi E-Z Setup Script (LibreELEC/Linux+Kodi) [2017/02/21]37